Summary

  • RFC 814 described a chain of translations inside an Internet host: human-visible names mapped to addresses, addresses mapped to routes, and service names mapped to transport-specific port identifiers. Each reference answered a different question.
  • Growth made exhaustive tables untenable. Clark recommended distributed name service, use-sized caches and replaceable interfaces, while leaving initial gateway discovery to the local network rather than forcing one global mechanism.
  • Separation bounded authority. A name lookup did not prove a route, an address did not select a process, and a registered port did not authenticate traffic. Later DNS design preserved the rule by keeping network identifiers, addresses and routes out of required name syntax.

The wrong machine answered correctly

RFC 814 began from an implementation problem with a human consequence. A host had moved, the local copy of the NIC table had not, and a connection opened to whatever machine now occupied the old address. A person watching an interactive session might notice. Queued mail could proceed unattended and turn a stale binding into a misleading delivery event.

That example matters because every component could work as designed. The name parser accepted the string. The table returned a syntactically valid address. IP found a route. TCP reached a listener. The failure was in the relationship between these acts. Delivery to an address was not delivery to the named object once the mapping had changed.

David D. Clark’s July 1982 paper therefore treated TCP/IP references as a sequence. Character strings named networks, hosts and services. A host name resolved to a 32-bit Internet address. The address identified an attachment and location, then drove a route choice. A service name selected a port in a particular transport. Collapsing those layers made a green result at one stage speak for every other stage.

Growth broke the complete table

The Internet Clark described had no more than roughly 25 active networks and a few hundred hosts. Even then, he warned implementers to plan for a much larger system—on the order of 1,000 networks and perhaps 25,000 hosts in the working estimate.

A complete table in every machine failed for three reasons. It grew too large, changed too often and carried mostly entries that a given host would never use. The proposed replacement was distributed responsibility: networks or groups of networks would maintain their own names, name servers would answer lookups, and hosts would retain only recently used bindings.

The most durable advice was about software boundaries. Existing table access should sit behind a subroutine rather than be scattered throughout the code. A local lookup implementation could later be replaced by a remote name-service call without rewriting every application. The interface preserved the question while allowing the answer mechanism to change.

This was minimum initial specification in practical form. Keep the common call small; localize the changing machinery behind it. Running code could migrate from HOSTS.TXT to a distributed service without forcing applications to learn where the authoritative table lived.

A cache was evidence with an age

Distribution did not remove uncertainty. RFC 814 saw that caching might worsen the moved-host problem: a machine holding a previous answer did not automatically know that the address behind a name had changed. It discussed querying the foreign address for its associated name as a verification idea, while recognizing a live mapping problem rather than declaring the cache authoritative forever.

Later DNS made expiration explicit. RFC 1034 associated typed resource records with names, distributed responsibility across zones and let the data source control refresh trade-offs. Its primary goal was a consistent name space whose names did not have to contain network identifiers, addresses or routes. An address became data obtainable about a name, not mandatory material embedded in the name itself.

That architecture permits continuity, but does not guarantee it. A domain name can have aliases, expire, be delegated incorrectly or be controlled by someone other than the operator a reader expects. A DNS answer can be authentic or forged, fresh or stale, reachable or black-holed. Separation creates room to preserve a reference while coordinates change; it does not turn the reference into proof of identity or ownership.

The address still needed a route

After lookup, IP faced another translation. If the destination belonged to the directly connected network, the host could send to it. Otherwise it needed a gateway. Early implementations could imagine one static entry for each of 256 possible network numbers, but movement, failure and expanded addressing made that exhaustive model brittle too.

RFC 814 proposed a route cache for destinations actually in use. With no entry, a host could try an accessible gateway. If a better gateway existed, an ICMP Redirect could teach the host a better next hop and update the cache. The route table was therefore not a second name table. It held an operational choice whose lifetime depended on topology and active work.

Initial gateway discovery remained deliberately local. One attached network might support broadcast discovery, another might provide a special facility, and another might require an installer to enter a gateway. The internetwork architecture did not inflate one local method into a universal rule.

RFC 1122 later strengthened this division: routing complexity belonged chiefly in gateways, hosts should be insulated from routing evolution, and route caches could hold path properties such as maximum datagram size or measured delay. Those properties belonged to a path epoch, not to the destination’s human name.

A port was not part of the address

An IP address delivered a datagram to a host, not directly to the final agent. IP dispatched to a higher-level protocol; TCP or UDP then used a port identifier to select a process, listener or connection. RFC 814 observed that contemporary TCP and UDP placed their port fields alike, but refused to make that coincidence a universal IP function.

There were architectural reasons. Other protocols might want different identifier sizes. Well-known port assignments were protocol-specific. Most importantly, IP was meant to contain what gateways needed to understand. Putting application dispatch into IP would have suggested that every gateway needed port semantics.

The document considered a richer alternative: send a character-string service descriptor to a rendezvous server, which would choose a port for that instance. Such indirection suited connection setup. It burdened a one-datagram UDP exchange with a preliminary trip and a larger field. RFC 814 left dispatch strategy to the higher-level protocol rather than forcing all services through one mandatory broker.

IANA’s current registry preserves the vocabulary boundary. Service names and port numbers distinguish services within TCP, UDP and other transports. The registry also states what assignment cannot prove: it does not endorse an application, and traffic on a registered port need not be the assigned service or safe traffic.

The address was a compact delivery compromise

Clark contrasted datagrams with virtual circuits. A circuit-oriented system could send an elaborate address during setup and then carry a short identifier. An Internet datagram had to remain routable without prior setup, so its address had to fit in every packet. Thirty-two bits were a compromise between reach and header cost, already requiring what the paper called considerable shoehorning.

That observation does not turn RFC 814 into a prediction of CIDR, NAT, IPv6 or today’s address market. It establishes the design pressure: an address was compact delivery state. Requiring the human reference to inherit that state would bind identity to the limits and movement of the delivery field.

The separation was the result

For operations, the four records should remain distinct. Preserve the queried name and the source and age of its binding. Preserve every returned address. Record the selected route, interface, next hop and route epoch. Record the transport and ports. Finally, preserve authentication, authorization and application completion separately.

A failure can then be located. A name may resolve while no route exists. A route may work while the wrong service listens. The expected process may accept a connection while rejecting identity. An application may authenticate a caller and still fail the requested operation.

RFC 814’s historical value lies in refusing the convenient shortcut of calling all these states “the destination.” The name was not the address. The address was not the route. The route was not the process. The port was not proof of the service. Interoperability became more durable because each translation could change without claiming authority over the next.

Sources