Hacker News Reader

Comment by throw0101a | Hacker News Reader

> HTTP/3 runs over QUIC – an encrypted general-purpose transport protocol that multiplexes multiple streams of data on a single connection.

Kind of sucks that SCTP, which also allows for multiplexing, never caught on for general use—probably because lack of support in various mid-network network boxen.

I guess we're generally stuck with tunnelling everything over HTTP (TCP and UDP) going forward. Every other kind of protocol implementation is out of the question because of NAT and various proxies.

View on HN

Sometimes I imagine an "alternate history" where IPv4 had 64-bit addresses, SCTP was used for everything we use TCP for, and "well-known ports" were eschewed in favor of DNS SRV records for service location (and all the goodness they bring).

Given that we haven't run out of (Ethernet) MAC addresses yet, even 48 bits may have been enough (until this point).

MAC addresses are link-local, not global.

Your device and my device could have the same MAC address and everything works fine until we find ourselves on the same L2 network. And there's practical limits to how large a single L2 network can be, and it's way smaller than 48 bits of space.

Yes, I know. But I think you misunderstood this sub-thread.

IPv4 has 32-bit addresses, and we've run out of those, which necessitated a new protocol (IPv6) with a larger addresses space (and the use of NAT until it's rolled out everywhere). However, the GP said:

> Sometimes I imagine an "alternate history" where IPv4 had 64-bit addresses […]

Which would have allowed for continued use of this alternate-history-IPv4 without having to NAT and without all the work to enable IPv6.

My observation was that 64b addresses would probably not not even been needed, as we're using "only" 48b for Ethernet MAC addresses and we haven't run out of those yet, so an alternative-history-IPv4 with "only" 48b addresses (instead of 64b or IPv6's 128b) would probably also been enough.

At least until now, early 2022. I'm sure at some point the alternate-history-IPv4 addresses would have run out, and an alternate-history-IPv5/6 would have had to have been developed eventually too.

> And there's practical limits to how large a single L2 network can be, and it's way smaller than 48 bits of space.

Well IPv6 subnets are /64, so ¯\_(ツ)_/¯. (Though 2^64 hosts are not actually expected to live in a single subnet: that's the equivalent of four billion Internets.)

> an alternative-history-IPv4 with "only" 48b addresses (instead of 64b or IPv6's 128b) would probably also been enough

MAC address can be assigned in arbitrarily small blocks whereas IP addresses must be assigned as large prefixes, ideally one prefix per org. Otherwise the internet routing table would be too large. I don’t think 2^48 is reasonable right now without NAT and it certainly won’t be enough in the near future.

Also 48b MAC addresses are kinda small. InfiniBand uses 64b and newer protocols should do the same.

> MAC address can be assigned in arbitrarily small blocks

Not really. Of the 48b available, the first 24 are assigned to an organization:

* https://en.wikipedia.org/wiki/Organizationally_unique_identi...

* http://standards-oui.ieee.org/oui/oui.txt

then they can assigned the other 24b as they wish. This is in some way similar to an IP prefix being assigned, which can then be used however the assignee wishes.

48b would have lasted longer than 32, perhaps delaying the need for NAT (RFC 1631 from 1994), but certainly at some point an address extension would have been needed. Of course in the 1970s it would have been hard/impossible to predict needing more than four billion addresses for a research/academic network.

You don’t need an OUI. They sell smaller blocks: https://standards.ieee.org/products-services/regauth/oui36/

Sounds a bit like half way to OSI network style

Perhaps. When OSI was still a going concern I was far too young to have paid attention. Glancing at the PDF for the X.224 spec[0] I see things like "The initiator may assign the transport connection to an existing network connection of which it is the owner or to a new network connection (see Note 1) which it creates for this purpose." In X.225[1] I see some references to re-using transport connections. (Egad, the ITU documentation is much less fun to read than RFCs.) It certainly looks like the layering in the OSI protocols is taken nearly to the absurd.

I do know Vint Cerf has stated using the IP address as the connection endpoint identifier in TCP and UDP was a mistake.[2]

[0] https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.22...

[1] https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.22...

[2] https://youtu.be/t9M0RPNr9qg?t=2229

It would help to have quality implementations of the full SCTP specs first.

Reply on news.ycombinator.com