RMON IPv6/MPLS IDs: Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol Label Switching (MPLS)
Identifying IPv6 and MPLS traffic in network monitoring tools.
Stephan, E. and J. Palet, "Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol Label Switching (MPLS)", RFC 3919, DOI 10.17487/RFC3919, October 2004, <https://www.rfc-editor.org/info/rfc3919>.
@misc{rfc3919,
series = {Request for Comments},
number = 3919,
howpublished = {RFC 3919},
publisher = {RFC Editor},
doi = {10.17487/RFC3919},
url = {https://www.rfc-editor.org/info/rfc3919},
author = {E. Stephan and J. Palet},
title = {{Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol Label Switching (MPLS)}},
pagetotal = 8,
year = 2004,
month = oct,
} RFC text
Contents
Network Working Group E. Stephan
Request for Comments: 3919 France Telecom R&D
Category: Informational J. Palet
Consulintel
October 2004
Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and
Multi Protocol Label Switching (MPLS)
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This memo defines additional (to those in RFC 2896) protocol
identifier examples for IP version 6 and MPLS protocols. These can
be used to produce valid protocolDirTable INDEX encodings, as defined
by the Remote Network Monitoring MIB (Management Information Base)
Version 2 [RFC2021] and the RMON Protocol Identifier Reference
[RFC2895].
This document contains additional (to those in RFC 2896) protocol
identifier macros for well-known protocols. A conformant
implementation of the RMON-2 MIB [RFC2021] can be accomplished
without the use of these protocol identifiers, and accordingly, this
document does not specify any IETF standard. It is published to
encourage better interoperability between RMON-2 agent
implementations, by providing RMON related IPv6 and MPLS protocol
information.
Table of Contents
1. The Internet-Standard Management Framework . . . . . . . . . . 2
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Relationship to the Remote Network Monitoring MIB. . . . . . . 2
4. MPLS layer protocol identifiers . . . . . . . . . . . . . . . 2
5. IPv6 Protocols . . . . . . . . . . . . . . . . . . . . . . . . 3
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 7
Full Copyright Statement. . . . . . . . . . . .. . . . . . . . 8
1. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410]. Managed objects are accessed via a virtual
information store, termed the Management Information Base or MIB. MIB
objects are generally accessed through the Simple Network Management
Protocol (SNMP). Objects in the MIB are defined using the mechanisms
defined in the Structure of Management Information (SMI). This memo
specifies a MIB module that is compliant to the SMIv2, which is
described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579]
and STD 58, RFC 2580 [RFC2580].
2. Overview
This memo defines basic protocol identifiers for IP version 6 and
MPLS protocols.
The "Remote Network Monitoring MIB Protocol Identifier Macros"
[RFC2896], defines various protocol identifiers. The syntax of the
protocol identifier descriptor is defined in the RMON Protocol
Identifier Reference [RFC2895]. The reader should be familiar with
these documents.
The intent of this document is not to adapt each protocol identifier
defined in the RFC 2895 and in the RFC 2896 to IP version 6, but to
define protocol identifiers for IP version 6 protocols and for MPLS
protocol.
3. Relationship to the Remote Network Monitoring MIB
RMON MIB implementations use protocol identifiers to describe
unambiguous capabilities in protocolDirTable entries.
4. MPLS layer protocol identifiers
This section defines protocol identifiers for MPLS with unambiguous
names to distinguish MPLS Unicast from MPLS Multicast.
-- MPLS unicast
mplsu PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"MPLS Label Stack Encoding."
CHILDREN
"Children of MPLS are not systematically identifiable. "
REFERENCE
"RFC 3032, MPLS Label Stack Encoding [RFC3032]."
::= {
ether2 0x8847, -- RFC 3032 section 5
snap 0x8847,
802-1Q 0x8847,
ppp 0x0281, -- RFC 3032 section 4.3
}
-- MPLS multicast
mplsm PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"MPLS Label Stack Encoding."
CHILDREN
"Children of MPLS are not systematically identifiable."
REFERENCE
"RFC 3032, MPLS Label Stack Encoding [RFC3032]."
::= {
ether2 0x8848, -- RFC 3032 section 5
snap 0x8848,
802-1Q 0x8848,
ppp 0x0283, -- RFC 3032 section 4.3
}
5. IPv6 Protocols
ip6 PROTOCOL-IDENTIFIER
PARAMETERS {}
ATTRIBUTES {}
DESCRIPTION
"The protocol identifiers for the Internet Protocol, Version 6
[RFC2460]."
CHILDREN
"Children of 'ip6' are selected by the value in the Protocol
field (one octet), as defined in the PROTOCOL NUMBERS table
within the Assigned Numbers Document.
The value of the Protocol field is encoded in an octet string as
[ 0.0.0.a ], where 'a' is the protocol field.
Children of 'ip6' are encoded as [ 0.0.0.a ], and named as 'ip6
a' where 'a' is the protocol field value. For example, a
protocolDirID-fragment value of:
0.0.0.1.0.0.0.41.0.0.0.58
defines an encapsulation of IPv6-ICMP (ether2.ip6.icmp6)"
ADDRESS-FORMAT
"16 octets of the IPv6 address, in network byte order. Each ip
packet contains two addresses, the source address and the
destination address."
DECODING
"Note: ether2.ip.ipip6.udp is a different protocolDirID than
ether2.ip6.udp, as identified in the protocolDirTable. As such,
two different local protocol index values will be assigned by
the agent. E.g., (full INDEX values shown):
ether2.ip.ipip6.udp =
16.0.0.0.1.0.0.8.0.0.0.0.41.0.0.0.17.4.0.0.0.0
ether2.ip6.udp =
12.0.0.0.1.0.0.0.41.0.0.0.17.3.0.0.0 "
REFERENCE
"RFC 2460 [RFC2460] defines the Internet Protocol version 6; The
following URL defines the authoritative repository for the
PROTOCOL NUMBERS Table:
http://www.iana.org/assignments/protocol-numbers"
::= {
ether2 0x86DD,
802-1Q 0x86DD,
mplsu 41,
mplsm 41
}
ipip6 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
}
DESCRIPTION
"IPv6 in IPv4 Tunneling"
CHILDREN
"Children of 'ipip6' are selected and encoded in the same manner
as children of ip6."
ADDRESS-FORMAT
"The 'ipip6' address format is the same as the IPv6 address
format."
DECODING
"Note: ether2.ip.ipip6.udp is a different protocolDirID than
ether2.ip6.udp, as identified in the protocolDirTable. As such,
two different local protocol index values will be assigned by
the agent. E.g., (full INDEX values shown):
ether2.ip.ipip6.udp =
16.0.0.0.1.0.0.8.0.0.0.0.41.0.0.0.17.4.0.0.0.0
ether2.ip6.udp =
12.0.0.0.1.0.0.0.41.0.0.0.17.3.0.0.0 "
REFERENCE
"RFC 2473 [RFC2473] defines Generic Packet Tunneling in IPv6
Specification."
::= {
ip 41
}
icmp6 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Internet Message Control Protocol for IP Version 6"
REFERENCE
"RFC 2463 [RFC2463] Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6) Specification "
::= {
ip6 58,
ipip6 58
}
6. Security Considerations
This document contains textual descriptions of well-known networking
protocols, not the definition of any networking behavior. As such,
no security considerations are raised by its publication.
7. Acknowledgments
The authors would like to acknowledge the European Commission support
in the co-funding of the 6QM project, where this work is being
developed.
8. References
8.1. Normative References
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2463] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[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.
[RFC2895] Bierman, A., Bucci, C., and R. Iddon, "Remote Network
Monitoring MIB Protocol Identifier Reference", RFC 2895,
August 2000.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
8.2. Informative References
[RFC2021] Waldbusser, S., "Remote Network Monitoring Management
Information Base Version 2 using SMIv2", RFC 2021, January
1997.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2896] Bierman, A., Bucci, C., and R. Iddon, "Remote Network
Monitoring MIB Protocol Identifier Macros", RFC 2896,
August 2000.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
Authors' Addresses
Stephan Emile
France Telecom R & D
2 avenue Pierre Marzin
Lannion, F-22307
Fax: +33 2 96 05 18 52
EMail: emile.stephan@francetelecom.com
Jordi Palet
Consulintel, IPv6 R&D
San Jose Artesano, 1
Alcobendas, Madrid, Spain E-28108
Fax: +34 91 151 81 98
EMail: jordi.palet@consulintel.es
Full Copyright Statement
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
AI ELI5
On this page
§1Protocol Identifiers in Network Monitoring
RMON is a management framework that allows network monitoring tools to observe and report on network traffic. A key part of RMON is the protocolDirTable, which lists the network protocols present on a monitored link and describes their relationships. For example, an entry in this table might identify Ethernet frames carrying IP, and a child entry might identify UDP packets inside those IP packets.
RFC 2896 defined protocol identifier macros for many common protocols using the syntax defined in RFC 2895. However, those definitions covered IPv4 and older technologies but not IPv6 or MPLS, which have become increasingly important. RFC 3919 extends these definitions to include IPv6, IPv6-in-IPv4 tunneling, and MPLS (both unicast and multicast variants).
These protocol identifiers are not required to implement RMON-2: a compliant monitoring tool could function without them. However, providing these identifiers improves interoperability and clarity, allowing different monitoring tools to report on the same traffic in consistent ways.
Network monitors need to say: I see Ethernet carrying IPv6 with UDP inside. Before this memo, they had no standard way to describe IPv6 and MPLS. Now they do.
§2How Protocol Identifiers Work
A protocol identifier is a description of a protocol layer and its parameters. Each identifier defines a CHILDREN property, describing which protocol types can appear inside it. For example, the identifier for Ethernet defines children including IPv4, IPv6, and MPLS. Each child protocol inherits the structure and is indexed according to standardized tables.
Protocol identifiers also define an ADDRESS-FORMAT, specifying how addresses in that protocol layer are represented when monitoring tools report on traffic flows. For IPv6, addresses are 16 octets, stored in network byte order. The source and destination address appear in each IPv6 packet.
Identifiers define a DECODING section that explains how the protocol is recognized in practice. For example, an IPv6 packet over Ethernet is identified by the EtherType 0x86DD. When IPv6 is tunneled inside IPv4 (protocol number 41), monitoring tools must treat the tunnel as a distinct protocol layer.
Each protocol is like a labeled box: the label says what it is, what can fit inside it, and how to tell it apart from other boxes.
§3IPv6 Protocol Identifiers
The ip6 protocol identifier covers the Internet Protocol Version 6 as defined in RFC 2460. IPv6 packets can be carried over Ethernet (EtherType 0x86DD), over 802.1Q VLAN frames (also 0x86DD), and over MPLS (protocol number 41). The identifier's CHILDREN are determined by the value in the IPv6 Next Header field, which points to the protocol type of the payload (such as 58 for ICMPv6).
Addresses in IPv6 are 16 octets, comprising a source address and a destination address. Monitoring tools use these addresses to identify communication flows between hosts.
The RFC also defines ipip6, the protocol identifier for IPv6 packets tunneled inside IPv4 packets. This is a transitional mechanism that allows IPv6 hosts to communicate over IPv4-only networks. IPv6-in-IPv4 appears as IPv4 protocol number 41. When encapsulated in IPv4, the IPv6 payload retains its own addressing and protocol identification, so monitoring tools must treat the tunnel as a distinct protocol layer.
The RFC defines icmp6 as a child of both ip6 and ipip6, pointing to protocol number 58 (ICMPv6, the control protocol for IPv6).
IPv6 is a new address system with 16-byte addresses. It can ride inside Ethernet, 802.1Q, or MPLS. When IPv6 is hidden inside IPv4 (tunneling), monitors see a separate layer and must decode both layers.
§4MPLS Protocol Identifiers
MPLS is a forwarding mechanism that simplifies how packets move through networks. Instead of examining destination IP addresses at each router, MPLS routers read short labels and forward packets accordingly. This allows faster forwarding and enables traffic engineering.
MPLS packets are identified by an EtherType value (0x8847 for unicast, 0x8848 for multicast) when carried over Ethernet or 802.1Q. Over PPP links, MPLS uses protocol numbers 0x0281 (unicast) and 0x0283 (multicast).
The RFC defines two protocol identifiers: mplsu for MPLS Unicast and mplsm for MPLS Multicast. Both are references to RFC 3032 (MPLS Label Stack Encoding) and cover the same protocol but with different forwarding models.
A key limitation is that children of MPLS are not systematically identifiable. Because MPLS labels can hide various protocol types, monitoring tools cannot automatically determine what protocol type carries the traffic inside an MPLS label without special configuration or knowledge of how the label is used in a particular network.
MPLS is like a subway token: instead of checking the destination, the clerk just looks at the token number and sends you to the right train. MPLS tokens can carry IPv4, IPv6, or anything else, but the monitor cannot always tell what is inside.
§5Use in Monitoring and Management
Network monitoring tools use these protocol identifiers to populate the RMON protocolDirTable. When an agent scans a monitored link, it discovers which protocols are present and reports them using these identifiers. A monitoring station can then query the table to understand the protocol stack: for example, discovering that Ethernet carries both IPv4 and IPv6, and that IPv6 appears both natively and tunneled inside IPv4.
These identifiers enable RMON-2 agents to classify traffic flows by protocol layer, count packets and bytes by protocol type, and create filters for monitoring specific protocol combinations. For example, a monitoring tool might report how many IPv6 ICMPv6 packets were exchanged between two hosts, or how many MPLS-labeled packets are being forwarded.
The protocol identifiers follow the established RMON framework defined in RFC 2895 and RFC 2896, ensuring compatibility with existing monitoring tools and management stations. Tools that already implement RMON-2 can adopt these identifiers without architectural changes.
When you set up a network monitor, it builds a catalog of what it sees on the wire. With these definitions, it can now catalog IPv6 and MPLS traffic the same way it catalogs IPv4.