Hacker News Reader

Comment by sixothree | Hacker News Reader

I find it extremely awkward that we actually use numbers for ports. Port 80 is typically used for HTTP, but there's nothing preventing another application from using port 80. Why not call the port "HTTP" instead. Better yet why not give it an integer range of ports to go along with the naming - Eg MyApp[1], MyApp[2].

If you want to hide a port from being probed then give it a GUID as a name. No more port scans.

View on HN

At the time TCP/UDP were invented, keeping packet size small was very important. A string or GUID as addressing information would have been out of the question.

(If there wasn't a need to distinguish multiple clients on the same machine, we might have only had 255 ports!)

A standard port for HTTP servers is needed, as most HTTP clients don't support DNS SRV records.

That said, in the IPv6 world there's no technical reason you can't just let every service bind a different IP address.

> in the IPv6 world there's no technical reason you can't just let every service bind a different IP address.

I'm not a networking expert, but is that true that you can create multiple ip's for a single device using ipv6? Sounds like it would end up very messy.

You can do that, provided that the network routes multiple IPs (or a whole prefix) to the device. It tends to be pretty messy keeping track of all the addresses in the OS configuration, but that's an opportunity for OSes to get better.

> It tends to be pretty messy keeping track of all the addresses in the OS configuration, but that's an opportunity for OSes to get better.

Seems like an odd thing to do, create bizarre (unnecessary?) complexities simply as an opportunity for OSes to get better.

Are there any advantages to doing it that way?

Packet size is important. If your ports are strings, every packet gets that much bigger. Nobody wants slow internet for programming convenience.

It's not even convenient. Strings are one of the biggest scourges of any programming language out there. Giant mess in basically every language until Java got it somewhat right, and even then don't forget your equals...

C# (.NET) could be the forerunner if only they had not gone with UTF16, but then it's only with hindsight that we can point out UTF8.

Strings are only a problem because they are being treated as text. In this case, they would simply be treated as binary identifiers, so there is no problem. The raw bytes would do just as well for this kind of thing.

Only if they are fixed length. If you used variable length strings in packet headers things would get complicated.

But if you're fine with fixed-length strings, you could just as well use all those bits to represent a number instead.

The name could be used for connection establishment, then a random port is assigned, just like the client port.

Portmap[1] lets you use names instead of port numbers. A server just grabs an arbitrary port number and then registers itself with the portmap server. When you want to connect from a client, you first ask the portmap server for the port number.

[1] https://en.wikipedia.org/wiki/Portmap

As an alternative, predating Portmap by around 700 RFCs: tcpmux[0]. Everything connects to port 1 and asks for services by name.

[0]: https://tools.ietf.org/html/rfc1078

I have an experimental protocol that uses tcpmux. Works very well for that purpose.

However, it sort of requires your service to be started by inetd. It doesn't work for services that want to manage their own listen queues.

It also complicates firewalls. It makes it much harder to have rules that vary per service.

Easy to do with DNS SRV records. Just add: _http._tcp.hostname SRV priority weight port target. and you can use any available port you like.

Of course, current TCP has 16-bit ports hard coded. But IPv6 has almost unlimited addresses.

For some reason, SRV records are not in wide spread use.

>For some reason, SRV records are not in wide spread use.

No legacy tooling supports it. Poor support on the products already there. Huge numbers of firewalls are hard coded to 80:443 so alternate ports would be blocked.

When you make a poor choice on the internet, it lasts forever.

> Why not call the port "HTTP" instead

This is what /etc/services is for:

telnet localhost http ...

But unfortunately very few applications do resolve "port name to port number" as they resolve "hostname to ip address".

More practically, it's very nearly become a moot point due to firewalls which block all traffic except to a very narrow set of ports. Opening holes on enterprise firewalls is a gargantuan battle. Which is why we've seen what are effectively new services implemented as port 80 features: Twitter, Reddit, Facebook, Gmail, Dropbox just off the top of my head (irc, Usenet, finger, email, ftp, arguably, in their basic implementations).

See Meredith L. Patterson's "On Port 80" https://medium.com/@maradydd/on-port-80-d8d6d3443d9a

Is it possible to file an RFC to IETF for these kinds of solutions? I see lot of great ideas but never see anybody proposing them anywhere, why?

This particular idea is bad.

IIRC, appletalk used service names, not ports.

Which is why when Apple moved to TCP/IP, multicast DNS (Bonjour, zeroconf) was such a crucial part, because it let them implement a similar model on top of port numbers.

Reply on news.ycombinator.com