RFC 2895
Remote Network Monitoring MIB Protocol Identifier Reference
Part 1 of 9 🎀
RFC 2895: Remote Network Monitoring MIB Protocol Identifier Reference 🦋
okay bestie, so this is RFC 2895, a Standards Track doc from August 2000 💅 It was written by A. Bierman (Cisco Systems, Inc.), C. Bucci (Cisco Systems, Inc.), and R. Iddon (3Com, Inc.) 🫶 It obsoletes RFC 2074, which was the first version of the RMON Protocol Identifiers doc. This one takes the standards-track reference bits and leaves the non-normative stuff to a different doc. It's giving clean, targeted, no-drama spec energy ✨
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 🌸
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. 🔥
Abstract
okay so the main vibe here is that this memo defines a notation for describing protocol layers inside a protocol encapsulation 🧚 It's specifically built for encoding INDEX values in the protocolDirTable, which lives in the RMON-2 MIB (Remote Network Monitoring Management Information Base) [RFC2021]. It also includes definitions for the standard protocol directory base layer identifiers 💜
The first version of the RMON Protocol Identifiers Document [RFC2074] got split up into two pieces. This doc is the standards-track Reference portion, and there's also an Informational document. The RMON Protocol Identifier Macros document [RFC2896] now holds the non-normative portion of that spec 🍓
And yes, this document obsoletes RFC 2074 💖
Table of Contents
1 The SNMP Network Management Framework .......................... 3
2 Overview ....................................................... 3
2.1 Terms ........................................................ 4
2.2 Relationship to the Remote Network Monitoring MIB ............ 6
2.3 Relationship to the RMON Protocol Identifier Macros Document . 6
2.4 Relationship to the ATM-RMON MIB ............................. 7
2.4.1 Port Aggregation ........................................... 7
2.4.2 Encapsulation Mappings ..................................... 7
2.4.3 Counting ATM Traffic in RMON-2 Collections ................. 8
2.5 Relationship to Other MIBs ................................... 9
3 Protocol Identifier Encoding ................................... 9
3.1 ProtocolDirTable INDEX Format Examples ....................... 11
3.2 Protocol Identifier Macro Format ............................. 12
3.2.1 Lexical Conventions ........................................ 12
3.2.2 Notation for Syntax Descriptions ........................... 13
3.2.3 Grammar for the PI Language ................................ 13
3.2.4 Mapping of the Protocol Name ............................... 15
3.2.5 Mapping of the VARIANT-OF Clause ........................... 16
3.2.6 Mapping of the PARAMETERS Clause ........................... 17
3.2.6.1 Mapping of the 'countsFragments(0)' BIT .................. 18
3.2.6.2 Mapping of the 'tracksSessions(1)' BIT ................... 18
3.2.7 Mapping of the ATTRIBUTES Clause ........................... 18
3.2.8 Mapping of the DESCRIPTION Clause .......................... 19
3.2.9 Mapping of the CHILDREN Clause ............................. 19
3.2.10 Mapping of the ADDRESS-FORMAT Clause ...................... 20
3.2.11 Mapping of the DECODING Clause ............................ 20
3.2.12 Mapping of the REFERENCE Clause ........................... 20
3.3 Evaluating an Index of the ProtocolDirTable .................. 21
4 Base Layer Protocol Identifier Macros .......................... 22
4.1 Base Identifier Encoding ..................................... 22
4.1.1 Protocol Identifier Functions .............................. 22
4.1.1.1 Function 0: None ......................................... 23
4.1.1.2 Function 1: Protocol Wildcard Function ................... 23
4.2 Base Layer Protocol Identifiers .............................. 24
4.3 Encapsulation Layers ......................................... 31
4.3.1 IEEE 802.1Q ................................................ 31
5 Intellectual Property .......................................... 34
6 Acknowledgements ............................................... 35
7 References ..................................................... 35
8 IANA Considerations ............................................ 39
9 Security Considerations ........................................ 39
10 Authors' Addresses ............................................ 40
Appendix A ....................................................... 41
11 Full Copyright Statement ...................................... 421. The SNMP Network Management Framework 🧚
so the SNMP Management Framework is currently made up of five major components 💅
- An overall architecture, described in RFC 2571 [RFC2571].
- Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
- Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
- Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905].
- A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575].
if you want a deeper intro to the current SNMP Management Framework, go read RFC 2570 [RFC2570] 🦋
managed objects get accessed through a virtual information store called the Management Information Base, or MIB. Objects in the MIB get defined using the mechanisms in the SMI 🌈
This memo does not specify a MIB module. 🙈
2. Overview 🌸
the RMON-2 MIB [RFC2021] uses hierarchically formatted OCTET STRINGs to globally identify individual protocol encapsulations in the protocolDirTable 🍓
this guide has the algorithms and the authoritative set of base layer protocol identifier macros, which you use inside INDEX values in the protocolDirTable 💜
and this is the second revision of this doc. It's meant to replace the first half of the first RMON-2 Protocol Identifiers document [RFC2074] ✨
2.1. Terms
okay so first things first, the key words are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document, and they're to be read as described in RFC 2119 [RFC2119] 🔑✨
there are also a bunch of terms that get used all over this doc, plus the RMON-2 MIB [RFC2021], so let's meet them 🫶
parent protocol: Also called 'parent'. This is the encapsulating protocol identifier for a specific protocol layer. For example, IP is the parent protocol of UDP. Base layers can't have parent protocols, not ever 🙅♀️ The term can point at one specific encapsulating protocol, or it can be used generically for any encapsulating protocol.
child protocol: Also called 'child'. This is the encapsulated protocol identifier for a specific protocol layer. For example, UDP is a child protocol of IP. Like the parent, it can mean one specific encapsulated protocol or any encapsulated protocol in general 🎀
layer-identifier: An octet string fragment that represents a particular protocol encapsulation layer or sub-layer. A fragment is exactly four octets, encoded in network byte order. If present, the child layer-identifiers for a protocol MUST have unique values among each other. (See section 3.3 for more details.) This is a must-have, bestie, no exceptions 🔒
protocol: A particular protocol layer, as specified by the encoding rules in this document. It usually means a single layer in a given encapsulation. Heads up though, the RMON-2 MIB [RFC2021] sometimes uses this word for a fully-specified protocol-identifier string. In that case the string is named after its upper-most layer. A named protocol can also mean any encapsulation of that protocol 💅
protocol-identifier string: An octet string that represents a particular protocol encapsulation, as specified by the encoding rules in this document. The RMON-2 MIB [RFC2021] calls this the protocolDirID object. It's built from one or more layer-identifiers, read left to right. The left-most layer-identifier is the base layer encapsulation, and each layer-identifier to its right is a child layer protocol encapsulation 🌸
protocol-identifier macro: Also called a PI macro. This is a macro-like textual construct used to describe a particular networking protocol. Only the protocol attributes that matter for RMON use are documented. The word 'macro' is kind of a historical leftover, so PI macros aren't real macros, and they're not ASN.1 macros either 🙃 The current set of published RMON PI macros lives in the RMON Protocol Identifier Macros document [RFC2896].
The PI macro has a few jobs:
- Names the protocol for use within the RMON-2 MIB [RFC2021].
- Describes how the protocol is encoded into an octet string.
- Describes how child protocols are identified (if applicable), and encoded into an octet string.
- Describes which protocolDirParameters are allowed for the protocol.
- Describes how the associated protocolDirType object is encoded for the protocol.
- Provides reference(s) to authoritative documentation for the protocol.
protocol-variant-identifier macro: Also called a PI-variant macro. This is a special kind of PI macro, used to describe a particular protocol layer that can't be identified with a deterministic, and (usually) hierarchical structure, like most networking protocols have 🦋
The PI-variant macro and the PI-macro share one set of syntax rules (see section 3.2). The only difference is that different sub-clauses are required for each type.
A protocol identified with a PI-variant macro is really a variant of a well-known encapsulation that may be in the protocolDirTable. This is how the IANA-assigned protocols get documented. They need it because they can't be practically identified by examining 'appropriate network traffic' (for example, the packets that carry them). All other protocols, the ones you can identify by looking at appropriate network traffic, SHOULD be documented using the protocol-identifier macro. (See section 3.2 for details.) ✨
protocol-parameter: A single octet that corresponds to a specific layer-identifier in the protocol-identifier. This octet is a bit-mask that indicates special functions or capabilities the agent provides for that protocol. (See section 3.2.6 for details.) 🧚
protocol-parameters string: An octet string that contains one protocol-parameter for each layer-identifier in the protocol-identifier. The RMON-2 MIB [RFC2021] calls this the protocolDirParameters object. (See the section 3.2.6 for details.) 💜
protocolDirTable INDEX: A protocol-identifier and protocol-parameters octet string pair that has been converted into an INDEX value, following the encoding rules in section 7.7 of RFC 1902 [RFC1902] 🍓
pseudo-protocol: A convention or algorithm that's only used inside this document, for the purpose of encoding protocol-identifier strings 🙈
protocol encapsulation tree: Protocol encapsulations can be organized into an inverted tree. The root nodes are the base encapsulations. The child nodes of any node in the tree, if it has any, are the encapsulations of its child protocols. It's giving family tree 🌳
2.2. Relationship to the Remote Network Monitoring MIB
this doc is here to define the encoding rules for the OCTET STRING objects protocolDirID and protocolDirParameters 💖 RMON-2 tables, like the ones in the new Protocol Distribution, Host, and Matrix groups, don't use the full protocolDirTable INDEX strings. They use a local INTEGER INDEX (protocolDirLocalIndex) to identify protocols for counting purposes. Only the protocolDirTable uses the protocolDirID and protocolDirParameters strings described in this document.
this document is separate from the RMON-2 MIB objects [RFC2021] on purpose, so this document can be updated without republishing any MIB objects 🎀
this document doesn't cover auto-discovery and auto-population of the protocolDirTable. The RMON standard doesn't explicitly define that functionality. An agent SHOULD fill the directory with the 'interesting' protocols that the intended applications depend on 👑
2.3. Relationship to the RMON Protocol Identifier Macros Document
the original RMON Protocol Identifiers document [RFC2074] has the protocol directory reference material, plus a bunch of examples of protocol identifier macros 📚
those macros got moved into their own document, the RMON Protocol Identifier Macros document [RFC2896]. This lets the normative text (this document) move forward on the standards track with the RMON-2 MIB [RFC2021], while the collection of PI macros lives in an Informational RFC 🦋
the PI Macros document is separate from this one on purpose, so the list of published PI macros can be updated without republishing any MIB objects or encoding rules. Protocol Identifier macros submitted by the RMON working group and the wider community (to the RMONMIB WG mailing list at 'rmonmib@ietf.org') get collected, screened by the RMONMIB working group, and, if approved, added to a later version of the PI Macros document 💅
Macros submissions are collected in IANA's MIB files under the directory ftp://ftp.isi.edu/mib/rmonmib/rmon2_pi_macros/, and in the RMONMIB working group mailing list message archive file www.ietf.org/mail-archive/working-groups/rmonmib/current/maillist.htm 🌈
2.4. Relationship to the ATM-RMON MIB
the ATM Forum standardized "Remote Monitoring MIB Extensions for ATM Networks" (ATM-RMON MIB) [AF-NM-TEST-0080.000]. It gives you RMON-like stats, host, matrix, and matrixTopN capability for NSAP address-based (ATM Adaption Layer 5, AAL-5) cell traffic ⭐
2.4.1. Port Aggregation
it is possible to correlate ATM-RMON MIB data with packet-based RMON-2 [RFC2021] collections, but only if the ATM-RMON 'portSelGrpTable' and 'portSelTable' are configured to give the same level of port aggregation that the packet-based collection uses. For traditional RMON dataSources, this means an ATM-RMON 'portSelectGroup' has to contain a single port 🔥
2.4.2. Encapsulation Mappings
the RMON PI document doesn't have explicit PI macro support for "Multiprotocol Encapsulation over ATM Adaptation Layer 5" [RFC1483], or for the ATM Forum "LAN Emulation over ATM" (LANE) [AF-LANE-0021.000]. Instead, a probe has to 'fit' the ATM encapsulation into one of the base layers defined in this document (that's llc, snap, or vsnap). This is true no matter how the agent gets the raw data (for example VC-muxing vs. LLC-muxing, or routed vs. bridged formats). See section 3.2 for details on identifying and decoding a particular base layer 🧠
an NMS can figure out some of the leftover encapsulation details by checking the interface type (ifType) of the dataSource for a particular RMON collection:
RFC 1483 dataSource ifTypes:
- aal5(49)
LANE dataSource ifTypes:
- aflane8023(59)
- aflane8025(60)these dataSources need the ifStackTable from the Interfaces MIB [RFC2233] to be implemented. Some implementations might use dataSource values that show an ifType of 'atm(37)' (because they don't support the ifStackTable), but the RMONMIB WG strongly discourages that 🙅♀️
2.4.3. Counting ATM Traffic in RMON-2 Collections
the RMON-2 Application Layer (AL) and Network Layer (NL) (host/matrix/topN) tables need their octet counters to go up by the size of the actual frame, not by the size of the frame attributed to a given protocol 📦
probe implementations must use the AAL-5 frame size (not the AAL-5 payload size or the encapsulated MAC frame size) as the 'frame size' when incrementing RMON-2 octet counters (for example 'nlHostInOctets' or 'alHostOutOctets') 💯
the RMONMIB WG hasn't dealt with packet capture issues for AAL-5 based traffic yet. So it's up to the implementation whether padding octets (like RFC 1483 VC-muxed, bridged 802.3 or 802.5 traffic, or LANE traffic) show up in the RMON-1 'captureBufferPacketData' MIB object. Normally, the first octet of the captured frame is the first octet of the destination MAC address (DA) 🫧
2.5. Relationship to Other MIBs
the RMON Protocol Identifiers Reference document is meant for use with the protocolDirTable inside the RMON MIB. It isn't relevant to any other MIB, and it isn't intended for use with any other MIB 🍭
3. Protocol Identifier Encoding ✨
okay so the protocolDirTable is indexed by TWO OCTET STRINGs, protocolDirID and protocolDirParameters 💖. To encode the table index, each variable-length string gets turned into an OBJECT IDENTIFIER fragment, following the encoding rules in section 7.7 of RFC 1902 [RFC1902] 🧚. Then the index fragments just get smooshed together (concatenated) ✨. Peep figures 1a - 1d below for the full deets 👀.
protocolDirID is made of one or more 4-octet "layer-identifiers" 🦋. The whole string uniquely pins down one spot in the protocol encapsulation tree 🌳. The second OCTET STRING, protocolDirParameters, holds a matching number of 1-octet protocol-specific parameters, one for each 4-octet layer-identifier in the first string 💅.
A protocol layer is usually identified by a single 32-bit value 🎀. Each layer-identifier gets written as four sub-components [ a.b.c.d ], where 'a' through 'd' are the bytes of that 32-bit value in network byte order 🌸. If a protocol layer can't fit into 32 bits, then it must be defined as an 'ianaAssigned' protocol (more on that in a sec 👑).
The figures below show the difference between the OBJECT IDENTIFIER and OCTET STRING encodings of the protocol identifier string 🍓.
Fig. 1a
protocolDirTable INDEX Format
-----------------------------
+---+--------------------------+---+---------------+
| c ! | c ! protocolDir |
| n ! protocolDirID | n ! Parameters |
| t ! | t ! |
+---+--------------------------+---+---------------+ Fig. 1b
protocolDirTable OCTET STRING Format
------------------------------------
protocolDirID
+----------------------------------------+
| |
| 4 * N octets |
| |
+----------------------------------------+
protocolDirParameters
+----------+
| |
| N octets |
| |
+----------+N is the number of protocol-layer-identifiers needed for the entire encapsulation of the named protocol 🧁. Note that the layer following the base layer usually identifies a network layer protocol, but this is not always the case (most notably for children of the 'vsnap' base-layer) 🙈.
Fig. 1c
protocolDirTable INDEX Format Example
-------------------------------------
protocolDirID protocolDirParameters
+---+--------+--------+--------+--------+---+---+---+---+---+
| c | proto | proto | proto | proto | c |par|par|par|par|
| n | base | L(B+1) | L(B+2) | L(B+3) | n |ba-| L3| L4| L5|
| t |(+flags)| L3 | L4 | L5 | t |se | | | |
+---+--------+--------+--------+--------+---+---+---+---+---+ subOID
| 1 | 4 | 4 | 4 | 4 | 1 | 1 | 1 | 1 | 1 | countWhen encoded in a protocolDirTable INDEX, each of the two strings must be preceded by a length sub-component 🔥. In this example, N equals '4', the first 'cnt' field would contain the value '16', and the second 'cnt' field would contain the value '4' 💜.
Fig. 1d
protocolDirTable OCTET STRING Format Example
--------------------------------------------
protocolDirID
+--------+--------+--------+--------+
| proto | proto | proto | proto |
| base | L3 | L4 | L5 |
| | | | |
+--------+--------+--------+--------+ octet
| 4 | 4 | 4 | 4 | count
protocolDirParameters
+---+---+---+---+
|par|par|par|par|
|ba-| L3| L4| L5|
|se | | | |
+---+---+---+---+ octet
| 1 | 1 | 1 | 1 | countAlthough this example shows four encapsulated protocols, in practice any non-zero number of layer-identifiers may be present 🦋. The only real limit is the OBJECT IDENTIFIER length restrictions, as specified in section 3.5 of RFC 1902 [RFC1902] 💅.
3.1. ProtocolDirTable INDEX Format Examples
these PI identifier fragments are examples of some fully encoded protocolDirTable INDEX values for various encapsulations 🎀. Bestie, look at how the same protocol changes its numbers depending on what's underneath it 🌈.
-- HTTP; fragments counted from IP and above
ether2.ip.tcp.www-http =
16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.80.4.0.1.0.0
-- SNMP over UDP/IP over SNAP
snap.ip.udp.snmp =
16.0.0.0.3.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
-- SNMP over IPX over SNAP
snap.ipx.snmp =
12.0.0.0.3.0.0.129.55.0.0.144.15.3.0.0.0
-- SNMP over IPX over raw8023
ianaAssigned.ipxOverRaw8023.snmp =
12.0.0.0.5.0.0.0.1.0.0.144.15.3.0.0.0
-- IPX over LLC
llc.ipx =
8.0.0.0.2.0.0.0.224.2.0.0
-- SNMP over UDP/IP over any link layer
ether2.ip.udp.snmp
16.1.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
-- IP over any link layer; base encoding is IP over ether2
ether2.ip
8.1.0.0.1.0.0.8.0.2.0.0
-- AppleTalk Phase 2 over ether2
ether2.atalk
8.0.0.0.1.0.0.128.155.2.0.0
-- AppleTalk Phase 2 over vsnap
vsnap.apple-oui.atalk
12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.03.2. Protocol Identifier Macro Format
the following example is here to introduce the protocol-identifier macro 🧚. This macro-like construct is used to represent both protocols and protocol-variants, so it's kinda doing double duty 💖.
If the 'VariantOfPart' component of the macro is present, then the macro represents a protocol-variant instead of a protocol 🦋. This clause is currently used only for IANA assigned protocols, enumerated under the 'ianaAssigned' base-layer 🌸. The VariantOfPart component MUST be present for IANA assigned protocols 👑.
3.2.1. Lexical Conventions
The PI language defines the following keywords 🎀:
ADDRESS-FORMAT
ATTRIBUTES
CHILDREN
DECODING
DESCRIPTION
PARAMETERS
PROTOCOL-IDENTIFIER
REFERENCE
VARIANT-OFThe PI language defines the following punctuation elements 💅:
{ left curly brace
} right curly brace
( left parenthesis
) right parenthesis
, comma
::= two colons and an equal sign
-- two dashes3.2.2. Notation for Syntax Descriptions
An extended form of BNF notation is used to specify the syntax of the PI language 🌈. The rules for this notation are:
- Literal values are specified in quotes, for example
"REFERENCE" - Non-terminal items are surrounded by less than (<) and greater than (>) characters, for example
<parmList> - Terminal items are specified without surrounding quotes or less than and greater than characters, for example
'lcname' - A vertical bar (|) is used to indicate a choice between items, for example
'number | hstr' - Ellipsis are used to indicate that the previous item may be repeated one or more times, for example
<parm>... - Square brackets are used to enclose optional items, for example
[ "," <parm> ] - An equals character (=) is used to mean "defined as," for example
'<protoName> = pname'
3.2.3. Grammar for the PI Language
The following are "terminals" of the grammar. They're identical to the same lexical elements from the MIB module language, except for hstr and pname 🫶:
<lc> = "a" | "b" | "c" | ... | "z"
<uc> = "A" | "B" | "C" | ... | "Z"
<letter> = <lc> | <uc>
<digit> = "0" | "1" | ... | "9"
<hdigit> = <digit> | "a" | "A" | "b" | "B" | ... | "f" | "F"
<lcname> = <lc> [ <lcrest> ]
<lcrest> = ( <letter> | <digit> | "-" ) [ <lcrest> ]
<pname> = ( <letter> | <digit> ) [ <pnrest> ]
<pnrest> = ( <letter> | <digit> | "-" | "_" | "*" ) [ <pnrest> ]
<number> = <digit> [ <number> ] -- to a max dec. value of 4g-1
<hstr> = "0x" <hrest> -- to a max dec. value of 4g-1
<hrest> = <hdigit> [ <hrest> ]
<lf> = linefeed char
<cr> = carriage return char
<eoln> = <cr><lf> | <lf>
<sp> = " "
<tab> = " "
<wspace> = { <sp> | <tab> | <eoln> } [<wspace>]
<string> = """ [ <strest> ] """
<strest> = ( <letter> | <digit> | <wspace> ) [ <strest> ]The following is the extended BNF notation for the grammar, with starting symbol <piFile> 🍓:
-- a file containing one or more Protocol Identifier (PI)
-- definitions
<piFile> = <piDefinition>...
-- a PI definition
<piDefinition> =
<protoName> "PROTOCOL-IDENTIFIER"
[ "VARIANT-OF" <protoName> ]
"PARAMETERS" "{" [ <parmList> ] "}"
"ATTRIBUTES" "{" [ <attrList> ] "}"
"DESCRIPTION" string
[ "CHILDREN" string ]
[ "ADDRESS-FORMAT" string ]
[ "DECODING" string ]
[ "REFERENCE" string ]
"::=" "{" <encapList> "}"
-- a protocol name
<protoName> = pname
-- a list of parameters
<parmList> = <parm> [ "," <parm> ]...
-- a parameter
<parm> = lcname [<wspace>] "(" [<wspace>]
<nonNegNum> [<wspace>] ")" [<wspace>]
-- list of attributes
<attrList> = <attr> [ [<wspace>] "," [<wspace>] <attr> ]...
-- an attribute
<attr> = lcname [<wspace>] "(" [<wspace>]
<nonNegNum> [<wspace>] ")"
-- a non-negative number
<nonNegNum> = number | hstr
-- list of encapsulation values
<encapList> = <encapValue> [ [<wspace>] ","
[<wspace>] <encapValue> ]...
-- an encapsulation value
<encapValue> = <baseEncapValue> | <normalEncapValue>
-- base encapsulation value
<baseEncapValue> = <nonNegNum>
-- normal encapsulation value
<normalEncapValue> = <protoName> <wspace> <nonNegNum>
-- comment
<two dashes> <text> <end-of-line>3.2.4. Mapping of the Protocol Name 🎀
okay so the protoName value, which we call the protocol name, shall be an ASCII string that's between one and 64 characters long, and it can only use these characters:
"A"through"Z""a"through"z""0"through"9"- dash (
-) - underbar (
_) - asterisk (
*) - plus (
+)
the first character has a stricter guest list, so it can only be one of these:
"A"through"Z""a"through"z""0"through"9"
this value SHOULD be the name or acronym that identifies the protocol 💖. case matters here, so FTP and ftp are NOT the same thing 🙈. the name SHOULD match the "most well-known" name or acronym for the protocol. for example, the document at
ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbersdefines the IP Protocol field values, so protocol-identifier macros for children of IP SHOULD be given names that match the protocol names in that authoritative doc ✨. same deal for UDP and TCP children: they SHOULD be given names that match the port number name assignments in:
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numberswhen the "well-known name" has characters that aren't allowed in protocol names, they MUST be changed to a dash (-) 💅. if the first character has to change, the protocol name gets a p stuck on the front, so the old first letter can become a dash.
for example, z39.50 becomes z39-50, and 914c/g becomes 914c-g. these are all legal protocol names:
ftp, ftp-data, whois++, sql*net, 3com-tsmux, ocs_cmualso, it's totally possible that different encapsulations of the same protocol (each one gets its own entry in the protocolDirTable) end up with the same protocol name 🦋. that's fine, because the protocolDirID INDEX value is what defines a particular protocol, not the protocol name string. the name is just a label, bestie.
3.2.5. Mapping of the VARIANT-OF Clause 🧚
this clause only shows up for IANA assigned protocols. it points at the protocol-identifier macro that's closest to this particular protocol, and that one's called the "reference protocol" 👑. a protocol-identifier macro MUST exist for the reference protocol. when this clause is there, the macro gets called a protocol-variant-identifier.
if the variant's semantics match the reference for a given clause (like CHILDREN or ADDRESS-FORMAT), then that clause SHOULD NOT be copied into the protocol-variant-identifier macro. no need to repeat yourself, periodt 💅.
here's the tricky bit: the PARAMETERS and ATTRIBUTES clauses MUST be present in a protocol-identifier. so the protocol-variant-identifier MUST still have an empty ParamList and AttrList (written as PARAMETERS {}), and the real ParamList and AttrList get looked up in the reference protocol-identifier macro instead 🌸.
also, if an ianaAssigned protocol is defined and it isn't a variant of any other documented protocol, then the regular protocol-identifier macro SHOULD be used, not the protocol-variant-identifier version 🫶.
3.2.6. Mapping of the PARAMETERS Clause 💜
the protocolDirParameters object lets an NMS switch expensive probe resources on and off 🔥. an agent might support a given parameter all the time, never, or only when the current resource load allows it.
the PARAMETERS clause is a list of bit definitions that can be encoded straight into the matching ProtocolDirParameters octet, in network byte order. zero or more bit definitions can show up. only bits 0-7 are valid encoding values. this clause defines the entire BIT set allowed for a given protocol, and a conforming agent may choose to implement a subset of zero or more of these PARAMETERS.
by convention, some common bit definitions get used across different protocols. those bit positions MUST NOT be used for other parameters, and they MUST be reserved if a given protocol doesn't use them ✨.
bits get encoded in a single octet. bit 0 is the high order (left-most) bit in the octet, and bit 7 is the low order (right-most) bit in the first octet. reserved bits and unspecified bits in the octet are set to zero.
Table 3.1 Reserved PARAMETERS Bits
------------------------------------
Bit Name Description
---------------------------------------------------------------------
0 countsFragments higher-layer protocols encapsulated within
this protocol will be counted correctly even
if this protocol fragments the upper layers
into multiple packets.
1 tracksSessions correctly attributes all packets of a protocol
which starts sessions on well known ports or
sockets and then transfers them to dynamically
assigned ports or sockets thereafter (e.g. TFTP).the PARAMETERS clause MUST be present in all protocol-identifier macro declarations, but it can be equal to zero (empty) 🍓.
3.2.6.1. Mapping of the 'countsFragments(0)' BIT 🦋
this bit tells you whether the probe is correctly attributing all fragmented packets of the specified protocol, even when the individual frames carrying that protocol can't be identified as fragments. the probe isn't required to actually hand any reassembled datagrams (for address-analysis, filtering, or anything else) over to the NMS, so don't expect that 🙈.
this bit MUST only be set in a protocolDirParameters octet that corresponds to a protocol supporting fragmentation and reassembly in some form. TCP packets aren't considered 'fragmented-streams', so TCP is not eligible, sorry TCP 💀.
this bit MAY be set in more than one protocolDirParameters octet within a protocolDirTable INDEX, in case an agent can count fragments at more than one protocol layer 🌈.
3.2.6.2. Mapping of the 'tracksSessions(1)' BIT 🧚
the 'tracksSessions(1)' bit tells you whether frames that are part of remapped sessions (like TFTP download sessions) get counted correctly by the probe. for a protocol like that, the probe usually has to analyze all packets received on the indicated interface and keep some state information around, like the remapped UDP port number for TFTP 👑.
the semantics of the 'tracksSessions' parameter don't depend on the other protocolDirParameters definitions, so this parameter MAY be combined with any other legal parameter configurations 💖.
3.2.7. Mapping of the ATTRIBUTES Clause ✨
the protocolDirType object gives an NMS an idea of what a probe can decode for a given protocol, or the general attributes of that protocol 🔥.
the ATTRIBUTES clause is a list of bit definitions that get encoded into the matching instance of ProtocolDirType. the BIT definitions are specified in the SYNTAX clause of the protocolDirType MIB object.
Table 3.2 Reserved ATTRIBUTES Bits
------------------------------------
Bit Name Description
---------------------------------------------------------------------
0 hasChildren indicates that there may be children of
this protocol defined in the protocolDirTable
(by either the agent or the manager).
1 addressRecognitionCapable
indicates that this protocol can be used
to generate host and matrix table entries.the ATTRIBUTES clause MUST be present in all protocol-identifier macro declarations, but it MAY be empty 🫶.
3.2.8. Mapping of the DESCRIPTION Clause 🌸
the DESCRIPTION clause gives a text description of the protocol that this macro identifies. heads up though: it SHOULD NOT include details about stuff covered by the CHILDREN, ADDRESS-FORMAT, DECODING and REFERENCE clauses 🙅♀️.
the DESCRIPTION clause MUST be present in all protocol-identifier macro declarations 💅.
3.2.9. Mapping of the CHILDREN Clause 🍓
the CHILDREN clause describes child protocols for protocols that support them 🦋. it has three sub-sections:
- details on the field(s)/value(s) used to select the child protocol, and how that selection happens
- details on how those value(s) are encoded in the protocol identifier octet string
- details on how child protocols get named with respect to their parent protocol label(s)
the CHILDREN clause MUST be present in all protocol-identifier macro declarations where the 'hasChildren(0)' BIT is set in the ATTRIBUTES clause 🔥.
3.2.10. Mapping of the ADDRESS-FORMAT Clause 🧚
the ADDRESS-FORMAT clause describes the OCTET-STRING format(s) used when encoding addresses 🌈.
this clause MUST be present in all protocol-identifier macro declarations where the 'addressRecognitionCapable(1)' BIT is set in the ATTRIBUTES clause 👑.
3.2.11. Mapping of the DECODING Clause 💜
the DECODING clause describes the decoding procedure for the specified protocol. it has useful decoding hints for the implementor, but it SHOULD NOT over-replicate information that's already in the documents cited in the REFERENCE clause. it might contain a complete description of any decoding information required ✨.
for 'extensible' protocols (where the 'hasChildren(0)' BIT is set), this includes offset and type info for the field(s) used for child selection, plus info on figuring out where the child protocol starts 🫶.
for 'addressRecognitionCapable' protocols, this includes offset and type info for the field(s) used to generate addresses 🌸.
the DECODING clause is optional, and it MAY be omitted if the REFERENCE clause already points to decoding info for the specified protocol 💖.
3.2.12. Mapping of the REFERENCE Clause 🎀
if a publicly available reference document exists for this protocol, it SHOULD be listed here 🦋. typically that's a URL if possible. if not, it's the name and address of the controlling body.
the CHILDREN, ADDRESS-FORMAT, and DECODING clauses SHOULD limit how much information they pull from an authoritative document, like the Assigned Numbers document [RFC1700]. any duplication or paraphrasing should be brief and consistent with that authoritative document 🙈.
the REFERENCE clause is optional, but it SHOULD be implemented if an authoritative reference exists for the protocol (especially for standard protocols) 👑.
3.3. Evaluating an Index of the ProtocolDirTable ✨
Okay bestie, this part is all about how you read a protocolDirTable INDEX 🔍. The evaluation happens after the INDEX value has been turned into two OCTET STRINGs, using the INDEX encoding rules from the SMI [RFC1902] 💖.
Protocol-identifiers get checked left to right, starting with the protocolDirID. Its length MUST be evenly divisible by four 🧮, and the protocolDirParameters length MUST be exactly one quarter of the protocolDirID string length 🎀.
Parsing starts with the base layer identifier, which MUST be present 🌸, and then keeps going through one or more upper layer identifiers until every OCTET of the protocolDirID has been used ✨. Layers MUST NOT be skipped, so stuff like 'SNMP over IP' or 'TCP over ether2' can not exist 🙈.
The base-layer-identifier also carries a 'special function identifier' that may apply to the rest of the protocol identifier 🧚.
Wild-carding at the base layer within a protocol encapsulation is the only supported special function at this time. (See section 4.1.1.2 for details.) 💅
Once the protocol-identifier string (the value of protocolDirID) has been parsed, each octet of the protocol-parameters string gets evaluated and applied to the matching protocol layer 🦋.
A protocol-identifier label MAY map to more than one value. Like, 'ip' maps to 5 distinct values, one for each supported encapsulation. (see the 'IP' section under 'L3 Protocol Identifiers' in the RMON Protocol Identifier Macros document [RFC2896].) 👑
It is important to note that these macros are conceptually expanded at implementation time, not at run time. ⭐
If you substitute every possible value of each label for each child protocol, you get a list of all possible protocol-identifiers 🌈. So 'ip' would result in 5 distinct protocol-identifiers. Likewise each child of 'ip' would map to at least 5 protocol-identifiers, one for each encapsulation (e.g. ip over ether2, ip over LLC, etc.) 💜.
4. Base Layer Protocol Identifier Macros 🎀
The following PROTOCOL IDENTIFIER macros can be used to construct protocolDirID and protocolDirParameters strings 🧩.
An identifier is encoded by constructing the base-identifier, then adding one layer-identifier for each encapsulated protocol 🦋.
Refer to the RMON Protocol Identifier Macros document [RFC2896] for a listing of the non-base layer PI macros published by the working group 📚. Note that other PI macro documents may exist, and it should be possible for an implementor to populate the protocolDirTable without the use of the PI Macro document [RFC2896] 🫶.
4.1. Base Identifier Encoding 🌸
The first layer encapsulation is called the base identifier, and it contains optional protocol-function information and the base layer (e.g. MAC layer) enumeration value used in this protocol identifier ✨.
The base identifier is encoded as four octets, as shown in figure 2 🧮.
Fig. 2
base-identifier format
+---+---+---+---+
| | | | |
| f |op1|op2| m |
| | | | |
+---+---+---+---+ octet
| 1 | 1 | 1 | 1 | countThe first octet ('f') is the special function code, found in table 4.1. The next two octets ('op1' and 'op2') are operands for the indicated function. If not used, an operand must be set to zero. The last octet, 'm', is the enumerated value for a particular base layer encapsulation, found in table 4.2. All four octets are encoded in network-byte-order 💖.
4.1.1. Protocol Identifier Functions 🔥
The base layer identifier contains information about any special functions to perform during collections of this protocol, as well as the base layer encapsulation identifier 👑.
The first three octets of the identifier contain the function code and two optional operands. The fourth octet contains the particular base layer encapsulation used in this protocol (fig. 2) 🌈.
Table 4.1 Assigned Protocol Identifier Functions
-------------------------------------------------
Function ID Param1 Param2
----------------------------------------------------
none 0 not used (0) not used (0)
wildcard 1 not used (0) not used (0)4.1.1.1. Function 0: None 🍓
If the function ID field (1st octet) is equal to zero, the 'op1' and 'op2' fields (2nd and 3rd octets) must also be equal to zero. This special value indicates that no functions are applied to the protocol identifier encoded in the remaining octets. The identifier represents a normal protocol encapsulation 💅.
4.1.1.2. Function 1: Protocol Wildcard Function 🦄
The wildcard function (function-ID = 1) is used to aggregate counters, by using a single protocol value to indicate potentially many base layer encapsulations of a particular network layer protocol. A protocolDirEntry of this type will match any base-layer encapsulation of the same network layer protocol 🧚.
The 'op1' field (2nd octet) is not used and MUST be set to zero 🙈.
The 'op2' field (3rd octet) is not used and MUST be set to zero 🙈.
Each wildcard protocol identifier MUST be defined in terms of a 'base encapsulation'. This SHOULD be as 'standard' as possible for interoperability purposes. The lowest possible base layer value SHOULD be chosen. So, if an encapsulation over 'ether2' is permitted, then this should be used as the base encapsulation. If not, then an encapsulation over LLC should be used, if permitted. And so on for each of the defined base layers 🎀.
It should be noted that an agent does not have to support the non-wildcard protocol identifier over the same base layer. For instance, a token ring only device would not normally support IP over the ether2 base layer. Nevertheless, it should use the ether2 base layer for defining the wildcard IP encapsulation. The agent MAY also support counting some or all of the individual encapsulations for the same protocols, in addition to wildcard counting. Note that the RMON-2 MIB [RFC2021] does not require that agents maintain counters for multiple encapsulations of the same protocol. It is an implementation-specific matter as to how an agent determines which protocol combinations to allow in the protocolDirTable at any given time 🌸.
4.2. Base Layer Protocol Identifiers 💜
The base layer is mandatory, and defines the base encapsulation of the packet and any special functions for this identifier 👑.
There are no suggested protocolDirParameters bits for the base layer 🫶.
The suggested value for the ProtocolDirDescr field for the base layer is given by the corresponding "Name" field in table 4.2 below. However, implementations are only required to use the appropriate integer identifier values 💅.
For most base layer protocols, the protocolDirType field should contain bits set for the 'hasChildren(0)' and 'addressRecognitionCapable(1)' attributes. However, the special 'ianaAssigned' base layer should have no parameter or attribute bits set 🌈.
By design, only 255 different base layer encapsulations are supported. There are five base encapsulation values defined at this time. Very few new base encapsulations (e.g. for new media types) are expected to be added over time ⭐.
Table 4.2 Base Layer Encoding Values
--------------------------------------
Name ID
------------------
ether2 1
llc 2
snap 3
vsnap 4
ianaAssigned 5-- Ether2 Encapsulation
ether2 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"DIX Ethernet, also called Ethernet-II."
CHILDREN
"The Ethernet-II type field is used to select child protocols.
This is a 16-bit field. Child protocols are deemed to start at
the first octet after this type field.
Children of this protocol are encoded as [ 0.0.0.1 ], the
protocol identifier for 'ether2' followed by [ 0.0.a.b ] where
'a' and 'b' are the network byte order encodings of the high
order byte and low order byte of the Ethernet-II type value.
For example, a protocolDirID-fragment value of:
0.0.0.1.0.0.8.0 defines IP encapsulated in ether2.
Children of ether2 are named as 'ether2' followed by the type
field value in hexadecimal. The above example would be declared
as:
ether2 0x0800"
ADDRESS-FORMAT
"Ethernet addresses are 6 octets in network order."
DECODING
"Only type values greater than 1500 decimal indicate Ethernet-II
frames; lower values indicate 802.3 encapsulation (see below)."
REFERENCE
"The authoritative list of Ether Type values is identified by the
URL:
ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers"
::= { 1 }-- LLC EncapsulationOkay bestie, the llc macro is next and it's a whole vibe 💅🎀
llc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"The Logical Link Control (LLC) 802.2 protocol."
CHILDREN
"The LLC Source Service Access Point (SSAP) and Destination
Service Access Point (DSAP) are used to select child protocols.
Each of these is one octet long, although the least significant
bit is a control bit and should be masked out in most situations.
Typically SSAP and DSAP (once masked) are the same for a given
protocol - each end implicitly knows whether it is the server or
client in a client/server protocol. This is only a convention,
however, and it is possible for them to be different. The SSAP
is matched against child protocols first. If none is found then
the DSAP is matched instead. The child protocol is deemed to
start at the first octet after the LLC control field(s).
Children of 'llc' are encoded as [ 0.0.0.2 ], the protocol
identifier component for LLC followed by [ 0.0.0.a ] where 'a' is
the SAP value which maps to the child protocol. For example, a
protocolDirID-fragment value of:
0.0.0.2.0.0.0.240
defines NetBios over LLC.
Children are named as 'llc' followed by the SAP value in
hexadecimal. So the above example would have been named:
llc 0xf0"
ADDRESS-FORMAT
"The address consists of 6 octets of MAC address in network
order. Source routing bits should be stripped out of the address
if present."
DECODING
"Notice that LLC has a variable length protocol header; there are
always three octets (DSAP, SSAP, control). Depending on the
value of the control bits in the DSAP, SSAP and control fields
there may be an additional octet of control information.
LLC can be present on several different media. For 802.3 and
802.5 its presence is mandated (but see ether2 and raw 802.3
encapsulations). For 802.5 there is no other link layer
protocol.
Notice also that the raw802.3 link layer protocol may take
precedence over this one in a protocol specific manner such that
it may not be possible to utilize all LSAP values if raw802.3 is
also present."
REFERENCE
"The authoritative list of LLC LSAP values is controlled by the
IEEE Registration Authority:
IEEE Registration Authority
c/o Iris Ringel
IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 2 }So llc is the LLC 802.2 protocol, and it's the parent for everything that rides on it 🧚 Its children get picked by the SSAP and DSAP fields, which are each one octet long. The least significant bit in each is a control bit, and you should mask it out in most cases. Usually the SSAP and DSAP match once masked, since each end just knows if it's the client or the server. It's only a convention though, so they can totally be different 🙈 The SSAP gets checked against child protocols first, and if nothing matches, the DSAP gets a turn. The child starts at the first octet after the LLC control field(s).
Children of llc are encoded as [ 0.0.0.2 ] (the llc component) followed by [ 0.0.0.a ], where a is the SAP value for the child. So a protocolDirID-fragment of 0.0.0.2.0.0.0.240 is NetBios over LLC 🍓 Children are named llc plus the SAP value in hex, so that one is llc 0xf0.
For addresses, you get 6 octets of MAC address in network order, and source routing bits get stripped out if they're there ✨
For decoding, LLC's header is variable length. There are always three octets (DSAP, SSAP, control), and depending on the control bits there might be one more octet of control info 💜 LLC shows up on a few media. It's mandated on 802.3 and 802.5 (but check out ether2 and raw 802.3 encapsulations), and on 802.5 there's no other link layer protocol. Also, raw802.3 might take priority over llc in a protocol-specific way, which means you might not be able to use every LSAP value if raw802.3 is present too 😭
For the reference, the official list of LLC LSAP values is controlled by the IEEE Registration Authority, c/o Iris Ringel, IEEE Standards Dept, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331, Phone +1 908 562 3813, Fax: +1 908 562 1571 📞
snap is next, and it's basically the sequel to llc 🦋 Here's the macro:
snap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"The Sub-Network Access Protocol (SNAP) is layered on top of LLC
protocol, allowing Ethernet-II protocols to be run over a media
restricted to LLC."
CHILDREN
"Children of 'snap' are identified by Ethernet-II type values;
the SNAP Protocol Identifier field (PID) is used to select the
appropriate child. The entire SNAP protocol header is consumed;
the child protocol is assumed to start at the next octet after
the PID.
Children of 'snap' are encoded as [ 0.0.0.3 ], the protocol
identifier for 'snap', followed by [ 0.0.a.b ] where 'a' and 'b'
are the high order byte and low order byte of the Ethernet-II
type value.
For example, a protocolDirID-fragment value of:
0.0.0.3.0.0.8.0
defines the IP/SNAP protocol.
Children of this protocol are named 'snap' followed by the
Ethernet-II type value in hexadecimal. The above example would
be named:
snap 0x0800"
ADDRESS-FORMAT
"The address format for SNAP is the same as that for LLC"
DECODING
"SNAP is only present over LLC. Both SSAP and DSAP will be 0xAA
and a single control octet will be present. There are then three
octets of Organizationally Unique Identifier (OUI) and two octets
of PID. For this encapsulation the OUI must be 0x000000 (see
'vsnap' below for non-zero OUIs)."
REFERENCE
"SNAP Identifier values are assigned by the IEEE Standards
Office. The address is:
IEEE Registration Authority
c/o Iris Ringel
IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 3 }So snap is SNAP layered over LLC, which lets Ethernet-II protocols run over a media that only supports LLC ✨ Its children are picked by Ethernet-II type values using the SNAP PID field. The whole SNAP header gets consumed, and the child starts at the next octet after the PID.
Children of snap are encoded as [ 0.0.0.3 ] (the snap component) followed by [ 0.0.a.b ], where a and b are the high and low order bytes of the Ethernet-II type. So 0.0.0.3.0.0.8.0 is IP/SNAP 🌈 Children get named snap plus the Ethernet-II type in hex, so that example is snap 0x0800.
The address format is the same as for LLC 💅
For decoding, SNAP only shows up over LLC. Both SSAP and DSAP are 0xAA, and there's one control octet. After that come three octets of OUI and two octets of PID. For this encapsulation the OUI has to be 0x000000 (for non-zero OUIs, see vsnap below) 👑
The SNAP Identifier values are assigned by the IEEE Standards Office, at the same IEEE Registration Authority address as before: c/o Iris Ringel, IEEE Standards Dept, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331, Phone +1 908 562 3813, Fax: +1 908 562 1571 🫶
Now vsnap, the vendor SNAP one 🌸
vsnap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"This pseudo-protocol handles all SNAP packets which do not have
a zero OUI. See 'snap' above for details of those that have a
zero OUI value."
CHILDREN
"Children of 'vsnap' are selected by the 3 octet OUI; the PID is
not parsed; child protocols are deemed to start with the first
octet of the SNAP PID field, and continue to the end of the
packet. Children of 'vsnap' are encoded as [ 0.0.0.4 ], the
protocol identifier for 'vsnap', followed by [ 0.a.b.c ] where
'a', 'b' and 'c' are the 3 octets of the OUI field in network
byte order.
For example, a protocolDirID-fragment value of:
0.0.0.4.0.8.0.7 defines the Apple-specific set of protocols
over vsnap.
Children are named as 'vsnap <OUI>', where the '<OUI>' field is
represented as 3 octets in hexadecimal notation.
So the above example would be named:
'vsnap 0x080007'"
ADDRESS-FORMAT
"The LLC address format is inherited by 'vsnap'. See the 'llc'
protocol identifier for more details."
DECODING
"Same as for 'snap' except the OUI is non-zero and the SNAP
Protocol Identifier is not parsed."
REFERENCE
"SNAP Identifier values are assigned by the IEEE Standards
Office. The address is:
IEEE Registration Authority
c/o Iris Ringel
IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 4 }vsnap is the catch-all for every SNAP packet that has a non-zero OUI 💖 It's not really a protocol itself. Its children are selected by the 3-octet OUI, and the PID never gets parsed. The child starts at the first octet of the SNAP PID field and runs to the end of the packet.
Children of vsnap are encoded as [ 0.0.0.4 ] (the vsnap component) followed by [ 0.a.b.c ], with a, b and c being the three OUI octets in network byte order. So 0.0.0.4.0.8.0.7 gets you the Apple-specific set of protocols over vsnap 🍎 These are named vsnap <OUI>, with the OUI written as 3 hex octets, so that example is vsnap 0x080007.
The address format gets inherited from llc, so check out the llc macro for the details 🧚
Decoding is the same as snap, except the OUI is non-zero and the SNAP PID doesn't get parsed 💅
The SNAP Identifier values are assigned by the IEEE Standards Office, same address again: c/o Iris Ringel, IEEE Standards Dept, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331, Phone +1 908 562 3813, Fax: +1 908 562 1571 ✨
Next is ianaAssigned, which is kinda the odd one out 🦋
ianaAssigned PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"This branch contains protocols which do not conform easily to
the hierarchical format utilized in the other link layer
branches. Usually, such a protocol 'almost' conforms to a
particular 'well-known' identifier format, but additional
criteria are used (e.g. configuration-based), making protocol
identification difficult or impossible by examination of
appropriate network traffic (preventing the any 'well-known'
protocol-identifier macro from being used).
Sometimes well-known protocols are simply remapped to a different
port number by one or more venders (e.g. SNMP). These protocols
can be identified with the 'limited extensibility' feature of the
protocolDirTable, and do not need special IANA assignments.
A centrally located list of these enumerated protocols must be
maintained by IANA to insure interoperability. (See section 2.3
for details on the document update procedure.) Support for new
link-layers will be added explicitly, and only protocols which
cannot possibly be represented in a better way will be considered
as 'ianaAssigned' protocols.
IANA protocols are identified by the base-layer-selector value [
0.0.0.5 ], followed by the four octets [ 0.0.a.b ] of the integer
value corresponding to the particular IANA protocol.
Do not create children of this protocol unless you are sure that
they cannot be handled by the more conventional link layers
above."
CHILDREN
"Children of this protocol are identified by implementation-
specific means, described (as best as possible) in the 'DECODING'
clause within the protocol-variant-identifier macro for each
enumerated protocol.
Children of this protocol are encoded as [ 0.0.0.5 ], the
protocol identifier for 'ianaAssigned', followed by [ 0.0.a.b ]
where 'a', 'b' are the network byte order encodings of the high
order byte and low order byte of the enumeration value for the
particular IANA assigned protocol.
For example, a protocolDirID-fragment value of:
0.0.0.5.0.0.0.1
defines the IPX protocol encapsulated directly in 802.3
Children are named 'ianaAssigned' followed by the numeric value
of the particular IANA assigned protocol. The above example
would be named:
'ianaAssigned 1' "
DECODING
"The 'ianaAssigned' base layer is a pseudo-protocol and is not
decoded."
REFERENCE
"Refer to individual PROTOCOL-IDENTIFIER macros for information
on each child of the IANA assigned protocol."
::= { 5 }So ianaAssigned is for protocols that don't fit neatly into the hierarchy the other link layer branches use 🧩 Usually one of these "almost" fits a well-known identifier format, but extra criteria (like configuration) make it hard or impossible to identify from the traffic itself. That's why no well-known protocol-identifier macro can be used for it.
Sometimes well-known protocols just get remapped to a different port number by vendors, like SNMP. Those can be handled with the "limited extensibility" feature of the protocolDirTable and don't need special IANA assignments 💜 IANA has to keep a centrally located list of these enumerated protocols so everyone stays interoperable. (See section 2.3 for the document update procedure.) New link layers get added explicitly, and only protocols that can't possibly be represented some better way end up as ianaAssigned protocols 🌟
IANA protocols are identified by the base-layer-selector value [ 0.0.0.5 ], followed by the four octets [ 0.0.a.b ] holding the integer value for that specific IANA protocol.
Do not create children of this protocol unless you are sure they can't be handled by the more conventional link layers above. Seriously, be sure 😭
Children of this protocol are identified by implementation-specific means, described as best as possible in the DECODING clause of the protocol-variant-identifier macro for each enumerated protocol 🔥 They're encoded as [ 0.0.0.5 ] (the ianaAssigned component) followed by [ 0.0.a.b ], where a and b are the high and low order bytes of the enumeration value, in network byte order. So 0.0.0.5.0.0.0.1 is the IPX protocol encapsulated directly in 802.3 🎀 Children get named ianaAssigned plus the numeric value, so that example is 'ianaAssigned 1'.
For decoding, the ianaAssigned base layer is a pseudo-protocol and doesn't get decoded 🙈
For reference, look at the individual PROTOCOL-IDENTIFIER macros for info on each IANA-assigned child 🌈
Now ipxOverRaw8023, which is a VARIANT-OF ipx. Iykyk 🧚
ipxOverRaw8023 PROTOCOL-IDENTIFIER
VARIANT-OF ipx
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"This pseudo-protocol describes an encapsulation of IPX over
802.3, without a type field.
Refer to the macro for IPX for additional information about this
protocol."
DECODING
"Whenever the 802.3 header indicates LLC a set of protocol
specific tests needs to be applied to determine whether this is a
'raw8023' packet or a true 802.2 packet. The nature of these
tests depends on the active child protocols for 'raw8023' and is
beyond the scope of this document."
::= {
ianaAssigned 1, -- [0.0.0.1]
802-1Q 0x05000001 -- 1Q_IANA [5.0.0.1]
}ipxOverRaw8023 is a pseudo-protocol for IPX encapsulated over 802.3 with no type field 💅 Check out the IPX macro for more on it.
When the 802.3 header says LLC, you have to run some protocol-specific tests to figure out whether it's a raw8023 packet or a real 802.2 one. Those tests depend on the active child protocols for raw8023, and they're out of scope for this document 💀
Its value is listed as ianaAssigned 1 ([0.0.0.1]), and also as 802-1Q 0x05000001 (1Q_IANA [5.0.0.1]) 🍓
4.3. Encapsulation Layers ✨
Encapsulation layers sit between the base layer and the network layer 🌸 Whether a probe exposes all of these encapsulations in its RMON-2 Protocol Directory is an implementation-specific matter, so it's totally up to the implementation 💖
4.3.1. IEEE 802.1Q 🎀
okay so RMON probes can totally run into 'VLAN tagged' frames on the links they're watching 👀 The IEEE Virtual LAN (VLAN) encapsulation standards [IEEE802.1Q] and [IEEE802.1D-1998] define an encapsulation layer that gets slotted in after the MAC layer and before the network layer. This section defines a PI macro that supports most (but not all) features of that layer 💅
Most notably, the RMON PI macro '802-1Q' does not expose the Token Ring Encapsulation (TR-encaps) bit in the TCI portion of the VLAN header 🙈 Whether an RMON probe converts LLC-Token Ring (LLC-TR) frames to LLC-Native (LLC-N) format for RMON collection is an implementation specific matter, so it's up to the implementation 🤷♀️
To support the Ethernet and LLC-N formats in the most efficient way, and still stay aligned with the RMON-2 'collapsed' base layer approach (i.e., support for snap and vsnap), the children of 802dot1Q are encoded a little differently than the children of other base layer identifiers 🧚
802-1Q PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"IEEE 802.1Q VLAN Encapsulation header.
Note that the specific encoding of the TPID field is not
explicitly identified by this PI macro. Ethernet-encoded vs.
SNAP-encoded TPID fields can be identified by the ifType of the
data source for a particular RMON collection, since the SNAP-
encoded format is used exclusively on Token Ring and FDDI media.
Also, no information held in the TCI field (including the TR-
encap bit) is identified in protocolDirID strings utilizing this
PI macro."
CHILDREN
"The first byte of the 4-byte child identifier is used to
distinguish the particular base encoding that follows the 802.1Q
header. The remaining three bytes are used exactly as defined by
the indicated base layer encoding.
In order to simplify the child encoding for the most common
cases, the 'ether2' and 'snap' base layers are combined into a
single identifier, with a value of zero. The other base layers
are encoded with values taken from Table 4.2.
802-1Q Base ID Values
---------------------
Base Table 4.2 Base-ID
Layer Encoding Encoding
-------------------------------------
ether2 1 0
llc 2 2
snap 3 0
vsnap 4 4
ianaAssigned 5 5
The generic child layer-identifier format is shown below:
802-1Q Child Layer-Identifier Format
+--------+--------+--------+--------+
| Base | |
| ID | base-specific format |
| | |
+--------+--------+--------+--------+
| 1 | 3 | octet count
Base ID == 0
------------
For payloads encoded with either the Ethernet or LLC/SNAP headers
following the VLAN header, children of this protocol are
identified exactly as described for the 'ether2' or 'snap' base
layers.
Children are encoded as [ 0.0.129.0 ], the protocol identifier
for '802-1Q' followed by [ 0.0.a.b ] where 'a' and 'b' are the
network byte order encodings of the high order byte and low order
byte of the Ethernet-II type value.
For example, a protocolDirID-fragment value of:
0.0.0.1.0.0.129.0.0.0.8.0
defines IP, VLAN-encapsulated in ether2.
Children of this format are named as '802-1Q' followed by the
type field value in hexadecimal.
So the above example would be declared as:
'802-1Q 0x0800'.
Base ID == 2
------------
For payloads encoded with a (non-SNAP) LLC header following the
VLAN header, children of this protocol are identified exactly as
described for the 'llc' base layer.
Children are encoded as [ 0.0.129.0 ], the protocol identifier
component for 802.1Q, followed by [ 2.0.0.a ] where 'a' is the
SAP value which maps to the child protocol. For example, a
protocolDirID-fragment value of:
0.0.0.1.0.0.129.0.2.0.0.240
defines NetBios, VLAN-encapsulated over LLC.
Children are named as '802-1Q' followed by the SAP value in
hexadecimal, with the leading octet set to the value 2.
So the above example would have been named:
'802-1Q 0x020000f0'
Base ID == 4
------------
For payloads encoded with LLC/SNAP (non-zero OUI) headers
following the VLAN header, children of this protocol are
identified exactly as described for the 'vsnap' base layer.
Children are encoded as [ 0.0.129.0 ], the protocol identifier
for '802-1Q', followed by [ 4.a.b.c ] where 'a', 'b' and 'c' are
the 3 octets of the OUI field in network byte order.
For example, a protocolDirID-fragment value of:
0.0.0.1.0.0.129.0.4.8.0.7 defines the Apple-specific set of
protocols, VLAN-encapsulated over vsnap.
Children are named as '802-1Q' followed by the <OUI> value, which
is represented as 3 octets in hexadecimal notation, with a
leading octet set to the value 4.
So the above example would be named:
'802-1Q 0x04080007'.
Base ID == 5
------------
For payloads which can only be identified as 'ianaAssigned'
protocols, children of this protocol are identified exactly as
described for the 'ianaAssigned' base layer.
Children are encoded as [ 0.0.129.0 ], the protocol identifier
for '802-1Q', followed by [ 5.0.a.b ] where 'a' and 'b' are the
network byte order encodings of the high order byte and low order
byte of the enumeration value for the particular IANA assigned
protocol.
For example, a protocolDirID-fragment value of:
0.0.0.1.0.0.129.0.5.0.0.0.1
defines the IPX protocol, VLAN-encapsulated directly in 802.3
Children are named '802-1Q' followed by the numeric value of the
particular IANA assigned protocol, with a leading octet set to
the value of 5.
Children are named '802-1Q' followed by the hexadecimal encoding
of the child identifier. The above example would be named:
'802-1Q 0x05000001'. "
DECODING
"VLAN headers and tagged frame structure are defined in
[IEEE802.1Q]."
REFERENCE
"The 802.1Q Protocol is defined in the Draft Standard for Virtual
Bridged Local Area Networks [IEEE802.1Q]."
::= {
ether2 0x8100 -- Ethernet or SNAP encoding of TPID
-- snap 0x8100 ** excluded to reduce PD size & complexity
}Now for the child-encoding bits, which are the spicy part 🌶️ Children of 802-1Q are split up by a Base ID byte, and the rest of the 4-byte child identifier is whatever the base layer normally uses 🦋
- Base ID 0 covers the Ethernet and LLC/SNAP cases, since 'ether2' and 'snap' got merged together to keep things simple 💜
- Base ID 2 is for non-SNAP LLC payloads 🌸
- Base ID 4 is for LLC/SNAP payloads with a non-zero OUI 🍓
- Base ID 5 is for payloads that can only be identified as 'ianaAssigned' protocols 🌈
5. Intellectual Property 💖
okay, quick legal-ish bit but make it cute 🫶 The IETF takes no position on whether any intellectual property or other rights that might be claimed to apply to the technology in this document are valid or in scope, or on whether licenses for those rights are available. It also doesn't claim to have looked for any such rights. Info on the IETF's procedures for rights in standards-track and standards-related documents is in BCP-11. Copies of claimed rights that were submitted for publication, any assurances of licenses that will be made available, or the results of an attempt to get a general license or permission for implementors or users of this specification can be obtained from the IETF Secretariat."
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 required to practice this standard. Please send that info to the IETF Executive Director 📩
6. Acknowledgements 🫶
This document was produced by the IETF RMONMIB Working Group 🌟
The authors wanted to thank these people for their contributions to this document:
- Anil Singhal, Frontier Software Development, Inc.
- Jeanne Haney, Bay Networks
- Dan Hansen, Network General Corp.
Special thanks to these people for writing RMON PI macro compilers and improving the specification of the PI macro language 👑
- David Perkins, DeskTalk Systems, Inc.
- Skip Koppenhaver, Technically Elite, Inc.
7. References ✨
okay so this is the reading list, bestie 📚 every source this spec leans on is here, and I kept every single title, number, and date exactly as written
- [AF-LANE-0021.000] LAN Emulation Sub-working Group, B. Ellington, "LAN Emulation over ATM - Version 1.0", AF-LANE-0021.000, ATM Forum, IBM, January 1995.
- [AF-NM-TEST-0080.000] Network Management Sub-working Group, Test Sub-working Group, A. Bierman, "Remote Monitoring MIB Extensions for ATM Networks", AF- NM-TEST-0080.000, ATM Forum, Cisco Systems, February 1997.
- [IEEE802.1D-1998] LAN MAN Standards Committee of the IEEE Computer Society, "Information technology -- Telecommunications and information exchange between systems -- Local and metropolitan area networks -- Common specification -- Part 3: Media Access Control (MAC) Bridges", ISO/IEC Final DIS 15802-3 (IEEE P802.1D/D17) Institute of Electrical and Electronics Engineers, Inc., May 1998.
- [IEEE802.1Q] LAN MAN Standards Committee of the IEEE Computer Society, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", Draft Standard P802.1Q/D11, Institute of Electrical and Electronics Engineers, Inc., July 1998.
- [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990.
- [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
- [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
- [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
- [RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.
- [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
- [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
- [RFC1902] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996.
- [RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
- [RFC1904] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
- [RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
- [RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)"", RFC 1906, January 1996.
- [RFC2021] Waldbusser, S., "Remote Network Monitoring MIB (RMON-2)", RFC 2021, January 1997.
- [RFC2074] Bierman, A. and R. Iddon, "Remote Network Monitoring MIB Protocol Identifiers", RFC 2074, January 1997.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2233] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB Using SMIv2", RFC 2233, November 1997.
- [RFC2271] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, January 1998.
- [RFC2272] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, January 1998.
- [RFC2273] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2273, January 1998.
- [RFC2274] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, January 1998.
- [RFC2275] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, January 1998.
- [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999.
- [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999.
- [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999.
- [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999.
- [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999.
- [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999.
- [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
- [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
- [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
- [RFC2896] Bierman, A., Bucci, C. and R. Iddon, "Remote Network Monitoring MIB Protocol Identifier Macros", RFC 2896, August 2000.
8. IANA Considerations 🎀
okay so IANA basically only shows up in rare moments 🥹 the protocols in this spec are almost entirely defined somewhere else, but every now and then a protocol needs an arbitrary Protocol Identifier assignment so it can show up in the RMON-2 protocolDirTable. Those protocol identifier macros get defined under the ianaAssigned base layer (see sections 3. and 4.2) 💖
right now there's only one protocol living under ianaAssigned, and it's called ipxOverRaw8023 (see section 4.2) ✨
9. Security Considerations 💅
this section is lowkey the shortest one, but it's still giving full seriousness 🔥 this document is all about the syntax and semantics of the textual descriptions of networking protocols. It is NOT defining any networking behavior, so no security considerations are raised by this memo 🙈
10. Authors' Addresses 🧚
here's who wrote it, bestie 🫶
Andy Bierman
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA USA 95134
Phone: +1 408-527-3711
EMail: abierman@cisco.com
Chris Bucci
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA USA 95134
Phone: +1 408-527-5337
EMail: cbucci@cisco.com
Robin Iddon
c/o 3Com Inc.
Blackfriars House
40/50 Blackfrias Street
Edinburgh, EH1 1NE, UK
Phone: +44 131.558.3888
EMail: NoneAppendix A: Changes since RFC 2074 🦋
okay so this is the glow-up log 💜 here's everything that changed between RFC 2074 and this doc:
- RFC 2074 got split into a reference document (this document) on the standards track and an informational document [RFC2896], so most protocol identifier macros could move out of the standards track document 🌸
- Administrative updates: added an author, added copyrights, updated SNMP framework boilerplate ✨
- Updated overview section 🌿
- Section 2.1 got MUST, SHOULD text added per template 💅
- Section 2.1 also got some new terms:
- parent protocol
- child protocol
- protocol encapsulation tree
- Added section 2.3 about splitting into 2 documents: "Relationship to the RMON Protocol Identifier Macros Document" 🎀
- Added section 2.4 "Relationship to the ATM-RMON MIB" 💖
- Rewrote section 3.2 "Protocol Identifier Macro Format". No semantic changes were made, but the PI macro syntax is now specified in greater detail using BNF notation 📚
- Section 3.2.3.1 "Mapping of the
countsFragments(0)BIT" got clarified. It now allows multipleprotocolDirParametersoctets in a given PI string to set thecountsFragmentsbit. The RFC version says just one octet can set this BIT. It's a useful feature for identifying fragmentation at multiple layers, and most RMON-2 agents were already doing this, so the WG agreed to this clarification 🙌 - Added section 4.3 "Encapsualtion Layers" 🧚
- This document ends after the base layer encapsulation definitions (through RFC 2074, section 5.2) 🌈
- Added Intellectual Property section 🔥
- Moved RFC 2074 section 5.3 "L3: Children of Base Protocol Identifiers" through the end of RFC 2074 to the PI Reference [RFC2896] document, where many new protocol identifier macros were added for application protocols and non-IP protocol stacks 👑
- Acknowledgements section has been updated 🫶
11. Full Copyright Statement 💖
Copyright (C) The Internet Society (2000). All Rights Reserved. 🎀
Okay so the Internet Society owns the copyright, and here's what you're allowed to do with this doc. ✨ You can copy it and pass it around to your friends, and you can make derivative works that comment on it, explain it, or help people implement it. You can publish and distribute those too, in whole or in part, with no restrictions of any kind 🫶. The one catch is that the copyright notice and this paragraph have to stay on every copy and every derivative work. 💅
Now the main-character rule: this document itself may not be modified in any way 🙅♀️. That includes deleting the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when you need it for developing Internet standards (then you have to follow the copyright procedures in the Internet Standards process 📜), or when you need to translate it into a language other than English 🌍.
The permissions above are perpetual, meaning they're forever 💜. The Internet Society and its successors or assigns can't revoke them. 🦋
This document and everything in it is provided "AS IS", and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 😭 No guarantees, bestie, so read it with that in mind. 🙈
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. 🍓 Thank you to the Internet Society for keeping the RFC Editor running! 🫶✨
📦 where this page comes from
- ietf: rfc2895 2000-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms