7 ms·

TCP/IP is so entrenched in everything, literally, it will still be in use when we leave this planet and it gets swallowed up by the sun. The news will report th

TCP/IP is so entrenched in everything, literally, it will still be in use when we leave this planet and it gets swallowed up by the sun. The news will report the destruction of Earth and explain that it and its inhabitants longest lasting legacy is TCP/IP, then report that the transition to IPv6 is going well and everyone will be on it soon...

vmfunction 3y ago
The fact that it takes so long to transition to IPv6 and like many other obstruction to technological/social progress are economic and business gain for a certain small group of people and organisations.
- nine_k 3y ago
  It's just plain cost. Reworking things takes engineering time, an engineers need to be paid. If I were to list impediments to the technical development of the Internet, local telco monopolies would be much higher in the list, but it's another kettle of fish.
- samwillis 3y ago
  I propose the Willis law (are you allowed to name a law after yourself?): The spread and reach of TCP/IP will accelerate at a pace faster than that of the transition to IPv6 indefinitely, therefore we are saddled with IPv4 until the end of time.
  - klabb3 3y ago
    In fact, we know that IPv4 lives in the observable universe. You can travel at the speed of light towards IPv6, but the expansion rate of space time-itself (you can think of space-time as a series of tubes) is not limited by the speed of light. Thus, IPv6 is only theorized to exist, in order to explain other physical phenomena. Worse, even if it was proven to exist by a distant observer, there no way for them to relay that information back to us because our routers here at earth would drop the packets.
- TheLoafOfBread 3y ago
  People wanted to change bitfield with version from 4 to 6 and increase amount of bytes in IP address filed. Simple KISS. Instead of that we got fragile, backward incompatible, unnecessarily complex, jack of all trades protocol. And people are surprised that even after decades since the release of IPv6, it is being avoided like a plague.
  - p1mrx 3y ago
    Consider that NAT64 is able to translate between IPv4 and IPv6 at the packet level. If the protocols were as different as you suggest, this wouldn't be possible.
    - michaelt 3y ago
      Doesn't IPv6 remove broadcast, thus removing DHCP and ARP? I mean, hosts need to be 'dual stack' to support IPv4 and IPv6 together - whereas TheLoafOfBread's proposal would allow support of both with one backward-compatible stack.
      - p1mrx 3y ago
        DHCP and ARP use 32-bit addresses, so those protocols had to change regardless. I would challenge you to find someone who knows the difference between Ethernet broadcast and multicast without looking up the answer. They are very similar mechanisms.
      - yencabulator 3y ago
        NAT64 is never in a position to need to translate DHCP & ARP, those live fully on one side of NAT64 ("4" side for DHCP & ARP, "6" side for SLAAC/DHCPv6 & NDP). NAT64 is involved on the level of TCP & UDP, not lower level protocols.
  - doublepg23 3y ago
    This comes up often. What do you think would happen if you sent a “IPv4+” packet? All the ossified equipment would drop it. So you have to replace all this equipment, ideally _once_ so we ought to make it count.
- zekica 3y ago
  The main issue with IPv6 adoption is people who didn't learn IPv4 before NAT, and want to use the hammer (IPv4 NAT) for everything.
  - pif 3y ago
    A hammer working fine today, that you own, is better than a machine tool tomorrow, that you'll have to pay.
    - fknorangesite 3y ago
      I wish we had an idiom for this. Maybe something bird-related.
  - talideon 3y ago
    Also, developers who don't know how to get their daemons to listen on multiple interfaces at once.
    - cesarb 3y ago
      That's not necessary; listening on the wildcard IPv6 address without the "IPv6 only" flag enabled on the socket is enough. A IPv4 connection arriving at it is mapped to a special IPv6 address, so the code doesn't have to care about IPv4. Unless you were using Windows, where IIRC the IPv4 and IPv6 stacks were separate, and a single socket couldn't be used to listen to both at the same time. (This might already have been fixed in more recent Windows releases.)
- PeterisP 3y ago
  I'd say that it's not that there's some gain causing people/organizations to be obstructive, but rather that IPv4 and its address shortage simply isn't a problem for the influential people and organizations, they're doing just fine and for them there is nothing that needs to be fixed; IPv6 is needed by "someone else" who can be safely ignored with no noticeable effect to the bottom line.
- pif 3y ago
  IPv6 lacks back compatibility with the current standard. It cannot succeed.
  - bauruine 3y ago
    It doesn't there are millions of IPv6 only devices that can connect to IPv4 only sites. See US mobile carriers.
greyface- 3y ago
TCP becomes unusable under interplanetary latencies; leaving the planet will force us to transition off of it.
- pif 3y ago
  More likely, we will end up with 15 competing standard. https://xkcd.com/927/ https://xkcd.com/927/
- talideon 3y ago
  Nah. The main impetus to achieve FTL communication will be because it'll be easier than shifting people off of TCP.
  - deleted 3y ago
    [deleted]
  - aardvark179 3y ago
    It’s all fun and games until you get an ACK before you sent the SYN.
    - pif 3y ago
      That's a solved problem, just ask the thiotimoline research group. https://en.wikipedia.org/wiki/Thiotimoline https://en.wikipedia.org/wiki/Thiotimoline
    - dredmorbius 3y ago
      Tardis Control Protocol.
- KptMarchewa 3y ago
  I don't think volume of data average user will want to send to Mars over next 100 years will be a important factor enough. I envision Mars comms using some kind of relay service, to which you'd communicate using TCP
  - 3y ago
PinguTS 3y ago
Actually, even TCP is going to be replaced. I just want to remind the initial work of Google on QUIC, which now has become some standard. It is based on UDP and re-defining TCP features based on UDP together with cryptography and by allowing IP changes to allow moving clients.
- speed_spread 3y ago
  TCP is fine and isn't going anywhere. QUIC is an overengineered contraption that only exists to serve more ads. SSH doesn't need it. Postgres doesn't need it. Nobody needs QUIC except Google.
  - neysofu 3y ago
    QUIC is not without defects, I'm with you there, but almost almost any "web-scale" company dealing with a lot of cellular connections would disagree with your statement. Uber, Verizon, Cloudflare, Meta, Fastly, among others, some of which have reported very significant latency reductions.
  - yencabulator 3y ago
    > SSH doesn't need it. SSH's "master" mode connection sharing would benefit from QUIC / HTTP/3 head of line blocking elimination just as much as browsers would. Run a heavy rsync using connection sharing with an interactive session and you'll notice the interactive sessions latency suffering noticably. Long-lived SSH connections would benefit from QUIC / HTTP/3 session survivability.
- londons_explore 3y ago
  And yet, even with QUIC and a brand new Google phone on a Google wifi network and a Google Fi cell connection, I still can't walk away from my house and have a video call migrate from wifi to 5G without the audio glitching and dropping frames. All the mobility benefits of QUIC mean nothing when the rest of the software stack isn't designed to let it work.
  - 867-5309 3y ago
ajsnigrutin 3y ago
So.... which will come first, "the year of IPv6" or "the year of linux desktop"? :)
- deleted 3y ago
  [deleted]
- api 3y ago
  IPv6 is waiting on stubborn cloud networks and CDNs. Most of the edge now has it. My guess is that it’s mostly reluctance to introduce complexity when most customers are not asking for it. The biggest holdouts seem to be connected to Microsoft, with GitHub being one of the most relevant. The Linux desktop will arrive if we just wait for Microsoft to keep making Windows worse. Linux doesn’t have to get better. MS just needs to incorporate more ads.
  - jasode 3y ago
    >IPv6 is waiting on stubborn cloud networks and CDNs. Most of the edge now has it. Depends on the ISP. E.g. a lot of Verizon/Frontier FiOS residential customers don't have IPv6. Google statistics say USA is ~47% IPv6. Frontier FiOS is less % than that. Example recent thread: https://old.reddit.com/r/frontierfios/comments/v9azjj/june_2022_will_frontier_fios_ever_offer_ipv6/ https://old.reddit.com/r/frontierfios/comments/v9azjj/june_2... Google's statistics: https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
- leansensei 3y ago
  I know you are joking but I don't get the longevity of this joke. I've been running Debian with XFCE for more than 12 years, on PCs custom-built and branded, and on laptops both of enterprise quality and retail junk. Heck, our entire B2B commerce business runs the same setup, with far fewer (read: zero) issues compared to when we were using Windows 98, 98SE, XP SP3, 7, Vista, and 10, at which point we declined Microsoft's telemetry and ads and forced OneDrive shenanigans and promptly switched everyone to Debian+XFCE. 99.9% of the time, modern Linux works out of the box everytime. So I'd say it's on par with Windows versions, except I practically never need to download install drivers, or to face ads. Maybe I'm on a different planet on which the year of the Linux desktop has arrived for longer than a decade.
MisterTea 3y ago
I think the real issue is the operating systems did not properly abstract away the APIs, protocols and networks. On plan 9 the dial string is my favorite part of networking because you optionally specify the network in addition to the address and port in the form of a string: net!address!service. To dial an ssh server on port 1234 you run "ssh user@tcp!server.net!1234". The network database (ndb) can then be setup to alias names with protocols or ports so you can omit parts of the dial string for known services e.g. ssh defaults to tcp and port 22. The dial string neatly wraps up the entire network connection into a single string alleviating the program from having to offer command line arguments for port numbers which leaks protocol details into the code making things ugly and difficult to change. This lets your server take a dial string and listen on any network - even if that network isn't IP! So say you wanted to bring IPX/SPX back from the dead and use it in any program: so you write an IPX/SPX stack that binds over /net, then tell your server to listen on spx!*!555. Now your client also runs an IPX/SPX stack bound over /net and you hand the client program the dial string spx!server!555 and your program starts communicating over IPX/SPX to the server. Done. Want to use connect to an ssh server using quic on plan 9 (Assuming an imaginary quic stack)? just change the dial string to quic!host!port. Done. Once you use an OS with clean and simple abstractions you are left craving more of it. I wish more people took an interest in building much more radical operating systems.

vmfunction 3y ago

The fact that it takes so long to transition to IPv6 and like many other obstruction to technological/social progress are economic and business gain for a certain small group of people and organisations.

nine_k 3y ago
It's just plain cost. Reworking things takes engineering time, an engineers need to be paid. If I were to list impediments to the technical development of the Internet, local telco monopolies would be much higher in the list, but it's another kettle of fish.
samwillis 3y ago
I propose the Willis law (are you allowed to name a law after yourself?): The spread and reach of TCP/IP will accelerate at a pace faster than that of the transition to IPv6 indefinitely, therefore we are saddled with IPv4 until the end of time.
- klabb3 3y ago
  In fact, we know that IPv4 lives in the observable universe. You can travel at the speed of light towards IPv6, but the expansion rate of space time-itself (you can think of space-time as a series of tubes) is not limited by the speed of light. Thus, IPv6 is only theorized to exist, in order to explain other physical phenomena. Worse, even if it was proven to exist by a distant observer, there no way for them to relay that information back to us because our routers here at earth would drop the packets.
TheLoafOfBread 3y ago
People wanted to change bitfield with version from 4 to 6 and increase amount of bytes in IP address filed. Simple KISS. Instead of that we got fragile, backward incompatible, unnecessarily complex, jack of all trades protocol. And people are surprised that even after decades since the release of IPv6, it is being avoided like a plague.
- p1mrx 3y ago
  Consider that NAT64 is able to translate between IPv4 and IPv6 at the packet level. If the protocols were as different as you suggest, this wouldn't be possible.
  - michaelt 3y ago
    Doesn't IPv6 remove broadcast, thus removing DHCP and ARP? I mean, hosts need to be 'dual stack' to support IPv4 and IPv6 together - whereas TheLoafOfBread's proposal would allow support of both with one backward-compatible stack.
    - p1mrx 3y ago
      DHCP and ARP use 32-bit addresses, so those protocols had to change regardless. I would challenge you to find someone who knows the difference between Ethernet broadcast and multicast without looking up the answer. They are very similar mechanisms.
    - yencabulator 3y ago
      NAT64 is never in a position to need to translate DHCP & ARP, those live fully on one side of NAT64 ("4" side for DHCP & ARP, "6" side for SLAAC/DHCPv6 & NDP). NAT64 is involved on the level of TCP & UDP, not lower level protocols.
- doublepg23 3y ago
  This comes up often. What do you think would happen if you sent a “IPv4+” packet? All the ossified equipment would drop it. So you have to replace all this equipment, ideally _once_ so we ought to make it count.
zekica 3y ago
The main issue with IPv6 adoption is people who didn't learn IPv4 before NAT, and want to use the hammer (IPv4 NAT) for everything.
- pif 3y ago
  A hammer working fine today, that you own, is better than a machine tool tomorrow, that you'll have to pay.
  - fknorangesite 3y ago
    I wish we had an idiom for this. Maybe something bird-related.
- talideon 3y ago
  Also, developers who don't know how to get their daemons to listen on multiple interfaces at once.
  - cesarb 3y ago
    That's not necessary; listening on the wildcard IPv6 address without the "IPv6 only" flag enabled on the socket is enough. A IPv4 connection arriving at it is mapped to a special IPv6 address, so the code doesn't have to care about IPv4. Unless you were using Windows, where IIRC the IPv4 and IPv6 stacks were separate, and a single socket couldn't be used to listen to both at the same time. (This might already have been fixed in more recent Windows releases.)
PeterisP 3y ago
I'd say that it's not that there's some gain causing people/organizations to be obstructive, but rather that IPv4 and its address shortage simply isn't a problem for the influential people and organizations, they're doing just fine and for them there is nothing that needs to be fixed; IPv6 is needed by "someone else" who can be safely ignored with no noticeable effect to the bottom line.
pif 3y ago
IPv6 lacks back compatibility with the current standard. It cannot succeed.
- bauruine 3y ago
  It doesn't there are millions of IPv6 only devices that can connect to IPv4 only sites. See US mobile carriers.

greyface- 3y ago

TCP becomes unusable under interplanetary latencies; leaving the planet will force us to transition off of it.

pif 3y ago
More likely, we will end up with 15 competing standard. https://xkcd.com/927/ https://xkcd.com/927/
talideon 3y ago
Nah. The main impetus to achieve FTL communication will be because it'll be easier than shifting people off of TCP.
- deleted 3y ago
  [deleted]
- aardvark179 3y ago
  It’s all fun and games until you get an ACK before you sent the SYN.
  - pif 3y ago
    That's a solved problem, just ask the thiotimoline research group. https://en.wikipedia.org/wiki/Thiotimoline https://en.wikipedia.org/wiki/Thiotimoline
  - dredmorbius 3y ago
    Tardis Control Protocol.
KptMarchewa 3y ago
I don't think volume of data average user will want to send to Mars over next 100 years will be a important factor enough. I envision Mars comms using some kind of relay service, to which you'd communicate using TCP
- 3y ago

PinguTS 3y ago

Actually, even TCP is going to be replaced. I just want to remind the initial work of Google on QUIC, which now has become some standard. It is based on UDP and re-defining TCP features based on UDP together with cryptography and by allowing IP changes to allow moving clients.

speed_spread 3y ago
TCP is fine and isn't going anywhere. QUIC is an overengineered contraption that only exists to serve more ads. SSH doesn't need it. Postgres doesn't need it. Nobody needs QUIC except Google.
- neysofu 3y ago
  QUIC is not without defects, I'm with you there, but almost almost any "web-scale" company dealing with a lot of cellular connections would disagree with your statement. Uber, Verizon, Cloudflare, Meta, Fastly, among others, some of which have reported very significant latency reductions.
- yencabulator 3y ago
  > SSH doesn't need it. SSH's "master" mode connection sharing would benefit from QUIC / HTTP/3 head of line blocking elimination just as much as browsers would. Run a heavy rsync using connection sharing with an interactive session and you'll notice the interactive sessions latency suffering noticably. Long-lived SSH connections would benefit from QUIC / HTTP/3 session survivability.
londons_explore 3y ago
And yet, even with QUIC and a brand new Google phone on a Google wifi network and a Google Fi cell connection, I still can't walk away from my house and have a video call migrate from wifi to 5G without the audio glitching and dropping frames. All the mobility benefits of QUIC mean nothing when the rest of the software stack isn't designed to let it work.
- 867-5309 3y ago

ajsnigrutin 3y ago

So.... which will come first, "the year of IPv6" or "the year of linux desktop"? :)

deleted 3y ago
[deleted]
api 3y ago
IPv6 is waiting on stubborn cloud networks and CDNs. Most of the edge now has it. My guess is that it’s mostly reluctance to introduce complexity when most customers are not asking for it. The biggest holdouts seem to be connected to Microsoft, with GitHub being one of the most relevant. The Linux desktop will arrive if we just wait for Microsoft to keep making Windows worse. Linux doesn’t have to get better. MS just needs to incorporate more ads.
- jasode 3y ago
  >IPv6 is waiting on stubborn cloud networks and CDNs. Most of the edge now has it. Depends on the ISP. E.g. a lot of Verizon/Frontier FiOS residential customers don't have IPv6. Google statistics say USA is ~47% IPv6. Frontier FiOS is less % than that. Example recent thread: https://old.reddit.com/r/frontierfios/comments/v9azjj/june_2022_will_frontier_fios_ever_offer_ipv6/ https://old.reddit.com/r/frontierfios/comments/v9azjj/june_2... Google's statistics: https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
leansensei 3y ago
I know you are joking but I don't get the longevity of this joke. I've been running Debian with XFCE for more than 12 years, on PCs custom-built and branded, and on laptops both of enterprise quality and retail junk. Heck, our entire B2B commerce business runs the same setup, with far fewer (read: zero) issues compared to when we were using Windows 98, 98SE, XP SP3, 7, Vista, and 10, at which point we declined Microsoft's telemetry and ads and forced OneDrive shenanigans and promptly switched everyone to Debian+XFCE. 99.9% of the time, modern Linux works out of the box everytime. So I'd say it's on par with Windows versions, except I practically never need to download install drivers, or to face ads. Maybe I'm on a different planet on which the year of the Linux desktop has arrived for longer than a decade.

MisterTea 3y ago

I think the real issue is the operating systems did not properly abstract away the APIs, protocols and networks. On plan 9 the dial string is my favorite part of networking because you optionally specify the network in addition to the address and port in the form of a string: net!address!service. To dial an ssh server on port 1234 you run "ssh user@tcp!server.net!1234". The network database (ndb) can then be setup to alias names with protocols or ports so you can omit parts of the dial string for known services e.g. ssh defaults to tcp and port 22. The dial string neatly wraps up the entire network connection into a single string alleviating the program from having to offer command line arguments for port numbers which leaks protocol details into the code making things ugly and difficult to change. This lets your server take a dial string and listen on any network - even if that network isn't IP! So say you wanted to bring IPX/SPX back from the dead and use it in any program: so you write an IPX/SPX stack that binds over /net, then tell your server to listen on spx!*!555. Now your client also runs an IPX/SPX stack bound over /net and you hand the client program the dial string spx!server!555 and your program starts communicating over IPX/SPX to the server. Done. Want to use connect to an ssh server using quic on plan 9 (Assuming an imaginary quic stack)? just change the dial string to quic!host!port. Done. Once you use an OS with clean and simple abstractions you are left craving more of it. I wish more people took an interest in building much more radical operating systems.