Summary

  • RFC 1108 defined IPv4 option 133 as a repeatable container for additional security labels, with each format code governed by its own interoperable specification.
  • Every Extended Security Option depended on a companion Basic Security Option and shared configuration; stripping the extension could make a packet unusable or attach the wrong sensitivity label.

A container whose meaning lived elsewhere

The Extended Security Option began with type 133, a variable length of at least three octets, and a one-octet Additional Security Info Format Code. Whatever followed belonged to the syntax named by that code. The additional field itself could even be empty if its defining format allowed it.

RFC 1108 required more than a registry label. Each format code was to have an RFC describing its syntax and an algorithmic accept-or-reject procedure in enough detail for independent vendors to interoperate. A mapping from the bits to human labels could remain restricted, but machines still needed a public processing contract.

The option was copied into fragments and could occur several times, bounded only by the IPv4 header-size limit. That multiplicity did not make it independent. Every datagram carrying ESO also had to carry the Basic Security Option. ESO without BSO was an error, as were an unregistered code, an inconsistent length or data that violated the code's defining RFC; RFC 1108 called for ICMP Parameter Problem processing in those cases.

Nor was support all-or-nothing. A system could implement BSO without ESO, or recognise only selected ESO format codes. The protection-authority bits in BSO did not map onto ESO's format-code namespace. Two neighbouring fields could therefore participate in the same security decision while being governed by different registries and capabilities.

As with the basic label, route enforcement required more than header parsing. Intermediate systems could not generally select protected paths by ESO labels until routing protocols also carried that information. The option transported a claim; the network still needed configured port parameters, supported-code knowledge and route state to act on it.

What stripping changed

RFC 7126 later recorded the option's bounded use in private, high-security networks. It warned that stripping ESO could cause the receiver to discard the packet as improperly labelled. Worse, a receiver might associate the data with an incorrect sensitivity label, upgrading or downgrading its treatment.

That asymmetry shaped the advice. A device could not know in advance whether it had been installed in such an environment. The default therefore should not remove the option or drop a packet merely because ESO was present, although an administrator who knew the environment did not use it could configure dropping. Auditable packet counts were also recommended.

The sources do not establish current deployment share, current supported-code inventories or universal product behaviour. Their durable point is architectural: extensibility does not eliminate coordination. It moves coordination into registries, separate specifications and configuration that must remain aligned.

Sources