RFC 5488
Network Mobility (NEMO) Management Information Base
RFC 5488: Network Mobility (NEMO) Management Information Base 🦋
okay bestie, RFC 5488 is giving network management for mobile networks 🌸. It's a Standards Track document from April 2009 in the Network Working Group, and the authors are S. Gundavelli (Cisco), G. Keeni (Cyber Solutions), K. Koide (KDDI CORPORATION), and K. Nagami (INTEC NetCore). Its title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨.
Status of This Memo 📝
this one is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬. If you want to know where it currently sits in standardization, check the latest edition of the "Internet Official Protocol Standards" (STD 1) 🔍. Distribution of this memo is unlimited, so it's fully shareable 💕.
Copyright Notice ⚖️
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 🔒. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they stood on the date this document was published (http://trustee.ietf.org/license-info). Please read those carefully, because they spell out your rights and restrictions for this document 📜.
Abstract 🌈
this memo defines a chunk of the Management Information Base (MIB), specifically the Network Mobility (NEMO) support MIB, and it's meant to be used with network management protocols across the Internet community 💜. The main point is that the NEMO MIB is how you monitor and control a Mobile IPv6 node that has NEMO functionality 🧚.
Table of Contents 📚
1. The Internet-Standard Management Framework ......................2
2. Overview ........................................................2
2.1. The Mobile IPv6 Protocol and NEMO Entities .................2
2.2. Relationship to Other MIB Modules ..........................3
2.3. Terminology ................................................3
2.4. MIB Design .................................................3
3. The NEMO MIB ....................................................4
4. IANA Considerations ............................................41
5. Security Considerations ........................................41
6. Acknowledgments ................................................42
7. References .....................................................42
7.1. Normative References ......................................42
7.2. Informative References ....................................431. The Internet-Standard Management Framework ✨
if you want the full tea on the current Internet-Standard Management Framework, go check section 7 of RFC 3410 [RFC3410] 📖. Managed objects get accessed through a virtual information store called the Management Information Base, or MIB 🗄️. MIB objects are usually accessed through the Simple Network Management Protocol (SNMP) 📡. Objects in the MIB are defined with the mechanisms from the Structure of Management Information (SMI) 🧩. This memo specifies a MIB module that is compliant with SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580] 💅.
2. Overview 🦋
2.1. The Mobile IPv6 Protocol and NEMO Entities 🌸
Mobile IPv6 (MIPv6) [RFC3775] is the protocol that lets nodes stay reachable while they move around the IPv6 Internet 🚶♀️. The Network Mobility (NEMO) Basic Support Protocol [RFC3963] is an extension to Mobile IPv6 that makes it possible for an entire network to move 🚌. The goals of Network Mobility support are discussed in [RFC4886], and the related terminology is in [RFC4885] 📚.
Typically, mobile routers implement NEMO functionality to get network mobility going 🛜. A mobile router can also act as a mobile node, though 👀. In this document, any entity that implements the NEMO protocol is called a NEMO entity 🫶.
This document defines a set of managed objects (MOs) that you can use to monitor and control NEMO entities 🎀.
2.2. Relationship to Other MIB Modules 💕
this document is focused on managing a NEMO entity 💖. It's assumed that implementations will support the ifTable from the IF-MIB [RFC2863] 🧃. The MOBILEIPV6-MIB [RFC4295] defines the managed objects for a mobile node 📱. Implementations that support both mobile node and NEMO functionality SHOULD implement the managed objects defined for NEMO entities and mobile nodes from both the MOBILEIPV6-MIB and the NEMO-MIB 🙌. The NEMO-MIB uses the textual conventions defined in the INET-ADDRESS-MIB [RFC4001] 🧠.
2.3. Terminology 🔤
the terminology here lines up with the definitions in the Mobile IPv6 protocol specification [RFC3775] and the NEMO Basic Support specification [RFC3963] ✨.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] 🫶. Yes, these are the official BCP 14 key words, so read them with their full weight 💅.
2.4. MIB Design 🧩
the NEMO MIB is made up of these groups of definitions 🍓:
nemoCore: a generic group with objects that are shared by all NEMO entities 🌈.nemoHa: this group models the home agent service 🏠. It has objects for the services and their advertisement parameters that the home agent offers on each of its links 📣. It also holds objects for maintaining the home agent list on each link where the service is offered 📋.nemoMr: this group models the mobile router service 🚐. It has objects for the Dynamic Home Agent discovery function and its related parameters 🔎. It also has objects that record the mobile router's movement 🗺️.nemoNotifications: defines the set of notifications used to monitor NEMO entities asynchronously 🔔.
The tables inside the groups above are:
nemoBindingCacheTable: models the Binding Cache on the home agent and correspondent node 🗃️. It has details on the Binding Update requests that were received and accepted 💌.nemoMrEgressIfTable: holds information about the configured egress interfaces 🚪.nemoMrBLTable: models the Binding Update List on the mobile router 📒. It has info about the registration requests the mobile router sent, plus the matching results 🎯.nemoHaCounterTable: holds registration statistics for every mobile router registered with the home agent 📊.nemoHaMobileNetworkPrefixTable: holds the list of mobile network prefixes that the home agent maintains 🌐.
3. The NEMO MIB 💜
NEMO-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, mib-2, Unsigned32, Counter32,
Gauge32,
OBJECT-TYPE, NOTIFICATION-TYPE
FROM SNMPv2-SMI
TEXTUAL-CONVENTION,
TruthValue, DateAndTime, TimeStamp
FROM SNMPv2-TC
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF
InetAddressType, InetAddress, InetAddressPrefixLength
FROM INET-ADDRESS-MIB
InterfaceIndex
FROM IF-MIB
mip6BindingHomeAddressType, mip6BindingHomeAddress,
mip6MnBLEntry, mip6BindingCacheEntry,
mip6MnBLCOAType, mip6MnBLCOA
FROM MOBILEIPV6-MIB
;
nemoMIB MODULE-IDENTITY
LAST-UPDATED "200903100000Z" -- 10 March 2009
ORGANIZATION "IETF MEXT Working Group"
CONTACT-INFO
" Sri Gundavelli
Postal: Cisco
170 W.Tasman Drive,
San Jose, CA 95134
USA
Tel: +1-408-527-6109
Email: sgundave@cisco.com
Glenn Mansfield Keeni
Postal: Cyber Solutions Inc.
6-6-3, Minami Yoshinari
Aoba-ku, Sendai, Japan 989-3204.
Tel: +81-22-303-4012
Fax: +81-22-303-4015
E-mail: glenn@cysols.com
Kenichi Nagami
Postal: INTEC NetCore Inc.
1-3-3, Shin-suna
Koto-ku, Tokyo, 135-0075
Japan
Tel: +81-3-5665-5069
E-mail: nagami@inetcore.com
Kazuhide Koide
Postal: KDDI CORPORATION
GARDEN AIR TOWER 3-10-10, Iidabashi
Chiyoda-ku, Tokyo, 102-8460 Japan
Tel: +81-3-6678-3378
E-mail: ka-koide@kddi.com
Support Group E-mail: mext@ietf.org
"
DESCRIPTION
"Copyright (c) 2009 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with
or without modification, are permitted provided that the
following conditions are met:
- Redistributions of source code must retain the above
copyright notice, this list of conditions and the
following disclaimer.
- Redistributions in binary form must reproduce the
above copyright notice, this list of conditions and
the following disclaimer in the documentation and/or
other materials provided with the distribution.
- Neither the name of Internet Society, IETF or IETF
Trust, nor the names of specific contributors, may be
used to endorse or promote products derived from this
software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
This version of this MIB module is part of RFC 5488;
see the RFC itself for full legal notices."
REVISION "200903100000Z" -- 10 March 2009
DESCRIPTION "Initial version, published as RFC 5488."
::= { mib-2 184 }
-- The NEMO MIB has the following primary groupsOkay, bestie, we're diving into the actual MIB bits now 🧚💖 Here's the OID tree that hangs everything off nemoMIB, with the sub-groups sorted underneath 🌸
nemoNotifications OBJECT IDENTIFIER ::= { nemoMIB 0 }
nemoObjects OBJECT IDENTIFIER ::= { nemoMIB 1 }
nemoConformance OBJECT IDENTIFIER ::= { nemoMIB 2 }
nemoCore OBJECT IDENTIFIER ::= { nemoObjects 1 }
nemoMr OBJECT IDENTIFIER ::= { nemoObjects 2 }
nemoCn OBJECT IDENTIFIER ::= { nemoObjects 3 }
nemoHa OBJECT IDENTIFIER ::= { nemoObjects 4 }
-- The sub groups
nemoSystem OBJECT IDENTIFIER ::= { nemoCore 1 }
nemoBindings OBJECT IDENTIFIER ::= { nemoCore 2 }
nemoConfiguration OBJECT IDENTIFIER ::= { nemoCore 3 }
nemoStats OBJECT IDENTIFIER ::= { nemoCore 4 }
nemoMrSystem OBJECT IDENTIFIER ::= { nemoMr 1 }
nemoMrConf OBJECT IDENTIFIER ::= { nemoMr 2 }
nemoMrRegistration OBJECT IDENTIFIER ::= { nemoMr 3 }
nemoMrGlobalStats OBJECT IDENTIFIER ::= { nemoMr 4 }
nemoHaAdvertisement OBJECT IDENTIFIER ::= { nemoHa 1 }
nemoHaStats OBJECT IDENTIFIER ::= { nemoHa 2 }
nemoHaRegistration OBJECT IDENTIFIER ::= { nemoHa 3 }
nemoHaGlobalStats OBJECT IDENTIFIER ::= { nemoHaStats 1 }Next up are the textual conventions, which are basically reusable type definitions. This one is the rejection code you get back in a Binding Acknowledgment when a Binding Update gets turned down for NEMO-specific reasons 🙈🔥
-- Textual Conventions
NemoBURequestRejectionCode ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The value of the status field in the Binding
Acknowledgment message when the Binding Update
was rejected for NEMO-specific reasons.
"
REFERENCE
"RFC 3963: Section 4.2"
SYNTAX INTEGER {
mobileRouterOperationNotPermitted (140),
invalidPrefix (141),
notAuthorizedForPrefix (142),
forwardingSetupFailed (143)
}Now the nemoSystem group, where the capabilities and the on/off switch live, plus the counter discontinuity timestamp in the stats group ✨
--
--
-- nemoSystem group
--
--
nemoCapabilities OBJECT-TYPE
SYNTAX BITS {
mobileRouter (0),
homeAgentSupport (1)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the NEMO functions that
are supported by this managed entity. Multiple
NEMO functions may be supported by a single
entity.
"
REFERENCE
"RFC 3963: Section 3"
::= { nemoSystem 1 }
nemoStatus OBJECT-TYPE
SYNTAX INTEGER { enabled(1), disabled(2) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object indicates whether the NEMO
function is enabled for the managed entity. If it
is enabled, the agent discovery and registration
functions will be operational.
Changing the status from enabled(1) to disabled(2)
will terminate the agent discovery and registration
functions. On the other hand, changing the status
from disabled(2) to enabled(1) will start the agent
discovery and registration functions.
The value of this object MUST remain unchanged
across reboots of the managed entity.
"
::= { nemoSystem 2 }
nemoCounterDiscontinuityTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime on the most recent occasion at
which any one or more of this NEMO entity's counters,
viz., counters with OID prefix 'nemoMrConf',
'nemoMrRegnCounters', 'nemoMrGlobalStats', or
'nemoHaGlobalStats', suffered a discontinuity. If
no such discontinuities have occurred since the last
re-initialization of the local management subsystem,
then this object will have a zero value.
"
::= { nemoStats 1 }Onto the nemoConfiguration group, which starts with the mobile router's Binding Update List table. Each row is a binding the mobile router has set up or is still trying to set up 🦋
--
--
-- nemoConfiguration group
--
--
nemoMrBLTable OBJECT-TYPE
SYNTAX SEQUENCE OF NemoMrBLEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table corresponds to the Binding Update List
(BL) that includes NEMO-related information and that
is maintained by the mobile router. The table
holds a row for every binding that the mobile
router has established or is trying to establish.
Entries from the table are deleted as the lifetime
of the binding expires.
"
REFERENCE
"RFC 3775: Sections 4.5, 11.1
RFC 3963: Section 5.2"
::= { nemoMrRegistration 1 }
nemoMrBLEntry OBJECT-TYPE
SYNTAX NemoMrBLEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry pertaining to NEMO-related information
contained in a Binding Update sent by a NEMO-enabled
mobile router to its home agent.
"
AUGMENTS {mip6MnBLEntry}
::= { nemoMrBLTable 1 }
NemoMrBLEntry ::= SEQUENCE {
nemoMrBLMode INTEGER,
nemoMrBLMrFlag TruthValue,
nemoMrBLHomeAddressPrefixLength InetAddressPrefixLength,
nemoMrBLCareofAddressPrefixLength InetAddressPrefixLength,
nemoMrBLActiveEgressIfIndex InterfaceIndex,
nemoMrBLEstablishedHomeTunnelIfIndex InterfaceIndex
}
nemoMrBLMode OBJECT-TYPE
SYNTAX INTEGER {
implicitMode (1),
explicitMode (2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"implicitMode(1): the Mobile Network Prefix Option
is not included in the Binding Update by the mobile
router.
explicitMode(2): the mobile router included one or
more Mobile Network Prefix Options in the Binding
Update.
"
REFERENCE
"RFC 3963: Section 5.2"
::= { nemoMrBLEntry 1 }
nemoMrBLMrFlag OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"true(1): the mobile router sent the Binding Update
with Mobile Router Flag set.
false(2): the mobile router did not send the Binding
Update with Mobile Router Flag set. This implies that
the mobile router is acting as a mobile node.
"
REFERENCE
"RFC 3963: Sections 4.1, 5.1"
::= { nemoMrBLEntry 2 }
nemoMrBLHomeAddressPrefixLength OBJECT-TYPE
SYNTAX InetAddressPrefixLength
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The prefix length of the mobile router's home network.
"
REFERENCE
"RFC 3963: Section 3"
::= { nemoMrBLEntry 3 }
nemoMrBLCareofAddressPrefixLength OBJECT-TYPE
SYNTAX InetAddressPrefixLength
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The prefix length of the care-of address of the
mobile router.
"
REFERENCE
"RFC 3963: Section 3"
::= { nemoMrBLEntry 4 }
nemoMrBLActiveEgressIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The interface index of the currently active
egress interface.
"
REFERENCE
"RFC 3963: Section 5.5"
::= { nemoMrBLEntry 5 }
nemoMrBLEstablishedHomeTunnelIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The interface index of the tunnel established
between the mobile router and the home agent
for NEMO traffic.
"
REFERENCE
"RFC 3963: Section 5.5"
::= { nemoMrBLEntry 6 }Last bit for now: the mobile router registration counters, plus the registration mode knob that decides how mobile network prefixes get sent to the home agent 💅✨
-- Mobile Router Registration Group Counters
nemoMrRegnCounters OBJECT IDENTIFIER ::= { nemoMrRegistration 2 }
nemoMrMobilityMessagesSent OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of mobility messages, i.e., IPv6
datagrams with Mobility Header, sent by the mobile
node. This will include Binding Updates sent by a
mobile router with the Mobile Router Flag set.
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoCounterDiscontinuityTime.
"
REFERENCE
"RFC 3775: Sections 4.2, 6.1
RFC 3963: Section 4.1"
::= { nemoMrRegnCounters 1 }
nemoMrMobilityMessagesRecd OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of mobility messages, i.e., IPv6
datagrams with Mobility Header, received by the
mobile node. This will include Binding
Acknowledgements with Mobile Router Flag set that
are sent to a mobile router.
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoCounterDiscontinuityTime.
"
REFERENCE
"RFC 3775: Sections 4.2, 6.1
RFC 3963: Sections 4.1, 4.2"
::= { nemoMrRegnCounters 2 }
nemoMrPrefixRegMode OBJECT-TYPE
SYNTAX INTEGER {
implicitMode (1),
explicitMode (2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object indicates the mode in which the mobile
network prefixes will be registered with the home
agent.
implicitMode(1): the Mobile Network Prefix Option will
not be included in the Binding Update by the mobile
router.
explicitMode(2): the mobile router will include one or
more Mobile Network Prefix Options in the Binding
Update.
The value of this object MUST remain unchanged
across reboots of the managed entity.
"
REFERENCE
"RFC 3963: Section 5.2"
::= { nemoMrRegistration 3 }Okay bestie, we're picking up right where the MIB gets into the home agent's mobile network prefix table 💖 Here's the first chunk of the table definitions 🎀
nemoHaMobileNetworkPrefixTable OBJECT-TYPE
SYNTAX SEQUENCE OF NemoHaMobileNetworkPrefixEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains the mobile network prefixes
that the home agent maintains for the mobile router.
The mobile network prefixes in this table are
registered by Binding Updates or are manually
pre-configured.
"
REFERENCE
"RFC 3963: Section 6.1.2"
::= { nemoHaRegistration 1 }
nemoHaMobileNetworkPrefixEntry OBJECT-TYPE
SYNTAX NemoHaMobileNetworkPrefixEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry for a mobile network prefix.
The instances of the columnar objects in this entry
pertain to an interface for a particular value of
mip6BindingHomeAddressType, mip6BindingHomeAddress,
and nemoHaMobileNetworkPrefixSeqNo.
The nemoHaMobileNetworkPrefixSeqNo object is used to
distinguish between multiple instances of
the mobile network prefix in the same Binding Update
for the same set of mip6BindingHomeAddressType and
mip6BindingHomeAddress.
There is no upper-bound on the maximum number of
mobile network prefixes in a Binding Update but, for
practical purposes, the upper bound of the value
nemoHaMobileNetworkPrefixSeqNo is set to 1024.
Implementers need to be aware that if the total
number of octets in mip6BindingHomeAddress
exceeds 112, then OIDs of column
instances in this row will have more than 128
sub-identifiers and cannot be accessed using
SNMPv1, SNMPv2c, or SNMPv3.
"
INDEX { mip6BindingHomeAddressType,
mip6BindingHomeAddress,
nemoHaMobileNetworkPrefixSeqNo
}
::= { nemoHaMobileNetworkPrefixTable 1 }
NemoHaMobileNetworkPrefixEntry ::= SEQUENCE {
nemoHaMobileNetworkPrefixSeqNo Unsigned32,
nemoHaMobileNetworkPrefixType InetAddressType,
nemoHaMobileNetworkPrefix InetAddress,
nemoHaMobileNetworkPrefixLength Unsigned32,
nemoHaMobileNetworkPrefixSource INTEGER
}So the table itself holds the mobile network prefixes the home agent keeps for each mobile router, and they come in via Binding Updates or get set up by hand 🧚 Each row is its own little main character 👑 and the entry's index is the combo of the home address type, the home address, and a sequence number, so you can tell apart several prefixes that all ride in the same Binding Update 💅 There's no hard upper limit on prefixes per Binding Update, but the sequence number tops out at 1024 for practical reasons, and heads up, if the home address gets really long (more than 112 octets), the OIDs blow past 128 sub-identifiers and SNMPv1, SNMPv2c, and SNMPv3 can't reach them 😭
nemoHaMobileNetworkPrefixSeqNo OBJECT-TYPE
SYNTAX Unsigned32 (1..1024)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A Binding Update may have multiple mobile network
prefixes.
This object, along with mip6BindingHomeAddressType
and mip6BindingHomeAddress, uniquely identifies a
row containing a single mobile network prefix for
a mobile router in this table.
"
REFERENCE
"RFC 3963: Sections 2, 6.1, 6.2"
::= { nemoHaMobileNetworkPrefixEntry 1 }
nemoHaMobileNetworkPrefixType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The address type for the mobile network prefix
that follows.
"
::= { nemoHaMobileNetworkPrefixEntry 2 }
nemoHaMobileNetworkPrefix OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A mobile network prefix related to the
corresponding Binding Update.
The type of the address represented by this object
is specified by the corresponding
nemoHaMobileNetworkPrefixType object.
"
REFERENCE
"RFC 3963: Sections 2, 6.1, 6.2"
::= { nemoHaMobileNetworkPrefixEntry 3 }
nemoHaMobileNetworkPrefixLength OBJECT-TYPE
SYNTAX Unsigned32 (0..128)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The length of the prefix specified by the corresponding
nemoHaMobileNetworkPrefix object.
"
REFERENCE
"RFC 3963: Sections 4.3, 6.1, 6.2"
::= { nemoHaMobileNetworkPrefixEntry 4 }
nemoHaMobileNetworkPrefixSource OBJECT-TYPE
SYNTAX INTEGER {
configured (1),
bindingUpdate (2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The information source of the mobile network prefix
configured with the Binding Update.
configured(1): indicates that the mobile network prefix
has been manually pre-configured.
bindingUpdate(2): indicates that the information is
introduced to the home agent by the Mobile Network
Prefix Option in the Binding Updates received by the
home agent.
"
REFERENCE
"RFC 3963: Sections 4.3, 6.1, 6.2"
::= { nemoHaMobileNetworkPrefixEntry 5 }Those columns are the good stuff ✨ The sequence number picks out one prefix per row, the type and prefix tell you what the address looks like, the length says how long the prefix is (0 to 128, no cap), and the source column says whether the prefix was manually configured or came in through a Mobile Network Prefix Option in a Binding Update 🌸
nemoBindingCacheTable OBJECT-TYPE
SYNTAX SEQUENCE OF NemoBindingCacheEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table models the Binding Cache that includes
NEMO-related information and that is maintained by the
home agent. Entries in this table are not required
to survive a reboot of the home agent.
"
REFERENCE
"RFC 3775: Sections 4.5, 9.1, 10.1,
RFC 3963: Section 6.1"
::= { nemoBindings 1 }
nemoBindingCacheEntry OBJECT-TYPE
SYNTAX NemoBindingCacheEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry containing additional information related
to NEMO-enabled entries in the Binding Cache table
of the home agent.
"
AUGMENTS {mip6BindingCacheEntry}
::= { nemoBindingCacheTable 1 }
NemoBindingCacheEntry ::= SEQUENCE {
nemoBindingMrFlag TruthValue,
nemoBindingMrMode INTEGER
}
nemoBindingMrFlag OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"true(1): indicates that the Binding Cache entry is from
an entity acting as a mobile router.
false(2): implies that the Binding Cache entry is from
an entity acting as a mobile node.
"
REFERENCE
"RFC 3963: Sections 6.1.1, 6.2"
::= { nemoBindingCacheEntry 1 }
nemoBindingMrMode OBJECT-TYPE
SYNTAX INTEGER {
implicitMode(1),
explicitMode(2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"implicitMode(1): the Mobile Network Prefix Option is
not included in the Binding Update by the mobile
router.
explicitMode(2): the mobile router included one or
more Mobile Network Prefix Options in the Binding
Update.
"
REFERENCE
"RFC 3963: Sections 5.2, 6.1.1, 6.2"
::= { nemoBindingCacheEntry 2 }Now we're in the Binding Cache zone 🦋 This table is the NEMO-flavoured extra info the home agent keeps, and it augments the regular mip6 Binding Cache entry, so each NEMO row hangs off a standard one 🧁 Heads up: entries here don't have to survive a home agent reboot, so don't panic if they vanish after a restart 🙈 The flag tells you whether the entry belongs to a mobile router (true) or a mobile node (false), and the mode tells you whether the mobile router sent the Mobile Network Prefix Option in its Binding Update (explicit) or didn't (implicit) 💜
--
-- nemoMrEgressIfTable
--
nemoMrEgressIfTable OBJECT-TYPE
SYNTAX SEQUENCE OF NemoMrEgressIfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table representing the egress interfaces that
will be used by the mobile router for roaming to
foreign networks. Each entry in this table
represents a configured egress interface.
"
::= { nemoMrSystem 1 }
nemoMrEgressIfEntry OBJECT-TYPE
SYNTAX NemoMrEgressIfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the egress interface table. It
represents a single egress interface entry.
"
INDEX { nemoMrEgressIfIndex }
::= { nemoMrEgressIfTable 1 }
NemoMrEgressIfEntry ::=
SEQUENCE {
nemoMrEgressIfIndex InterfaceIndex,
nemoMrEgressIfPriority Unsigned32,
nemoMrEgressIfDescription SnmpAdminString,
nemoMrEgressIfRoamHoldDownTime Gauge32
}
nemoMrEgressIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The index of the interface on the mobile router.
"
::= { nemoMrEgressIfEntry 1 }
nemoMrEgressIfPriority OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The priority configured to the egress interface.
This value will be configured to a value between 0
and 255.
"
::= { nemoMrEgressIfEntry 2 }
nemoMrEgressIfDescription OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A human-readable textual description of the egress
interface on the mobile router.
"
::= { nemoMrEgressIfEntry 3 }
nemoMrEgressIfRoamHoldDownTime OBJECT-TYPE
SYNTAX Gauge32
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the time for which the
egress interface will be held down during roaming
to avoid interface flapping.
"
::= { nemoMrEgressIfEntry 4 }On the mobile router side, the egress interface table is the list of interfaces the mobile router uses when it roams to foreign networks 🚀 Each row is one configured egress interface, with its index, a priority from 0 to 255, a human-readable description, and a roam hold-down time in seconds, which says how long the interface stays down while roaming so it doesn't flap around like a dramatic ex 😂
nemoMrDiscoveryRequests OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Total number of Modified Dynamic Home Agent Address
Discovery Requests, with Mobile Router Support Flag
set, sent by the mobile router.
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoCounterDiscontinuityTime.
"
REFERENCE
"RFC 3775: Sections 10.5, 11.4.1
RFC 3963: Section 7.1"
::= { nemoMrConf 1 }
nemoMrDiscoveryReplies OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Total number of Modified Dynamic Home Agent Address
Discovery Replies, with Mobile Router Support Flag
set, received by the mobile router.
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoCounterDiscontinuityTime.
"
REFERENCE
"RFC 3775: Sections 10.5, 11.4.1
RFC 3963: Section 7.2"
::= { nemoMrConf 2 }Last up for this batch are the two discovery counters 🎀 The requests counter tallies the Modified Dynamic Home Agent Address Discovery Requests the mobile router sends (with the Mobile Router Support Flag set), and the replies counter tallies the matching replies it receives. Both can reset when the management system re-initializes, or whenever nemoCounterDiscontinuityTime says so, so keep that in mind when you're reading the numbers 📊✨
Okay so the mobile router's counters are up next, and they're giving detective energy 🕵️♀️✨
Our first one is nemoMrDiscoveryRepliesRouterFlagZero. It counts the Modified Dynamic Home Agent Address Discovery Replies that came back with the Mobile Router Support Flag set to 0, even though the request had it set to 1. Basically, that means there's no home agent in the home network that supports mobile router stuff 🥺
nemoMrDiscoveryRepliesRouterFlagZero OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Total number of Modified Dynamic Home Agent Address
Discovery Replies, with Mobile Router Support Flag set
to 0 although the flag in the corresponding request
is set to 1. It implies that there is no home agent
that supports mobile router functionality in the home
network.
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoCounterDiscontinuityTime.
"
REFERENCE
"RFC 3775: Sections 10.5, 11.4.1
RFC 3963: Section 7.2"
::= { nemoMrConf 3 }Next up is nemoMrMovedHome, which counts how many times the mobile router notices it has moved from a foreign network back to its home network 🏠💜
nemoMrMovedHome OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of times the mobile router has detected
movement from a foreign network to its home
network.
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoCounterDiscontinuityTime.
"
REFERENCE
"RFC 3963: Section 3"
::= { nemoMrConf 4 }nemoMrMovedOutofHome is the opposite move. It tallies the times the mobile router detects that it has left the home network for a foreign one, gets a care-of address, and kicks off the care-of address registration process 🧳✈️
nemoMrMovedOutofHome OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of times the mobile router has detected
movement to a foreign network from the home
network, has acquired a care-of address, and
has initiated the care-of address registration
process.
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoCounterDiscontinuityTime.
"
REFERENCE
"RFC 3963: Section 3"
::= { nemoMrConf 5 }Now nemoMrMovedFNtoFN, which counts hops between two foreign networks. The original is really particular that "movement" here means layer 3, so the care-of address changed and the registration process ran. It also counts the total across all egress interfaces, but the mobile entity's movement as a mobile node isn't counted 🌐💅
nemoMrMovedFNtoFN OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of times the mobile router has detected
movement to/from a foreign network from/to another
foreign network. Note that 'movement' implies
movement in layer 3, i.e., the mobile router's care-of
address changed, and it initiated the care-of address
registration process.
If there are multiple egress interfaces, this counter
counts the total number of movements. The movement
as a mobile node of the mobile entity is not counted.
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoCounterDiscontinuityTime.
"
REFERENCE
"RFC 3963: Section 3"
::= { nemoMrConf 6 }nemoMrBetterIfDetected counts how many times the NEMO entity found an egress interface with better priority 🌿✨
nemoMrBetterIfDetected OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of times the NEMO entity has found an egress
interface with better priority.
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoCounterDiscontinuityTime.
"
::= { nemoMrConf 7 }Okay, now we get into the global stats for the mobile router 🌸 These are all Binding Acknowledgement counters, and each one is for one specific status code. Let's go 💖
--
-- nemoStats:nemoMrGlobalStats
--
nemoMrBindingAcksWONemoSupport OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of Binding Acknowledgements without
NEMO support received by the mobile router.
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoCounterDiscontinuityTime.
"
REFERENCE
"RFC 3963: Section 5.3"
::= { nemoMrGlobalStats 1 }
nemoMrBindingAcksRegTypeChangeDisallowed OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of Binding Acknowledgements
received by the mobile router with status code
indicating 'Registration type change disallowed'
(Code 139).
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoCounterDiscontinuityTime.
"
REFERENCE
"RFC 3775: Section 9.5.1
RFC 3963: Section 6.2"
::= { nemoMrGlobalStats 2 }
nemoMrBindingAcksOperationNotPermitted OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of Binding Acknowledgements
received by the mobile router with status code
indicating 'Mobile Router Operation not permitted'
(Code 140).
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoCounterDiscontinuityTime.
"
REFERENCE
"RFC 3963: Section 6.6"
::= { nemoMrGlobalStats 3 }
nemoMrBindingAcksInvalidPrefix OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of Binding Acknowledgements
received by the mobile router with status code
indicating 'Invalid Prefix' (Code 141).
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoCounterDiscontinuityTime.
"
REFERENCE
"RFC 3963: Section 6.6"
::= { nemoMrGlobalStats 4 }
nemoMrBindingAcksNotAuthorizedForPrefix OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of Binding Acknowledgements
received by the mobile router with status code
indicating 'Not Authorized for Prefix' (Code 142).
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoCounterDiscontinuityTime.
"
REFERENCE
"RFC 3963 : Section 6.6"
::= { nemoMrGlobalStats 5 }
nemoMrBindingAcksForwardingSetupFailed OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of Binding Acknowledgements
received by the mobile router with status code
indicating 'Forwarding Setup failed' (Code 143).
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoCounterDiscontinuityTime.
"
REFERENCE
"RFC 3963: Section 6.6"
::= { nemoMrGlobalStats 6 }
nemoMrBindingAcksOtherError OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of Binding Acknowledgements
received by the mobile router (Mobile Router Flag is
set) with status code other than:
successfully processed --(Code 0 )
mobileRouterOperationNotPermitted (140) --(Code 140)
invalidPrefix (141) --(Code 141)
notAuthorizedForPrefix (142) --(Code 142)
forwardingSetupFailed (143) --(Code 143)
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoCounterDiscontinuityTime.
"
REFERENCE
"RFC 3963 : Section 6.6"
::= { nemoMrGlobalStats 7 }Last but not least, we hit the home agent's global stats 🏡🧚 These are the Binding Acknowledgement counters from the home agent's side, and the first two are a little different from the mobile router ones.
--
-- nemoStats:nemoHaGlobalStats
--
nemoHaBUAcksWONemoSupport OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of Binding Acknowledgements
without NEMO support sent by the home agent.
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoCounterDiscontinuityTime.
"
REFERENCE
"RFC 3963: Section 5.3"
::= { nemoHaGlobalStats 1 }
nemoHaBUAcksRegTypeChangeDisallowed OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of Binding Update requests
rejected by the home agent with status code
in the Binding Acknowledgement indicating
'Registration type change disallowed' (Code 139).
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoCounterDiscontinuityTime.
"
REFERENCE
"RFC 3775: Section 9.5.1
RFC 3963: Section 6.2"
::= { nemoHaGlobalStats 2 }
nemoHaBUAcksOperationNotPermitted OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of Binding Update requests
rejected by the home agent with status code in
the Binding Acknowledgement indicating 'Mobile
Router Operation not permitted' (Code 140).
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoCounterDiscontinuityTime.
"
REFERENCE
"RFC 3963: Section 6.6"
::= { nemoHaGlobalStats 3 }That's the whole mobile router and home agent counter lineup, bestie 🌈💜
Okay so the home agent keeps a whole tally of Binding Update drama 💅 These first counters track the rejections that come with the specific status codes 141, 142, and 143 🫶
nemoHaBUAcksInvalidPrefix OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of Binding Update requests
rejected by the home agent with status code in
the Binding Acknowledgement indicating 'Invalid
Prefix' (Code 141).
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoCounterDiscontinuityTime.
"
REFERENCE
"RFC 3963: Section 6.6"
::= { nemoHaGlobalStats 4 }
nemoHaBUAcksNotAuthorizedForPrefix OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of Binding Update requests
rejected by the home agent with status code in
the Binding Acknowledgement indicating 'Not
Authorized for Prefix' (Code 142).
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoCounterDiscontinuityTime.
"
REFERENCE
"RFC 3963: Section 6.6"
::= { nemoHaGlobalStats 5 }
nemoHaBUAcksForwardingSetupFailed OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of Binding Update requests
rejected by the home agent with status code in
the Binding Acknowledgement indicating 'Forwarding
Setup failed' (Code 143).
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoCounterDiscontinuityTime.
"
REFERENCE
"RFC 3963: Section 6.6"
::= { nemoHaGlobalStats 6 }Each of these is a Counter32 that only goes up, and it's read-only, so the manager can look but not touch 👀 The counter can reset when the management system re-initializes, or at other times that nemoCounterDiscontinuityTime tells you about 🌸
Then there's the catch-all bucket for anything from a mobile router that doesn't fit the other three. It counts Binding Update requests where the Mobile Router Flag is set and the home agent rejected them with some status code other than 140 through 143 (the list is right there in the description, so no guessing needed) ✨
nemoHaBUAcksOtherError OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of Binding Update requests
from mobile routers (Mobile Router Flag is set)
rejected by the home agent with status code
other than:
mobileRouterOperationNotPermitted (140)
invalidPrefix (141)
notAuthorizedForPrefix (142)
forwardingSetupFailed (143)
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoCounterDiscontinuityTime.
"
REFERENCE
"RFC 3963: Section 6.6"
::= { nemoHaGlobalStats 7 }Now we get to the per-router stats 🧚 The nemoHaCounterTable holds registration statistics for every mobile router registered with the home agent, so it's basically a little scrapbook for each one 📖
nemoHaCounterTable OBJECT-TYPE
SYNTAX SEQUENCE OF NemoHaCounterEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing registration statistics for all
mobile routers registered with the home agent.
"
::= { nemoHaStats 2 }
nemoHaCounterEntry OBJECT-TYPE
SYNTAX NemoHaCounterEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Home agent registration statistics for a mobile
router.
Implementers need to be aware that if the total
number of octets in mip6BindingHomeAddress
exceeds 113, then OIDs of column instances in
this row will have more than 128 sub-identifiers and
cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3.
"
INDEX { mip6BindingHomeAddressType,
mip6BindingHomeAddress
}
::= { nemoHaCounterTable 1 }Heads up, implementers 🚨 If the home address gets bigger than 113 octets, the OIDs for the columns in that row blow past 128 sub-identifiers, and then SNMPv1, SNMPv2c, and SNMPv3 can't reach them at all. Not a vibe 💀
The row itself is the NemoHaCounterEntry sequence, and it's indexed by the binding's home address type and home address 💖
NemoHaCounterEntry ::= SEQUENCE {
nemoHaBURequestsAccepted Counter32,
nemoHaBURequestsDenied Counter32,
nemoHaBCEntryCreationTime DateAndTime,
nemoHaBUAcceptedTime DateAndTime,
nemoHaBURejectionTime DateAndTime,
nemoHaRecentBURejectionCode NemoBURequestRejectionCode,
nemoHaCtrDiscontinuityTime TimeStamp
}Next up are the two accepted and denied tallies, which are the main event of each row 🎀
nemoHaBURequestsAccepted OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Total number of Binding Update requests from the
mobile router accepted by the home agent.
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoHaCtrDiscontinuityTime.
"
::= { nemoHaCounterEntry 1 }
nemoHaBURequestsDenied OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Total number of Binding Update requests from the
mobile router rejected by the home agent.
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times as indicated by the value of
nemoHaCtrDiscontinuityTime.
"
::= { nemoHaCounterEntry 2 }Now the timestamps 🕰️ These use DateAndTime (SIZE (11)), and the MIB is strict about it: the implementation MUST return all 11 bytes so the manager can work out the offset from GMT. Non-negotiable, bestie 🫶
nemoHaBCEntryCreationTime OBJECT-TYPE
SYNTAX DateAndTime (SIZE (11))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The time when the current Binding Cache entry was
created for the mobile router. An implementation
MUST return all 11 bytes of the DateAndTime
textual-convention so that a manager may retrieve
the offset from GMT time.
"
::= { nemoHaCounterEntry 3 }
nemoHaBUAcceptedTime OBJECT-TYPE
SYNTAX DateAndTime (SIZE (11))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The time at which the last Binding Update was
accepted by the home agent for this mobile router.
An implementation MUST return all 11 bytes of the
DateAndTime textual-convention so that a manager
may retrieve the offset from GMT time.
"
::= { nemoHaCounterEntry 4 }
nemoHaBURejectionTime OBJECT-TYPE
SYNTAX DateAndTime (SIZE (11))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The time at which the last Binding Update was
rejected by the home agent for this mobile router.
If there have been no rejections, then this object
will be inaccessible. An implementation MUST return
all 11 bytes of the DateAndTime textual-convention
so that a manager may retrieve the offset from GMT
time.
"
::= { nemoHaCounterEntry 5 }If nothing has ever been rejected, the nemoHaBURejectionTime just goes inaccessible instead of showing a fake timestamp 🙈
Next is the most recent rejection code, which is the latest status (128 or higher) sent back to that mobile router in a Binding Acknowledgment 🔥 If a request got rejected and no Binding Acknowledgment was sent, this object still holds the status code for why it was rejected. And if there have been zero rejections, you guessed it, it's inaccessible 💅
nemoHaRecentBURejectionCode OBJECT-TYPE
SYNTAX NemoBURequestRejectionCode
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Status code (>= 128) in the latest Binding
Acknowledgment indicating a rejection, sent to this
mobile router.
If a Binding Update request is rejected and a Binding
Acknowledgment is not sent to this mobile router,
then this will be the value of the Status code that
corresponds to the reason of the rejection. If there
have been no Binding Update request rejections, then
this object will be inaccessible.
"
::= { nemoHaCounterEntry 6 }Last but definitely not least is the per-row discontinuity timestamp 👑 It holds the sysUpTime from the most recent moment that either the accepted or denied counter in this row got a discontinuity. If that never happened since the last re-initialization, the value is zero 🌈
nemoHaCtrDiscontinuityTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime on the most recent occasion
at which any one or more of the counters in this row,
viz., instances of 'nemoHaBURequestsAccepted' and
'nemoHaBURequestsDenied', suffered a discontinuity.
If no such discontinuity has occurred since the
last re-initialization of the local management
subsystem, then this object will have a zero value.
"
::= { nemoHaCounterEntry 7 }
---
--
--
-- nemoNotifications
--
--
nemoHomeTunnelEstablished NOTIFICATION-TYPE
OBJECTS {
nemoMrBLActiveEgressIfIndex,
nemoMrBLEstablishedHomeTunnelIfIndex,
mip6MnBLCOAType,
mip6MnBLCOA,
nemoMrBLHomeAddressPrefixLength,
nemoMrBLCareofAddressPrefixLength
}
STATUS current
DESCRIPTION
"This notification is sent by the mobile router
every time the tunnel is established between the
home agent and the mobile router.
"
REFERENCE
"RFC 3963: Section 5.5"
::= { nemoNotifications 1 }
nemoHomeTunnelReleased NOTIFICATION-TYPE
OBJECTS {
nemoMrBLActiveEgressIfIndex,
nemoMrBLEstablishedHomeTunnelIfIndex,
mip6MnBLCOAType,
mip6MnBLCOA,
nemoMrBLHomeAddressPrefixLength,
nemoMrBLCareofAddressPrefixLength
}
STATUS current
DESCRIPTION
"This notification is sent by the mobile router
every time the tunnel is deleted between the home
agent and the mobile router.
"
REFERENCE
"RFC 3963: Section 5.5"
::= { nemoNotifications 2}Those two notifications are the tunnel alarms 🚨 The mobile router fires one every time the home tunnel gets set up, and another every time it gets torn down. They both carry the same six objects so the manager gets the full picture 🦋
Now the conformance bit, where the MIB sorts its objects into groups 🧚 Groups 1 and 2 hold the groups and compliances, and the three units of conformance are below 💜
-- Conformance information
nemoGroups OBJECT IDENTIFIER ::= { nemoConformance 1 }
nemoCompliances OBJECT IDENTIFIER ::= { nemoConformance 2 }
-- Units of conformance
nemoSystemGroup OBJECT-GROUP
OBJECTS {
nemoCapabilities,
nemoStatus
}
STATUS current
DESCRIPTION
"A collection of objects for basic NEMO
monitoring.
"
::= { nemoGroups 1 }
nemoBindingCacheGroup OBJECT-GROUP
OBJECTS {
nemoBindingMrFlag,
nemoBindingMrMode
}
STATUS current
DESCRIPTION
"A collection of objects for monitoring the
NEMO extensions of the Binding Cache.
"
::= { nemoGroups 2 }
nemoStatsGroup OBJECT-GROUP
OBJECTS {
nemoCounterDiscontinuityTime
}
STATUS current
DESCRIPTION
"A collection of objects for
monitoring NEMO statistics.
"
::= { nemoGroups 3 }okay so we're still in the NEMO MIB module and this part is all about the groups and compliance statements 🎀 the groups are basically bundles of objects, so a manager can check a whole feature at once 💅
nemoMrConfGroup OBJECT-GROUP
OBJECTS {
nemoMrEgressIfPriority,
nemoMrEgressIfDescription,
nemoMrEgressIfRoamHoldDownTime,
nemoMrDiscoveryRequests,
nemoMrDiscoveryReplies,
nemoMrDiscoveryRepliesRouterFlagZero,
nemoMrMovedHome,
nemoMrMovedOutofHome,
nemoMrMovedFNtoFN,
nemoMrBetterIfDetected
}
STATUS current
DESCRIPTION
"A collection of objects for monitoring
the configuration-related information on
the mobile router.
"
::= { nemoGroups 4 }
nemoMrRegistrationGroup OBJECT-GROUP
OBJECTS {
nemoMrBLMode,
nemoMrBLMrFlag,
nemoMrBLHomeAddressPrefixLength,
nemoMrBLCareofAddressPrefixLength,
nemoMrBLActiveEgressIfIndex,
nemoMrBLEstablishedHomeTunnelIfIndex,
nemoMrMobilityMessagesSent,
nemoMrMobilityMessagesRecd,
nemoMrPrefixRegMode,
nemoMrBindingAcksWONemoSupport,
nemoMrBindingAcksRegTypeChangeDisallowed,
nemoMrBindingAcksOperationNotPermitted,
nemoMrBindingAcksInvalidPrefix,
nemoMrBindingAcksNotAuthorizedForPrefix,
nemoMrBindingAcksForwardingSetupFailed,
nemoMrBindingAcksOtherError
}
STATUS current
DESCRIPTION
"A collection of objects for monitoring
the registration details and statistics for
the mobile router.
"
::= { nemoGroups 5 }
nemoHaSystemGroup OBJECT-GROUP
OBJECTS {
nemoHaMobileNetworkPrefixType,
nemoHaMobileNetworkPrefix,
nemoHaMobileNetworkPrefixLength,
nemoHaMobileNetworkPrefixSource
}
STATUS current
DESCRIPTION
"A collection of objects for basic NEMO
configuration monitoring at the home agent.
"
::= { nemoGroups 6 }
nemoHaStatsGroup OBJECT-GROUP
OBJECTS {
nemoHaBURequestsAccepted,
nemoHaBURequestsDenied,
nemoHaBCEntryCreationTime,
nemoHaBUAcceptedTime,
nemoHaBURejectionTime,
nemoHaRecentBURejectionCode,
nemoHaCtrDiscontinuityTime
}
STATUS current
DESCRIPTION
"A collection of objects for monitoring NEMO
registration-related statistics pertaining to
the mobile routers registered with the home agent.
"
::= { nemoGroups 7 }
nemoHaGlobalStatsGroup OBJECT-GROUP
OBJECTS {
nemoHaBUAcksWONemoSupport,
nemoHaBUAcksRegTypeChangeDisallowed,
nemoHaBUAcksOperationNotPermitted,
nemoHaBUAcksInvalidPrefix,
nemoHaBUAcksNotAuthorizedForPrefix,
nemoHaBUAcksForwardingSetupFailed,
nemoHaBUAcksOtherError
}
STATUS current
DESCRIPTION
"A collection of objects for monitoring basic
NEMO advertisement and registration statistics
on a home agent.
"
::= { nemoGroups 8 }
nemoNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
nemoHomeTunnelEstablished,
nemoHomeTunnelReleased
}
STATUS current
DESCRIPTION
"A collection of notifications from a home agent
or correspondent node to the manager about the
tunnel status of the mobile router.
"
::= { nemoGroups 9 }now the compliance statements 🫶 these are the "what does an implementer have to support to claim they're compliant" bit, and it's giving a checklist vibe 💜 the MANDATORY-GROUPS clauses are the must-haves, and the read-only versions let you skip write access 🌸
-- Compliance statements
nemoCoreCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities
that implement the NEMO-MIB.
"
MODULE -- this module
MANDATORY-GROUPS { nemoSystemGroup
}
::= { nemoCompliances 1 }
nemoCompliance2 MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities that
implement the NEMO-MIB and support monitoring of
the Binding Cache.
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 mip6BindingHomeAddressType
-- SYNTAX InetAddressType { ipv6(2) }
-- DESCRIPTION
-- This MIB module requires support for global
-- IPv6 addresses for the mip6BindingHomeAddress
-- object.
--
-- OBJECT mip6BindingHomeAddress
-- SYNTAX InetAddress (SIZE(16))
-- DESCRIPTION
-- This MIB module requires support for global
-- IPv6 addresses for the mip6BindingHomeAddress
-- object.
--
"
MODULE -- this module
MANDATORY-GROUPS { nemoSystemGroup,
nemoBindingCacheGroup
}
::= { nemoCompliances 2 }
nemoCoreReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities
that implement the NEMO-MIB without support
for read-write (i.e., in read-only mode).
"
MODULE -- this module
MANDATORY-GROUPS { nemoSystemGroup
}
OBJECT nemoStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { nemoCompliances 3 }
nemoReadOnlyCompliance2 MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities that
implement the NEMO-MIB without support for read-write
(i.e., in read-only mode) and with support for
monitoring of the Binding Cache.
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 mip6BindingHomeAddressType
-- SYNTAX InetAddressType { ipv6(2) }
-- DESCRIPTION
-- This MIB module requires support for global
-- IPv6 addresses for the mip6BindingHomeAddress
-- object.
--
-- OBJECT mip6BindingHomeAddress
-- SYNTAX InetAddress (SIZE(16))
-- DESCRIPTION
-- This MIB module requires support for global
-- IPv6 addresses for the mip6BindingHomeAddress
-- object.
--
"
MODULE -- this module
MANDATORY-GROUPS { nemoSystemGroup,
nemoBindingCacheGroup
}
OBJECT nemoStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { nemoCompliances 4 }
nemoMrCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities that
implement the NEMO-MIB for monitoring configuration-
related information, registration details, and
statistics on a mobile router.
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 mip6MnHomeAddressType
-- SYNTAX InetAddressType { ipv6(2) }
-- DESCRIPTION
-- This MIB module requires support for global
-- IPv6 addresses for the mip6MnHomeAddress
-- object.
--
-- OBJECT mip6MnHomeAddress
-- SYNTAX InetAddress (SIZE(16))
-- DESCRIPTION
-- This MIB module requires support for global
-- IPv6 addresses for the mip6MnHomeAddress
-- object.
--
-- OBJECT mip6MnBLNodeAddressType
-- SYNTAX InetAddressType { ipv6(2) }
-- DESCRIPTION
-- This MIB module requires support for global
-- IPv6 addresses for the mip6MnBLNodeAddress
-- object.
--
-- OBJECT mip6MnBLNodeAddress
-- SYNTAX InetAddress (SIZE(16))
-- DESCRIPTION
-- This MIB module requires support for global
-- IPv6 addresses for the mip6MnBLNodeAddress
-- object.
"
MODULE -- this module
MANDATORY-GROUPS { nemoStatsGroup,
nemoMrConfGroup,
nemoMrRegistrationGroup
}
::= { nemoCompliances 5 }
nemoMrReadOnlyCompliance2 MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities that
implement the NEMO-MIB without support for read-
write (i.e., in read-only mode) and with support for
monitoring of configuration-related information,
registration details, and statistics on a mobile
router.
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 mip6MnHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6MnHomeAddress -- object. -- -- OBJECT mip6MnHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6MnHomeAddress -- object. -- -- OBJECT mip6MnBLNodeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6MnBLNodeAddress -- object. -- -- OBJECT mip6MnBLNodeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6MnBLNodeAddress -- object. " MODULE -- this module MANDATORY-GROUPS { nemoStatsGroup, nemoMrConfGroup, nemoMrRegistrationGroup }
OBJECT nemoMrPrefixRegMode MIN-ACCESS read-only DESCRIPTION
"Write access is not required." ::= { nemoCompliances 6 }
nemoHaCoreCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the NEMO-MIB for configuration monitoring at the home agent.
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 mip6BindingHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6BindingHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6BindingHomeAddress -- object. -- " MODULE -- this module MANDATORY-GROUPS { nemoHaSystemGroup } ::= { nemoCompliances 7 }
nemoHaCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the NEMO-MIB with support for monitoring of the home agent functionality, specifically the home-agent-registration-related statistics.
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 mip6BindingHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6BindingHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6BindingHomeAddress -- object. -- " MODULE -- this module MANDATORY-GROUPS { nemoHaSystemGroup, nemoHaStatsGroup, nemoHaGlobalStatsGroup } ::= { nemoCompliances 8 }
nemoNotificationCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the NEMO-MIB and support Notification from the home agent. " MODULE -- this module MANDATORY-GROUPS { nemoNotificationGroup } ::= { nemoCompliances 9 }
END
4. IANA Considerations ✨
ok so IANA has given the 'nemoMIB' a base arc in the mib-2 (Standards Track) OID tree, and its number is 184 🎀. That's the official ID slot, and it's giving permanent address energy 💅.
5. Security Considerations 💀
bestie, this section is SERIOUS. Read it like your SNMP config depends on it, because it does 😭
ngl there are a bunch of management objects in this MIB module with a MAX-ACCESS of read-write. Those can be sensitive or vulnerable in some network environments. Supporting SET operations in a non-secure environment without proper protection can seriously mess with network operations 🙈. These are the tables and objects, plus their sensitivity and vulnerability:
nemoStatus: The value of this object is used to enable or disable the NEMO functionality on a NEMO entity. Access to this MO may be abused to disrupt the communication that depends on NEMO 🚨.nemoMrPrefixRegMode: The value of this object is used to control the mode in which mobile network prefixes will be registered with the home agent. Access to this object may be abused to disrupt the setting up of mobile network prefixes 😤.
Some of the readable objects in this MIB module (the ones with a MAX-ACCESS other than not-accessible) may also be sensitive or vulnerable in some networks. So it's important to control even GET and/or NOTIFY access to them, and maybe even encrypt their values when they travel over the network via SNMP 🔐. These are the tables and objects, and their sensitivity and vulnerability:
nemoHaMobileNetworkPrefixTypenemoHaMobileNetworkPrefixnemoHaMobileNetworkPrefixLength:
The address-related objects above may be considered particularly sensitive and/or private 🫣. The mobile-network-prefix-related objects reveal the configuration of the mobile router, so they may be sensitive too.
SNMP versions before SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), there is still no control over who on that secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Main character villain energy 💀.
It is RECOMMENDED that implementers consider the security features 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 turn on cryptographic security. It is then a customer/operator responsibility to make sure the SNMP entity giving access to an instance of this MIB module is properly configured, so the objects are only accessible to principals (users) with legitimate rights to GET or SET (change/create/delete) them 🧚.
6. Acknowledgments 🫶
The authors would like to thank Alex Petrescu, Pascal Thubert, Kent Leung, T.J Kniveton, Thierry Ernst, Alberto Garcia, Marcelo Bagnulo, Vijay K. Gurbani, Bert Wijnen, Chris Newman, Dan Romanascu, and Jari Arkko for their review comments on this document. Absolute legends, every single one 👑.
7. References 📚
7.1. Normative References
- [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.
- [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
- [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
- [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
- [RFC4295] Keeni, G., Koide, K., Nagami, K., and S. Gundavelli, "Mobile IPv6 Management Information Base", RFC 4295, April 2006.
7.2. Informative References
- [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
- [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
- [RFC4886] Ernst, T., "Network Mobility Support Goals and Requirements", RFC 4886, July 2007.
Authors' Addresses 💅
Sri Gundavelli 🌈
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Phone: +1-408-527-6109
EMail: sgundave@cisco.comGlenn Mansfield Keeni 🦋
Glenn Mansfield Keeni
Cyber Solutions
6-6-3 Minami Yoshinari, Aoba-ku
Sendai 989-3204,
Japan
Phone: +81-22-303-4012
EMail: glenn@cysols.comKazuhide Koide 🌸
Kazuhide Koide
KDDI CORPORATION
GARDEN AIR TOWER 3-10-10, Iidabashi
Chiyoda-ku, Tokyo, 102-8460 Japan
Phone: +81-3-6678-3378
EMail: ka-koide@kddi.comKenichi Nagami 🍓
Kenichi Nagami
INTEC NetCore
1-3-3, Shin-suna
Koto-ku, Tokyo, 135-0075,
Japan
Phone: +81-3-5665-5069
EMail: nagami@inetcore.com📦 where this page comes from
- ietf: rfc5488 2009-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms