[ih] Fwd: History from 1960s to 2025 (ARPANET to TCP)

[Jack Haverty]

Forwarding for Tony Li -- email to the list doesn't work for him. /Jack


-------- Forwarded Message --------
Subject: 	Re: [ih] History from 1960s to 2025 (ARPANET to TCP)
Date: 	Sat, 3 Jan 2026 12:58:06 -0800
From: 	Tony Li <tony.li at tony.li>
To: 	Jack Haverty <jack at 3kitty.org>
CC: 	Brian E Carpenter via Internet-history 
<internet-history at elists.isoc.org>



Hi Jack,


> In the new Internet architecture today, TCPV4 is still in use, even 
> though TCPV6 was "on the shelf" decades ago. Has the delay been a 
> result of the change in architecture? Are we missing the "process" for 
> evolution of the networking mechanisms? Is such a process even 
> possible given the size and breadth of the Internet?


The delay comes from a very simple reason: a lack of a compelling reason 
to change.
IPv6 is architecturally identical to IPv4, intentionally. However, this 
also means that IPv6 has no significant advantages over IPv4. Those that 
have been invented have been retrofitted to IPv4. We necessarily 
grandfathered all of the IPv4 Internet indefinitely into the future, so 
there is no compulsion to change and no desire to do so. Conversion is 
laborious process, with no significant upside.


> So, my basic question for History is "Why did the architecture 
> change?" Were the arguments for a separate network switch (e.g., an 
> IMP) no longer applicable? Did the technology explosion during the 70s 
> have some effect? What was the reasoning behind the decision to move 
> the "virtual circuit" mechanisms from the network (IMPs) to the hosts?


The architecture changed because it needed to. But because we are 
unwilling to consider architectural change now, we are stuck with where 
we have been since 1983. Moving connection management to the end host 
was an absolutely necessity for scalability and stability. That was the 
right call.

Moving forward, if we want to make architectural change and get it 
deployed, we have to find a way to motivate it so that it gets through 
the IETF process, through vendor implementation, and through end-user 
deployment. That implies that it has to solve a serious, real problem 
with the current architecture. So far, no problem has crossed the pain 
threshold to make that effort worthwhile.

Regards,
T

p.s. For some reason, my postings never seem to make it onto the list. 
Please feel free to forward if you like.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20260103/93bb2a56/attachment-0001.asc>