On 15-jul-2005, at 17:36, Noel Chiappa wrote:
Demultiplexing should happen on source and destination IP
addresses and
source and destination port numbers. ... that allows for a 65536
sessions towards each possible IP address connected to the network.
It depends on what protocol you are talking about.
For TCP, this is true: incoming packet demux is based on foreign
address/port
as well as local port, so each local port could have (as you point
out) up to
65K connections to any other IP address.
Right.
However, for UDP this is not the case; the base UDP protocol has no
concept of
"connection", and demultiplexing is *supposed* to be done only on
local port.
For one-packet-in-each-direction protocols such as DNS this would be
accurate (another reading of RFC 768 (got to love those two/three
page RFCs) reveals that the source port is optional), but:
unless, of course, the higher-level protocol running on top of UDP
does some
sort of demultiplexing (which might use foreign host/port, of course).
And if the source port isn't used in the first place, there isn't
much need to increase the field. :-)
Another observation: as far as I can tell, well known port numbers
are always assigned for both TCP and UDP, even though only a small
number of protocols runs over both TCP and UDP. Splitting up the
number space between TCP and UDP would provide some relief,
especially for UDP (the less used of the two).
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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf