Remote Network Monitoring MIB Protocol Identifiers
obsoleted by
- rfc-2895 — Remote Network Monitoring MIB Protocol Identifier Reference
Extracted elements (26)
Protocol-identifier macros are expanded at implementation time, not at run time. A label such as 'ip' may map to multiple distinct values (one per supported encapsulation), so 'ip' produces 5 distinct protocol-identifiers and each child of ip maps to at least 5 identifiers.
Protocol identifier macros are intentionally separated from the RMON-2 MIB objects to allow frequent updates to the identifier definitions without republication of MIB objects. Macro submissions are collected via the RMONMIB WG mailing list and IANA FTP directory.
The ianaAssigned base-layer is provided for protocols that cannot be identified by examination of appropriate network traffic (e.g., those requiring configuration-based criteria). Standard protocols remapped to non-standard ports should use the user-extensibility feature of protocolDirTable instead, and do not need IANA assignments.
DNS may be transported by either UDP or TCP; the domain protocol-identifier macro covers both transports (udp 53 and tcp 53). DNS requests over UDP are restricted to 512 bytes.
Only type values >= 1500 decimal in the Ethernet header indicate Ethernet-II (ether2) frames; lower values indicate 802.3 encapsulation. The ether2 protocol identifier applies only to the former.
Agent implementations must ensure the protocolDirTable does not contain any instances of the protocolDirDescr object which differ only in case of one or more letters when they are intended to represent different protocols. NMS applications may treat protocol names as case-insensitive strings.
The CHILDREN clause must be present in all protocol-identifier macro declarations in which the 'hasChildren(0)' bit is set in the ATTRIBUTES clause. The ADDRESS-FORMAT clause must be present when the 'addressRecognitionCapable(1)' bit is set.
The 'countsFragments(0)' bit may be set in at most one protocolDirParameters octet within a protocolDirTable INDEX, and only for a protocol that supports fragmentation and reassembly. TCP is explicitly ineligible.
The PARAMETERS clause must be present in all protocol-identifier macro declarations but may be empty. The ATTRIBUTES and DESCRIPTION clauses must also be present in all protocol-identifier macro declarations.
The protocolDirID length must be evenly divisible by four, and the protocolDirParameters length must be exactly one quarter of the protocolDirID string length. Layers may not be skipped in a protocol-identifier.
A protocol-identifier string (protocolDirID) is composed of one or more 4-octet layer-identifiers concatenated together, uniquely identifying a protocol encapsulation tree. The protocolDirParameters string contains one 1-octet parameter per 4-octet layer-identifier.
IP (ip) is identified as a child of ether2 (0x0800), llc (0x06), snap (0x0800), and also as ip-in-ip (ip protocol 4) and ip-in-ip with encapsulation (ip protocol 94). IP children are selected by the 1-octet Protocol field, encoded as [0.0.0.a].
NFS uses the 'countsFragments(0)' parameter because NFS transactions begin with a portmapper request and subsequent fragments must be tracked by remembering port assignments from each RPC function call.
SNMP request/response is identified at UDP port 161, IPX socket 0x900f, and AppleTalk DDP type 8. SNMP traps are identified at UDP port 162, IPX socket 0x9010, and AppleTalk DDP type 9.
TCP children (application protocols) are identified by the 16-bit Destination Port value encoded as [0.0.a.b] in network byte order. UDP children use the same encoding. TCP does not support the countsFragments parameter.
TFTP uses the 'tracksSessions(1)' parameter because only the first packet goes to UDP port 69; subsequent packets use dynamically assigned ports. The parameter indicates the probe tracks the remapped session ports.
The vsnap pseudo-protocol handles all SNAP packets with non-zero OUI. Its identifier is 8 octets: [0.0.0.4] followed by [0.a.b.c.0.0.d.e] where a/b/c are the 3-octet OUI and d/e are the 2-byte EtherType. Two protocolDirParameters octets are required, the second set to zero.
The wildcard function (function-ID=1) uses a single protocol value to match any base-layer encapsulation of a particular network-layer protocol. Each wildcard must be defined in terms of a base encapsulation, preferring ether2 if permitted.
Two ATTRIBUTES bits are defined: bit 0 'hasChildren' indicates child protocols may be defined in the protocolDirTable; bit 1 'addressRecognitionCapable' indicates the protocol can be used to generate host and matrix table entries.
Two reserved PARAMETERS bits are defined: bit 0 'countsFragments' indicates the probe correctly counts higher-layer protocols even when the encapsulating protocol fragments them; bit 1 'tracksSessions' indicates the probe correctly attributes packets for protocols that remap to dynamic ports (e.g., TFTP).
Five base layer encapsulation values are defined: ether2=1, llc=2, snap=3, vsnap=4, ianaAssigned=5. By design only 255 different base layer encapsulations are supported. New base encapsulation values are expected to be added over time.
IANA assigned protocol identifiers are enumerated under the ianaAssigned base-layer (value 5). The first assigned protocol is ipxOverRaw8023=1, for IPX encapsulated directly in 802.3 without a type field. A centrally maintained list is required for interoperability.
Two protocol identifier functions are assigned: function 0 (none/no-op) and function 1 (wildcard). The wildcard function aggregates counters across all base-layer encapsulations of a given network-layer protocol.
The RFC explicitly states that security issues are not discussed in this memo.
Normal (non-base, non-vsnap) layer-identifiers are exactly 4 octets encoded in network byte order. The vsnap base-layer identifier is exactly 8 octets, requiring 2 protocolDirParameters octets (the second must be zero).
The base-identifier is encoded as exactly 4 octets: 1 octet function code ('f'), 2 octets operands ('op1', 'op2'), and 1 octet base-layer enumeration ('m'), all in network byte order. The 'vsnap' base-layer identifier is an exception, encoded as 8 octets.