[Tsvwg] IANA issue with RFC2960/draft-ietf-tsvwg-2960bis

[Lars Eggert <[e-mail]>]

Hi,

during a second IANA review of the IANA considerations section in  
draft-ietf-tsvwg-2960bis during the RFC Editor's "IANA" state, a  
discrepancy has been identified. Basically, the text that describes  
the port number assignment procedure - which had been taken verbatim  
from RFC2960 - wasn't describing the procedure that IANA has actually  
used since RFC2960 was published seven years ago.

The IANA instructions in draft-ietf-tsvwg-2960bis and RFC2960  
basically say "for each existing TCP/UDP port assignment, create a  
similar entry in the SCTP port number registry", i.e., a blanket  
assignment of SCTP port numbers for all existing TCP/UDP assignments.

What appears to have happened is that the ADs at the time identified  
an issue with the text that was in the ID that became RFC2960 and  
instructed IANA to follow a different procedure, namely, to not  
perform a blanket assignment and instead create individual entries in  
the SCTP port number registry on request, similar to how IANA handles  
requests for TCP/UDP and DCCP port numbers. Unfortunately, the text  
in RFC2960 was never updated to reflect this change in procedure.

When I reviewed 2960bis I didn't question this, because it was what I  
thought the policy was, and it wasn't for the -bis document to change  
the policy. Now that we've found out that the IANA procedures in  
RFC2960 were actually modified by the ADs at the time, the situation  
has changed.

In my (and Magnus) opinion, we should change the IANA considerations  
text in 2960bis to describe the allocation policy that has actually  
been in effect for the last seven years, i.e., allocate individual  
SCTP ports by request, instead of the blanket registration that the  
text currently describes.

I'll propose some text changes to 2960bis to that effect below, which  
I'd like TSVWG and the IESG to review, but let me first explain why I  
think this is the correct approach:

	(1) I find myself agreeing with the old ADs' argumentation.
	SCTP and TCP (and UDP) have different requirements, and it
	is not obvious that an application can substitute one transport
	protocol for another. (And yes, the current practice of allocating
	both TCP and UDP ports for an application if it requests either
	UDP or TCP only is for that reason also problematic, but let's get
	to that another time.)

	(2) For our other recent transport protocol (DCCP), we also didn't
	do a blanket port reservation for all existing TCP and UDP ports
	and instead require individual registrations, although one could
	similarly argue that UDP apps can simply migrate to DCCP. Doing
	something different for SCTP is inconsistent.

	(3) The scope of 2960bis was clarification and fixes. For that
	reason, the IANA registration that is used in practice should
	be described as part of 2960bis, i.e., 2960bis should "fix" that
	error in RFC2960.

Several applications already use SCTP on port numbers that have been  
assigned to them for TCP or UDP, because the authors were not aware  
that they would need to request an allocation from IANA. I propose  
that the change to the IANA Considerations section in 2960bis  
register the SCTP ports of those applications, to "bless" those  
existing uses.

All that said, below is the proposal to update 2960bis. The text  
mirrors the allocation procedure for DCCP ports (thanks, RFC4340  
authors!)

Please comment. IANA has agreed to put a hold on the document until  
this issue has been clarified.

Lars


OLD TEXT:

14.  IANA Considerations

    This protocol will require port reservation like TCP for the use of
    "well known" servers within the Internet.  All current TCP ports
    shall be automatically reserved in the SCTP port address space.  New
    requests should follow IANA's current mechanisms for TCP.

    This protocol may also be extended through IANA in three ways:

    --   through definition of additional chunk types,
    --   through definition of additional parameter types, or
    --   through definition of additional cause codes within ERROR  
chunks

    In the case where a particular ULP using SCTP desires to have its  
own
    ports, the ULP should be responsible for registering with IANA for
    getting its ports assigned.


NEW TEXT:

14.  IANA Considerations

    SCTP defines three registries that IANA maintains:

    --   through definition of additional chunk types,
    --   through definition of additional parameter types, or
    --   through definition of additional cause codes within ERROR  
chunks

    SCTP requires that the IANA Port Numbers registry be opened for SCTP
    port registrations; Section 14.5 describes how.


14.5  Port Numbers Registry

    SCTP services may use 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 SCTP 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; they MUST NOT be registered.

    The Port Numbers registry should accept registrations for SCTP ports
    in the Well Known Ports and Registered Ports ranges.  Well Known and
    Registered Ports SHOULD NOT be used without registration.  Although
    in some cases -- such as porting an application from TCP to SCTP --
    it may seem natural to use a SCTP port before registration  
completes,
    we emphasize that IANA will not guarantee registration of particular
    Well Known and Registered Ports.  Registrations should be requested
    as early as possible.

    Each port registration SHALL include the following information:

    o  A short port name, consisting entirely of letters (A-Z and a-z),
       digits (0-9), and punctuation characters from "-_+./*" (not
       including the quotes).

    o  The port number that is requested to be registered.

    o  A short English phrase describing the port's purpose.

    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 indicating a contact person
       is recommended.

    Registrants are encouraged to follow these guidelines when  
submitting
    a registration.

    o  A port name SHOULD NOT be registered for more than one SCTP port
       number.

    o  A port name registered for TCP MAY be registered for SCTP as  
well.
       Any such registration SHOULD use the same port number as the
       existing TCP registration.

    o  Concrete intent to use a port SHOULD precede port registration.
       For example, existing TCP ports SHOULD NOT be registered in
       advance of any intent to use those ports for SCTP.

    This document registers the following ports.  (These registrations
    should be considered models to follow for future allocation  
requests.)

            discard  9/sctp  Discard  # IETF TSVWG
                                      # Randall Stewart <[e-mail]>
                                      # [draft-ietf-tsvwg-2960bis-05]

            The discard service, which accepts SCTP connections on
            port 9, discards all incoming application data and sends
            no data in response. Thus, SCTP's discard port is analogous
            to TCP's discard port, and might be used to check the
            health of a SCTP stack.

    <add further registrations here>