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

From: Michael Tuexen <[email-masked]>
Date: Tue, 3 Jul 2007 10:46:28 +0200

Hi Lars,

sounds good to me. Just two questions:
1. 2960bis is in the RFC editor queue. How will this change of text  
happen?
2. Do I need to write an ID or RFC to register a port? Or can I just  
contact
    IANA? I'm asking this only for registration of port numbers which  
are
    registered for TCP and/or UDP for a similar service like the discard
    port you use as an example.

Best regards
Michael

On Jun 28, 2007, at 7:53 PM, Lars Eggert wrote:

> 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 <[email-masked]>
>                                      # [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>

---

From: Lars Eggert <[email-masked]>
Date: Tue, 3 Jul 2007 11:53:35 +0300

> 1. 2960bis is in the RFC editor queue. How will this change of text  

It's currently in the "IANA" state, and I asked IANA to hold it there  
until this issue is resolved. Once we have agreed on a procedure, we  
can update the text with an RFC Editor Note.

> 2. Do I need to write an ID or RFC to register a port? Or can I  
> just contact
>    IANA?

No ID needed, the idea is to use "First Come First Served" as an  
allocation policy, similar to UDP and TCP ports. I should probably  
make that explicit in the text.

(Also, note that the process IANA currently uses requires an Expert  
Review. I'm still trying to determine what the rationale for that was  
and if this should be continued. The current proposal does not have  
such an Expert Review stage.)

> I'm asking this only for registration of port numbers which are

Under the current proposal, you don't ever need a draft, whether this  
is for a port number with an existing UDP/TCP registration or for one  
without.

Lars

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 3 Jul 2007 16:02:42 +0200

Hi Lars,

then I'm fine with your proposal.

Best regards
Michael

On Jul 3, 2007, at 10:53 AM, Lars Eggert wrote:

>> 1. 2960bis is in the RFC editor queue. How will this change of  
>> text happen?
>
> It's currently in the "IANA" state, and I asked IANA to hold it  
> there until this issue is resolved. Once we have agreed on a  
> procedure, we can update the text with an RFC Editor Note.
>
> Review. I'm still trying to determine what the rationale for that  
> was and if this should be continued. The current proposal does not  
> have such an Expert Review stage.)
>
> Under the current proposal, you don't ever need a draft, whether  
> this is for a port number with an existing UDP/TCP registration or  
> for one without.
>
> Lars