Subject: [port-srv-reg] -03 draft candidate

From: Stuart Cheshire <[email-masked]>
Date: Thu, 24 Sep 2009 21:29:58 -0700

I plan to check in some changes to draft-ietf-tsvwg-iana-ports, as  
soon as I get write access. Many are just typographical and/or  
spelling mistakes, which I won't waste time describing in great  
depth, unless someone raises an objection. The non-trivial changes  
are described below:

I added some text explaining why relying on port numbers as  
application protocol identifiers is becoming less useful:

> @@ -142,7 +142,7 @@
>        communication. Ports serve two purposes: first, they
>        provide a demultiplexing identifier to differentiate
>        transport sessions between the same pair of endpoints, and
> -      second, they also identify the application protocol and
> +      second, they may also identify the application protocol and
>        associated service to which processes bind.
>        Newer transport protocols, such as the Stream Control
>        Transmission Protocol (SCTP)
> @@ -177,6 +177,43 @@
>        port number registry
>        <xref target="REGISTRY" />.</t>
>
> +      <t>It should be noted that over time the assumption that
> +      a particular port number necessarily implies a particular
> +      service has become less true:</t>
> +
> +      <t>
> +        <list style="symbols">
> +          <t>When different background applications on a single  
> computer
> +          each export a web-based user interface, (e.g. as done by  
> the
> +          Common Unix Printing System <xref target="CUPS" />) they  
> cannot
> +          all get TCP port 80, especially if that computer is also  
> hosting
> +          a conventional web site on TCP port 80. Consequently, a  
> single
> +          host may have several different processes all answering  
> HTTP
> +          requests of various kinds, on ports other than port 80.</t>
> +
> +          <t>When different users are running multiple copies
> +          of the same application on a single computer, multiple
> +          instances of the application cannot listen on the same
> +          port at the same time. Consequently, applications of
> +          this kind need to be programmed to expect that they
> +          may not always be able to get the port they want,
> +          and may have to listen on an alternative port instead.</t>
> +
> +          <t>When different computers in a home are using a NAT  
> gateway
> +          to share a single IP address, the computers can request  
> that
> +          the NAT gateway create port mappings to enable them to  
> receive
> +          inbound connections <xref target="I-D.cheshire-nat-pmp" />,
> +          but they can't all get the same external port at the  
> same time.
> +          Consequently, some applications on some of those computers
> +          may be receiving inbound connections on port other than the
> +          port usually used for the service in question.
> +          As ISPs begin to deploy large-scale NAT, sharing a single
> +          IP address between multiple homes, it is likely to  
> become even
> +          more common to have applications receiving connections on
> +          dynamically allocated ports.</t>
> +        </list>
> +      </t>
> +
>        <t>Applications either use numeric port numbers directly,
>        look up port numbers based on service names via system
>        calls such as getservbyname() on UNIX, look up port numbers
> @@ -1277,6 +1317,7 @@
>        <?rfc include="reference.RFC.4960" ?>
>        <?rfc include="reference.RFC.5237" ?>
>        <?rfc include="reference.I-D.cheshire-dnsext-dns-sd" ?>
> +      <?rfc include="reference.I-D.cheshire-nat-pmp" ?>
>        <?rfc include="reference.I-D.ietf-dccp-serv-codes" ?>
>        <!--     <reference anchor="I-D.touch-tsvwg-port-guidelines">
>         <front>
> @@ -1349,6 +1390,16 @@
>          <seriesInfo name=""
>          value="http://www.trilogy-project.org/" />
>        </reference>
> +
> +      <reference anchor="CUPS" target="http://www.cups.org/">
> +        <front>
> +            <title>Common Unix Printing System</title>
> +            <author initials="" surname="" fullname="">
> +                <organization />
> +            </author>
> +        </front>
> +      </reference>
> +
>      </references>
>    </back>
>  </rfc>

I re-ordered this section into what I thought was a more logical  
order. Registration Owner should come first, since that's not  
changeable. To avoid forward references in the text, I put Service  
Name first, then Port Number, then Transport Protocol.

> @@ -696,53 +733,39 @@
>          <t>
>          <list style="symbols">
>
> -          <t>Registration Technical Contact: Name and
> -          email address of the technical contact person for the
> -          registration. This is REQUIRED. Additional address
> -          information MAY be provided. For registrations done
> -          through IETF-published RFCs, one or more technical
> -          contact persons SHALL be provided.</t>
> -
>            <t>Registration Owner: Name and email
>            address of the owner of the registration. This is
> -          REQUIRED. For individuals, this is the same as the
> -          registration technical contact; for organizations,
> -          this is a point of contact at that organization. For
> +          REQUIRED.  For
>            registrations done through IETF-published RFCs, the
>            registration ownership will belong to the IETF and not
>            the technical contact persons.</t>
>
> -          <t>Transport Protocol: The transport
> -          protocol(s) for which the port number or service name
> -          allocation is requested MUST be provided. This field
> -          is currently limited to one or more of TCP, UDP, SCTP,
> -          and DCCP.</t>
> -
> -          <t>Port Number: If assignment of port
> -          number(s) is desired, either the currently Unassigned
> -          port number(s) the requester suggests for allocation
> -          or the tag "ANY" MUST be provided. If only a service
> -          name is to be assigned, this field MUST be empty. If
> -          specific port numbers are requested, IANA is
> -          encouraged to allocate the suggested numbers. If the
> -          tag "ANY" is specified, IANA will choose a suitable
> -          number from the Registered Ports range. Note that the
> -          applicant MUST NOT use the suggested ports prior to
> -          the completion of the registration.</t>
> +          <t>Registration Technical Contact: Name and
> +          email address of the technical contact person for the
> +          registration. This is REQUIRED.
> +          For individuals, this is the same as the
> +          Registration Owner; for organizations,
> +          this is a point of contact at that organization.
> +          Additional address
> +          information MAY be provided. For registrations done
> +          through IETF-published RFCs, one or more technical
> +          contact persons SHALL be provided.</t>
>
>            <t>Service Name: A desired unique service
>            name for the service associated with the registration
> -          request, for use in various service selection and
> -          discovery mechanisms, MUST be provided. Valid service
> +          request MUST be provided, for use in various service  
> selection and
> +          discovery mechanisms (including, but not limited to,
> +          DNS SRV records <xref target="RFC2782" />). Valid service
>            names MUST only contain these US-ASCII
>            <xref target="ANSI.X3-4.1986" />
>            characters: letters from
>            A to Z, digits from 0 to 9, and hyphens
>            ("-", ASCII 0x2D or decimal 45). They MUST
> -          be at MOST fifteen characters long,
> -          MUST NOT begin or end with a hyphen, and MUST NOT
> -          consist of only digits, in order to be distinguishable from
> -          port numbers. In order to be unique, they
> +          be at least one character and no more than fifteen  
> characters
> +          long, MUST NOT begin or end with a hyphen, and MUST NOT
> +          consist of only digits (in order to be distinguishable from
> +          port numbers, which are typically written as all digits).
> +          In order to be unique, they
>            MUST NOT be identical to any currently registered
>            service names in the IANA registry
>            <xref target="REGISTRY" />.
> @@ -751,6 +774,24 @@
>            clarity), but for the purposes of comparison, the case  
> is ignored.
>            </t>
>
> +          <t>Port Number: If assignment of port
> +          number(s) is desired, either the currently Unassigned
> +          port number(s) the requester suggests for allocation
> +          or the tag "ANY" MUST be provided. If only a service
> +          name is to be assigned, this field MUST be empty. If
> +          specific port numbers are requested, IANA is
> +          encouraged to allocate the suggested numbers. If the
> +          tag "ANY" is specified, IANA will choose a suitable
> +          number from the Registered Ports range. Note that the
> +          applicant MUST NOT use the suggested ports prior to
> +          the completion of the registration.</t>
> +
> +          <t>Transport Protocol: The transport protocol(s) for which
> +          the allocation
> +          is requested MUST be provided. This field
> +          is currently limited to one or more of TCP, UDP, SCTP,
> +          and DCCP.</t>
> +
>            <t>Service Code: A desired unique service
>            code for the service associated with the registration
>            request. Service codes are specific to the DCCP protocol

I updated the section on defining new service names to be a bit more  
explicit, added "sql*net", and stated explicitly what "whois++" becomes.

> @@ -955,22 +996,22 @@
>        was chosen to allow maximum compatibility of service names with
>        current and future service discovery mechanisms.</t>
>
> -      <t>Unfortunately, the current port number registry
> -      <xref target="REGISTRY" />
> -      contains a few assigned service names that do not conform to  
> the
> -      new naming rules. In all cases, this is because they contain
> -      illegal characters such as asterisks, dots, plusses, slashes,
> -      or underscores. (All current service names conform to the  
> length
> -      requirement of 15 characters or less.)</t>
> -
> -      <t>Upon approval of this document, IANA SHALL take immediate
> -      actions to resolve these inconsistencies. For any registry
> -      assignment with an illegal service name, IANA SHALL
> +      <t>As of 5th August 2009 approximately 98% of the so-called
> +      "Short Names" from existing port number registrations
> +      <xref target="REGISTRY" /> meet the rules for legal service  
> names
> +      stated in <xref target="registration" />, and hence will be  
> used
> +      unmodified.</t>
> +
> +      <t>The remaining approximately 2% of the exiting "Short  
> Names" are not
> +      suitable to be used directly as well-formed service names  
> because they
> +      contain illegal characters such as asterisks, dots, plusses,  
> slashes,
> +      or underscores. All existing "Short Names" conform to the  
> length
> +      requirement of 15 characters or less. For these unsuitable
> +      "Short Names", listed in the table below, the service name  
> will be the
> +      Short Name with any illegal characters replaced by hyphens.  
> IANA SHALL
>        add an alias to the registry that assigns a well-formed service
>        name for the existing service but otherwise duplicates the
> -      original assignment information. It is desirable if the alias
> -      closely resembles the original service name, e.g., by remapping
> -      underscores to dashes, etc.
> +      original assignment information.
>        In the description field of the
>        new alias, IANA SHALL record that it assigns a well-formed  
> service
>        name for the previous service and point to the original  
> assignment.
> @@ -979,18 +1020,10 @@
>        many common service discovery mechanisms, and provide a  
> reference
>        to the new alias, which can be used in this way.</t>
>
> -      <t>As of 2009-8-5 <xref target="REGISTRY" />, these service  
> names
> -      were illegal under the rules stated in
> -      <xref target="registration" />:</t>
> +      <t>Names containing illegal characters to be replaced by  
> hyphens:</t>
>
>  	<texttable><ttcol/><ttcol/><ttcol/>
> -
>  <c>914c/g	  </c>
> -<c>EtherNet/IP-1  </c>
> -<c>EtherNet/IP-2  </c>
> -<c>LiebDevMgmt_A  </c>
> -<c>LiebDevMgmt_C  </c>
> -<c>LiebDevMgmt_DM </c>
>  <c>acmaint_dbd	  </c>
>  <c>acmaint_transd </c>
>  <c>atex_elmd	  </c>
> @@ -1026,6 +1059,8 @@
>  <c>erunbook_agent </c>
>  <c>erunbook_server</c>
>  <c>esri_sde	  </c>
> +      <c>EtherNet/IP-1</c>
> +      <c>EtherNet/IP-2</c>
>  <c>event_listener </c>
>  <c>flr_agent	  </c>
>  <c>gds_db	  </c>
> @@ -1040,6 +1075,9 @@
>  <c>intel_rci	  </c>
>  <c>interhdl_elmd  </c>
>  <c>lan900_remote  </c>
> +      <c>LiebDevMgmt_A</c>
> +      <c>LiebDevMgmt_C</c>
> +      <c>LiebDevMgmt_DM</c>
>  <c>mapper-ws_ethd </c>
>  <c>matrix_vnet	  </c>
>  <c>mdbs_daemon	  </c>
> @@ -1070,6 +1108,7 @@
>  <c>sge_execd	  </c>
>  <c>sge_qmaster	  </c>
>  <c>shiva_confsrvr </c>
> +      <c>sql*net</c>
>  <c>srvc_registry  </c>
>  <c>stm_pproc	  </c>
>  <c>subntbcst_tftp </c>
> @@ -1078,11 +1117,12 @@
>  <c>veritas_pbx	  </c>
>  <c>vision_elmd	  </c>
>  <c>vision_server  </c>
> -<c>whois++	  </c>
>  <c>wrs_registry	  </c>
>  <c>z39.50	  </c>
>  </texttable>
>
> +      <t>In the case of "whois++", the service name will be  
> "whoisplusplus".</t>
> +
>        </section>
>
>         <section anchor="sctpdccpexp"

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Sep 2009 21:04:24 -0700

HiStuart,

I generally agree with the changes suggested, except as below.

Stuart Cheshire wrote:
> I plan to check in some changes to draft-ietf-tsvwg-iana-ports, as soon
> as I get write access. Many are just typographical and/or spelling
> mistakes, which I won't waste time describing in great depth, unless
> someone raises an objection. The non-trivial changes are described below:
> 
...
>> +      service has become less true:</t>

If it is true, it needs a citation. If there is no citation, I'd suggest
dropping this.

>> +
>> +      <t>
>> +        <list style="symbols">
>> +          <t>When different background applications on a single computer
>> +          each export a web-based user interface, (e.g. as done by the
>> +          a conventional web site on TCP port 80. Consequently, a single
>> +          host may have several different processes all answering HTTP

HTTP is a format for messages, but doesn't necessarily imply an
application service or application protocol. There are many systems that
use HTTP formatting for a variety of services, defined by the particular
HTTP messages exchanged.

The same has been true for ASCII command-line interfaces; they all could
run over telnet, but they back onto different application services. This
does not validate the idea that the protocol is any less a new service,
just because it uses a web engine for its implementation or HTML for its
markup.

I'm not clear on why this is relevant; it appears to suggest that
computers are increasingly using the same service on different ports,
but I don't see that as the case.

>> +          and may have to listen on an alternative port instead.</t>

There are a small number of assigned alternative ports as well. However,
it is also increasingly common that such services are virtualized,
sending one of a number of DNS names that resolve to the same IP address
inside the command (as with HTTP 1.1) or running copies of a service on
different IP addresses on the same machine.

I.e., I agree that this may be true, but this is basically saying "when
you can't run on a registered port, there are problems" - which are
either solved by using a backup registered port, or are unsolvable.

>> +          <t>When different computers in a home are using a NAT gateway
>> +          to share a single IP address, the computers can request that
>> +          the NAT gateway create port mappings to enable them to receive
>> +          but they can't all get the same external port at the same
>> time.
>> +          IP address between multiple homes, it is likely to become even

The focus of the document is registered names and numbers. It's true
that NATs defeat that, but what's the reason for discussing that in this
doc?

Joe