Hi Bryan, In the DCCP meeting you mentioned that a problem you have with dccp-natencap is its preservation of the DCCP port numbers. Let me give you the thought train that led to preserving the port numbers and maybe you can give me your thoughts on why they shouldn't be preserved. The idea behind preserving the port numbers is simple -- if there's only one port space then there can be only one transport protocol per port. For example, port 80 is currently allocated as HTTP for UDP, TCP and SCTP. HTTP over UDP is not really defined, but it is defined for both TCP and SCTP. If there's only one port space, how can a server tell which transport protocol is intended? Rely on accidental differences between a TCP SYN and an SCTP INIT? Only allow a server to serve one transport? The problem gets worse with the recent IANA decision, due to depletion of the port space, to allocate ports independently for each transport. With this you can get a port that's a different application for each transport. This can exist even when the ports are nominally allocated to the same application although it's less apparent. There are situations where the port is allocated to one application for UDP and TCP, but the two transports provide different functions. Often the UDP port provides a discovery/registration service and the TCP port provides a data transfer service. As far as I can see, draft-denis-udp-transport offers no remedy to this. The "Meta-SYN" idea you discussed in tsvarea has possibilities. It could allow sharing a port between TCP/SCTP/DCCP but would rely on having no existing UDP application that uses that port. For a trivial example, discard is defined as port 9 for all of the transport protocols. Even with a Meta-SYN, a listener wouldn't be able to determine if the client meant plain-old-UDP or fancy-new-udp-encap. Tom P.
