Summary

  • RFC 1044 let a transmitter set HYPERchannel's SRC flag when its 32-bit FROM address was fit for a reversed reply. Intermediate adapters could clear the flag if that return condition failed.
  • A surviving flag meant that swapping TO and FROM would reach the process that originated the message. It did not check the message bytes, identify a person or authorize the application request; CRC, protocol-server selection and physical trust remained separate controls.

The most useful sentence in RFC 1044 is also its most carefully bounded one. If a HYPERchannel message arrived with the Source Address Correct bit still set, the FROM address was guaranteed correct “in the sense” that reversing TO and FROM would deliver a message to the process that originated it. The qualification matters. The bit established a property of a return path. It did not define every other meaning that an operator might attach to the source.

Published in February 1988, RFC 1044 documented how IP datagrams and related protocols were carried over Network Systems HYPERchannel equipment. It tried to regularize a de facto 16-bit practice, introduce a compatible 32-bit address form, register message types and move address resolution from local tables toward servers and future broadcast-capable ARP. The result is a unusually explicit record of several kinds of evidence sharing one header without becoming interchangeable.

FROM began as an address for the answer

In the basic HYPERchannel message, TO selected the destination while FROM travelled with the message so the receiver could send something back. The network did not use FROM to deliver the outbound message. RFC 1044 says that, in general, reversing the two 16-bit address fields and their trunk masks could reliably return a response to the origin.

That is a practical symmetry, not a statement about human identity. A return label can identify where a response should go even when it says nothing about who typed the request, which account should be charged, whether the sending program was compromised or whether the requested operation was allowed. The address belongs to the carrier's delivery model.

The specification also embedded a protocol server inside the logical part of TO. A process registered the complete address it wished to receive. Once that address selected the final server, the message-type field could not redirect delivery to a different one, although intermediate equipment could use the type for handling in transit. Destination selection and in-path classification were therefore different controls before the SRC flag entered the discussion.

The extended header made returnability a path assertion

The 32-bit header added domain and network coordinates and three flags that are easy to blur together. GNA signalled the extended address form. CRC requested or reported an end-to-end integrity check by suitably equipped adapters. SRC asserted that the supplied source address was correct for the reverse journey.

The SRC rule is subtractive. A transmitting host sets the bit after endeavouring to provide the correct FROM address for the adapter interface it used. Every intermediate adapter on the delivery path may turn the bit off if that address is not a TO address that would route a reversed message to the originator. The destination sees the residue of those checks.

This is not a vote in which several devices positively certify an identity. Nor is it a secret that only an authorized sender can produce. The transmitter writes the initial claim; the path can withdraw it. A surviving bit says that no participating adapter found the specified reverse-delivery defect under the rules it implemented. Absence says even less about cause: the sender may have omitted the assertion, an adapter may have cleared it correctly, an implementation may not have supported the mechanism, or the physical path may have changed.

The asymmetry is historically instructive. Negative evidence can prevent a receiver from relying on the strongest return-address claim. Positive evidence remains conditional on the custody and correctness of the devices that preserved it.

“Correct” had one operational meaning

RFC 1044 does not leave the word correct unlimited. It defines the outcome: reverse the carrier addresses and the response reaches the process that originated the message. This is stronger than merely observing that a packet arrived. It gives the receiver a testable continuation path and binds the address to one origin process in the HYPERchannel delivery system.

It is still narrower than authentication. A program can originate a message without being an authorized principal. A machine can be physically located where its address says it is while running altered code. A response can return successfully while the original request remains malicious, stale or outside policy. Returnability answers where a reply goes; authorization answers whether an effect should occur.

The document itself supplies the missing condition. It says that systems could obtain a high degree of security from the FROM address by paying careful attention to the physical security of adapters and intermediate links. That is an architectural premise, not a property magically produced by the bit. If equipment, configuration and links are inside an accountable physical boundary, the address may support a local legitimacy decision. Without proof of that custody, the flag cannot establish the premise on its own.

CRC checked bytes, not the requester

The separate CRC flag makes the evidence boundary visible. Equipped adapters could append and check a 32-bit CRC covering the network message through intermediate networks and hardware. If the check worked, it supported a claim that the carried bits were not corrupted along that path.

CRC did not make the FROM address reversible; SRC did not show that the associated data was intact. Neither flag identified a person, proved that the embedded IP source was legitimate or supplied permission for an application operation. A receiver that logged only “validated” would erase whether it meant address reversal, byte integrity, protocol-server selection or application acceptance.

RFC 791 adds another layer, not a replacement. The embedded IPv4 datagram has its own source and destination fields, protocol value, Total Length and header checksum. The HYPERchannel carrier has its own addresses and flags. Agreement between the IP source and a resolved HYPERchannel FROM address can be useful, but two consistent address fields still do not name an authorized actor.

Address resolution was another independent record

RFC 1044 describes a migration from low-order address truncation, through local configuration files and a known ARP server, toward a future distributed broadcast mode. It explicitly invokes RFC 826, whose generic format maps protocol addresses to link-layer addresses.

Resolution answers which HYPERchannel header should carry an IP datagram toward a local host or next gateway. It does not show who controls the resulting address or whether the table was fresh. A static entry, a centralized answer and a broadcast reply create different provenance records. None can be silently promoted into application authorization.

The SRC bit can preserve a claim about the return address after resolution. It cannot repair a wrong mapping merely because the wrong address is internally reversible. Consistency is not truth; it is only one condition a trustworthy system may require.

The receiving driver was told not to overreact

The IP encapsulation section contains a final restraint. Transmitting IP drivers should set Source Address Correct when they have endeavoured to supply the interface's completely correct FROM address. But receiving IP drivers were instructed to take no action on the bit at that time. More work was needed to decide what should happen if the flag was absent in a real or imagined security violation.

That instruction prevents an attractive mistake. A newly specified evidence bit does not automatically become an admission gate. Operators still need a failure policy, compatibility knowledge, custody assumptions and a way to distinguish unsupported signalling from an actual path defect. A receiver that drops every unmarked message may transform incomplete deployment into an outage; one that treats every marked message as authorized may transform reachability into privilege.

RFC 1044's achievement was not to solve source authentication. It made a physical-network property explicit enough to be tested, cleared and carried alongside other properties. Its careful division of flags and fields shows how an early high-speed carrier could expose useful evidence without claiming that one bit governed the whole request.

Sources and limits of evidence

RFC 1044 supplies the HYPERchannel message formats, address reversal, logical-server selection, flag semantics, physical-security condition, driver guidance and resolution stages. RFC 791 defines the embedded IPv4 header and its separate length, address and checksum fields. RFC 826 defines the generic protocol-to-link-address resolution model reused by RFC 1044.

These sources establish a documented specification and its stated assumptions. They do not prove that a named installation implemented SRC, that every adapter cleared it correctly, that any physical boundary was secure, that an observed request came from an authorized person, or that a requested action completed.