Hacker News Reader

This explanation doesn’t sound simpler at all, it sounds like the complexity (each computer runs multiple services) is just obfuscated by making it part of the IP address. It would make routing a nightmare since the router now needs to keep a table of all services running on all hosts to know where to route traffic.

Routing would be no different. Routers already work with IP address prefixes. In the scheme described, a computer's IP is just a /32 prefix of a 48-bit address, and serves as the router for the 65k addresses.

Isn’t that what we have now with addresses and ports? What’s the difference?

The biggest difference is language - we don't have to think about addresses and ports being different ideas. Our APIs and textbooks get simpler.

And from an address perspective, its better because we end up with much more flexibility around how our networks are designed. Want to use 1 public IP address with 10k web servers? Now you can! Want a single machine to handle 10M outgoing socket connections? Sure - just allocate more addresses from your pool.

You can already do some of this stuff right now, but its awkward to reason about because of how ports and addresses interrelate. It'd be simpler and easier if we just think of the (address,port) tuple as a single address entity.

The main difference is that 'ports' live under the protocol layer (TCP/UDP/...) - TCP port 22 and UDP port 22 are not in the same address space

In many way's it's a very historical thing, back when TCP/IP was one of many competing network architecture (early 80s) most of the competing architectures did it the other way (there was only one port at that level and protocols ran under that). Is one better than the other? probably not much - TCP/IP won (IMHO) because they understood datagrams vs. virtual cicuits - they didn't plan on charging for TCP or IP level retries.

I think the mistake was that TCP should have build on top of UDP and have ports in the UDP layer, not the layer providing reliability and persistence.

Is this the idea behind HTTP 3? (Honest question.)

> DNS should associate a name with an address - including what we currently call the port.

This is something I really agree with. For an example that does naming right, Google's internal BNS addresses[0] in fact resolve to a host IP address plus port. Much more convenient because conceptually now a single piece of information is needed to identify a specific running instance of an application on a machine.

[0]: https://sre.google/sre-book/production-environment/

DNS supports SRV records which resolve to a host and port. They’re rarely used, however.

Unfortunately web browser, web apps and websockets can only use a few ports, so if you run a service that you later want to interoperate with a web app of some sort, you don't really have a choice. In a way, ports are already becoming obsolete for some applications.

Web browsers are actually quite flexible about what ports they can use. However some ISPs and “enterprise” networks will filter traffic on non-standard ports. That’s the real problem.

not being a big networks guy, but this feels like segment routing + network function virtualization (+ DNS) in a weird sort of way

or alternatively IPv6 Multicast Addresses: https://www.iana.org/assignments/ipv6-multicast-addresses/ip...

They're probably here because of the "layering" concept. If you view it from that angle, they're necessary to identify the application.

Of course, they are not really used that way nowadays... except by firewalls maybe, so even more stuff is moving to 80/443.

They are kind of useful sometimes if you consider port < 1000 privileged, although that's also quite limited.

I've always viewed (and I'm talking about IPv4 here) that the IP layer allows two computers to exchange data, while UDP and TCP allow two processes to exchange data. In other words, IP names a computer, and UDP/TCP name a process. It's probably not really needed for IPv6, but the concept was carried over since it was already there.

I also always think it would be easier if we could have the addressing to extend to individual receivers within the machine.

In effect, a machine would have its own internal network with individual, publicly addressable nodes representing various receivers.

Just imagine how virtualisation/containerisation would get simplified.

IPv6 I think tries to do this with link-local addresses. It doesn't make things simpler. It probably is supposed to but I've yet to really understand it.

Link local addresses are something completely different.

Ports are needed. Destination ports map to "listening" processes on a single machine; the abstraction is needed because more than one process on a system can use the TCP/IP stack.

> It makes way more sense to think of an IP address as the entire “address”+port tuple.

There's already a term for that - they call that a socket.

SNI has to do more with the "Host:" header of HTTP and the behavior of HTTP servers than anything else. Web servers started using that due to IPv4 address exhaustion and the need to host multiple "sites" on a single IP. IPv4 scarcity created a lot of twists in the end-to-end design, including this and NAT.

I think it would be cool if DNS gained the explicit capability to resolve names not only to IP addresses but also destination port. Not sure why it didn't. Certain apps can use SRV records or whatever but it's not standard.

In IPv6 each host has 2^64 addresses and the kernel just advertises its configured prefix to its router which then delegates routing to it. Instead of one address multiplexed onto 65535 ports, since every host now has 1.844674407371e19 addresses just use those.

That does not seem easier to think about, which address was this process on, you now have 1 interface with possibly 100s of addresses, need to keep track which address is for what application..

Seems more logical to just do the IP+port tuple. Maybe having TCP and UDP on separate port "namespaces" is the confusing part here and someone above mentioned could be simplified.

It's already typical to have multiple IPv6 addresses per interface, due to privacy extensions. You can see which IP address an application is listening on with netstat in the same way you see the port number. You would need to allocate addresses differently—each host would get a /112 instead of a /128 so that the port number can be placed in the lowest 16 bits, and the tooling (e.g. "ip addr") would by default show the 112-bit prefix assigned to the host rather than hundreds of individual /128 addresses.

The real casualty from merging IP addresses and ports, however, is that it would no longer make sense to listen on a certain port on "any" address/prefix (::/0); if there is more than one interface or prefix assigned to a host and an application wants to accept incoming connections from each of them it will need to listen on multiple sockets, and open and close those sockets as prefixes are added or removed.

SRV solves so many issues. It was codified as a standard 22 years ago. Maybe because it was invented at Microsoft, and the "year 2000 M$" was evil, the free software/open source people weren't interested in it and now it's mainly used by Microsoft products; as far as I can tell from my own experience with it.

It really gets better if you allow arbitrary sized addresses, where we can route with any prefix until we finally get to a destination.

Yep, that would be fun, and could obsolete DNS for some use cases. Though having variable length addresses in headers would be a headache for a lot of things.

Yes it does open the door to all sorts of pathologically inefficient routing.