[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dccp] port numbers and DCCP
Eddie,
IANA will probably be happy to have it this way...so thanks.
But some pushback comments inline.
>
> I've cut and pasted the Port Numbers section below. It refers to
> "textual Service Codes"; I added an earlier small section on
> representing Service Codes in text -- briefly, SC:fdpz,
> SC=1717858426, and SC=x6664707A all represent the same Service Code
> (1717858426).
>
> Comments from interested listeners? Magnus? Allison? Colin? Lars?
> Thanks,
> Eddie
>
>
> 19.9. Port Numbers
>
> DCCP applications may use service-contact port numbers to provide
> service to unknown callers, as in TCP and UDP. IANA is therefore
> requested to open the existing Port Numbers registry for DCCP using
> the following rules, which we intend to mesh well with existing Port
> Numbers registration procedures.
>
> Port numbers are divided into three ranges. The Well Known Ports
> are those from 0 through 1023, the Registered Ports are those from
> 1024 through 49151, and the Dynamic and/or Private Ports are those
> from 49152 through 65535. Well Known and Registered Ports are
> intended for use by server applications that desire a default
> contact point on a system. On most systems, Well Known Ports can
> only be used by system (or root) processes or by programs executed
> by privileged users, while Registered Ports can be used by ordinary
> user processes or programs executed by ordinary users. Dynamic
> and/or Private Ports are intended for temporary use, including
> client-side ports, out-of-band negotiated ports, and application
> testing prior to registration of a dedicated port.
>
> The Port Numbers registry should accept registrations for DCCP ports
> in the Well Known Ports and Registered Ports ranges. Well Known and
> Registered Ports SHOULD NOT be used without registration. In
> contrast, Dynamic and/or Private Ports MUST NOT be registered.
Back to you on this from your earlier mail - you argued for the SHOULD
NOT because people might use the Well Known ports and Registered Ports
experimentally while porting their UDP application on Port N onto DCCP
Port N. This does make sense, but if you have the SHOULD NOT there with
no example, it is a contradiction to the advice to use the Private Ports
for temporary purposes. IETF SHOULD/SHOULD NOTs are confusing.
If this stays a SHOULD NOT, it needs the specific example of why
someone would rarely not use the temporary, e.g. add this something
like this:
NOTE: a developer porting her UDP application from UDP Port
N to DCCP Port N may find herself using that Port temporarily
while awaiting the completion of the registration request.
IANA will not guarantee registration of particular Well Known
and Registered Ports, so going through the registration request
as early as possible is advised.
And, FYI, there's been a lot of progress because of the IETF
Administrative Support Activity, so instead of year-long waits for
a port to be assigned, it should be under 30 days for FCFS.
>
> Each port registration SHALL include the following information:
>
> o The port number that is requested to be registered.
>
> o A short port name, consisting entirely of letters (A-Z and a-z),
> digits (0-9), and the punctuation characters in "-_+./*" (not
> including the quotes).
>
> o A short English phrase describing the port's purpose. This
> SHOULD include one or more space-separated textual Service Code
> descriptors naming the port's corresponding Service Codes (see
> Section 8.1.2).
>
> o Name and contact information for the person or entity performing
> the registration, and possibly a reference to a document defining
> the port's use. Registrations coming from IETF working groups
> need only name the working group, but it is also recommended to
> indicate a contact person.
>
> Registrants are encouraged to follow these guidelines when applying
> to register a port number:
>
> o The same port name SHOULD NOT be registered for more than one
> DCCP port number.
>
> o A port name registered for TCP, UDP, and/or SCTP MAY be
> registered for DCCP as well. However, any such registration
> SHOULD use the same port number as the existing TCP, UDP, and/or
> SCTP registration.
No: it does not make sense to register ports for reliable
or partially-reliable transports when you register DCCP ports; those
are different transport services. The applications that use datagrams
can be seen to go over DCCP straightforwardly, but not applications
that use TCP and SCTP. Some SCTP applications use PR-SCTP, but this
is partially reliable, depending how they configure it.
I'd also be concerned about encouraging that DCCP ports be signed up
for all the ones that are already UDP, because there are a lot of
UDP ports allocated that don't make sense. The result is that the
Well-Known Port Space for UDP has only 174 left unassigned; there
are also 14 set aside as Reserved, and at least 2 of these, 1022/1023,
cannot be allocated.
Here's an alternative:
o A port name registered for UDP MAY be registered for DCCP as
well. However, such registrations should be performed only for
those UDP port names where DCCP will be used for transport, not
on a wholesale basis, in order to conserve the port space. When
performed, such registrations SHOULD use the same port number as the
as the existing UDP registration.
o Applications to register port names for DCCP which are in
use for SCTP or TCP should be sent not to IANA, but to the
Transport Area Directors, who will review them within thirty
days of the request. Port names in SCTP and TCP are usually
for non-datagram applications, so the Transport Area Directors
should consider whether the registration request is sensible,
and instruct IANA to perform it only if so. The Area Directors'
reply to any such application will be made public.
>
> o Multiple registrations for the same DCCP port with different port
> names are allowed, but discouraged. In any case, two different
> registrations for the same DCCP port MUST have disjoint Service
> Codes.
>
> This document registers the following port, which should also be
> considered a model registration.
>
> discard 9/dccp Discard SC:DISC
> # IETF dccp WG, Eddie Kohler <kohler at cs.ucla.edu>, DCCP RFC
>
> The discard service, which accepts DCCP connections on the discard
> port, discards all incoming application data and sends no data in
> response. Thus, DCCP's discard port is analogous to TCP's discard
> port, and might be used to check the health of a DCCP stack.
>