Summary

  • IPv4 option 136 carried one 16-bit SATNET stream identifier through networks that did not understand the stream concept.
  • Host and router standards first stopped the field from causing action, then formal deprecation and filtering guidance completed its retirement.

A complete mechanism in four octets

RFC 791 gave Stream Identifier no variable list or pointer. The first octet was type 136, the second declared a fixed length of 4, and the final two held a 16-bit Stream ID. Its purpose was narrow: carry a SATNET stream identifier across networks that did not support streams themselves.

The option’s copy bit was set. If an IPv4 datagram fragmented, every fragment inherited the identifier. It could appear at most once. Those rules made sense for a label meant to survive passage through infrastructure that lacked its semantics: intermediaries did not need to understand the stream for the value to remain attached.

That economy also exposes the dependency. The four bytes defined carriage, not an independent stream system. They contained no negotiation, allocation procedure, validation or fallback meaning. Once the SATNET stream concept ceased to matter operationally, the option had no general Internet purpose to discover inside itself.

Obsolescence before formal retirement

By RFC 1122, the host rule was already explicit: Stream Identifier was obsolete, SHOULD NOT be sent, and MUST be silently ignored when received. RFC 1812 carried the same settlement into routers. A router should not originate it; if received locally it must ignore it; if present in a forwarded packet it must pass through unchanged while doing nothing with the value.

Ignoring and preserving were not contradictory. The first prevented dead semantics from controlling current behavior. The second avoided turning an obsolete but well-formed field into an accidental forwarding failure. Compatibility had been reduced to inertia.

RFC 6814 finally deprecated Stream ID formally in 2012 as part of cleaning the IPv4 option registry. RFC 7126 then described no current use, no specific known security problem, and no interoperability cost from blocking it. Its operational advice was therefore simpler than for diagnostic options: routers, gateways and firewalls should drop packets that contain it.

Sources