RFC 2074
Remote Network Monitoring MIB Protocol Identifiers
RFC 2074: Remote Network Monitoring MIB Protocol Identifiers 🎀
okay bestie, let's get into RFC 2074 🦋 It's about how we name protocol layers so the RMON-2 MIB can tell them apart, and it's giving very organized energy 💅
- Number: RFC 2074
- Title: Remote Network Monitoring MIB Protocol Identifiers
- Authors: A. Bierman (Cisco Systems) and R. Iddon (AXON Networks, Inc.)
- Category: Standards Track
- Date: January 1997
- Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🙈
Status of This Memo
okay so this part is the legal-ish bit, but it's important 💜 The doc is a standards track protocol for the Internet community, and they literally want people to talk about it and suggest improvements ✨ To find out where it actually stands, check the current "Internet Official Protocol Standards" (STD 1). And the distribution is unlimited, so share it with everyone 🌈
Table of Contents
1 Introduction .................................................... 3
2 The SNMP Network Management Framework ........................... 3
2.1 Object Definitions ............................................ 3
3 Overview ........................................................ 3
3.1 Terms ......................................................... 4
3.2 Relationship to the Remote Network Monitoring MIB ............. 6
3.3 Relationship to the Other MIBs ................................ 6
4 Protocol Identifier Encoding .................................... 7
4.1 ProtocolDirTable INDEX Format Examples ........................ 9
4.2 Protocol Identifier Macro Format .............................. 10
4.2.1 Mapping of the Protocol Name ................................ 12
4.2.2 Mapping of the VARIANT-OF Clause ............................ 13
4.2.3 Mapping of the PARAMETERS Clause ............................ 13
4.2.3.1 Mapping of the 'countsFragments(0)' BIT ................... 14
4.2.3.2 Mapping of the 'tracksSessions(1)' BIT .................... 15
4.2.4 Mapping of the ATTRIBUTES Clause ............................ 15
4.2.5 Mapping of the DESCRIPTION Clause ........................... 15
4.2.6 Mapping of the CHILDREN Clause .............................. 16
4.2.7 Mapping of the ADDRESS-FORMAT Clause ........................ 16
4.2.8 Mapping of the DECODING Clause .............................. 16
4.2.9 Mapping of the REFERENCE Clause ............................. 17
4.2.10 Evaluating a Protocol-Identifier INDEX ..................... 17
5 Protocol Identifier Macros ...................................... 18
5.1 Base Identifier Encoding ...................................... 18
5.1.1 Protocol Identifier Functions ............................... 19
5.1.1.1 Function 0: No-op ......................................... 19
5.1.1.2 Function 1: Protocol Wildcard Function .................... 19
5.2 Base Layer Protocol Identifiers ............................... 20
5.2.1 Ether2 Encapsulation ........................................ 21
5.2.2 LLC Encapsulation ........................................... 22
5.2.3 SNAP over LLC (OUI=000) Encapsulation ....................... 23
5.2.4 SNAP over LLC (OUI != 000) Encapsulation .................... 24
5.2.5 IANA Assigned Protocols ..................................... 25
5.2.5.1 IANA Assigned Protocol Identifiers ........................ 27
5.3 L3: Children of Base Protocol Identifiers ..................... 27
5.3.1 IP .......................................................... 28
5.3.2 IPX ......................................................... 29
5.3.3 ARP ......................................................... 30
5.3.4 IDP ......................................................... 30
5.3.5 AppleTalk ARP ............................................... 31
5.3.6 AppleTalk ................................................... 31
5.4 L4: Children of L3 Protocols .................................. 32
5.4.1 ICMP ........................................................ 32
5.4.2 TCP ......................................................... 32
5.4.3 UDP ......................................................... 33
5.5 L5: Application Layer Protocols ............................... 33
5.5.1 FTP ......................................................... 33
5.5.1.1 FTP-DATA .................................................. 33
5.5.1.2 FTP Control ............................................... 34
5.5.2 Telnet ...................................................... 34
5.5.3 SMTP ........................................................ 34
5.5.4 DNS ......................................................... 35
5.5.5 BOOTP ....................................................... 35
5.5.5.1 Bootstrap Server Protocol ................................. 35
5.5.5.2 Bootstrap Client Protocol ................................. 35
5.5.6 TFTP ........................................................ 36
5.5.7 HTTP ........................................................ 36
5.5.8 POP3 ........................................................ 36
5.5.9 SUNRPC ...................................................... 37
5.5.10 NFS ........................................................ 38
5.5.11 SNMP ....................................................... 38
5.5.11.1 SNMP Request/Response .................................... 38
5.5.11.2 SNMP Trap ................................................ 39
6 Acknowledgements ................................................ 39
7 References ...................................................... 40
8 Security Considerations ......................................... 43
9 Authors' Addresses .............................................. 431. Introduction ✨
okay so this memo defines an experimental chunk of the Management Information Base (MIB) for network management protocols on the Internet 🧚 The main thing it does is describe the algorithms needed to identify the different protocol encapsulations that get managed with the Remote Network Monitoring MIB Version 2 [RMON2] ✨ It's related to the original Remote Network Monitoring MIB [RFC1757], but it only talks about objects in the RMON-2 MIB, so that's the only one we're looking at 💖
2. The SNMP Network Management Framework 🌸
the SNMP Network Management Framework is currently made of three major pieces, and they're all kind of iconic 👑
- the SMI, described in RFC 1902 [RFC1902], which is the mechanism for describing and naming objects so they can be managed 🍓
- the MIB-II, STD 17, RFC 1213 [RFC1213], which is the core set of managed objects for the Internet protocol suite 💜
- the protocol, STD 15, RFC 1157 [RFC1157] and/or RFC 1905 [RFC1905], which is how you actually access the managed information 🔥
textual conventions are defined in RFC 1903 [RFC1903], and conformance statements are defined in RFC 1904 [RFC1904] 🎀
the Framework also lets new objects be defined for experimentation and evaluation, which is very lowkey a vibe for trying new stuff 🦋
2.1. Object Definitions
managed objects are accessed through a virtual information store called the Management Information Base, or MIB 🫶 Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) that's defined in the SMI. Each object type gets named by an OBJECT IDENTIFIER, which is an administratively assigned name. The object type plus an object instance together uniquely identify one specific instantiation of the object ✨ For human convenience, people often use a textual string called the descriptor to refer to the object type 💅
3. Overview 🌈
the RMON-2 MIB [RMON2] uses hierarchically formatted OCTET STRINGs to globally identify individual protocol encapsulations in the protocolDirTable 🧚
this guide has algorithms and examples of protocol identifier encapsulations for use as INDEX values in the protocolDirTable 💖
ngl, this doc is NOT the authoritative reference on the protocols it covers 🙈 For the full, official info, check the Official Internet Standards document [RFC1800], the Assigned Numbers document [RFC1700], or other appropriate RFCs, IEEE documents, and so on.
3.1. Terms
there are a few terms used all through this document and in the RMON-2 MIB [RMON2] that you should know first 🎀
layer-identifier: An octet string fragment representing one particular protocol encapsulation layer 🦋 It's a string fragment that identifies one specific encapsulation layer. The string is exactly four octets, except for the 'vsnap' base-layer identifier, which is exactly eight octets, and it's encoded in network byte order. A particular protocol encapsulation can be identified by starting with a base layer encapsulation (see the 'Base Protocol Identifiers' section for more detail), then following the encoding rules in the CHILDREN clause and assignment section for that layer. Then you just repeat for each identified layer in the encapsulation. (See section 4.2.10 'Evaluating a Protocol-Identifier INDEX' for more detail.) 💅
protocol: A particular protocol layer, as specified by the encoding rules in this document ✨ It usually refers to a single layer in a given encapsulation. Heads up, the RMON-2 MIB [RMON2] sometimes uses this term to name a fully specified protocol-identifier string. In that case, the protocol-identifier string is named after its upper-most layer. A named protocol can also refer to any encapsulation of that protocol 🌸
protocol-identifier string: An octet string representing a particular protocol encapsulation, as specified by the encoding rules in this document 🫶 This string is identified in the RMON-2 MIB [RMON2] as the protocolDirID object. A protocol-identifier string is made up of one or more layer-identifiers 🍓
protocol-identifier macro: A group of formatted text describing a particular protocol layer, as used within the RMON-2 MIB [RMON2] ✨ This macro is iconic because it does several jobs:
- Names the protocol for use within the RMON-2 MIB [RMON2].
- 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: A group of formatted text describing a particular protocol layer, as used within the RMON-2 MIB [RMON2] 🔥 This protocol is a variant of a well known encapsulation that may be present in the protocolDirTable. This macro is used to document the IANA assigned protocols, which are needed to identify protocols that can't practically be identified by looking at 'appropriate network traffic' (for example, the packets that carry them). All other protocols, the ones that can be identified by examining appropriate network traffic, should be documented using the protocol-identifier macro. A protocol-variant-identifier gets documented using the protocol-variant version of the protocol-identifier macro 👑
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 the corresponding protocol 🌈
protocol-parameters string: An octet string that contains one protocol-parameter for each layer-identifier in the protocol-identifier 💜 See the section 'Mapping of the PARAMETERS Clause' for more detail. This string is identified in the RMON-2 MIB [RMON2] as the protocolDirParameters object 🦋
ok that's the first chunk, bestie 🫶 More parts are coming, so stay tuned 💖
protocolDirTable INDEX: bestie, this is the pair of a protocol-identifier and a protocol-parameters octet string, converted into an INDEX value using the encoding rules in section 7.7 of RFC 1902 [RFC1902]. 🎀
pseudo-protocol: a convention or algorithm that lives only inside this document, used for encoding protocol-identifier strings. It's a little helper, not a real protocol 🧚
3.2. Relationship to the Remote Network Monitoring MIB
Okay so this document exists to suggest possible string values for the OCTET STRING objects protocolDirID and protocolDirParameters. 💅 The new Protocol Distribution, Host, and Matrix groups use a local INTEGER INDEX instead, so they stay unaffected if this document changes. Only the protocolDirTable uses the strings (protocolDirID and protocolDirParameters) described here. Main character energy for the table, honestly 👑
This document is not meant to limit which protocols can be identified for counting in the RMON-2 MIB. Loads of protocol encapsulations that aren't named here could show up in a real implementation of the protocolDirTable 🌈 And an implementation of the protocolDirTable doesn't have to include every protocol from the example section below either, no pressure 🫶
This document is kept separate from the MIB objects on purpose, so it can get frequent updates without republishing any MIB objects. ✨ Protocol Identifier macros from the RMON working group and the wider community get sent to the RMONMIB WG mailing list at rmonmib@cisco.com, and they'll be collected and added to this document 💌
Macro submissions get collected in the IANA's MIB files under the directory ftp://ftp.isi.edu/mib/rmonmib/rmon2_pi_macros/, and also in the RMONMIB working group mailing list message archive file ftp://ftp.cisco.com/ftp/rmonmib/rmonmib. 🦋
This document doesn't talk about auto-discovery and auto-population of the protocolDirTable, because the RMON standard doesn't define that functionality. Instead, an agent should fill the directory with 'interesting' protocols, depending on what the applications are for 🔥
3.3. Relationship to the Other MIBs
The RMON Protocol Identifiers document is for use with the protocolDirTable inside the RMON MIB. It's not relevant to any other MIB, and it isn't intended for use with any other MIB. Very focused, very iconic 💜
4. Protocol Identifier Encoding ✨
The protocolDirTable is indexed by two OCTET STRINGs, protocolDirID and protocolDirParameters. To encode the table index, each variable-length string gets converted into an OBJECT IDENTIFIER fragment, following the encoding rules in section 7.7 of RFC 1902 [RFC1902]. Then the index fragments are just concatenated together. 🧩 (Check figures 1a - 1d below for more detail.)
The first OCTET STRING (protocolDirID) is made up of one or more 4-octet "layer-identifiers". Together, the whole string uniquely identifies one particular 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 normally identified by a single 32-bit value. Each layer-identifier gets encoded in the ProtocolDirID OCTET STRING INDEX as four sub-components [ a.b.c.d ], where 'a' through 'd' stand for each byte of the 32-bit value in network byte order. 🤓 If a particular protocol layer can't be encoded into 32 bits (except for the 'vsnap' base layer), then it must be defined as an 'ianaAssigned' protocol. There's more detail on IANA assigned protocols below.
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 |
| |
+----------+ Fig. 1c
protocolDirTable INDEX Format Example
-------------------------------------
protocolDirID protocolDirParameters
+---+--------+--------+--------+--------+---+---+---+---+---+
| c | proto | proto | proto | proto | c |par|par|par|par|
| n | base | L3 | L4 | L5 | n |ba-| L3| L4| L5|
| t |(+flags)| | | | t |se | | | |
+---+--------+--------+--------+--------+---+---+---+---+---+ subOID
| 1 | 4 or 8 | 4 | 4 | 4 | 1 |1/2| 1 | 1 | 1 | count
where N is the number of protocol-layer-identifiers required
for the entire encapsulation of the named protocol. Note that
the 'vsnap' base layer identifier is encoded into 8 sub-identifiers,
All other protocol layers are either encoded into 4 sub-identifiers
or encoded as a 'ianaAssigned' protocol. Fig. 1d
protocolDirTable OCTET STRING Format Example
--------------------------------------------
protocolDirID
+--------+--------+--------+--------+
| proto | proto | proto | proto |
| base | L3 | L4 | L5 |
| | | | |
+--------+--------+--------+--------+ octet
| 4 or 8 | 4 | 4 | 4 | count
protocolDirParameters
+---+---+---+---+
|par|par|par|par|
|ba-| L3| L4| L5|
|se | | | |
+---+---+---+---+ octet
|1/2| 1 | 1 | 1 | count
where N is the number of protocol-layer-identifiers required
for the entire encapsulation of the named protocol. Note that
the 'vsnap' base layer identifier is encoded into 8
protocolDirID sub-identifiers and 2 protocolDirParameters
sub-identifiers.Although 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 in section 3.5 of RFC 1902 [RFC1902].
Note that these two strings would not be concatenated together if they were ever returned in a GetResponse PDU, since they are different MIB objects. 🙈 However, protocolDirID and protocolDirParameters are not currently readable MIB objects.
4.1. ProtocolDirTable INDEX Format Examples
Time for the examples! 🍓
-- 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(1)).snmp =
12.0.0.0.5.0.0.0.1.0.0.155.15.3.0.0.0
-- IPX over LLC
llc.ipx =
8.0.0.0.2.0.224.224.3.2.0.0
-- SNMP over UDP/IP over any link layer
-- wildcard-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
-- wildcard-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).atalk
12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.04.2. Protocol Identifier Macro Format
This next example is here to introduce the protocol-identifier macro. (Heads up, the syntax isn't quite ASN.1 🙃) This macro is used to represent both protocols and protocol-variants.
If the 'VariantOfPart' component of the macro is present, then the macro represents a protocol-variant instead of a protocol. A protocol-variant-identifier is only used for IANA assigned protocols, enumerated under the 'ianaAssigned' base-layer. 🦋
RMON-PROTOCOL-IDENTIFIER MACRO ::=
BEGIN
PIMacroName "PROTOCOL-IDENTIFIER"
VariantOfPart
"PARAMETERS" ParamPart
"ATTRIBUTES" AttrPart
"DESCRIPTION" Text
ChildDescrPart
AddrDescrPart
DecodeDescrPart
ReferPart
"::=" "{" EncapsPart "}"
PIMacroName ::=
identifier
VariantOfPart ::=
"VARIANT-OF" identifier | empty
ParamPart ::=
"{" ParamList "}"
ParamList ::=
Params | empty
Params ::=
Param | Params "," Param
Param ::=
identifier "(" nonNegativeNumber ")"
AttrPart ::=
"{" AttrList "}"
AttrList ::=
Attrs | empty
Attrs ::=
Attr | Attrs "," Attr
Attr ::=
identifier "(" nonNegativeNumber ")"
ChildDescrPart ::=
"CHILDREN" Text | empty
AddrDescrPart ::=
"ADDRESS-FORMAT" Text | empty
DecodeDescrPart ::=
"DECODING" Text | empty
ReferPart ::=
"REFERENCE" Text | empty
EncapsPart ::=
"{" Encaps "}"
Encaps ::=
Encap | Encaps "," Encap
Encap ::=
BaseEncap | NormalEncap | VsnapEncap | IanaEncap
BaseEncap ::=
nonNegativeNumber
NormalEncap ::=
identifier nonNegativeNumber
VsnapEncap ::=
identifier "(" nonNegativeNumber ")" nonNegativeNumber
IanaEncap ::=
"ianaAssigned" nonNegativeNumber
| "ianaAssigned" identifier
| "ianaAssigned" identifier "(" nonNegativeNumber ")"
Text ::=
"""" string """"
END4.2.1. Mapping of the Protocol Name
The 'PIMacroName' value should be a lower-case ASCII string, and it should contain the name or acronym that identifies the protocol. 🔤 NMS applications may treat protocol names as case-insensitive strings. Agent implementations must make sure the protocolDirTable doesn't contain any instances of the protocolDirDescr object that differ only in the case of one or more letters, if those identifiers are meant to represent different protocols. 🙅♀️
It's possible that different encapsulations of the same protocol (which get represented by different entries in the protocolDirTable) will be given the same protocol name. 🎀
A protocol name should match the "most well-known" name or acronym for the protocol in question. For example, the document at the URL ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers defines IP Protocol field values. So protocol-identifier macros for children of IP should be named consistently with the protocol names in that authoritative document. 📚✨
4.2.2. Mapping of the VARIANT-OF Clause 🧚
Okay bestie, this clause only shows up for IANA assigned protocols 🎀. It names the protocol-identifier macro that most closely matches this protocol, and that one is called the "reference protocol" 💜. (A protocol-identifier macro MUST exist for the reference protocol.) When this clause shows up in a protocol-identifier macro, that macro becomes a 'protocol-variant-identifier' ✨.
Any clause (e.g. CHILDREN, ADDRESS-FORMAT) in the reference protocol-identifier macro SHOULD NOT be duplicated in the protocol-variant-identifier macro, as long as the 'variant' protocols' semantics are identical for that clause 🫶.
Since the PARAMETERS and ATTRIBUTES clauses MUST be present in a protocol-identifier, an empty 'ParamPart' and 'AttrPart' (i.e. PARAMETERS {}) MUST be present in a protocol-variant-identifier macro, and the 'ParamPart' and 'AttrPart' from the reference protocol-identifier macro get checked instead 💅.
Note that if an 'ianaAssigned' protocol is defined that is not a variant of any other documented protocol, then the protocol-identifier macro SHOULD be used instead of the protocol-variant-identifier version of the macro. 🙈
4.2.3. Mapping of the PARAMETERS Clause 🔥
The protocolDirParameters object gives an NMS the power to switch expensive probe resources on and off 👑. An agent MAY support a given parameter all the time, not at all, or subject to current resource load.
The PARAMETERS clause is a list of bit definitions that can be directly encoded into the associated ProtocolDirParameters octet in network byte order. Zero or more bit definitions MAY be present. Only bits 0-7 are valid encoding values. This clause defines the entire BIT set allowed for a given protocol. A conforming agent MAY choose to implement a subset of zero or more of these PARAMETERS.
By convention, the following common bit definitions get used by different protocols ✨. These bit positions MUST NOT be used for other parameters. They SHOULD be reserved if a given protocol doesn't use them. Bits are encoded in network-byte order.
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 MAY be equal to zero (empty). Note that an NMS MUST figure out whether a given PARAMETER bit is supported by trying to create the desired protocolDirEntry. The associated ATTRIBUTE bits for 'countsFragments' and 'tracksSessions' do not exist 🙈.
4.2.3.1. Mapping of the 'countsFragments(0)' BIT 🍓
This bit says whether the probe is correctly attributing all fragmented packets of the specified protocol, even when individual frames carrying this protocol can't be identified as fragments 🧩. Note that the probe is not required to actually present any re-assembled datagrams (for address-analysis, filtering, or any other purpose) to the NMS.
This bit MAY only be set in a protocolDirParameters octet that corresponds to a protocol supporting fragmentation and reassembly in some form. Note that TCP packets are not considered 'fragmented-streams', so TCP is not eligible 🚫.
This bit MAY be set in at most one protocolDirParameters octet within a protocolDirTable INDEX.
4.2.3.2. Mapping of the 'tracksSessions(1)' BIT 🦋
The 'tracksSessions(1)' bit says whether frames that are part of remapped sessions (e.g. TFTP download sessions) are correctly counted by the probe 💖. For a protocol like this, the probe MUST usually analyze all packets received on the indicated interface, and keep some state information (e.g. the remapped UDP port number for TFTP).
The semantics of the 'tracksSessions' parameter are independent of the other protocolDirParameters definitions, so this parameter MAY be combined with any other legal parameter configuration 🌈.
4.2.4. Mapping of the ATTRIBUTES Clause 🌸
The protocolDirType object gives an NMS a look at a probe's capabilities for decoding a given protocol, or the general attributes of that protocol 👀.
The ATTRIBUTES clause is a list of bit definitions that get encoded into the associated 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 🧸.
4.2.5. Mapping of the DESCRIPTION Clause 📝
The DESCRIPTION clause gives a textual description of the protocol identified by this macro. Notice that it SHOULD NOT contain details about items covered by the CHILDREN, ADDRESS-FORMAT, DECODING and REFERENCE clauses 💅.
The DESCRIPTION clause MUST be present in all protocol-identifier macro declarations.
4.2.6. 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 process is performed
- Details on how the value(s) are encoded in the protocol identifier octet string
- Details on how child protocols are named with respect to their parent protocol label(s)
The CHILDREN clause MUST be present in all protocol-identifier macro declarations in which the 'hasChildren(0)' BIT is set in the ATTRIBUTES clause 🌳.
4.2.7. 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 in which the 'addressRecognitionCapable(1)' BIT is set in the ATTRIBUTES clause 🎯.
4.2.8. 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 SHOULD NOT over-replicate information in documents cited in the REFERENCE clause. It might contain a complete description of any decoding information required 📚.
For 'extensible' protocols ('hasChildren(0)' BIT set), this includes offset and type information for the field(s) used for child selection, as well as information on determining the start of the child protocol.
For 'addressRecognitionCapable' protocols, this includes offset and type information for the field(s) used to generate addresses.
The DECODING clause is OPTIONAL, and MAY be omitted if the REFERENCE clause points to decoding information for the specified protocol 🥰.
4.2.9. Mapping of the REFERENCE Clause 🔗
If a publicly available reference document exists for this protocol, it SHOULD be listed here. Typically this will be a URL if possible; if not, it will be the name and address of the controlling body 🌐.
The CHILDREN, ADDRESS-FORMAT, and DECODING clauses SHOULD limit the amount of information that may currently be obtained from an 'authoritative' document, such as the Assigned Numbers document [RFC1700]. Any duplication or paraphrasing of information SHOULD be brief and consistent with the authoritative document.
The REFERENCE clause is OPTIONAL, but SHOULD be implemented if an authoritative reference exists for the protocol (especially for standard protocols) ⭐.
4.2.10. Evaluating a Protocol-Identifier INDEX 🧮
The following evaluation is done after the protocolDirTable INDEX value has been converted into two OCTET STRINGs, following the INDEX encoding rules specified in the SMI [RFC1902].
Protocol-identifiers are evaluated left to right, starting with the protocolDirID, whose length SHOULD be evenly divisible by four. The protocolDirParameters length SHOULD be exactly one quarter of the protocolDirID string length 🍰.
Protocol-identifier parsing starts with the base layer identifier, which MUST be present, and continues for one or more upper layer identifiers until all OCTETs of the protocolDirID have been used. Layers may not be skipped, so identifiers such as 'SNMP over IP' or 'TCP over anylink' can not exist 🙅♀️.
The base-layer-identifier also contains a 'special function identifier' which 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. Refer to the 'Base Protocol Identifiers' section for wildcard encoding rules 🃏.
After the protocol tree identified in protocolDirID has been parsed, each parameter bit-mask (one octet for each 4-octet layer-identifier) is evaluated and applied to the corresponding protocol layer 🎯.
A protocol-identifier label may map to more than one value. For instance, 'ip' maps to 5 distinct values, one for each supported encapsulation (see the 'IP' section under 'L3 Protocol Identifiers'), 🌈
It is important to note that these macros are conceptually expanded at implementation time, not at run time ⏰.
If all the macros are expanded completely by substituting all possible values of each label for each child protocol, a list of all possible protocol-identifiers is produced. 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.) 💜.
5. Protocol Identifier Macros 🎀
The following PROTOCOL IDENTIFIER macros can be used to construct protocolDirID and protocolDirParameters strings 🧁.
The sections defining protocol examples are meant to grow over subsequent releases. Minimal protocol support is included at this time. (Refer to section 3.2 for details on the protocol macro update procedure 🦋.)
An identifier is encoded by constructing the base-identifier, then adding one layer-identifier for each encapsulated protocol 🌸.
5.1. Base Identifier Encoding 🎀
okay so the first layer wrapper is called the base identifier 💅 and it holds the optional protocol-function info plus the base layer (e.g. MAC layer) enumeration value used in this protocol identifier. it's giving "who am I and what special stuff do I do" ✨
the base identifier is encoded as four octets, as you can see 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, and you look it up in table 4.1 🌸 the next two octets ('op1' and 'op2') are operands for whatever function is being called. if an operand isn't used, it must be set to zero 🙈 the last octet, 'm', is the enumerated value for a particular base layer encapsulation, which lives in table 4.2 ✨ and all four octets are encoded in network-byte-order 💜
5.1.1. Protocol Identifier Functions 🌈
the base layer identifier holds info about any special functions to perform during collections of this protocol, plus the base layer encapsulation identifier 💖 the first three octets have the function code and two optional operands, and the fourth octet has 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)5.1.1.1. Function 0: No-op 💀
if the function ID field (1st octet) is equal to zero, the the 'op1' and 'op2' fields (2nd and 3rd octets) must also be equal to zero. this special value means no functions are applied to the protocol identifier encoded in the remaining octets 🫶 the identifier just represents a normal protocol encapsulation.
5.1.1.2. Function 1: Protocol Wildcard Function 🍓
the wildcard function (function-ID = 1) is used to aggregate counters. it does this 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 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 🦋 if an encapsulation over 'ether2' is permitted, than this should be used as the base encapsulation.
the agent may also be requested to count some or all of the individual encapsulations for the same protocols, in addition to wildcard counting. note that the RMON-2 MIB [RMON2] does not require that agents maintain counters for multiple encapsulations of the same protocol 🙈 it's an implementation-specific matter as to how an agent decides which protocol combinations to allow in the protocolDirTable at any given time.
5.2. Base Layer Protocol Identifiers 🧁
the base layer is mandatory, and it 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 ProtocolDirDescr field for the base layer is given by the corresponding "Name" field in the table 4.1 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 🎀 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 55.2.1. Ether2 Encapsulation 💖
okay this is the ether2 definition, the OG one 🌈
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 MSB and
LSB 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 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 or equal to 1500 decimal indicate
Ethernet-II frames; lower values indicate 802.3 encapsulation
(see below)."
REFERENCE
"A Standard for the Transmission of IP Datagrams over Ethernet
Networks; RFC 894 [RFC894].
The authoritative list of Ether Type values is identified by the
URL:
ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers"
::= { 1 }5.2.2. LLC Encapsulation 🍓
and here's llc, the 802.2 one 🦋
llc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"The LLC (802.2) protocol."
CHILDREN
"The LLC SSAP and DSAP (Source/Dest Service Access Points) 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 raw802.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 }5.2.3. SNAP over LLC (OUI=000) Encapsulation ✨
next up is snap, the one layered on top of LLC so Ethernet-II protocols can run over LLC-only media 💜
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 PID (Protocol Identifier) field 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 MSB and LSB 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 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 }5.2.4. SNAP over LLC (OUI != 000) Encapsulation 🌸
vsnap is the catch-all for SNAP packets with a non-zero OUI, and it's giving very organised vibes 🧚
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 do."
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.0.0.d.e ] where
'a', 'b' and 'c' are the 3 octets of the OUI field in network
byte order. This is in turn followed by the 16-bit EtherType
value, where the 'd' and 'e' represent the MSB and LSB of the
EtherType, respectively.
For example, a protocolDirID-fragment value of:
0.0.0.4.0.8.0.7.0.0.128.155
defines the AppleTalk Phase 2 protocol over vsnap.
Note that two protocolDirParameters octets must be present in
protocolDirTable INDEX values for 'vsnap' protocols. The first
protocolDirParameters octet defines the actual parameters. The
second protocolDirParameters octet is not used and must be set to
zero.
Children are named as 'vsnap(<OUI>) <ethertype>', where the
'<OUI>' field is represented as 3 octets in hexadecimal notation
or the ASCII string associated with the OUI value. The
<ethertype> field is represented by the 2 byte EtherType value in
hexadecimal notation. So the above example would be named:
'vsnap(0x080007) 0x809b' or 'vsnap(apple) 0x809b'"
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."
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 }The gist: children get picked by the 3-octet OUI, and the PID never gets parsed 🦋 Each child is encoded as 0.0.0.4 followed by 0.a.b.c.0.0.d.e, with d and e being the MSB and LSB of the EtherType. The example 0.0.0.4.0.8.0.7.0.0.128.155 is AppleTalk Phase 2 over vsnap, and it gets named vsnap(0x080007) 0x809b or vsnap(apple) 0x809b 💅
Two protocolDirParameters octets are required in the protocolDirTable INDEX values for vsnap, and the second one has to be zero 🎀
5.2.5. IANA Assigned Protocols
bestie, this branch is for the protocols that refuse to fit neatly into the hierarchy 🌈 They almost follow a well-known identifier format, but extra criteria (like configuration) make them impossible or really hard to spot just by looking at traffic 😭
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 'user-extensibility' feature of the
protocolDirTable, and do not need special IANA
assignments.
A centrally located list of these enumerated protocols must be
maintained to insure interoperability.
(See section 3.2 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 'ianaEnumerated' protocols.
IANA assigned protocols are identified by the base-layer-selector
value [ 0.0.0.5 ], followed by the four octets [ a.b.c.d ] 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.
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 name or numeric
of the particular IANA assigned protocol. The above
example would be named:
'ianaAssigned 1' or 'ianaAssigned ipxOverRaw8023'"
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 the base layer is selected by 0.0.0.5, followed by four octets a.b.c.d holding the integer for the specific IANA protocol 🍓 Children get named ianaAssigned plus the name or number, like ianaAssigned 1 or ianaAssigned ipxOverRaw8023 ✨ The base layer is a pseudo-protocol and isn't decoded itself, and the IANA list is meant to stay centrally maintained so everyone stays interoperable 🫶
5.2.5.1. IANA Assigned Protocol Identifiers
These protocol-variant-identifier macros are how the RMONMIB IANA assigned protocols get identified, by plain enumeration 🔥 Some enumerations may carry an extra four-octet layer identifier (same idea as the vsnap base layer), so check the CHILDREN clause of the protocol-identifier macro to see how many octets the ianaAssigned layer identifier uses 💜
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 }ipxOverRaw8023 is IPX sent over 802.3 without a type field 🌸 Telling a raw8023 packet apart from a real 802.2 one takes protocol-specific tests, and those depend on the active child protocols for raw8023. That part is out of scope for this document 🙈
5.3. L3: Children of Base Protocol Identifiers ✨
Okay so, network layer macros add extra info about the network layer, and they sit right after a base layer-identifier in a protocol identifier 💖
The ProtocolDirParameters supported at this layer are countsFragments(0) and tracksSessions(1), and an agent is allowed to implement only some of them 🧚 The protocol-name should be used for the ProtocolDirDescr field 🎀 The ProtocolDirType ATTRIBUTES used here are hasChildren(0) and addressRecognitionCapable(1). Agents can implement a subset of these per protocol, which limits which tables that protocol can show up in (like protocol distribution, host, and matrix tables) 🦋
The macros below are for example purposes only 💅 They aren't an exhaustive list, and they aren't an authoritative source for any of the protocol info. But any protocol that can encapsulate other protocols must be documented here so its children can be encoded into protocolDirID strings 👑 Leaf protocols should be documented too, but an implementation can still identify a leaf that isn't listed, as long as its parent is documented 🫶
5.3.1. IP
ip PROTOCOL-IDENTIFIER
PARAMETERS {
countsFragments(0) -- This parameter applies to all child
-- protocols.
}
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"The protocol identifiers for the Internet Protocol (IP). Note
that IP may be encapsulated within itself, so more than one of
the following identifiers may be present in a particular
protocolDirID string."
CHILDREN
"Children of 'ip' 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 'ip' are encoded as [ 0.0.0.a ], and named as 'ip a'
where 'a' is the protocol field value. For example, a
protocolDirID-fragment value of:
0.0.0.1.0.0.8.0.0.0.0.1
defines an encapsulation of ICMP (ether2.ip.icmp)"
ADDRESS-FORMAT
"4 octets of the IP address, in network byte order. Each ip
packet contains two addresses, the source address and the
destination address."
DECODING
"Note: ether2/ip/ipip4/udp is a different protocolDirID than
ether2/ip/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/ipip4/udp 16.0.0.0.1.0.0.8.0.0.0.0.4.0.0.0.17.4.0.0.0.0
ether2/ip/udp 12.0.0.0.1.0.0.8.0.0.0.0.17.3.0.0.0 "
REFERENCE
"RFC 791 [RFC791] defines the Internet Protocol; The following
URL defines the authoritative repository for the PROTOCOL NUMBERS
Table:
ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers"
::= {
ether2 0x0800,
llc 0x06,
snap 0x0800,
ip 4,
ip 94
}IP is the protocol that nests inside itself, so you can get several ip identifiers in one protocolDirID 🌈 Children are picked by the Protocol field, encoded as [ 0.0.0.a ]. For example, 0.0.0.1.0.0.8.0.0.0.0.1 is ICMP over ether2 (ether2.ip.icmp) 💖 Heads up: ether2/ip/ipip4/udp and ether2/ip/udp are different protocolDirIDs, so the agent assigns them two separate local protocol index values 😭 The RFC 791 reference is the Internet Protocol spec, and the PROTOCOL NUMBERS table lives at the IANA repository listed below 🍓
5.3.2. IPX
ipx PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"Novell IPX"
CHILDREN
"Children of IPX are defined by the 16 bit value of the
Destination Socket field. The value is encoded into an octet
string as [ 0.0.a.b ], where 'a' and 'b' are the network byte
order encodings of the MSB and LSB of the destination socket
field."
ADDRESS-FORMAT
"4 bytes of Network number followed by the 6 bytes Host address
each in network byte order".
REFERENCE
"The IPX protocol is defined by the Novell Corporation
A complete description of IPX may be secured at the following
address:
Novell, Inc.
122 East 1700 South
P. O. Box 5900
Provo, Utah 84601 USA
800 526 5463
Novell Part # 883-000780-001"
::= {
ether2 0x8137, -- 0.0.129.55
llc 0xe0e003, -- 0.224.224.3
snap 0x8137, -- 0.0.129.55
ianaAssigned 0x1 -- 0.0.0.1 (ipxOverRaw8023)
}IPX is Novell's protocol, and its children are keyed off the 16-bit Destination Socket field, encoded as [ 0.0.a.b ] 🎀 Addresses are 4 bytes of network number followed by a 6-byte host address, both in network byte order 💅 Novell's own docs are the reference here, so if you want the full picture, that's where it's at 📚
5.3.3. ARP
arp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"An Address Resolution Protocol message (request or response).
This protocol does not include Reverse ARP (RARP) packets, which
are counted separately."
REFERENCE
"RFC 826 [RFC826] defines the Address Resolution Protocol."
::= {
ether2 0x806, -- [ 0.0.8.6 ]
snap 0x806
}ARP covers Address Resolution Protocol request and response messages 🌸 Reverse ARP packets aren't included here since they're counted separately, and [RFC826] is the spec that defines ARP 🦋
5.3.4. IDP
idp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"Xerox IDP"
CHILDREN
"Children of IDP are defined by the 8 bit value of the Packet
type field. The value is encoded into an octet string as [
0.0.0.a ], where 'a' is the value of the packet type field in
network byte order."
ADDRESS-FORMAT
"4 bytes of Network number followed by the 6 bytes Host address
each in network byte order".
REFERENCE
"Xerox Corporation, Document XNSS 028112, 1981"
::= {
ether2 0x600, -- [ 0.0.6.0 ]
snap 0x600
}IDP is Xerox's protocol, and its children are defined by the 8-bit Packet type field, encoded as [ 0.0.0.a ] 🧚 Addresses use the same 4-byte network number plus 6-byte host layout as IPX, and the reference is the Xerox document XNSS 028112 from 1981 🍓
5.3.5. AppleTalk ARP
atalkarp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"AppleTalk Address Resolution Protocol."
REFERENCE
"AppleTalk Phase 2 Protocol Specification, document ADPA
#C0144LL/A."
::= {
ether2 0x80f3, -- [ 0.0.128.243 ]
vsnap(0x080007) 0x80f3
}5.3.6. AppleTalk ✨
okay so AppleTalk gets its own entry now, and it's giving main character energy 💅🎀
atalk PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"AppleTalk Protocol."
CHILDREN
"Children of ATALK are defined by the 8 bit value of the DDP type
field. The value is encoded into an octet string as [ 0.0.0.a ],
where 'a' is the value of the DDP type field in network byte
order."
ADDRESS-FORMAT
"2 bytes of Network number followed by 1 byte of node id each in
network byte order".
REFERENCE
"AppleTalk Phase 2 Protocol Specification, document ADPA
#C0144LL/A."
::= {
ether2 0x809b, -- [ 0.0.128.155 ]
vsnap(0x080007) 0x809b
}5.4. L4: Children of L3 Protocols 🦋
we're going one layer up now, bestie 🧚
5.4.1. ICMP 💬
icmp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Internet Message Control Protocol."
REFERENCE
"RFC 792 [RFC792] defines the Internet Control Message Protocol."
::= { ip 1 }5.4.2. TCP 🌸
tcp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Transmission Control Protocol."
CHILDREN
"Children of TCP are identified by the 16 bit Destination Port
value as specified in RFC 793. They are encoded as [ 0.0.a.b],
where 'a' is the MSB and 'b' is the LSB of the Destination Port
value. Both bytes are encoded in network byte order. For
example, a protocolDirId-fragment of:
0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.23
identifies an encapsulation of the telnet protocol
(ether2.ip.tcp.telnet)"
REFERENCE
"RFC 793 [RFC793] defines the Transmission Control Protocol.
The following URL defines the authoritative repository for
reserved and registered TCP port values:
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers"
::= { ip 6 }5.4.3. UDP 🍓
udp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"User Datagram Protocol."
CHILDREN
"Children of UDP are identified by the 16 bit Destination Port
value as specified in RFC 768. They are encoded as [ 0.0.a.b ],
where 'a' is the MSB and 'b' is the LSB of the Destination Port
value. Both bytes are encoded in network byte order. For
example, a protocolDirId-fragment of:
0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161
identifies an encapsulation of SNMP (ether2.ip.udp.snmp)"
REFERENCE
"RFC 768 [RFC768] defines the User Datagram Protocol.
The following URL defines the authoritative repository for
reserved and registered UDP port values:
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers"
::= { ip 17 }5.5. L5: Application Layer Protocols 👑
the main event, the stuff everyone actually uses 🫶
5.5.1. FTP 📁
5.5.1.1. FTP-DATA
ftp-data PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The File Transfer Protocol Data Port; the FTP Server process
default data-connection port. "
REFERENCE
"RFC 959 [RFC959] defines the File Transfer Protocol. Refer to
section 3.2 of [RFC959] for details on FTP data connections."
::= { tcp 20 }5.5.1.2. FTP Control
ftp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The File Transfer Protocol Control Port; An FTP client initiates
an FTP control connection by sending FTP commands from user port
(U) to this port."
REFERENCE
"RFC 959 [RFC959] defines the File Transfer Protocol."
::= { tcp 21 }5.5.2. Telnet 🖥️
telnet PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The Telnet Protocol; The purpose of the TELNET Protocol is to
provide a fairly general, bi-directional, eight-bit byte oriented
communications facility. Its primary goal is to allow a standard
method of interfacing terminal devices and terminal-oriented
processes to each other. "
REFERENCE
"RFC 854 [RFC854] defines the basic Telnet Protocol."
::= { tcp 23 }5.5.3. SMTP ✉️
smtp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The Simple Mail Transfer Protocol; SMTP control and data
messages are sent on this port."
REFERENCE
"RFC 821 [RFC821] defines the basic Simple Mail Transfer
Protocol."
::= { tcp 25 }5.5.4. DNS 🧭
domain PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Domain Name Service Protocol; DNS may be transported by either
UDP [RFC768] or TCP [RFC793]. If the transport is UDP, DNS
requests restricted to 512 bytes in length may be sent to this
port."
REFERENCE
"RFC 1035 [RFC1035] defines the Bootstrap Protocol."
::= { udp 53,
tcp 53 }5.5.5. BOOTP 🥾
5.5.5.1. Bootstrap Server Protocol
bootps PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Bootstrap Protocol Server Protocol; BOOTP Clients send requests
(usually broadcast) to the bootps port."
REFERENCE
"RFC 951 [RFC951] defines the Bootstrap Protocol."
::= { udp 67 }5.5.5.2. Bootstrap Client Protocol
bootpc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Bootstrap Protocol Client Protocol; BOOTP Server replies are
sent to the BOOTP Client using this destination port."
REFERENCE
"RFC 951 [RFC951] defines the Bootstrap Protocol."
::= { udp 68 }5.5.6. TFTP 🐣
tftp PROTOCOL-IDENTIFIER
PARAMETERS {
tracksSessions(1)
}
ATTRIBUTES { }
DESCRIPTION
"Trivial File Transfer Protocol; Only the first packet of each
TFTP transaction will be sent to port 69. If the tracksSessions
attribute is set, then packets for each TFTP transaction will be
attributed to tftp, instead of the unregistered port numbers that
will be encoded in subsequent packets."
REFERENCE
"RFC 1350 [RFC1350] defines the TFTP Protocol (revision 2); RFC
1782 [RFC1782] defines TFTP Option Extensions; RFC 1783 [RFC1783]
defines the TFTP Blocksize Option; RFC 1784 [RFC1784] defines
TFTP Timeout Interval and Transfer Size Options."
::= { udp 69 }5.5.7. HTTP 🌐
www-http PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Hypertext Transfer Protocol; "
REFERENCE
"RFC 1945 [RFC1945] defines the Hypertext Transfer Protocol
(HTTP/1.0)."
::= { tcp 80 }5.5.8. POP3 📬
pop3 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Post Office Protocol -- Version 3. Clients establish connections
with POP3 servers by using this destination port number."
REFERENCE
"RFC 1725 [RFC1725] defines Version 3 of the Post Office
Protocol."
::= { tcp 110 }5.5.9. SUNRPC 🎛️
sunrpc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0) -- port mapper function numbers
}
DESCRIPTION
"SUN Remote Procedure Call Protocol. Port mapper function
requests are sent to this destination port."
CHILDREN
Specific RPC functions are represented as children of the sunrpc
protocol. Each 'RPC function protocol' is identified by its
function number assignment. RPC function number assignments are
defined by different naming authorities, depending of the
function identifier value.
From [RFC1831]:
Program numbers are given out in groups of hexadecimal 20000000
(decimal 536870912) according to the following chart:
0 - 1fffffff defined by rpc@sun.com
20000000 - 3fffffff defined by user
40000000 - 5fffffff transient
60000000 - 7fffffff reserved
80000000 - 9fffffff reserved
a0000000 - bfffffff reserved
c0000000 - dfffffff reserved
e0000000 - ffffffff reserved
Children of 'sunrpc' are encoded as [ 0.0.0.111], the protocol
identifier component for 'sunrpc', followed by [ a.b.c.d ], where
a.b.c.d is the 32 bit binary RPC program number encoded in
network byte order. For example, a protocolDirID-fragment value
of:
0.0.0.111.0.1.134.163
defines the NFS function (and protocol).
Children are named as 'sunrpc' followed by the RPC function
number in base 10 format. For example, NFS would be named:
'sunrpc 100003'.
REFERENCE
"RFC 1831 [RFC1831] defines the Remote Procedure Call Protocol
Version 2. The authoritative list of RPC Functions is identified
by the URL:
ftp://ftp.isi.edu/in-notes/iana/assignments/sun-rpc-numbers"
::= { udp 111 }5.5.10. NFS 🗂️
nfs PROTOCOL-IDENTIFIER
PARAMETERS {
countsFragments(0)
}
ATTRIBUTES { }
DESCRIPTION
"Sun Network File System (NFS);"
DECODING
"The first packet in an NFS transaction is sent to the port-
mapper, and therefore decoded statically by monitoring RFC
portmap requests [RFC1831]. Any subsequent NFS fragments must be
decoded and correctly identified by 'remembering' the port
assignments used in each RPC function call (as identified
according to the procedures in the RPC Specification Version 2
[RFC1831]).
The 'countsFragments(0)' PARAMETER bit is used to indicate
whether the probe can (and should) monitor portmapper activity to
correctly attribute all NFS packets."
REFERENCE
"The NFS Version 3 Protocol Specification is defined in RFC 1813
[RFC1813]."
::= {
sunrpc 100003 -- [0.1.134.163]
}5.5.11. SNMP 📊
5.5.11.1. SNMP Request/Response
snmp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Simple Network Management Protocol. Includes SNMPv1 and SNMPv2
protocol versions. Does not include SNMP trap packets."
REFERENCE
"The SNMP SMI is defined in RFC 1902 [RFC1902]. The SNMP
protocol is defined in RFC 1905 [RFC1905]. Transport mappings
are defined in RFC 1906 [RFC1906]; RFC 1420 (SNMP over IPX)
[RFC1420]; RFC 1419 (SNMP over AppleTalk) [RFC1419]."
::= {
udp 161,
ipx 0x900f, -- [ 0.0.144.15 ]
atalk 8
}5.5.11.2. SNMP Trap 🔔
snmptrap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Simple Network Management Protocol Trap Port."
REFERENCE
"The SNMP SMI is defined in RFC 1902 [RFC1902]. The SNMP
protocol is defined in RFC 1905 [RFC1905]. Transport mappings
are defined in RFC 1906 [RFC1906]; RFC 1420 (SNMP over IPX)
[RFC1420]; RFC 1419 (SNMP over AppleTalk) [RFC1419]."
::= {
udp 162,
ipx 0x9010,
atalk 9
}6. Acknowledgements 🫶
this doc came out of the IETF RMONMIB Working Group, and the authors wanted to thank these people for their help 💜
- Anil Singhal, Frontier Software Development, Inc.
- Jeanne Haney, Bay Networks
- Dan Hansen, Network General Corp.
7. References 📚
- [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, USC/Information Sciences Institute, August 1980.
- [RFC791] Postel, J., ed., "Internet Protocol - DARPA Internet Program Protocol Specification", STD 5, RFC 791, USC/Information Sciences Institute, September 1981.
Postel, J., "Internet Control Message Protocol - DARPA Internet Program Protocol Specification", STD 5, RFC 792, USC/Information Sciences Institute, September 1981.
[RFC793] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", STD 5, RFC 793, USC/Information Sciences Institute, September 1981. 🦋
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982. 💌
[RFC826] Plummer, D., "An Ethernet Address Resolution Protocol or "Converting Network Protocol Addresses to 48-bit Ethernet Addresses for Transmission on Ethernet Hardware", STD 37, RFC 826, MIT-LCS, November 1982. 🧚
[RFC854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, ISI, May 1983. 🌸
[RFC894] Hornig, C., "A Standard for the Transmission of IP Datagrams over Ethernet Networks", RFC 894, Symbolics, April 1984. ✨
[RFC951] Croft, B., and J. Gilmore, "BOOTSTRAP Protocol (BOOTP)", RFC 951, Stanford and SUN Microsytems, September 1985. 🍓
[RFC959] Postel, J., and J. Reynolds, "File Transfer Protocol", STD 8, RFC 959, USC/Information Sciences Institute, October 1985. 📁
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987. 🗂️
[RFC1157] Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Laboratory for Computer Science, May 1990. 📡
[RFC1213] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. 💜
[RFC1350] Sollins, K., "TFTP Protocol (revision 2)", RFC 1350, MIT, July 1992. 🌈
[RFC1419] Minshall, G., and M. Ritter, "SNMP over AppleTalk", RFC 1419, Novell, Inc., Apple Computer, Inc., March 1993. 🍎
[RFC1420] Bostock, S., "SNMP over IPX", RFC 1420, Novell, Inc., March 1993. 🎀
[RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. 🔢
[RFC1725] Myers, J., and M. Rose, "Post Office Protocol - Version 3", RFC 1725, Carnegie Mellon, Dover Beach Consulting, November 1994. 📬
[RFC1757] S. Waldbusser, "Remote Network Monitoring MIB", RFC 1757, Carnegie Mellon University, February 1995. 👀
[RFC1782] Malkin, G., and A. Harkin, T "TFTP Option Extension", RFC 1782, Xylogics, Inc., Hewlett Packard Co., March 1995. 🧸
[RFC1783] Malkin, G., and A. Harkin, T "TFTP BlockOption Option", RFC 1783, Xylogics, Inc., Hewlett Packard Co., March 1995. 🧱
[RFC1784] Malkin, G., and A. Harkin, "TFTP Timeout Interval and Transfer Size Options", RFC 1784, Xylogics, Inc., Hewlett Packard Co., March 1995. ⏱️
[RFC1800] Postel, J., Editor, "Internet Official Protocol Standards", STD 1, RFC 1920, IAB, March 1996. 📜
[RFC1831] Srinivasan, R., "Remote Procedure Call Protocol Version 2", RFC 1831, Sun Microsystems, Inc., August 1995. 🛎️
[RFC1902] SNMPv2 Working Group, 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] SNMPv2 Working Group, 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] SNMPv2 Working Group, 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] SNMPv2 Working Group, 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] SNMPv2 Working Group, 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. 🚚
[RFC1945] Berners-Lee, T., and R. Fielding, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, MIT/UC-Irvine, November 1995. 🌐
[RMON2] S. Waldbusser, "Remote Network Monitoring MIB (RMON-2)", draft-ietf-rmonmib-rmon2-03.txt, International Network Services, January 1996. 🔭
8. Security Considerations 💀
Security issues are not discussed in this memo. 🙈 Not me noticing that this whole document has zero security talk. Keep that in mind as you read. 🫣
9. Authors' Addresses 🫶
Andy Bierman
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Phone: 408-527-3711
EMail: abierman@cisco.com
Robin Iddon
3Com/AXON
40/50 Blackfrias Street
Edinburgh, UK
Phone: +44 131.558.3888
EMail: robin_iddon@3mail.3com.comThat's the whole RFC, bestie! 🌈👑 Andy and Robin, you legends. ✨💖
📦 where this page comes from
- ietf: rfc2074 1997-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms