Summary

  • RFC 875 distinguished an Internet gateway that forwarded a shared IP datagram from a translating gateway that had to reconcile different address, acknowledgement, flow-control and application semantics.
  • Once the intermediary terminated both protocol worlds, it became a connection-state singularity: redundancy, failure recovery and every change on either side required another explicit design.

Draw two networks on a page. Put a rectangle between them. Add one arrow entering, another leaving, and call the rectangle a gateway. The diagram now claims that communication is possible before anyone has said what must survive the crossing.

M. A. Padlipsky attacked that rectangle in RFC 875, Gateways, Architectures, and Heffalumps, published in September 1982. The memo was not a standard and did not report a census of deployed translators. It was a warning about an architectural shortcut: treating a gateway between incompatible protocol suites as if it were merely a more ambitious version of an Internet gateway.

The distinction mattered because the Internet's ordinary gateway had a deliberately small job. Different packet networks could use different local framing, addressing and access procedures, but they carried the same Internet Protocol above them. The gateway adapted to each local network and forwarded the shared object. A translating/mapping gateway—Padlipsky's T/MG—had no such stable object. It had to decide which claim on one side corresponded to which claim on the other.

The thin common layer already contained a bargain

RFC 791 defined IP for interconnected packet-switched networks. It supplied fixed-length Internet addresses and fragmentation so that a datagram could cross networks with different packet sizes. It explicitly did not supply end-to-end reliability, sequencing or flow control. Those functions belonged elsewhere.

That negative space was part of the architecture. An IP gateway could inspect an Internet address, choose a next hop, unwrap the datagram from one local network and wrap it for another. It did not need to impersonate the TCP endpoints. RFC 791 even said that higher-level protocols need not be implemented in a gateway.

RFC 793 placed connection state, reliable delivery, sequencing, windows and urgent indications in TCP at the hosts. The network layer and the transport layer did not make identical promises. Interoperation worked because every participant knew which layer owned each promise.

RFC 875's complaint was not that heterogeneity was impossible. IP was built to cross heterogeneous packet networks. The complaint was that heterogeneity below a shared waist differs from semantic incompatibility above it. A gateway can replace a local frame because both sides agree that the enclosed IP datagram is still the same object. It cannot replace a missing application or transport guarantee by changing a field name.

An address with no foreign dimension could not be reformatted into one

Padlipsky began with NCP and TCP/IP because they were close enough to make the difficulty visible without exotic examples. An NCP host interface identified a host inside its own ARPANET address space. An IP address combined a network part with a host part. The NCP side therefore lacked an ordinary place to state, “the destination is this host on that other network.”

A translator could hunt for spare bits, alter the initial connection protocol, or place an Internet address in application data. Each answer changed the supposedly unchanged NCP environment. The problem was not the printed shape of the number. One side's contract lacked the scope expressed by the other.

RFC 875 described a more honest escape. The intermediary could become a host, terminate the first connection, ask a user which foreign system was wanted and originate a second connection. Padlipsky called this a “Janus Host,” after the two-faced deity. The mechanism could be useful, especially for interactive Telnet, but it was no longer a transparent connection.

RFC 801, the NCP/TCP transition plan, made that boundary operational. A Telnet user connected to a relay host, logged into a special account and then started another Telnet connection in the other environment. FTP required two file movements through the relay. Mail had its own relay method. The relay did not prove that one protocol suite had been translated into the other without loss. It exposed an application-specific handoff.

An acknowledgement could arrive from the wrong layer

The address problem was only the first missing meaning. Under NCP, a Ready for Next Message signal came from the destination IMP—or, when a translator intervened, from the IMP beside the translator. That signal did not necessarily describe the final foreign host's state.

The T/MG could delay the signal and hold data in buffers. But what event on the far protocol side should release it? If the foreign network acknowledged a local transmission, was that evidence of endpoint receipt, application consumption or merely another intermediate queue? A converter could manufacture a timing relationship; it could not manufacture an end-to-end fact that the other protocol never exposed.

This is why flow-control mismatch became more than a performance problem. Backpressure names the actor who must slow down and the evidence that permits it to resume. If the two suites stop senders at different boundaries, the gateway owns the mismatch. Buffers merely defer the decision and can make the intermediary the largest state holder in the path.

The urgent bit was not a universal emergency language

RFC 875 then used exceptional signalling. NCP had an interrupt command on a control link. TCP had an Urgent mechanism within the connection, and Telnet could carry an Interrupt Process command. Other protocol families offered expedited data. All appeared to mean “handle this quickly.” They did not necessarily command the same component.

TCP's specification helps locate the boundary. RFC 793 said the urgent mechanism should stimulate the receiving user to process urgent information and maintain the transition into and out of urgent mode. A mechanism that merely gives a protocol interpreter priority service is not equivalent to an instruction for the destination process to interrupt its work.

The translator therefore faced an unanswerable mapping when one side lacked the required action. Dropping the signal lost function. Treating expedited delivery as a process interrupt invented authority. Terminating the application and implementing a local policy admitted that the intermediary, not the original protocol, was making the choice.

Padlipsky reported a concrete illustration from University College London: a terminal gateway between ARPANET Telnet and the X.25/X.28/X.29 family could move data, but the memo said only the echoing option crossed. That observation should not be inflated into a complete audit of the system. Its value is narrower. Successful character transfer did not prove preservation of the option vocabulary surrounding the characters.

Redundancy exposed the state hidden inside the rectangle

Suppose the translator did manage every correspondence. It now held two connection identifiers, two sequence spaces, two flow-control states, address bindings, option state and application assumptions. A second translator installed beside it did not possess those facts automatically.

RFC 875 called the resulting intermediary a singularity point. A connection created through one T/MG became attached to that box. Alternate routing at the packet layer could route around a failed link, but it could not reconstruct the translator's private conversation. Redundancy required another protocol for state transfer, conflict handling and takeover. The box in the diagram had become a distributed system.

The same dependency appeared over time. A translator was pairwise: suite A to suite B. Adding suite C required more pairings. Changing either suite required every affected translator to be examined and perhaps rebuilt. The supposedly convenient boundary accumulated the release schedules and ambiguities of both sides.

A later router specification sharpened the distinction

RFC 1009 later defined an Internet gateway as an IP-level router. It still had to perform substantial adaptation. For each connected network it handled framing, MTU, local network address mapping, and local flow-control or error indications. It selected next hops, managed buffers and participated in routing.

But the object forwarded between those adaptations remained the IP datagram. The gateway did not promise to translate every application's address vocabulary, recreate a foreign endpoint's acknowledgement, or convert one process-control semantic into another. Thin did not mean trivial. It meant that the common contract had a boundary.

Later middleboxes repeated the questions, not the exact history

The recurrence of similar problems should not be read as a claim that RFC 875 predicted every future intermediary. The later documents concern different systems.

RFC 2775 observed that address translation breaks end-to-end address transparency and that applications carrying addresses in their payloads need application gateways or proxies. Each new address-dependent application can require new intermediary knowledge.

RFC 3234 catalogued middleboxes and treated their useful purposes seriously. It also recorded new failure modes: rerouting may encounter a box without the old state, crashed middleboxes affect sessions, and diagnosis spans multiple layers. Application gateways maintain state because they are participating in application semantics, not merely forwarding an opaque datagram.

RFC 4966 later moved NAT-PT to Historic status for specific technical and operational reasons. It documented embedded-address coupling, incompatible IPv4/IPv6 semantics, fragment-state problems, mapping lifetimes, DNS-ALG scaling and a single failure or attack nexus. Those findings do not condemn every translation mechanism. They show why “translate the packets” is never the complete specification.

The missing meaning had to become a visible decision

RFC 875's durable contribution is a test for diagrams. For each arrow crossing an intermediary, ask what claim entered, what claim left, which actor made the correspondence and what evidence survives failure.

If both networks share a minimal protocol, the gateway can remain narrow. It adapts local execution while preserving a common object. If the suites disagree, there are only explicit choices: reduce the service to the intersection, terminate and re-originate it, add new semantics to an endpoint, or accept that some function does not cross.

None is a magical translation. Each assigns authority and loss.

The bytes may arrive. The address may have been rewritten. The terminal may echo. Those are observable achievements. They do not prove that acknowledgement, urgency, application options or end-to-end continuity retained the same meaning. A gateway can carry what both sides have specified. It cannot invent a guarantee that one side never made.

Sources