Hacker News new | ask | show | jobs
by magicalhippo 53 days ago
I know it's mixing of layers, but I can't help but feel the IPv6 transition missed the boat when they didn't just get rid of ports in the process. They've changed so much else anyway.

Want to run another webserver instance or whatever on your computer? Get the OS to allocate a new IP for it. Ports be damned.

Could be implemented in a backwards compatible way by requiring all IPv6 TCP/UDP traffic to use a fixed port number.

2 comments

ipv6 packet does not have any port field. ports are on the level of tcp and udp, and you don't have to use tcp or udp on top of ipv6. ipv4 packet does not have any port information as well.
tcp6 is a thing though, was created at the same time as ipv6, and it does have ports, along with udp6. But if you really want one ip per stream and just hardwire port 1 or something, it's not like IPv6 does anything to stand in the way of that. Mght have performance issues on some OS's binding thousands of IPs to one interface, but that's on them to fix. Bigger lift would be the APIs that would need to change to manage whole prefixes at a time instead of single IPs.
afaik tcp and udp are the same on top of ipv6 as they are on top of ipv4, there are no tcp6 and udp6, the "6" suffix just hints they are comminucated on top of ipv6, but the packets are the same as before, no new standards.
I could have sworn there was a different and simplified format for segments (datagrams are already about as simple as they can be), but I apparently had hallucinated it all these years. Turns out the only difference is using the larger addresses in the checksum algorithm.

Still, I do have to wonder about a port-free world. Seems a lot of things would get simpler.

> ipv6 packet does not have any port field

Yes, that's why I said I know it was mixing of layers.

However ports are a layer violation in a strict sense, introduced as a workaround because there was no easy way to just add thousands of new IPs to a single host back in the IPv4 days. No need to continue a workaround that causes grief on a daily basis.

What do you mean? You’ll still have to use TCP or UDP over IPv6, and both of those protocols use ports. Nothing is stopping you from creating a transport protocol that doesn’t use ports if you want to, but that has nothing to do with the network layer.
I mean that to connect to a service you wouldn't need to know the port, the IPv6 address would be enough.

This is why I consider ports a layer violation of sorts. You never talk to a machine with TCP/UDP, you talk to a service on a machine. And so as it is the full address to the service isn't just the layer 3 address.

As I mentioned this would be especially interesting when hosting multiple services, same or different, on the same machine since there would be no port conflict.

Yeah, but I mean you just have to have something on the transport layer, you can't just encapsulate application layer into network skipping network, that's not how the network stack works.
Perhaps it's because I'm tired but I can't make sense of your objection.

As I said you could implement it by having TCP/UDP as is, just with a fixed port number. This wouldn't be unlike the myriad of other conventions that litter IPv6, such as using /64 for a host or ULA's having a certain prefix.

Conceptually its doable on linux and ipv6. Have the listening program sit on that default port of 80.

Something involving socat, an any-IP / TCP routing rule, a VPS or other machine with a ipv6 /64 and plenty of duct-tape.

You'd get an application sitting on port 80 accessible via some unique ipv6 address (in the /64) on a tcp port 80. They needn't be the same port number but it would make it easier.