Summary

  • RFC 1449 carried one SNMPv2 message grammar over UDP, OSI, AppleTalk DDP and IPX, but it did not pretend that those networks shared one address format. A transport-domain object identifier selected the grammar of the accompanying address.
  • All four address conventions used the ASN.1 base type OCTET STRING. Their meanings were incompatible: six octets meant IPv4 plus UDP port, twelve meant an IPX network, physical address and socket, while OSI and NBP values were length-delimited structures.
  • A valid domain/address pair made bytes interpretable. It did not prove assignment, routing, listener state, peer identity, authorization, a response or a device effect. Losing the domain destroyed meaning; retaining it supplied only the first layer of evidence.

The archive kept the value and lost the type

Take the six bytes C0 00 02 07 00 A1. If a record labels them SnmpUDPAddress, the first four octets can be read as an IPv4 address and the last two as a UDP port, both in network byte order. The final pair gives 161. The value now has a grammar.

Remove that label and certainty vanishes. Six is the required length of the UDP form, but length is not a universal naming authority. A compact private format could also occupy six bytes. A truncated value could happen to occupy six. Most importantly, RFC 1449 did not define an untagged bucket in which every OCTET STRING was guessed by shape. It defined named transport domains and address conventions that belonged together.

That is the historical interest of a document whose title sounds like plumbing. Published in April 1993, RFC 1449 described how version 2 of the Simple Network Management Protocol could travel over an initial set of protocol suites. The management message remained a management message. The road, address and local rendezvous rules changed around it.

The design made heterogeneity explicit instead of hiding it behind a universal-looking string. A manager could hold one abstract destination field only by also retaining the field that told it how to interpret that destination. The pair, not the byte string, was the usable object.

Five domain names, four address grammars

RFC 1449 assigned object identifiers beneath snmpDomains to UDP, connectionless OSI, connection-oriented OSI, DDP and IPX. CLNS and CONS shared the OSI address convention, which is why five domain identifiers selected four address types.

The UDP convention was the compact one. SnmpUDPAddress occupied exactly six octets. Octets one through four represented an IP address. Five and six represented the port. The display hint could render the result in a familiar dotted-address-and-port form, but the hint did not create the meaning. The domain and textual convention did.

The OSI convention could not be decoded by slicing at a fixed boundary. Its first octet stated the length of the NSAP. The NSAP followed, and the remaining octets carried the transport selector. Zero was permitted for the NSAP length, or a value from three through twenty; the total string could be one octet or from four through eighty-five. Here the first byte was not the beginning of an IPv4 address. It was control information for decoding the rest.

The DDP domain selected SnmpNBPAddress, an encoded AppleTalk NBP name rather than a raw DDP delivery tuple. Three length fields separated object, type and zone strings. The total could range from three to ninety-nine octets. Comparison was case-insensitive, and octet 255 was excluded from those strings. This is a different use of length, identity and location from either UDP or OSI.

IPX returned to a fixed size, but not to the UDP layout. Its twelve octets divided into a four-octet network number, a six-octet physical address and a two-octet socket number. A parser that retained only “twelve bytes” knew too little. A parser that forced the value into an IPv6-shaped display because the storage field was long enough would manufacture a fact never supplied by the protocol.

The common ASN.1 type therefore described storage mechanics, not semantic equivalence. OCTET STRING said that the value was an ordered run of octets. It did not say what positions meant, whether comparison was case-sensitive, which component was a selector or socket, or which network could carry the result.

The inner message did not have to become the road

The separation worked because RFC 1449 kept another invariant stable. An SNMPv2 message was serialized under the same Basic Encoding Rules and then placed whole into the transport unit selected for the domain. UDP used one datagram. DDP used one datagram. IPX used one datagram. The OSI mapping used one transport service data unit.

The RFC constrained BER along the way. Lengths used the definite form. Simple values such as INTEGER, OCTET STRING and OBJECT IDENTIFIER used primitive encoding; constructed encoding belonged to structured types. The restriction applied through the wrapper, protocol data units and contained objects. A worked GetBulkRequest showed that the same management operation could be expressed without making its syntax depend on the outer network.

This did not make the transports operationally interchangeable. Their addresses, listener conventions and failure modes remained different. It made the message portable because the common layer stopped at the message boundary. A protocol suite did not gain authority to redefine the PDU merely because it delivered the bytes.

UDP was nevertheless preferred. RFC 1449 advised systems deploying another mapping also to provide proxy service to the UDP mapping for the widest interoperability. Preference was not identity. It named a practical meeting point among implementations, while the domain tag continued to say which road a particular address belonged to.

Port 161 was correspondingly local to one mapping. The RFC suggested that agents using UDP listen there and notification sinks use 162. OSI used transport selectors. DDP used protocol type 8 and sockets 8 and 9, together with NBP types. IPX used packet type 4 and its own socket conventions. Treating 161 as the universal meaning of “SNMP endpoint” would erase the very heterogeneity the document took pains to encode.

Revision made the association more explicit

RFC 1906 replaced RFC 1449 in 1996. One revealing editorial change was to express each transport domain as an OBJECT-IDENTITY whose description named the corresponding address textual convention. The UDP domain said its address was SnmpUDPAddress; the OSI domains said SnmpOSIAddress; DDP pointed to SnmpNBPAddress; IPX pointed to SnmpIPXAddress.

That wording did not invent the pairing. RFC 1449 already supplied it through adjacent definitions and use. The successor made the schema relation harder to overlook. A domain identifier was not merely a code to decorate a row. It was the discriminator that selected the valid decoder for the row’s address value.

RFC 3417 later replaced RFC 1906 and carried the revision history forward. It described the preferred mapping more precisely as UDP over IPv4 and retained the domain-specific conventions. Its module recorded both the 1996 clarification and the 1993 initial version. The lineage shows a contract being refined without turning old source text into evidence of present use.

Historical continuity is easy to overread. A current standard can preserve an object identifier for compatibility even when a transport family is rare or absent in a given network. The continued existence of snmpIPXDomain proves that a standardized interpretation exists. It does not prove that an IPX stack is enabled, that a destination is configured or that any datagram crossed it.

Decoding was only the first gate

Suppose an observer retains both snmpUDPDomain and a six-octet value. The record can now support a bounded statement: under the RFC’s type contract, the bytes decode as a particular IPv4 address and UDP port. It cannot support the stronger statement that the address was assigned to the intended device at that time.

Assignment would need its own record. A route would need forwarding evidence. Reachability would need a probe or exchange. A listening process would need a response or host observation. Peer identity would need authentication bound to the exchange. Permission to retrieve or alter management objects would need an access-control decision. A successful request would still not by itself prove the final physical or service effect.

The chain is directional:

bytes → domain → typed address → selected transport → observed exchange → authenticated peer → authorized operation → measured effect

Each arrow requires new evidence. None can be filled by confidence in the field to its left.

This is where loss of the discriminator differs from ordinary uncertainty. If a route has not been observed, an operator may observe it later. If the domain tag has been irreversibly stripped from an old value, later software may have no principled way to reconstruct the original address grammar. The archive has not merely failed to prove delivery. It has destroyed its ability to say what destination was recorded.

Display was not storage

Display hints made the values readable to operators. A UDP value could appear as dotted decimal plus a port. An IPX value could be grouped according to network, physical and socket components. Readability helped prevent mistakes, but a rendered string was a projection of typed state.

Saving only that projection creates another ambiguity. Punctuation may suggest a type, but punctuation changes across tools. Leading zeroes disappear. Hexadecimal case changes. A selector can be escaped or truncated. A later parser may accept a string that the original convention would not have generated. Durable storage therefore needs the domain identifier, the exact octets and the decoder version; the friendly form can be regenerated.

The historical lesson is larger than SNMP. Extensible systems often place several meanings inside one convenient base field: bytes, strings, integers or JSON objects. That economy is safe only while a stable discriminator travels with the value. A schema that discards the tag in order to look simpler has not normalized the data. It has merged incompatible claims.

Sources and limits

The documentary line begins with the RFC Editor record for RFC 1449 and the full text of RFC 1449, continues through RFC 1906, and reaches the RFC Editor record for RFC 3417 and RFC 3417. These sources establish syntax, mapping rules, status and revision lineage. They do not establish vendor implementation, deployment, traffic volume, successful communication or present network effect.