Since Service Codes are freely assigned, and application developers are
encouraged to ask for what they need, it would be nice for these
developers to also know which port to use in some loosely coordinated
fashion! Free assignment of ports with Service Codes is one alternative,
but has many disadvantages. Following on from the discussion at the DCCP
WG yesterday, I propose the following text for and potential inclusion
in section 2.1 of draft-ietf-dccp-serv-codes-03.txt.
At the moment I can see no disadvantage in allowing this, can anyone see
reasons why it should be different or not done this way?
--- Proposed text
Applications that do not use out-of-band signalling can still
communicate, providing both client and server agree the port value to be
used (e.g. using a common method at the client and server to hash the
32-bit Service Code to a value in the dynamic port range). Note that
more than one DCCP server may share the same server port, since in DCCP
the Service Code mechanism is the method for unique identification of a
service.
The service code can be used to derive a default server port number for
a service using the RECOMMENDED method below. This provides applications
with easy identification of a default service code, without requiring
IANA action to create or update a registry. The returned value is in the
dynamic port range, as required by RFC4340: "Well Known and Registered
Ports SHOULD NOT be used without registration".
int sport; /* server port */
s_port = (sc[0]<<7)^(sc[1]<<5)^(sc[2]<<3)^sc[3] | 0xC000;
Where sc[] represents the four bytes of the Service Code, and sc[3] is
the least significant byte.
This algorithm has the following properties:
* The method assigns a default server port for each Service Code.
* The method seeks to assign different Service Codes to different ports,
but does not guarantee this is unique.
* The method preserves the four bits of the final bytes of the Service
Code, allowing a series of Service Codes to be requested that in this
method are mapped to adjacent ports, e.g. Foo1, and Foo2; and Fooa and
Foob would be assigned adjacent ports.
All applications and higher-layer protocols that have been assigned a
Service Code (or use a service code from the unassigned space) may
therefore use this method, which eliminates the need for each registered
Service Code to be allocated an IANA-assigned server port.
----------------
Questions asked:
Does this overide the ports registry? No. This method does not preclude
a server application using a well-known port, or other value negotiated
by some other means (e.g. SIP, RTSP,whatever...).
I heard some reluctance to permit this procedure over the wider port
range (e.g. 32K or 64K of port numbers), for fear of backwards
incompatibility with middleboxes or future port-based methods in these
boxes. A larger range would reduce the probability of port clashes.
Middleboxes and applications need to expect clashes, since ports can be
used for non-standardised servuces anyway).
Tom raised a question about whether we needed to specify the algorithm.
We don't need this for the DCCP stack (applications can choose any port,
and some will do this anyway). Some advantages of a common method that
I can see are:
* There is less probablity of a clash, e.g. application implementors
happen to follow example.com (or whatever) and choose the same port.
* A list can be compiled of all the default ports by running the
algorithm on the entire SC registry - who would use it? network
monitors? midboxes? people thinking about which SC to register?
Best wishes,
Gorry
