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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf