Summary

  • RFC 675 said independently chosen port identifiers might collide; adding the address that identified a TCP gave the socket a scope across connected networks.
  • A connection was the pair of endpoint sockets, so one local socket could participate in many distinct connections.
  • Later specifications placed host addressing and protocol dispatch in IP while TCP kept process ports. The documents show a change in specification language, not when every implementation adopted it.

A number could be local and still be useful

A port number did not need to be unique everywhere to be useful. It needed to distinguish processes inside the system that interpreted it. RFC 675, published in December 1974, made that boundary explicit: operating systems, TCPs, and users chose port identifiers independently, so two choices could coincide. The problem was not that the number was badly selected. The number was being asked to identify something outside its own scope.

Imagine two separate TCPs that each use the same port value. The number alone cannot tell a receiver which TCP, or which connected network, is meant. RFC 675 therefore combined the Internet address identifying a TCP with the port identifier. The resulting socket name was meant to be unique throughout the networks connected together. That is the specification’s answer to a naming collision: add the missing scope to the name rather than pretend that every local port is globally unique. RFC 675, §2.7

A connection had two endpoint names

The next step is easy to miss if “socket” is treated as a synonym for “connection.” RFC 675 specified a connection by the pair of sockets at its ends. A local socket could take part in many connections to different foreign sockets, and the connection could carry data in both directions. One endpoint name therefore did not have to be consumed by one permanent conversation. The remote endpoint completed the description.

This pair matters more than any one port number. If a service listens at a local endpoint, different peers can contact it from different foreign endpoints. The connection names remain distinguishable because the pair changes, even when the local socket is reused. The RFC describes this as a protocol interface; it does not say that a socket authenticates a user, proves ownership of a machine, or remains assigned forever.

The specification also leaves a practical boundary visible. It defines how the endpoint is named, while a host handles the binding of ports to processes. Naming a process endpoint across networks and deciding which local process receives traffic are related tasks, but they are not the same decision.

The address took its place in the Internet layer

The 1980 TCP specification described ports within each host and combined them with network and host addresses from the Internet layer to form a socket. It again used a pair of sockets to identify a connection and said that one socket could be used in several connections. It also described port-to-process binding as a matter handled independently by each host. RFC 761, §§1.4, 2.7

The accompanying Internet Protocol specification put host addressing and protocol selection in the IP header. Its addresses identified source and destination hosts, while a protocol field indicated the next-level protocol. The 1981 IP specification retained that separate protocol field; the 1981 TCP specification described a TCP socket as an Internet Address joined to a TCP port. Read together, the texts locate network reachability and next-protocol dispatch in IP, and process selection in the transport layer. RFC 760, §§1.1, 3.1 · RFC 791, §3.1 · RFC 793, §3.1 and Glossary

UDP makes the separation concrete in another transport. Its specification defines source and destination port fields, while its IP interface obtains Internet addresses and the protocol field from the Internet header. A port is therefore meaningful within an address and transport context; it is not a universal number that names an application across every network and protocol. RFC 768, “Fields” and “IP Interface”

The name was a boundary between layers

RFC 675’s socket solved a coordination problem without asking for one global port allocator. It made a locally useful number legible beyond its original TCP by adding the address scope needed to distinguish endpoints. Later specifications made the division of work more explicit: IP identified hosts and the next protocol, transport ports selected processes, and a pair of endpoint names described a connection.

That is a history of specification boundaries, not proof of a clean migration date or universal implementation. The RFCs say where fields belonged and what a connection name contained. They do not establish which network deployed each version or how a particular operating system represented it internally. Their durable lesson is narrower: a port can identify a local service only in context, while the connection’s scope comes from both ends and their network-layer addresses.

Sources and limits

The primary records are RFC 675, RFC 760, RFC 761, RFC 768, RFC 791, and RFC 793. They establish specification text and its terminology; they do not establish adoption, a deployment chronology, authentication, durable machine identity, or present-day operational behavior.