Now that we have IPv6 – do we need TCP/UDP port numbers anymore?
TCP/UDP port numbers are used to multiplex traffic to the same IP, so multiple services can be made reachable. I can't find docs when searching to understand if this is the only reason they exist but that is what I believe is their only purpose.
Recently I've started learning about Tor - you can make single service reachable through the Tor network with a Hidden Service address like: 3g2upl4pq6kufc4m.onion
Like IPv6, "Onion addresses" aren't starved for address space. With Onion addresses you can only host a single service behind the address. It's trivial to create and bring one up to host a service. I argue we can use IPv6 similarly.
Getting rid of TCP/UDP ports - the positives?:
1) We could chop off 4 bytes from TCP/UDP headers (2 x 16-bit for source/dest port)
2) Routing traffic to the right bound service in the kernel's networking stack might be made simpler.
3) Without ports you can't assume from an address what type of service is hosted there - with ports we assume port 80 is a webserver. People might start claiming addresses that end in ':BEEF]' to associate with webservers, though. WHERE"S THE BEEF?!
4) Port scans would become [EXHAUSTIVE] prefix/subnet scans, and it'd be harder to be sure you're fingerprinting the same host.
Some negatives:
1) People are used to reaching the same host at the same IP but when using a different port. This hasn't always been true with things like NAT and Haproxy, but if we got rid of ports you'd have to keep a note of which address hosts SSH. Ports make this less cumbersome.
2) Someone could maliciously try claiming every address in an advertised/routed/reachable prefix to starve other users of addresses - how possible is this? Any comment, NSA?
I don't think this will happen but I'd like to know other reasons why we need port numbers :>
11 comments
[ 3.0 ms ] story [ 33.5 ms ] threadhttp://www.spinics.net/lists/kernel/msg2001254.html
I hope this is the right place >.>
[...]
> Some negatives:
The first and the foremost: we would need two totally new protocols in place of two already well-known, well-functioning and well-tooled ones. Benefits you mentioned are negligible.
If SCTP did become the protocol we transition TCP/UDP to - should port numbers stay? (iyo)
If you want to get rid of port numbers, you will need to roll a new protocol, and nobody will go this way merely because of four bytes per packet.
Also, there would probably be vast amount of unexpected traps and pitholes without port numbers. We already know well how to work with port numbers. We don't know too well how to work without them.
Because SRV records aren't in widespread use (by specification and only consequently implementation). First you would need to stop using the A (or AAAA) record, on all existing protocols. This is a good thing because, comparatively, the A record is pretty stupid. However, it's never going to happen for the same reason that you probably can't set up an SRV record with whoever is hosting your DNS.
Also, ports are a portion of an address that routers can ignore - making them better at what they do. With multiple addresses per host you are going to annihilate routing tables/caches and make the internet slower.
If you got rid of the port numbers, you wouldn't just need an IP address for each service, you would need one for every outbound connection you make, and this address would need to be announced and stored in routing tables, checked for collisions, etc. Allocating ports is a lot cheaper, since only the endpoints (and stateful NATs/firewalls) need to know about them.
It's a fun question, but I think it has a straightforward answer.
1. The IPv6 header is already twice as big as the IPv4 header, so the win in shrinking the TCP or UDP headers is extremely marginal.
2. No, the kernel IP handling code would get more complicated; since BSD Unix, the PCB code in the kernel has assumed sessions were organized by port numbers. Meanwhile: the underlying concept of a numeric mapping between applications and instances of protocols on the wire wouldn't go away; you'd just be overloading IP addresses to accomplish it.
3. I agree that the opportunity to encode funny service names in hexadecimal trailing address space is an upside to eliminating ports.
4. Removing ports strictly simplifies network reconnaissance. IPv6 already makes scanning painful, whether or not you have TCP/UDP ports. With IPv6 and TCP ports, you have to do both: identify the live hosts, and then identify the listening ports on that host.
Some architectural downsides:
1. It is often (not always) helpful to distinguish between an entity providing a service and the services they provide. That distinction is lost when everything is an address.
2. Port numbers prevent us from accidentally trying to speak, say, RTP to a line-printer protocol server. Badly coded servers will often crash given random crap, and while that's not dispositive (the priority should be "eliminate badly coded servers), it's a helpful feature of having ports.
3. The network is required to be aware of which end-systems own which addresses. They are not required to be aware of which applications are running on which end-systems. The end-to-end argument says: put the minimum amount of state in the network, leave as much up to the end system as possible.
Much like a CCNA review from a few years ago :) Thanks.
I really liked your reply :-)