Summary

  • The original ARPANET did not begin with a doctrine that the network should do almost nothing. Its IMP subnet performed packetisation, checksumming, forwarding, reassembly, tracing and flow-control work. The important boundary was more concrete: BBN controlled the packet-switch implementation it had been contracted to deliver, while host groups still had to create the host software and conventions that made the machines communicate.
  • That division worked while NCP could rely on one ARPANET service model. It became a constraint when independently designed packet-radio, satellite and other networks had to interoperate. Open-architecture internetworking moved recoverability toward endpoints and simplified the common gateway function. The later end-to-end argument then supplied a sharper placement test: infrastructure may improve performance, but a function requiring application knowledge cannot be made completely correct there alone.

A September deadline before there was an Internet architecture

The first ARPANET Interface Message Processor was supposed to arrive at UCLA in September 1969. That deadline is a better place to begin this history than a diagram of clouds and protocol layers.

A delivery date turns architecture into a division of labor.

Someone had to procure hardware. Someone had to build the packet-switching machinery. Someone had to decide what the interface between the switch and a host meant. Someone had to make host computers—machines built for very different purposes, with different operating systems and local priorities—actually speak through that interface. And someone had to discover which assumptions failed only after the pieces were running.

ARPA’s decision to use a subnet of dedicated packet switches concentrated one difficult class of work in machines built specifically for communication. BBN won the 1968 contract and turned the Honeywell 516 into the machine that became the IMP. The contractor was not merely writing a paper specification. It was delivering executable infrastructure against a schedule.

That distinction matters because the resulting authority was unusually concrete. BBN could determine a great deal about the behavior of the IMP because BBN had to ship the IMP. Reliability engineering, debugging, reloading and the practical problem of keeping communication lines connected were not abstractions. Frank Heart’s retrospective description of the work emphasizes precisely those operational concerns. The subnet had to survive as a working system, not merely as an agreed concept.

Yet the host computers were not delivered as part of one vertically integrated product. The sites receiving IMPs had their own machines and their own host teams. As Steve Crocker later recalled, those teams had to build interfaces and software against BBN’s delivery schedule. The packet-switching subnet and the host environment therefore met at an engineered boundary.

That boundary is visible in the first RFC.

RFC 1 states that ARPA Network software existed partly in the IMPs and partly in the hosts. BBN specified the IMP software. The host groups were responsible for reaching agreement on the host software.

It is difficult to ask for a clearer early statement of divided responsibility.

But it would be a mistake to translate that sentence directly into the architecture of the later Internet. ARPANET had not already discovered the mature end-to-end principle. Its IMPs did substantial work that a reader raised on IP might instinctively expect to find elsewhere. Nor should the IMP be casually renamed a modern router. It was an ARPANET packet switch built before IP and embedded in a different service model.

The historical interest lies in the actual allocation of functions.

What had to be common? What could be supplied by the contractor? What still required cooperation by the host? What happened when the assumptions behind that allocation stopped fitting the environment?

Those questions are more important than deciding whether the IMP looks superficially “centralized” or “decentralized” from a distance. ARPANET’s first boundary was not a philosophical slogan. It was an operational bargain.

What BBN actually put inside the subnet

Calling an IMP an empty conduit badly understates the machine.

RFC 1 describes messages of as much as 8,080 bits. Those messages could be divided into packets no larger than 1,010 bits. The IMP machinery performed packet handling, forwarding and reassembly at the destination IMP. The design included a 24-bit cyclic checksum. It provided logical links, tracing support and the Request-for-Next-Message mechanism used to regulate the movement of traffic.

Those functions collectively reduced the amount of packet-network machinery every host group had to reinvent.

That was economically meaningful even before it was architecturally interesting.

If several expensive host systems were to communicate across one experimental network, each site could either absorb more of the communications problem locally or depend on a common communications substrate. Moving repeatable functions into the IMP subnet reduced duplicated engineering. A common mechanism could be tested once, improved once and deployed as part of the network service. The host groups could concentrate more of their effort on host interaction rather than reconstructing the packet fabric at every site.

The benefits of that arrangement were not merely developer convenience. Concentrating a function can produce scale economies in reliability work. The people responsible for the communications subnet can instrument it, debug recurring failure modes and improve behavior across every attached host.

That is one reason the IMP should not be retroactively treated as an architectural error that the Internet later corrected by removing infrastructure. The infrastructure was doing valuable work.

The more precise lesson is that infrastructure was good at functions for which it possessed the required information and control.

It could segment a message according to its own packet format because it knew that format. It could forward packets because it controlled the switching substrate. It could calculate a checksum over what it handled. It could reassemble material at the destination IMP because that operation fell within the IMP service. It could expose tracing mechanisms and constrain traffic using the mechanisms available to it.

The subnet had knowledge of the subnet.

That sounds obvious until a system asks it to guarantee something whose truth exists outside that knowledge.

The Host–IMP interface was an allocation of responsibility

RFC 7 makes the other side of the boundary visible. Host software had to deal with the Host–IMP interface, multiplexing and buffering. The host was not a passive appliance attached to a magical network.

RFC 2 likewise shows host software maintaining link state, performing checks and acknowledgements, and reacting to the status of remote hosts.

The boundary therefore did not divide “intelligent network” from “unintelligent computer.” It divided responsibilities according to what each component could actually observe and implement.

That is a much more useful historical distinction.

The host knew about local processes and local buffers. It knew what the host was trying to accomplish. It could maintain state whose meaning came from host interaction. It could interpret status in ways tied to the software running at the endpoint.

The IMP knew the packet-switching subnet. It could act on packet and link information available inside that system.

Neither side made the other unnecessary.

Indeed, one of the most revealing details in RFC 1 is a limit rather than a capability. The logical-link system could constrain some forms of congestion, but the destination IMP did not have unlimited capacity to deal with every possible link simultaneously. Hosts therefore had to cooperate.

That single limitation punctures the fantasy of an omniscient network.

A mechanism inside the infrastructure could change incentives and reduce a failure mode without eliminating the need for endpoint behavior. The network could impose useful discipline, but its discipline was bounded by its own buffers, interfaces and state.

This is a recurring pattern in systems engineering. A shared mechanism may substantially reduce the probability or cost of failure while still being unable to establish the final correctness condition.

Those are not equivalent claims.

The difference becomes crucial later.

Reliability was a distribution of work, not a location on a diagram

ARPANET’s design put substantial reliability work into the IMP subnet. The sources leave no basis for pretending otherwise.

The network checked, managed, forwarded and reassembled. Later documentation such as RFC 528 shows that checksumming inside IMP software remained part of the operational concern with network reliability.

At the same time, host protocols maintained their own state, checks and acknowledgements.

What matters is not whether one can color a box in a diagram and label it “reliability.” Reliability was decomposed.

Some failure modes were visible to the network. Some were visible to hosts. Some could be reduced by common machinery. Others required cooperation across the interface.

That distinction is also the beginning of an economic explanation for why architectural boundaries change.

If a common service can cheaply absorb a repeated task for every entity, there is a strong case for putting the task there. Duplication falls. Integration becomes easier. Operators gain one place to instrument a shared mechanism.

But concentration has a corresponding cost. The common service must make assumptions broad enough to remain valid for everyone who depends on it.

The more specific those assumptions become, the more expensive heterogeneity becomes.

ARPANET could live with a relatively rich common packet-switching service because NCP operated inside a particular network context. Once the problem changed from connecting heterogeneous hosts through ARPANET to connecting independently designed networks to one another, assumptions that had once been efficient became constraints.

The shift to internetworking was therefore not a morality play in which “smart edges” defeated a “bad network.” It was a change in the scale at which common assumptions had to hold.

Four kinds of authority that history too easily collapses

The IMP story becomes distorted when four different forms of authority are treated as one.

The first was procurement power.

ARPA could commission a network and select a contractor. Procurement determines who gets resources, what must be delivered and under what programmatic framework. Without it, the IMP subnet would not have appeared merely because packet switching was an attractive idea.

The second was implementation authority.

BBN had to make the IMP work. A contractor responsible for deployed software necessarily makes decisions that a paper architecture leaves unresolved. Hardware constraints, recovery behavior, diagnostics and operating practices become executable choices.

The third was interface authority.

A system cannot interoperate unless the boundary between components has meaning. BBN’s IMP implementation and the Host–IMP interface created facts that host teams had to respect if they wanted to connect successfully.

The fourth was architectural mandate.

That is the broadest claim: the proposition that because an actor controlled one delivered component, it therefore possessed an enduring right to determine other components, applications or future networks.

The cited historical record supports the first three in concrete forms. It does not support the fourth.

That boundary should not be confused with a claim that contracts were unimportant. The opposite is closer to the evidence. Contract, hardware, delivery schedule and operating service were precisely what converted an idea into infrastructure.

Deployed implementation mattered because it constrained everybody who wanted the system to operate.

But constraints created by a shipped interface are not automatically constitutional powers.

A useful way to read the period is that authority tracked implementation. BBN had strong authority over the machine it was responsible for building and operating because somebody had to make that machine deterministic enough to work. Host groups retained decisions that required host knowledge because those decisions could not simply be wished into the IMP.

That is an institutional inference from the functional evidence, not a declaration found in a surviving 1969 constitution. The early RFCs were working notes. The contract record available here is incomplete. Oral histories illuminate implementation priorities but do not reconstruct every instruction or dispute.

Still, the allocation of work is visible enough to reject a common historical shortcut: operational control over an intermediary does not, by itself, prove a permanent mandate over everything connected through it.

The success condition hidden inside NCP

A design can be excellent under the assumptions for which it was built and become limiting when those assumptions stop being true.

That is what happened to the NCP model.

Later Internet Society architectural histories explain that NCP relied on ARPANET itself to provide end-to-end reliability. NCP could identify a destination within the logic of the ARPANET service but had no way to address a network beyond a destination IMP.

As long as the problem was communication over ARPANET, that could be a coherent bargain. The host protocol could rely on characteristics supplied by one packet-switching environment.

The pressure changed when packet radio, satellite systems and other independently designed packet networks entered the picture.

Now the unit of heterogeneity was no longer merely the host.

The networks themselves were different.

That creates a deeper coordination problem. If internetworking requires every constituent network to implement the same internal reliability machinery, packet conventions, operational assumptions or connection semantics, then joining the system demands redesigning the networks that are supposed to remain independent.

The common layer becomes a demand for internal uniformity.

That was precisely what open-architecture internetworking had to avoid.

Independent networks needed to stand on their own. They could not all be rewritten into one enlarged ARPANET. The internetworking layer had to tolerate the fact that the component networks had been built differently.

The boundary of common correctness therefore had to move.

Open architecture changed the entity that had to remain common

The later open-architecture design accepted independent networks as a premise rather than an inconvenience to be engineered away.

The historical ground rules summarized by the Internet Society included networks remaining independently designed, a best-effort approach to communication, retransmission from the source when necessary and simple gateway devices connecting networks without retaining per-flow state as though the collection were one large connection-oriented substrate.

The common machinery did not disappear.

It changed jobs.

A gateway still had to forward traffic. Routing still mattered. Measurement still mattered. Operators still had state. Shared infrastructure still had to function.

What narrowed was the amount of end-to-end service semantics that every intervening system had to guarantee.

That is a profound difference.

Under the earlier NCP assumption, the host could lean on one underlying network’s reliable service. Under internetworking, no single constituent network could be assumed to possess enough control over all the others to supply such a guarantee.

If recovery depends on what happens across several independently operated networks, placing definitive recoverability inside one of those networks is structurally incomplete. The source has to retain the ability to retransmit because only the endpoints span the entire communication path in the relevant sense.

This is why “move reliability to the edge” is simultaneously useful and too crude.

The design did not move every reliability mechanism out of networks. Networks could still detect errors, manage their own resources and improve local performance.

What moved was ultimate responsibility for recovering communication across the internetwork.

The distinction is between local improvement and complete correctness.

The early Internet Transmission Control Program documented in RFC 675 belongs to this later phase. It must not be projected backward into the 1969 IMP design. The historical sequence matters because the architectural conclusion came from confronting a new problem: how to connect networks without requiring one network’s internal service model to become the constitution of all the others.

A gateway that remembers less can permit networks to remain different

The black-box gateway rule is easy to misunderstand as an aesthetic preference for simplicity.

Its economic importance is stronger.

Shared state creates dependencies.

If an intermediary holds detailed state for each communication relationship, endpoints and neighboring networks become dependent on the continuity, semantics and recovery behavior of that intermediary. Replacing it is harder because replacement must reproduce not only the wire interface but also the accumulated state and assumptions bound to it.

Per-flow state can therefore increase switching costs.

That does not make such state universally wrong. There are systems in which a stateful service has real value. The historical question is narrower: what state should every entity be forced to trust in the common path if independently designed networks are to interoperate?

The more that can remain local, the fewer assumptions have to be synchronized globally.

A simpler gateway boundary reduces the amount of agreement required before two different networks can join the same internetwork.

That is an interoperability dividend.

It also changes the institutional shape of the system. When correctness depends on narrow, reproducible forwarding behavior rather than on a rich shared intermediary, an implementation can in principle be replaced without reproducing an ever-expanding body of application-specific decisions.

Interface sufficiency matters more than institutional identity.

This is where the IMP history and the later Internet architecture connect without being the same thing.

The IMP demonstrated the enormous value of a dedicated communications substrate. Open architecture demonstrated the danger of requiring one such substrate’s service assumptions to encompass independently designed networks.

The lesson was not “abolish the box.”

It was “make sure the box is responsible only for claims it can actually make true.”

The end-to-end argument supplied the missing placement test

Saltzer, Reed and Clark later gave this problem a more general formulation.

If a function requires knowledge available only at the application endpoints, the function can be implemented completely and correctly only with participation from those endpoints.

A lower layer may still perform part of the function.

It may do so very profitably.

It may reduce errors, reduce latency, avoid needless retransmission or protect scarce resources. It may be so useful that removing it would be foolish.

But its usefulness does not convert it into a complete correctness mechanism if the final condition depends on information the lower layer does not possess.

That is the end-to-end argument at its most useful: a placement test.

It is not a ban on infrastructure functions.

This distinction prevents two opposite mistakes.

The first mistake is maximalism in the network: because an intermediary can improve a function, the intermediary should own the function’s authoritative state.

The second is an equally simplistic minimalism: because endpoints must ultimately verify a property, lower layers should never help.

The historical record supports neither extreme.

ARPANET’s IMPs prove that shared infrastructure can remove duplicated work and improve communication materially. The later Internet architecture proves that common infrastructure must be careful not to claim correctness whose decisive knowledge lies elsewhere.

RFC 3439’s later discussion of simplicity and the Internet’s minimalist IP layer belongs to this same architectural family. It does not describe a core without state, routing or operations. Rather, it warns about unnecessary complexity while recognizing that coarse-grained routing state remains part of the core.

A thin common layer is not an empty common layer.

The discipline is to identify which facts must be globally or commonly understood and which facts can remain outside the substrate.

Correctness moved because the scale of failure moved

The change from ARPANET to internetworking can be understood as a change in the failure domain.

Within one packet-switching network, a network operator can see and manage a large fraction of the mechanism relevant to delivery.

Across several autonomous networks, no single network possesses comparable control.

The larger the failure domain, the less credible it becomes for one intermediate component to promise final correctness on behalf of the entire path.

Endpoints are special not because they are philosophically pure, but because they terminate the operation whose success matters.

That functional observation also explains why recoverability is so central.

Suppose an intermediary improves delivery but can itself fail. If the endpoint still possesses enough information to detect failure and retry through the same or another path, the intermediary is helpful but not sovereign.

If instead the intermediary holds irreplaceable state required to decide whether the communication is valid, who the entity is, whether the operation is authorized or what the application is permitted to do, its failure changes character.

The intermediary is no longer merely an optimization point.

It has become part of the application’s authoritative state machine.

That increases both technical and institutional concentration.

The boundary is also a theory of replacement

A useful infrastructure boundary can be tested by asking what replacement requires.

BBN’s historical role was substantial precisely because its implementation was real. An IMP was not replaceable by a sentence in a standards document. The machine, its software, its interfaces and its operating behavior had to exist.

But the long-run architecture of an open internetwork benefits when the identity of the intermediary matters less than conformity to the required interface.

That shifts value from incumbent control toward reproducible function.

In economic terms, a sufficiently specified interface lowers entry costs for alternative implementations. It allows the market or operating community to distinguish a required function from the organization presently supplying it.

That does not mean replacement is costless.

Operational experience, debugging knowledge, deployed hardware and accumulated trust all create practical advantages for incumbents. Deployed systems have path dependence.

The relevant question is whether those advantages remain practical advantages or are transformed into architectural necessity.

Once a shared intermediary accumulates state that only the incumbent can interpret, migrate or authorize, switching costs rise sharply. The provider’s operational concentration can become institutional power even if no founding document granted such power.

This is one reason the distinction among procurement, implementation, interface and mandate matters so much.

Procurement can legitimately choose a supplier.

Implementation can legitimately require concrete decisions.

An interface can legitimately constrain entities who choose to interoperate.

None of those facts alone proves that the supplier should permanently control future choices outside that interface.

Deployed implementation made the early boundary real

One useful interpretive discipline in this history is to take running implementation seriously without turning implementation success into unlimited authority.

The early ARPANET boundary was not established merely by a committee announcing where functions should live. It became real because an IMP arrived, host teams connected to it and software had to behave in ways compatible with the actual interface.

That gives implementation a kind of primacy.

A function that nobody implements does not carry packets.

A specification that does not match deployed behavior does not rescue interoperability.

A beautiful allocation of responsibilities that cannot survive real buffers, line failures and recovery conditions is not an architecture in the operational sense.

The same discipline, however, limits the authority one should infer from success.

A working implementation proves that a particular set of functions can operate. It does not prove that every adjacent decision should be absorbed by the same actor or layer.

The IMP’s reality came from performing its job.

The host teams’ responsibilities remained real because there were decisions and states the IMP could not settle for them.

Later Internet architecture generalized the same limiting intuition across networks: specify enough common behavior for interoperability, but do not make the common layer responsible for every future choice merely because common infrastructure already exists.

Voluntary adoption is different from architectural command

The history also illuminates the difference between a design becoming common through deployment and becoming common through declaration.

ARPANET host groups had no practical option to pretend BBN’s delivered Host–IMP interface did not exist if they wanted their machines to communicate through that IMP. The deployed implementation created a compatibility fact.

That kind of constraint is fundamentally different from claiming that the operator of the intermediary may define any future rule and treat publication alone as universal obligation.

Open architecture benefits when later variation can remain local unless a shared invariant genuinely requires common treatment.

This does not eliminate standards, documentation or coordination. It changes the burden of proof.

A rule belongs in the minimum common substrate when incompatible local choices would destroy the interoperability property the substrate exists to provide.

A rule does not belong there merely because making it common would be administratively convenient.

That distinction is easy to state and hard to preserve.

Shared layers attract functions. Once every entity already depends on an intermediary, adding one more check, policy flag, identity attribute or decision point can look cheaper than building a separate mechanism.

Locally, the decision may be rational.

Systemically, repeated additions change the nature of the dependency.

The modern temptation is to put application state back in the path

The IMP history matters now because infrastructure products repeatedly face the same architectural temptation.

A shared intermediary sees traffic and is already operationally important. Engineers discover that the intermediary can also maintain identity information, security state, application policy, entitlement state or other application-specific facts.

Doing so may produce immediate benefits.

Common enforcement can reduce duplicated logic. Central observation can improve diagnosis. Shared policy can make behavior more consistent. An intermediary may stop failures earlier than an application can.

None of those advantages should be dismissed.

The placement test is different: does the intermediary possess enough information to make the final correctness claim?

If it does not, then the intermediary’s action is either an optimization, a partial defense or a local policy decision. Endpoints still need an independent way to know whether the application-level operation is correct.

The dangerous transition occurs when the system stops treating the intermediary as an aid and starts making its state authoritative.

At that moment, replacing the intermediary may require transferring application state, identity state and policy semantics rather than merely reproducing forwarding behavior.

Operational concentration turns into architectural lock-in.

Architectural lock-in can then become institutional mandate.

Nothing in the IMP history proves that every modern intermediary is illegitimate. That would be precisely the kind of overreach the history warns against.

The lesson is narrower and more useful: authority should track the function that an intermediary can actually implement and verify.

A reliability improvement is not necessarily a correctness proof

Leaders evaluating infrastructure commonly hear claims framed as reliability.

The architectural question is: reliability of what?

A mechanism may improve the probability that packets arrive.

Another may make a local link more robust.

Another may detect corrupted data.

Another may reduce congestion.

Another may provide an operational signal.

Each can be valuable.

Yet if the application’s success condition requires knowledge unavailable at that layer, none independently proves that the application operation completed correctly.

The distinction matters commercially because buyers often pay for a local reliability improvement as though they had purchased elimination of the end-to-end failure mode.

That can produce hidden residual risk.

A strong design makes the residual responsibility explicit.

The network may say, in effect: “I will provide this forwarding property, perform this check and expose this failure signal.”

The endpoint may then say: “Given those properties, I will determine whether the operation actually succeeded.”

That division is intellectually less satisfying than claiming one perfect layer, but operationally it is more honest.

ARPANET’s early RFCs already show such imperfection. Network mechanisms existed, and hosts still had to cooperate.

The later end-to-end argument did not invent the fact that layers have incomplete knowledge. It supplied a disciplined way to decide what that fact means for function placement.

Thinness should be measured by dependency, not feature count

“Thin core” is easily reduced to a count of features.

That is a poor measure.

A network layer can perform many mechanical operations without becoming an application authority if those operations are reproducible, bounded and independent of application-specific truth.

Conversely, a seemingly small feature can create enormous architectural dependency if it becomes the sole authority for identity, entitlement or application validity.

The relevant question is therefore not how many lines of code exist in the intermediary.

It is how much irreplaceable meaning lives there.

Routing state does not by itself make a network layer improperly “thick.” Forwarding requires routing.

Measurement does not automatically violate end-to-end design. Operators need observability.

Error detection can be valuable even if endpoints must still verify final correctness.

The concentration risk rises when the shared layer becomes the only place capable of deciding facts that entities cannot independently validate.

The IMP story helps because its boundary was concrete. BBN built a packet switch. Host teams built host software. Neither label concealed the fact that both sides had substantial responsibilities.

A modern architecture should demand the same clarity.

The deepest lesson is about bounded competence

ARPANET’s IMP subnet was powerful because it concentrated competence around a defined communications problem.

That concentration produced a working network.

The later Internet succeeded by refusing to assume that the same competence could be extended unchanged across every independently designed network.

That refusal is more subtle than hostility to centralization.

It recognizes that the value of a common layer comes from what the layer can do for everyone without needing to know everything about everyone.

The more application-specific knowledge a function requires, the more carefully one should ask whether it belongs in the shared path.

The more independently designed systems the architecture wants to accommodate, the more expensive universal internal assumptions become.

The more irreplaceable state an intermediary accumulates, the greater the switching cost when its behavior, owner or policy changes.

And the more operational concentration is treated as proof of legitimate mandate, the easier it becomes for an implementation boundary to harden into an institutional choke point.

None of that makes infrastructure unnecessary.

ARPANET’s history shows the opposite. Infrastructure made the network possible.

But the Internet’s later architecture learned something equally important: the shared substrate should not claim a scope of correctness larger than the information available to it.

The endpoint is not sacred.

The intermediary is not suspect by definition.

The placement question is functional.

Where does the information needed for complete correctness exist? Which lower-layer mechanisms can improve performance without becoming indispensable authorities? Which state must be common for interoperability? Which choices can remain local? Can an intermediary be replaced by another implementation of a sufficient interface, or has accumulated state turned the supplier itself into part of the protocol?

Those questions are the durable inheritance of the IMP boundary.

The first box did not contain the Internet.

It helped reveal where the network had to stop.

Sources and evidence limits

The evidence base combines contemporary or near-contemporary RFC material, later retrospective histories and oral histories. Those categories should not be treated as interchangeable. The earliest RFCs were working documents rather than a complete constitutional account of ARPANET. Surviving records do not reconstruct every instruction in the ARPA–BBN relationship, every implementation choice or every disagreement among entities. Later Internet and end-to-end literature is useful for explaining why the earlier model became limiting, but it should not be projected backward as a doctrine consciously held by all entities in 1969.

The institutional conclusion in this article is therefore bounded. The evidence directly supports BBN’s contractual and executable responsibility for the IMP, the separate host responsibilities described in early RFCs, the rich functions performed by the IMP subnet, NCP’s reliance on one reliable ARPANET service model, and the later relocation of recoverability in open-architecture internetworking.

The claim that architectural authority should remain bounded to the function and interface actually delivered is an editorial inference from those facts, not a quotation from a historical governing instrument. Keeping those two levels separate prevents later interpretation from masquerading as contemporary evidence.

  1. https://www.rfc-editor.org/rfc/rfc1.html Used for the explicit division between BBN-specified IMP software and host-group responsibility; IMP message and packet sizes; checksum, tracing, logical-link and RFNM mechanisms; and the need for host cooperation under resource constraints.

  2. https://www.rfc-editor.org/rfc/rfc2.html Used for host-side maintenance of link state, checks, acknowledgements and remote-network or remote-host status handling.

  3. https://www.rfc-editor.org/rfc/rfc7.html Used for Host–IMP interface processing and host-side multiplexing and buffering responsibilities.

  4. https://www.rfc-editor.org/rfc/rfc528.html Used for the continuing operational concern with IMP-software checksumming and network reliability.

  5. https://www.rfc-editor.org/rfc/rfc1000.html Used for Steve Crocker’s retrospective account of host-team work, the Host–IMP interface and the September 1969 IMP delivery schedule.

  6. https://archive.computerhistory.org/resources/access/text/2012/11/102706168-05-01-acc.pdf Used for BBN’s 1968 ARPANET contract and the transformation of the Honeywell 516 into the IMP.

  7. https://archive.computerhistory.org/resources/access/text/2017/11/102702222-05-01-acc.pdf Used for Frank Heart’s retrospective emphasis on reliability, debugging, reloading, line cross-patching and the operational legacy of the IMP work.

  8. https://www.internetsociety.org/internet/history-internet/brief-history-internet/ Used for NCP’s reliance on ARPANET reliability and for the open-architecture principles of independent networks, source retransmission and comparatively simple gateway behavior.

  9. https://www.internetsociety.org/internet/history-internet/brief-history-internet-related-networks/ Used for the historical transition from ARPANET toward interconnection among independently designed packet networks.

  10. https://datatracker.ietf.org/doc/html/rfc675 Used for the December 1974 Internet Transmission Control Program and as evidence of the later internetworking phase, not as evidence of the original 1969 IMP service.

  11. https://groups.csail.mit.edu/ana/People/DDC/ebook-arch-V1.pdf Used for retrospective analysis of the DARPA Internet design, datagram service and survivability priorities.

  12. https://groups.csail.mit.edu/ana/Publications/PubPDFs/End-to-End%20Arguments%20in%20System%20Design.pdf Used for the endpoint-knowledge placement test and the distinction between a complete correctness mechanism and a lower-layer mechanism that remains valuable as a performance enhancement.

  13. https://www.rfc-editor.org/rfc/rfc3439.html Used for later analysis linking end-to-end reasoning with a minimalist IP layer, simplicity and the continuing need for coarse-grained routing state in the core.

This source set does not establish that BBN alone invented packet switching, and no such claim is made here. Davies, Baran, Kleinrock, Roberts, ARPA site teams and other contributors belong to the wider history. Nor does the evidence justify calling the IMP a modern IP router, treating ARPANET as an early implementation of the mature end-to-end doctrine, or equating a thin shared layer with an unmanaged or stateless one.