On 15-jul-2005, at 21:05, Ken Raeburn wrote:
For TCP, the issue is less critical as there are already other mechanisms that allow us to move away from well known port numbers. One is the SRV DNS record that I mentioned yesterday, but if you set your way back machine to 1988 you'll find RFC 1078 which accomplishes the same thing in a different way.
Actually, it looks like 1078 (TCPMUX) basically runs everything over a connection to TCP port 1, so instead of limiting the connections to a given service from a single source IP address, you'd be limiting the connections to all multiplexed services, together, from a single source IP address. ("Sorry, you can't telnet in, you've got too many IMAP sessions open.")
Now, if you ran TCPMUX on all 64K ports....
Yes, that could be made to work... I don't think many clients implement it, though, although I seem to remember that at least one incarnation of inetd did/does.
Anyway, RFC 1078 doesn't solve the "many sessions between two addresses" issue, but I was talking about running out of well known port numbers here.
Unless I'm mistaken, SRV records can solve both (to some degree, you wouldn't want to have _huge_ amounts of DNS records for one service) since you can point a client to several addresses and/or ports. (Phillip, wat is the issue with SRV that you feel needs fixing?)
When I was talking about a private protocol extension between the hosts involved earlier, I was being imprecise: what I meant was that an extension to TCP could be created that allows for more port numbers, and that the two hosts involved could use such an extension between them. The "private" part wouldn't be the nature of the extension, but the fact that the actual clients don't have to be involved. As long as the component vendors all implement the extension, that would be enough.
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf