Hi Mark
The original DCCP draft did not use traditional ports at all; instead
the client allocated a 32-bit connection identifier that served to
uniquely identify the connection, and the server listen on a socket
bound only to a service code. This solution is unambiguous; the
Service Code is the only identifier for a listening socket at the
server side, and the DCCP client would have to include a service code
in the request or there would be no way for the request to reach the
listening application. However it suffered from the downside of being
sufficiently different from existing protocols that we were concerned
that it would hinder the use of DCCP through NATs.
This is not the ONLY problem with the 32-bit connection identifier. A 32-bit
connection identifier, identified by application name, means that a server
could not run more than one server for the same application. E.g. an
experimental server on port 8000 in addition to a deployment server on port
80. It is useful to have the additional indirection allowed by ports. THIS
was the killer argument that convinced you to put ports back in. (Oh: You
mention it below, I see!)
I don't really agree with the MUST enforcement in the rest of the document.
Enforcing these MUSTs increases the mandatory burden on implementers for no
immediately pressing reason. (There are 6 service codes registered at the
moment, and 3 well known ports! We are a long way from a collision.) If the
intent is to shift the Service Code into the equivalent of the "struct
sockaddr *" specified at bind() time, away from a socket option, I agree with
that intention, but one could encourage that without the MUSTs.
This I definitely disagree with:
IANA should allocate well-known DCCP ports on demand to anyone to
applies, without requiring a specification or additional
justification. Each well-known port request MUST be for a specific
registered DCCP service code. IANA should use an allocation policy
that attempts to minimize server port collisions, but it is expected
that the same well-known port will sometimes be allocated to more
than one service code.
* If you read the IANA Considerations section you will see that the parts you
want are already there, e.g., multiple registrations of the same port with
different service codes, service code specification as part of registration
with MUST. So what problem are you solving?
* IANA really, really, really wanted DCCP port number registration policies to
mesh well (i.e., be basically equivalent to) TCP/UDP policies. We had to
revise 4340 several times to make that happen. I agree with IANA in this case
and see no need to change the policy to something subtly different.
Eddie
