RFC 7388
Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
RFC 7388: Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) π¦
Okay bestie, RFC 7388 π came out in October 2014 as a Standards Track document, so it's an official Internet standard. It was written by J. Schoenwaelder, A. Sehgal (from Jacobs University), T. Tsou, and C. Zhou (from Huawei Technologies). Its ISSN is 2070-1721. The header doesn't say it obsoletes or updates any other RFC, so there's no drama there β¨
1. Introduction ....................................................2
2. The Internet-Standard Management Framework ......................2
3. Conventions .....................................................3
4. Overview ........................................................3
5. Relationship to Other MIB Modules ...............................7
6. Definitions .....................................................7
7. Security Considerations ........................................24
8. IANA Considerations ............................................25
9. References .....................................................25
9.1. Normative References ......................................25
9.2. Informative References ....................................26
Acknowledgements ..................................................27
Authors' Addresses ................................................27
Abstract π
Okay so this doc defines a chunk of a Management Information Base (MIB), which is basically the big organized list of stuff network management protocols can read and change. The specific chunk it's about is the objects for managing IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). Main character energy π
Status of This Memo πΈ
This is an Internet Standards Track document.
This doc is an IETF product, and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741.
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7388.
Copyright Notice π₯
Copyright (c) 2014 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 (http://trustee.ietf.org/license-info) as they stood on the publication date. Read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes.
1. Introduction β¨
Okay so this document defines a portion of the Management Information Base (MIB) for use with network management protocols. Specifically, it defines objects for managing IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [RFC4944].
A MIB module gives you a direct way to access data through the Simple Network Management Protocol (SNMP) [RFC3410]. But SNMP isn't always affordable on constrained devices π₯Ί Other protocols can also access the data modeled in MIB modules, and people have recently proposed bindings to the Constrained Application Protocol (CoAP) [RFC7252]. Lowkey iconic π§
2. The Internet-Standard Management Framework π
If you want a detailed overview of the documents that make up the current Internet-Standard Management Framework, go check section 7 of RFC 3410 [RFC3410].
Managed objects are accessed through a virtual information store called the Management Information Base, or MIB. People usually reach MIB objects through the Simple Network Management Protocol (SNMP). The objects in the MIB are defined using the mechanisms in the Structure of Management Information (SMI). This document 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]. It's giving well-organized π
3. Conventions π¦
Here's the important bit π«Ά 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]. Those words are the whole point of the spec-speak, so don't skip them, ngl π
4. Overview β¨
okay so the left side of Figure 1 is the lineup of IETF protocols built for constrained devices π§ and the right side lists the MIB modules that help you monitor and troubleshoot them ([RFC4113], [RFC4292], [RFC4293], and [RFC2863]). the LOWPAN-MIB defined in this document fills a hole π³οΈ by giving the 6LoWPAN layer its own monitoring and troubleshooting support. it was honestly overdue π
Protocol Layer MIB Modules
+--------------------+
| CoAP [RFC7252] |
+--------------------+ +--------------------------+
| UDP [RFC0768] | | UDP-MIB [RFC4113] |
+--------------------+ +--------------------------+
| IPv6 [RFC2460] | | IP-MIB [RFC4293] |
| ICMPv6 [RFC4443] | | IP-FORWARD-MIB [RFC4292] |
+--------------------+ +--------------------------+
| 6LoWPAN [RFC4944] | | LOWPAN-MIB [RFC7388] |
+--------------------+ +--------------------------+
| IF-MIB [RFC2863] |
+--------------------+ +--------------------------+
| IEEE 802.15.4, ... |
+--------------------+
Figure 1: Protocol Layers and MIB Modules
the LOWPAN-MIB module is basically a big pile of counters π’ that track how 6LoWPAN datagrams get processed by the 6LoWPAN layer. each object is defined twice: once for the global stats as seen by the 6LoWPAN layer, and once for per-interface 6LoWPAN stats. the per-interface stats are optional to implement, so no pressure lol π the object identifier registration tree looks like this:
---- lowpanMIB(1.3.6.1.2.1.226)
+---- lowpanNotifications(0)
+---- lowpanObjects(1)
| +---- lowpanStats(1)
| | +--r- lowpanReasmTimeout(1) Unsigned32
| | +--r- lowpanInReceives(2) Counter32
| | +--r- lowpanInHdrErrors(3) Counter32
| | +--r- lowpanInMeshReceives(4) Counter32
| | +--r- lowpanInMeshForwds(5) Counter32
| | +--r- lowpanInMeshDelivers(6) Counter32
| | +--r- lowpanInReasmReqds(7) Counter32
| | +--r- lowpanInReasmFails(8) Counter32
| | +--r- lowpanInReasmOKs(9) Counter32
| | +--r- lowpanInCompReqds(10) Counter32
| | +--r- lowpanInCompFails(11) Counter32
| | +--r- lowpanInCompOKs(12) Counter32
| | +--r- lowpanInDiscards(13) Counter32
| | +--r- lowpanInDelivers(14) Counter32
| | +--r- lowpanOutRequests(15) Counter32
| | +--r- lowpanOutCompReqds(16) Counter32
| | +--r- lowpanOutCompFails(17) Counter32
| | +--r- lowpanOutCompOKs(18) Counter32
| | +--r- lowpanOutFragReqds(19) Counter32
| | +--r- lowpanOutFragFails(20) Counter32
| | +--r- lowpanOutFragOKs(21) Counter32
| | +--r- lowpanOutFragCreates(22) Counter32
| | +--r- lowpanOutMeshHopLimitExceeds(23) Counter32
| | +--r- lowpanOutMeshNoRoutes(24) Counter32
| | +--r- lowpanOutMeshRequests(25) Counter32
| | +--r- lowpanOutMeshForwds(26) Counter32
| | +--r- lowpanOutMeshTransmits(27) Counter32
| | +--r- lowpanOutDiscards(28) Counter32
| | +--r- lowpanOutTransmits(29) Counter32
| +---- lowpanIfStatsTable(2)
| +---- lowpanIfStatsEntry(1) [ifIndex]
| +--r- lowpanIfReasmTimeout(1) Unsigned32
| +--r- lowpanIfInReceives(2) Counter32
| +--r- lowpanIfInHdrErrors(3) Counter32
| +--r- lowpanIfInMeshReceives(4) Counter32
| +--r- lowpanIfInMeshForwds(5) Counter32
| +--r- lowpanIfInMeshDelivers(6) Counter32
| +--r- lowpanIfInReasmReqds(7) Counter32
| +--r- lowpanIfInReasmFails(8) Counter32
| +--r- lowpanIfInReasmOKs(9) Counter32
| +--r- lowpanIfInCompReqds(10) Counter32
| +--r- lowpanIfInCompFails(11) Counter32
| +--r- lowpanIfInCompOKs(12) Counter32
| +--r- lowpanIfInDiscards(13) Counter32
| +--r- lowpanIfInDelivers(14) Counter32
| +--r- lowpanIfOutRequests(15) Counter32
| +--r- lowpanIfOutCompReqds(16) Counter32
| +--r- lowpanIfOutCompFails(17) Counter32
| +--r- lowpanIfOutCompOKs(18) Counter32
| +--r- lowpanIfOutFragReqds(19) Counter32
| +--r- lowpanIfOutFragFails(20) Counter32
| +--r- lowpanIfOutFragOKs(21) Counter32
| +--r- lowpanIfOutFragCreates(22) Counter32
| +--r- lowpanIfOutMeshHopLimitExceeds(23) Counter32
| +--r- lowpanIfOutMeshNoRoutes(24) Counter32
| +--r- lowpanIfOutMeshRequests(25) Counter32
| +--r- lowpanIfOutMeshForwds(26) Counter32
| +--r- lowpanIfOutMeshTransmits(27) Counter32
| +--r- lowpanIfOutDiscards(28) Counter32
| +--r- lowpanIfOutTransmits(29) Counter32
+---- lowpanConformance(2)
+---- lowpanGroups(1)
| +---- lowpanStatsGroup(1)
| +---- lowpanStatsMeshGroup(2)
| +---- lowpanIfStatsGroup(3)
| +---- lowpanIfStatsMeshGroup(4)
+---- lowpanCompliances(2)
+---- lowpanCompliance(1)
Figure 2: Object Identifier Registration Tree
the counters track 6LoWPAN datagrams received and transmitted, and how they get processed in the 6LoWPAN layer π¦ for link layers that use the 6LoWPAN dispatch byte from [RFC4944] (like IEEE 802.15.4), a 6LoWPAN datagram is one whose dispatch byte matches 01xxxxxx, 10xxxxxx, or 11xxxxxx. datagrams with a dispatch byte matching 00xxxxxx (NALP - not a LoWPAN frame) are not considered 6LoWPAN datagrams by this specification π
ββοΈ other radio technologies may use different mechanisms to identify 6LoWPAN datagrams (e.g., the BLUETOOTH Low-Energy Logical Link Control and Adaptation Protocol uses Channel Identifiers [IPV6-BTLE]).
the Case Diagram [CASE] in Figure 3 shows the conceptual relationships between the counters π¦ implementations may choose to process 6LoWPAN datagrams in a different order.
the generic InDiscards and OutDiscards counters can get incremented anytime 6LoWPAN datagrams are discarded for reasons not covered by the other, more specific counters. for example, an implementation discarding 6LoWPAN datagrams while all buffers are used for ongoing packet reassemblies will increment the relevant InDiscards counters for each discarded 6LoWPAN datagram π«Ά
IPv6 layer
^ v
InDelivers -+- -+- OutRequests
| |
InDiscards <--+ |
| |
InCompOKs .-->| |-->. OutCompReqds
InCompFails <--| | | +--> OutCompFails
InCompReqds `<--+ +<--' OutCompOKs
| |
| +-->. OutFragReqds
InReasmOKs .-->| | +--> OutFragFails
InReasmFails <--| | | -+- OutFragOKs
InReasmReqds `<--+ +<--' OutFragCreates
| |
| |
InMeshDelivers |<--. |
InMeshForwds | |-->. |
InMeshReceives +-->' | |
| +--> | OutMeshHopLimitExceeds
| +--> | OutMeshNoRoutes
| | |
| | .<--+ OutMeshRequests
| `-->| | OutMeshForwds
| `-->| OutMeshTransmits
| |
InHdrErrors <--+ +--> OutDiscards
| |
InReceives -+- -+- OutTransmits
^ v
interface layer
Figure 3: Conceptual Relationship between LOWPAN-MIB Counters
the fragmentation counters were modeled after the fragmentation counters of the IP-MIB [RFC4293] π§© the discard counters sit at the end of the input and output chains, but they can be bumped any time a datagram gets dropped for a reason the other counters don't cover.
the compression counters give you insight into compression requests and, especially, compression failures π the diagram is conceptual, though: compression happens after reassembly for incoming 6LoWPAN datagrams, and before fragmentation for outgoing ones. implementations may choose to do things slightly differently. for example, implementations may decompress FRAG1 fragments as soon as they are received, without waiting for reassembly to complete πΈ
the MESH header counters don't have an explicit discard counter πΈοΈ implementations that do not support mesh forwarding MUST count the number of received 6LoWPAN datagrams with a MESH header (lowpanInMeshReceives), but they MUST NOT increment the lowpanInMeshReceives and lowpanInMeshDelivers counters if these 6LoWPAN datagrams are dropped. β¨
5. Relationship to Other MIB Modules π
the MIB module imports definitions from SNMPv2-SMI [RFC2578], SNMPv2-CONF [RFC2580], and IF-MIB [RFC2863] π
6. Definitions π
LOWPAN-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, Counter32, mib-2
FROM SNMPv2-SMI -- RFC 2578
OBJECT-GROUP, MODULE-COMPLIANCE
FROM SNMPv2-CONF -- RFC 2580
ifIndex FROM IF-MIB; -- RFC 2863
lowpanMIB MODULE-IDENTITY
LAST-UPDATED "201410100000Z" -- October 10, 2014
ORGANIZATION
"IETF IPv6 over Networks of Resource-constrained Nodes
Working Group"
CONTACT-INFO
"WG Email: 6lo@ietf.org
WG Web: http://tools.ietf.org/wg/6lo/
Juergen Schoenwaelder
Jacobs University Bremen
Email: j.schoenwaelder@jacobs-university.de
Anuj Sehgal
Jacobs University Bremen
Email: s.anuj@jacobs-university.de
Tina Tsou
Huawei Technologies
Email: tina.tsou.zouting@huawei.com
Cathy Zhou
Huawei Technologies
Email: cathyzhou@huawei.com"
DESCRIPTION
"The MIB module for monitoring nodes implementing the IPv6
over Low-Power Wireless Personal Area Networks (6LoWPAN)
protocol.
Copyright (c) 2014 IETF Trust and the persons identified as
authors of the code. All rights reserved.
okay so we're still deep in the MIB module π§ first up is the tail end of the license fine print, then the whole lowpanStats counter party, then the per-interface table starts to show up π
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info)."
REVISION "201410100000Z" -- October 10, 2014
DESCRIPTION
"Initial version, published as RFC 7388."
::= { mib-2 226 }
-- object definitions
lowpanNotifications OBJECT IDENTIFIER ::= { lowpanMIB 0 }
lowpanObjects OBJECT IDENTIFIER ::= { lowpanMIB 1 }
lowpanConformance OBJECT IDENTIFIER ::= { lowpanMIB 2 }
lowpanStats OBJECT IDENTIFIER ::= { lowpanObjects 1 }
lowpanReasmTimeout OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum number of seconds that received fragments are
held while they are awaiting reassembly at this entity."
::= { lowpanStats 1 }
lowpanInReceives OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of 6LoWPAN datagrams received, including
those received in error."
::= { lowpanStats 2 }
lowpanInHdrErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of received 6LoWPAN datagrams discarded due to
errors in their headers, including unknown dispatch values."
::= { lowpanStats 3 }
lowpanInMeshReceives OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of received 6LoWPAN datagrams with a MESH
header."
::= { lowpanStats 4 }
lowpanInMeshForwds OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of received 6LoWPAN datagrams requiring mesh
forwarding."
::= { lowpanStats 5 }
lowpanInMeshDelivers OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of received 6LoWPAN datagrams with a MESH header
delivered to the local system."
::= { lowpanStats 6 }
lowpanInReasmReqds OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of received 6LoWPAN fragments that needed to
be reassembled. This includes both FRAG1 and FRAGN 6LoWPAN
datagrams."
::= { lowpanStats 7 }
lowpanInReasmFails OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of failures detected by the re-assembly
algorithm (e.g., timeouts). Note that this is not
necessarily a count of discarded 6LoWPAN fragments
since implementations can lose track of the number
of fragments by combining them as received."
::= { lowpanStats 8 }
lowpanInReasmOKs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of IPv6 packets successfully reassembled."
::= { lowpanStats 9 }
lowpanInCompReqds OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN datagrams requiring header
decompression."
::= { lowpanStats 10 }
lowpanInCompFails OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN datagrams where header decompression
failed (e.g., because the necessary context information was
not available)."
::= { lowpanStats 11 }
lowpanInCompOKs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN datagrams where header decompression
was successful."
::= { lowpanStats 12 }
lowpanInDiscards OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of received 6LoWPAN datagrams that were
discarded (e.g., for lack of buffer space) even though no
problems were encountered to prevent their continued
processing. Note that this counter does not include any
datagrams discarded due to a reassembly failure or a
compression failure."
::= { lowpanStats 13 }
lowpanInDelivers OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of IPv6 packets successfully delivered
to the IPv6 layer."
::= { lowpanStats 14 }
lowpanOutRequests OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of IPv6 packets supplied by the IPv6
layer."
::= { lowpanStats 15 }
lowpanOutCompReqds OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of IPv6 packets for which header
compression was attempted."
::= { lowpanStats 16 }
lowpanOutCompFails OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of IPv6 packets for which header
compression failed."
::= { lowpanStats 17 }
lowpanOutCompOKs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of IPv6 packets for which header
compression was successful."
::= { lowpanStats 18 }
lowpanOutFragReqds OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of IPv6 packets that required fragmentation
in order to be transmitted."
::= { lowpanStats 19 }
lowpanOutFragFails OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of IPv6 packets that have been discarded because
fragmentation failed."
::= { lowpanStats 20 }
lowpanOutFragOKs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of IPv6 packets that have been successfully
fragmented."
::= { lowpanStats 21 }
lowpanOutFragCreates OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN fragments that have been
generated as a result of fragmentation. This includes
both FRAG1 and FRAGN 6LoWPAN datagrams."
::= { lowpanStats 22 }
lowpanOutMeshHopLimitExceeds OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN datagrams with a MESH header that
were dropped because the hop limit was exceeded."
::= { lowpanStats 23 }
lowpanOutMeshNoRoutes OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN datagrams with a MESH header that
were dropped because there was no forwarding information
available."
::= { lowpanStats 24 }
lowpanOutMeshRequests OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN datagrams requiring MESH header
encapsulation."
::= { lowpanStats 25 }
lowpanOutMeshForwds OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN datagrams with a MESH header for
which suitable forwarding information was available."
::= { lowpanStats 26 }
lowpanOutMeshTransmits OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN datagrams with a MESH header
created."
::= { lowpanStats 27 }
lowpanOutDiscards OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of IPv6 packets that were discarded (e.g.,
for lack of buffer space) even though no problem was
encountered to prevent their transmission to their
destination."
::= { lowpanStats 28 }
lowpanOutTransmits OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of 6LoWPAN datagram that this entity
supplied to the lower layers for transmission."
::= { lowpanStats 29 }
lowpanIfStatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF LowpanIfStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table providing per-interface statistics."
::= { lowpanObjects 2 }
lowpanIfStatsEntry OBJECT-TYPE
SYNTAX LowpanIfStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry providing statistics for a specific interface."
INDEX { ifIndex }
::= { lowpanIfStatsTable 1 }
LowpanIfStatsEntry ::= SEQUENCE {
lowpanIfReasmTimeout Unsigned32,
lowpanIfInReceives Counter32,
lowpanIfInHdrErrors Counter32,
lowpanIfInMeshReceives Counter32,
lowpanIfInMeshForwds Counter32,
lowpanIfInMeshDelivers Counter32,
lowpanIfInReasmReqds Counter32,
lowpanIfInReasmFails Counter32,
lowpanIfInReasmOKs Counter32,
lowpanIfInCompReqds Counter32,
lowpanIfInCompFails Counter32,
lowpanIfInCompOKs Counter32,
lowpanIfInDiscards Counter32,
lowpanIfInDelivers Counter32,
lowpanIfOutRequests Counter32,
lowpanIfOutCompReqds Counter32,
lowpanIfOutCompFails Counter32,
lowpanIfOutCompOKs Counter32,
lowpanIfOutFragReqds Counter32,
lowpanIfOutFragFails Counter32,
lowpanIfOutFragOKs Counter32,
lowpanIfOutFragCreates Counter32,
lowpanIfOutMeshHopLimitExceeds Counter32,
lowpanIfOutMeshNoRoutes Counter32,
lowpanIfOutMeshRequests Counter32,
lowpanIfOutMeshForwds Counter32,
lowpanIfOutMeshTransmits Counter32,
lowpanIfOutDiscards Counter32,
lowpanIfOutTransmits Counter32
}
lowpanIfReasmTimeout OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum number of seconds that received fragments are
held while they are awaiting reassembly at this interface."
::= { lowpanIfStatsEntry 1 }
okay so the per-interface stats are where things get really spicy π¦ every counter here is a Counter32 and read-only, and they all live under lowpanIfStatsEntry, numbered 2 through 29. the receive side comes first, and it's giving detail π
lowpanIfInReceives OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of 6LoWPAN datagrams received on this
interface, including those received in error."
::= { lowpanIfStatsEntry 2 }
lowpanIfInHdrErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN datagrams received on this
interface that were discarded due to errors in
their headers, including unknown dispatch values."
::= { lowpanIfStatsEntry 3 }
lowpanIfInMeshReceives OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN datagrams received on this
interface with a MESH header."
::= { lowpanIfStatsEntry 4 }
lowpanIfInMeshForwds OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN datagrams received on this
interface requiring mesh forwarding."
::= { lowpanIfStatsEntry 5 }
lowpanIfInMeshDelivers OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN datagrams received on this
interface with a MESH header delivered to the local
system."
::= { lowpanIfStatsEntry 6 }
lowpanIfInReasmReqds OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN fragments received on this
interface that needed to be reassembled. This
includes both FRAG1 and FRAGN 6LoWPAN datagrams."
::= { lowpanIfStatsEntry 7 }
lowpanIfInReasmFails OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of failures detected by the reassembly
algorithm (e.g., timeouts) for datagrams received
on this interface. Note that this is not necessarily
a count of discarded 6LoWPAN fragments since
implementations can lose track of the number
of fragments by combining them as received."
::= { lowpanIfStatsEntry 8 }
lowpanIfInReasmOKs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of IPv6 packets successfully reassembled
from fragments received on this interface."
::= { lowpanIfStatsEntry 9 }
lowpanIfInCompReqds OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN datagrams received on this
interface requiring header decompression."
::= { lowpanIfStatsEntry 10 }
lowpanIfInCompFails OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN datagrams received on this
interface where header decompression failed (e.g.,
because the necessary context information was
not available)."
::= { lowpanIfStatsEntry 11 }
lowpanIfInCompOKs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN datagrams received on this
interface where header decompression was successful."
::= { lowpanIfStatsEntry 12 }
lowpanIfInDiscards OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN datagrams received on this
interface that were discarded (e.g., for lack of buffer
space) even though no problems were encountered to
prevent their continued processing. Note that this
counter does not include any datagrams discarded due
to a reassembly failure or a compression failure."
::= { lowpanIfStatsEntry 13 }
lowpanIfInDelivers OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of IPv6 packets received on this
interface that were successfully delivered to the
IPv6 layer."
::= { lowpanIfStatsEntry 14 }
now the transmit side, which is the mirror image πͺβ¨
lowpanIfOutRequests OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of IPv6 packets supplied by the IPv6
layer to be sent over this interface."
::= { lowpanIfStatsEntry 15 }
lowpanIfOutCompReqds OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of IPv6 packets to be sent over
this interface for which header compression was
attempted."
::= { lowpanIfStatsEntry 16 }
lowpanIfOutCompFails OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of IPv6 packets to be sent over
this interface for which header compression failed."
::= { lowpanIfStatsEntry 17 }
lowpanIfOutCompOKs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of IPv6 packets to be sent over
this interface for which header compression was
successful."
::= { lowpanIfStatsEntry 18 }
lowpanIfOutFragReqds OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of IPv6 packets to be sent over this
interface that required fragmentation in order
to be transmitted."
::= { lowpanIfStatsEntry 19 }
lowpanIfOutFragFails OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of IPv6 packets to be sent over this
interface that have been discarded because
fragmentation failed."
::= { lowpanIfStatsEntry 20 }
lowpanIfOutFragOKs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of IPv6 packets to be sent over this
interface that have been successfully fragmented."
::= { lowpanIfStatsEntry 21 }
lowpanIfOutFragCreates OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN fragments that have been
generated on this interface as a result of
fragmentation. This includes both FRAG1 and FRAGN
6LoWPAN datagrams."
::= { lowpanIfStatsEntry 22 }
lowpanIfOutMeshHopLimitExceeds OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN datagrams to be sent on this
interface with a MESH header that were dropped
because the hop limit was exceeded."
::= { lowpanIfStatsEntry 23 }
lowpanIfOutMeshNoRoutes OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN datagrams to be sent on this
interface with a MESH header that were dropped
because there was no forwarding information available."
::= { lowpanIfStatsEntry 24 }
lowpanIfOutMeshRequests OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN datagrams to be sent on this
interface requiring MESH header encapsulation."
::= { lowpanIfStatsEntry 25 }
lowpanIfOutMeshForwds OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN datagrams to be sent on this
interface with a MESH header for which suitable
forwarding information was available."
::= { lowpanIfStatsEntry 26 }
lowpanIfOutMeshTransmits OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 6LoWPAN datagrams to be sent on this
interface with a MESH header created."
::= { lowpanIfStatsEntry 27 }
lowpanIfOutDiscards OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of IPv6 packets to be sent over this
interface that were discarded (e.g., for lack of buffer
space) even though no problem was encountered to
prevent their transmission to their destination."
::= { lowpanIfStatsEntry 28 }
lowpanIfOutTransmits OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of 6LoWPAN datagrams to be sent on
this interface that this entity supplied to the lower
layers for transmission."
::= { lowpanIfStatsEntry 29 }
okay now the conformance bit, which is basically the rules for who has to implement what π the groups get tagged up and the compliance statement decides which ones are required for which kinds of systems
-- conformance definitions
lowpanGroups OBJECT IDENTIFIER ::= { lowpanConformance 1 }
lowpanCompliances OBJECT IDENTIFIER ::= { lowpanConformance 2 }
lowpanCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Compliance statement for systems that implement 6LoWPAN."
MODULE -- this module
MANDATORY-GROUPS {
lowpanStatsGroup
}
GROUP lowpanStatsMeshGroup
DESCRIPTION
"This group is mandatory for implementations that process
or forward 6LoWPAN datagrams with a MESH header."
GROUP lowpanIfStatsGroup
DESCRIPTION
"This group is mandatory for implementations that expose
per-interface statistics."
GROUP lowpanIfStatsMeshGroup
DESCRIPTION
"This group is mandatory for implementations that expose
per-interface statistics and that process or forward
6LoWPAN datagrams with a MESH header."
::= { lowpanCompliances 1 }
lowpanStatsGroup OBJECT-GROUP
OBJECTS {
lowpanReasmTimeout,
lowpanInReceives,
lowpanInHdrErrors,
lowpanInMeshReceives,
lowpanInReasmReqds,
lowpanInReasmFails,
lowpanInReasmOKs,
lowpanInCompReqds,
lowpanInCompFails,
lowpanInCompOKs,
lowpanInDiscards,
lowpanInDelivers,
lowpanOutRequests,
lowpanOutCompReqds,
lowpanOutCompFails,
lowpanOutCompOKs,
lowpanOutFragReqds,
lowpanOutFragFails,
lowpanOutFragOKs,
lowpanOutFragCreates,
lowpanOutDiscards,
lowpanOutTransmits
}
STATUS current
DESCRIPTION
"A collection of objects providing information and
statistics about the processing of 6LoWPAN datagrams,
excluding counters covering the processing of datagrams
with a MESH header."
::= { lowpanGroups 1 }
part 5 is next, and it's the last stretch π§π
lowpanStatsMeshGroup OBJECT-GROUP
OBJECTS {
lowpanInMeshForwds,
lowpanInMeshDelivers,
lowpanOutMeshHopLimitExceeds,
lowpanOutMeshNoRoutes,
lowpanOutMeshRequests,
lowpanOutMeshForwds,
lowpanOutMeshTransmits
}
STATUS current
DESCRIPTION
"A collection of objects providing information and
statistics about the processing of 6LoWPAN datagrams
with a MESH header."
::= { lowpanGroups 2 }
lowpanIfStatsGroup OBJECT-GROUP
OBJECTS {
lowpanIfReasmTimeout,
lowpanIfInReceives,
lowpanIfInHdrErrors,
lowpanIfInMeshReceives,
lowpanIfInReasmReqds,
lowpanIfInReasmFails,
lowpanIfInReasmOKs,
lowpanIfInCompReqds,
lowpanIfInCompFails,
lowpanIfInCompOKs,
lowpanIfInDiscards,
lowpanIfInDelivers,
lowpanIfOutRequests,
lowpanIfOutCompReqds,
lowpanIfOutCompFails,
lowpanIfOutCompOKs,
lowpanIfOutFragReqds,
lowpanIfOutFragFails,
lowpanIfOutFragOKs,
lowpanIfOutFragCreates,
lowpanIfOutDiscards,
lowpanIfOutTransmits
}
STATUS current
DESCRIPTION
"A collection of objects providing per-interface
information and statistics about the processing
of 6LoWPAN datagrams, excluding counters covering
the processing of datagrams with a MESH header."
::= { lowpanGroups 3 }
lowpanIfStatsMeshGroup OBJECT-GROUP
OBJECTS {
lowpanIfInMeshForwds,
lowpanIfInMeshDelivers,
lowpanIfOutMeshHopLimitExceeds,
lowpanIfOutMeshNoRoutes,
lowpanIfOutMeshRequests,
lowpanIfOutMeshForwds,
lowpanIfOutMeshTransmits
}
STATUS current
DESCRIPTION
"A collection of objects providing per-interface
information and statistics about the processing
of 6LoWPAN datagrams with a MESH header."
::= { lowpanGroups 4 }
END
7. Security Considerations πβ¨
okay bestie, security time, and it's giving serious but make it cute π«Ά. There are no management objects in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So if this MIB module is implemented correctly, an intruder can't alter or create any of its management objects with direct SNMP SET operations. Lowkey a big win π
.
Some of the readable objects here (so anything whose MAX-ACCESS is something other than not-accessible) might be sensitive or vulnerable depending on the network. So it's super 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 ππΈ.
The read-only counters show how much 6LoWPAN traffic a node is sending and receiving π. That can tell someone whether a device is always chatting with other devices, or whether it's mostly sitting quietly and not participating in any communication. That second one is giving "easy to take away unnoticed" energy, which is scary π. The reassembly counters could also be used to aim denial-of-service attacks at the reassembly mechanism π.
Here's the tea π΅: SNMP versions before SNMPv3 did not include adequate security. Even if the network itself is secure (for example, by using IPsec), there's still no control over who on that secure network gets to GET and SET (read, change, create, or delete) the objects in this MIB module. Not me being shook π.
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). Main character energy for SNMPv3 π¦π₯.
Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security ππ. It is then a customer/operator responsibility to 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) who have legitimate rights to GET or SET (change, create, or delete) them. Iykyk, access control is everything β¨.
8. IANA Considerations π§
The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER value, which is recorded in the SMI Numbers registry π:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
lowpanMIB { mib-2 226 }
9. References π
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, http://www.rfc-editor.org/info/rfc2119.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999, http://www.rfc-editor.org/info/rfc2578.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999, http://www.rfc-editor.org/info/rfc2579.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999, http://www.rfc-editor.org/info/rfc2580.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000, http://www.rfc-editor.org/info/rfc2863.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007, http://www.rfc-editor.org/info/rfc4944.
9.2. Informative References
[CASE] Case, J. and C. Partridge, "Case Diagrams: A First Step to Diagrammed Management Information Bases", Computer Communications Review 19(1), January 1989.
[IPV6-BTLE] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets over BLUETOOTH(R) Low Energy", Work in Progress, draft-ietf-6lo-btle-03, September 2014.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980, http://www.rfc-editor.org/info/rfc768.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998, http://www.rfc-editor.org/info/rfc2460.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002, http://www.rfc-editor.org/info/rfc3410.
[RFC4113] Fenner, B. and J. Flick, "Management Information Base for the User Datagram Protocol (UDP)", RFC 4113, June 2005, http://www.rfc-editor.org/info/rfc4113.
[RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April 2006, http://www.rfc-editor.org/info/rfc4292.
[RFC4293] Routhier, S., "Management Information Base for the Internet Protocol (IP)", RFC 4293, April 2006, http://www.rfc-editor.org/info/rfc4293.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006, http://www.rfc-editor.org/info/rfc4443.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014, http://www.rfc-editor.org/info/rfc7252.
Acknowledgements π
This specification borrows heavily from the IP-MIB defined in [RFC4293]. Thank you, IP-MIB, you're the real MVP π.
Juergen Schoenwaelder and Anuj Sehgal were partly funded by Flamingo, a Network of Excellence project (ICT-318488) supported by the European Commission under its Seventh Framework Programme πͺπΊβ¨.
Authors' Addresses π
Juergen Schoenwaelder
Jacobs University
Campus Ring 1
Bremen 28759
Germany
EMail: j.schoenwaelder@jacobs-university.de
Anuj Sehgal
Jacobs University
Campus Ring 1
Bremen 28759
Germany
EMail: s.anuj@jacobs-university.de
Tina Tsou
Huawei Technologies
2330 Central Expressway
Santa Clara CA 95050
United States
EMail: tina.tsou.zouting@huawei.com
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
China
EMail: cathyzhou@huawei.com
π¦ where this page comes from
- ietf: rfc7388 2014-10
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms