Subject: Re: Port numbers and IPv6 (was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)

From: [email-masked] (Noel Chiappa)
Date: Fri, 15 Jul 2005 11:36:18 -0400 (EDT)

> From: Iljitsch van Beijnum <[email-masked]>

    >> you can only have 65536 connections to a single service on a given
    >> port.

    > 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.

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.
(Which is why TFTP has that funny little hop-step with port numbers when a
TFTP transfer starts.) So for UDP, each local port could only have one
"connection" at a time (and that's to the entire Internet, not per-host) -
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).

However, not all implementations correctly implement this: for instance, I'm
rather embarassed to admit that when I recently looked at a TCP/IP I wrote
some years back, I discovered that the UDP layer used the exact same
demultiplexing code as TCP! Ooops...

	Noel

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 15 Jul 2005 17:59:56 +0200

> 65K connections to any other IP address.

Right.

> "connection", and demultiplexing is *supposed* to be done only on  

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  

> 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.

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 15 Jul 2005 15:05:43 -0400

> 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....

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 15 Jul 2005 21:22:51 +0200

On 15-jul-2005, at 21:05, Ken Raeburn wrote:

>> 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.