Summary

  • RFC 1365 proposed a Class F address whose extra bytes would sit in IP options while the fixed source and destination fields kept their positions.
  • Its interoperability section said the awkward part plainly: an old host would ignore a Class F datagram. A familiar header shape did not make the new address intelligible.

The promise was tempting. Keep the IP header where it is, find a little room in the options, and make an address longer without asking the whole Internet to swallow a different packet format. Karanjit Siyan offered that bargain in September 1992, when his Informational RFC 1365 described a shortage of network numbers under the then-current class system. He called for discussion, not a standard.

The packet already had a bounded amount of spare room. Its four-bit Internet Header Length field allowed at most fifteen words of four octets each. The basic header used five. Siyan proposed reserving six of the remaining ten words for ordinary options and four for an extended-address option. That division was a proposed layout budget: the address would borrow space from a finite field rather than magically enlarge the header.

His escape hatch was a new Class F prefix, 111110, in the fixed source and destination positions. The leading bits would announce that part of the address lived elsewhere. An offset in the fixed field would point to the address's second part in the options; a receiver could jump there instead of scanning every option. The second part would use a type-length-value structure. The memo described four-octet and eight-octet forms, F-4 and F-8, and proposed narrowing the existing reserved Class E pattern to 11110 to make room for the new prefix.

This is where a clever packet layout meets a less obliging machine. The address extension needed a receiver that knew how to recognise Class F, follow the offset, and assemble the two pieces. Section 3 says an existing host without that support would ignore the datagram. Communication with such hosts would be impossible. Siyan even sketched the receiving code to be added. He argued that this change would be smaller than introducing an entirely different IP header or protocol. Smaller was a claim about the intended modification, not a promise that old software would work untouched.

The distinction matters because the fixed address fields did not become ordinary addresses merely by staying in their old byte positions. In this design they were also signposts to new semantics in the options. A host still reading those bytes under the old class rules would not discover the rest of the address by accident. The proposal moved the compatibility cost from the visible envelope to the code that interprets it.

The document's status sets the historical limit. RFC 1365 was an Informational proposal, not an Internet standard or a record of deployment. Its RFC Editor text establishes the design and its admitted receiver break; it supplies no adoption tally. Nor is its Class F the small-site Class F discussed in a separate RFC 1375 proposal. The shared letter is a naming collision, not evidence of one design following the other.

The sharpest line in this little history is the one the author wrote himself: the datagram would be ignored by a host that did not support the new class. A system can keep the old wrapper, but the receiving program still decides what the wrapper means.