On 15-jul-2005, at 18:11, Ned Freed wrote:
Demultiplexing should happen on source and destination IP addresses
and source and destination port numbers. Assuming the server's IP
address and port number are given, that allows for a 65536 sessions
towards each possible IP address connected to the network.
This is the limit I'm talking about, which you now have agreed is a
protocol
design limit and not an implementation limit.
Sure.
That should be enough, I'd think.
And you'd be wrong.
Who, me? That can't be...
The specific case I've seen is with IMAP4. IMAP4 has the
characteristic that you often have a huge number of incoming
connections, only
a few of which are active at any given time.
I know what you mean, I've seen my Mac generate more than a dozen
simultaneous IMAP sessions on occasion. However, are you saying that
ONE client would use more than 64k IMAP sessions? That would be
inefficient, to say the least.
Also, since the clients don't tend to coordinate their port use, it's
common for servers to see lots of sessions where both the destination
port (duh, that's the well known one) and the source port are the
same. (When people connect to the IMAP server after booting their
source port is one of the first dozen or so that their OS uses.)
Since the server address is also fixed under normal circumstances,
the source address is a key ingredient in the demultiplexing.
Fortunately, there are enough of those for this purpose, even in IPv4.
But that doesn't mean nobody is hitting the 65536 limit imposed by
source port
numbers. They are, it causes problems, and this needs to be kept in
mind.
If they are, they're probably using some kind of proxy or NAT setup,
for instance, having SSL sessions decrypted and then forwarded to the
actual server port, making all the sessions seem to come from the
same address.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf