4 ms·

It is possible 64-bits might have discouraged adopters who didn't want to waste expensive unnecessary extra bits at the time, so TCP/IP might not have taken off

It is possible 64-bits might have discouraged adopters who didn't want to waste expensive unnecessary extra bits at the time, so TCP/IP might not have taken off.

kragen 3y ago
the ipv4+tcpv4 header is minimally 320 bits long so i don't think so
- jandrese 3y ago
  Routers don't care about the TCP header though, they only care about the 20 bytes of IP header. The interfaces on the router also care about the 14 byte MAC header, but that's a separate step. That said I agree that the world likely would have sucked it up and just gone with the 64 bit addresses, but there would have been a whole lot of grumbling for decades about the memory use. It's hard to imagine these days, but back then memory was outrageously expensive and enormous amounts of engineering went into minimizing memory use wherever possible. Having these addresses where we wouldn't even touch half of the bits for decades would have been unpopular with a lot of people, even if he would have been praised for being so forward thinking in the end. On the other hand, the transition to IPv6 does give us a chance to fix some of the longstanding defects in IPv4 that would otherwise be baked into the protocol until the end of time, so it's not all bad.
  - imtringued 3y ago
    We live in a NAT and CGNAT world. Routers do care about the TCP header.
    - detaro 3y ago
      now. Not at the time were "adopting TCP or not" was a question.
  - FullyFunctional 3y ago
    "Having these addresses where we wouldn't even touch half of the bits for decades would have been unpopular with a lot of people, even if he would have been praised for being so forward thinking in the end." Worse perhaps, people, algorithms, hardware, ... will all start to assume those bits are zero and start optimizing for that. We have seen this happen repeatedly throughout history (eg. Lisp pointers would stuff tags in the "spare" bits in addresses, making implementations non-portable). These are all hard problems, but the lesson I take away is to 1. Always have a plan for evolving the design/protocol/API/... 2. Aim for a watertight design that supports 1. (Example: TLS 1.3 puts random stuff into reserved fields so nobody can assume they are zero). 3. Really stretch your imagination about future usages (assume 50+ years) 4. Have a ridiculously comprehensive test suite for both clients and servers It seems clear that in terms of lifetimes, hardware gets used much longer than expected, software even more so (Y2K anyone), but protocols/formats/specs/... literally never dies
  - kragen 3y ago
    we're talking about decisions that were made in 01979 and finalized by 01981 https://datatracker.ietf.org/doc/html/rfc791 https://datatracker.ietf.org/doc/html/rfc791 there was no such thing as a router in the sense of dedicated hardware; a router ('gateway') was just a host with two or more interfaces the ram used by ipv4 addresses was the same kind of ram used by the rest of the ip header and indeed packet i mean originally you did have the imps but they were just looking at the arpanet node number; they weren't gateways the switch from variable-length addresses to 32-bit addresses happened between ien 80 in february 01979 https://www.rfc-editor.org/ien/ien80.pdf https://www.rfc-editor.org/ien/ien80.pdf and ien 111 in august 01979 https://www.rfc-editor.org/ien/ien111.txt https://www.rfc-editor.org/ien/ien111.txt cisco was founded five years later, in 01984, at which point regular ram cost on the order of a dollar a kibibyte, so the content-addressable memory you need to accelerate a router was maybe ten or twenty dollars a kibibyte would people complain about the ip headers having unnecessary junk in them? certainly, but there is plenty of that in the actually adopted protocol header design too, so clearly it wasn't a showstopper
- kortilla 3y ago
  This is not how routers look at it though. Routing is performed on the destination IP address, which is only 32 bits. Doubling from 32 to 64 would have had a significant impact on routing table size and it would have dropped the back pressure to keep it from growing too quickly for TCAMs. It would certainly be nice today, but it’s not a sure thing it wouldn’t have been killed off as “bloated” when there weren’t even 2^12 hosts.

It is possible 64-bits might have discouraged adopters who didn't want to waste expensive unnecessary extra bits at the time, so TCP/IP might not have taken off.

kragen 3y ago

the ipv4+tcpv4 header is minimally 320 bits long so i don't think so

jandrese 3y ago
Routers don't care about the TCP header though, they only care about the 20 bytes of IP header. The interfaces on the router also care about the 14 byte MAC header, but that's a separate step. That said I agree that the world likely would have sucked it up and just gone with the 64 bit addresses, but there would have been a whole lot of grumbling for decades about the memory use. It's hard to imagine these days, but back then memory was outrageously expensive and enormous amounts of engineering went into minimizing memory use wherever possible. Having these addresses where we wouldn't even touch half of the bits for decades would have been unpopular with a lot of people, even if he would have been praised for being so forward thinking in the end. On the other hand, the transition to IPv6 does give us a chance to fix some of the longstanding defects in IPv4 that would otherwise be baked into the protocol until the end of time, so it's not all bad.
- imtringued 3y ago
  We live in a NAT and CGNAT world. Routers do care about the TCP header.
  - detaro 3y ago
    now. Not at the time were "adopting TCP or not" was a question.
- FullyFunctional 3y ago
  "Having these addresses where we wouldn't even touch half of the bits for decades would have been unpopular with a lot of people, even if he would have been praised for being so forward thinking in the end." Worse perhaps, people, algorithms, hardware, ... will all start to assume those bits are zero and start optimizing for that. We have seen this happen repeatedly throughout history (eg. Lisp pointers would stuff tags in the "spare" bits in addresses, making implementations non-portable). These are all hard problems, but the lesson I take away is to 1. Always have a plan for evolving the design/protocol/API/... 2. Aim for a watertight design that supports 1. (Example: TLS 1.3 puts random stuff into reserved fields so nobody can assume they are zero). 3. Really stretch your imagination about future usages (assume 50+ years) 4. Have a ridiculously comprehensive test suite for both clients and servers It seems clear that in terms of lifetimes, hardware gets used much longer than expected, software even more so (Y2K anyone), but protocols/formats/specs/... literally never dies
- kragen 3y ago
  we're talking about decisions that were made in 01979 and finalized by 01981 https://datatracker.ietf.org/doc/html/rfc791 https://datatracker.ietf.org/doc/html/rfc791 there was no such thing as a router in the sense of dedicated hardware; a router ('gateway') was just a host with two or more interfaces the ram used by ipv4 addresses was the same kind of ram used by the rest of the ip header and indeed packet i mean originally you did have the imps but they were just looking at the arpanet node number; they weren't gateways the switch from variable-length addresses to 32-bit addresses happened between ien 80 in february 01979 https://www.rfc-editor.org/ien/ien80.pdf https://www.rfc-editor.org/ien/ien80.pdf and ien 111 in august 01979 https://www.rfc-editor.org/ien/ien111.txt https://www.rfc-editor.org/ien/ien111.txt cisco was founded five years later, in 01984, at which point regular ram cost on the order of a dollar a kibibyte, so the content-addressable memory you need to accelerate a router was maybe ten or twenty dollars a kibibyte would people complain about the ip headers having unnecessary junk in them? certainly, but there is plenty of that in the actually adopted protocol header design too, so clearly it wasn't a showstopper
kortilla 3y ago
This is not how routers look at it though. Routing is performed on the destination IP address, which is only 32 bits. Doubling from 32 to 64 would have had a significant impact on routing table size and it would have dropped the back pressure to keep it from growing too quickly for TCAMs. It would certainly be nice today, but it’s not a sure thing it wouldn’t have been killed off as “bloated” when there weren’t even 2^12 hosts.