One document matched: draft-ietf-tsvwg-iana-ports-09.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc comments="yes" ?>
<?rfc compact="yes"?>
<!--<?rfc editing="yes"?>-->
<?rfc inline="yes"?>
<?rfc strict="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?rfc tocompact="yes"?>
<rfc category="bcp" docName="draft-ietf-tsvwg-iana-ports-09"
ipr="pre5378Trust200902" updates="2780, 2782, 3828, 4340, 4960">
<front>
<title abbrev="Service Name and Port Number Procedures">Internet Assigned
Numbers Authority (IANA) Procedures for the Management of the Service Name
and Transport Protocol Port Number Registry</title>
<author fullname="Michelle Cotton" initials="M." surname="Cotton">
<organization abbrev="ICANN">Internet Corporation for Assigned Names and
Numbers</organization>
<address>
<postal>
<street>4676 Admiralty Way, Suite 330</street>
<code>90292</code>
<city>Marina del Rey</city>
<region>CA</region>
<country>USA</country>
</postal>
<phone>+1 310 823 9358</phone>
<email>michelle.cotton@icann.org</email>
<uri>http://www.iana.org/</uri>
</address>
</author>
<author fullname="Lars Eggert" initials="L." surname="Eggert">
<organization abbrev="Nokia">Nokia Research Center</organization>
<address>
<postal>
<street>P.O. Box 407</street>
<code>00045</code>
<city>Nokia Group</city>
<country>Finland</country>
</postal>
<phone>+358 50 48 24461</phone>
<email>lars.eggert@nokia.com</email>
<uri>http://research.nokia.com/people/lars_eggert/</uri>
</address>
</author>
<author fullname="Joe Touch" initials="J." surname="Touch">
<organization>USC/ISI</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<code>90292</code>
<city>Marina del Rey</city>
<region>CA</region>
<country>USA</country>
</postal>
<phone>+1 310 448 9151</phone>
<email>touch@isi.edu</email>
<uri>http://www.isi.edu/touch</uri>
</address>
</author>
<author fullname="Magnus Westerlund" initials="M." surname="Westerlund">
<organization>Ericsson</organization>
<address>
<postal>
<street>Farogatan 6</street>
<city>Stockholm</city>
<code>164 80</code>
<country>Sweden</country>
</postal>
<phone>+46 8 719 0000</phone>
<email>magnus.westerlund@ericsson.com</email>
</address>
</author>
<author fullname="Stuart Cheshire" initials="S." surname="Cheshire">
<organization abbrev="Apple">Apple Inc.</organization>
<address>
<postal>
<street>1 Infinite Loop</street>
<code>95014</code>
<city>Cupertino</city>
<region>CA</region>
<country>USA</country>
</postal>
<phone>+1 408 974 3207</phone>
<email>cheshire@apple.com</email>
</address>
</author>
<date year="2010" />
<area>Transport Area</area>
<workgroup>Transport Area Working Group</workgroup>
<keyword>IANA</keyword>
<keyword>transport</keyword>
<keyword>ports</keyword>
<keyword>port numbers</keyword>
<keyword>allocation</keyword>
<keyword>assignment</keyword>
<keyword>procedures</keyword>
<abstract>
<t>This document defines the procedures that the Internet Assigned
Numbers Authority (IANA) uses when handling assignment and other
requests related to the Service Name and Transport Protocol Port Number
Registry. It also discusses the rationale and principles behind these
procedures and how they facilitate the long-term sustainability of the
registry.</t>
<t>This document updates IANA's procedures by obsoleting the
previous UDP and TCP port assignment procedures defined in
Sections 8 and 9.1 of the IANA allocation guidelines [RFC2780],
and it updates the IANA Service Name and Port assignment
procedures for UDP-Lite [RFC3828], DCCP [RFC4340] and SCTP
[RFC4960]. It also updates the DNS SRV specification [RFC2782] to
clarify what a service name is and how it is registered.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>For many years, the assignment of new service names and port number
values for use with the Transmission Control Protocol (TCP) <xref
target="RFC0793"></xref> and the User Datagram Protocol (UDP) <xref
target="RFC0768"></xref> have had less than clear guidelines. New
transport protocols have been added - the Stream Control Transmission
Protocol (SCTP) <xref target="RFC4960"></xref> and the Datagram
Congestion Control Protocol (DCCP) <xref target="RFC4342"></xref> - and
new mechanisms like DNS SRV records <xref target="RFC2782"></xref> have
been developed, each with separate registries and separate guidelines.
The community also recognized the need for additional procedures beyond
just assignment; notably modification, revocation, and release.</t>
<t>A key element of the procedural streamlining specified in this
document is to establish identical assignment procedures for all IETF
transport protocols. This document brings the IANA procedures for TCP
and UDP in line with those for SCTP and DCCP, resulting in a single
process that requesters and IANA follow for all requests for all
transport protocols, including future protocols not yet defined.</t>
<t>In addition to detailing the IANA procedures for the initial
assignment of service names and port numbers, this document also
specifies post-assignment procedures that until now have been handled in
an ad hoc manner. These include procedures to de-assign a port number
that is no longer in use, to take a port number assigned for one
service that is no longer in use and reuse it for another service, and the
procedure by which IANA can unilaterally revoke a prior port number
assignment. <xref target="iana-procedures"></xref> discusses the
specifics of these procedures and processes that requesters and IANA
follow for all requests for all current and future transport
protocols.</t>
<t>IANA is the authority for assigning service names and port numbers.
The registries that are created to store these assignments are
maintained by IANA. For protocols developed by IETF working groups, IANA
now also offers a method for the "early assignment" <xref
target="RFC4020"></xref> of service names and port numbers, as described
in <xref target="assignment"></xref>.</t>
<t>This document updates IANA's procedures for UDP and TCP port numbers
by obsoleting Sections 8 and 9.1 of the IANA assignment guidelines <xref
target="RFC2780"></xref>. (Note that other sections of the IANA
assignment guidelines, relating to the protocol field values in IPv4
header, were also updated in February 2008 <xref
target="RFC5237"></xref>.) This document also updates the IANA
assignment procedures for DCCP <xref target="RFC4340"></xref> and SCTP
<xref target="RFC4960"></xref>.</t>
<t>The Lightweight User Datagram Protocol (UDP-Lite) shares the port space
with UDP. The UDP-Lite specification <xref target="RFC5237"></xref> says:
"UDP-Lite uses the same set of port number values
assigned by the IANA for use by UDP". Thus the update of UDP procedures
result in an update also of the UDP-Lite procedures.</t>
<t>This document also clarifies what a service name is and how it is
assigned. This will impact the DNS SRV specification <xref
target="RFC2782"></xref>, because that specification merely makes a
brief mention that the symbolic names of services are defined in
"Assigned Numbers" <xref target="RFC1700"></xref>, without stating to
which section it refers within that 230-page document. The DNS SRV
specification may have been referring to the list of Port Assignments
(known as /etc/services on Unix), or to the "Protocol And Service Names"
section, or to both, or to some other section. Furthermore, "Assigned
Numbers" is now obsolete <xref target="RFC3232"></xref> and has been
replaced by on-line registries <xref target="PORTREG"></xref><xref
target="PROTSERVREG"></xref>.<!--There are
additional updates and clarifications on how DNS SRV utilize the
Service name registry created in this document in
"Clarification of DNS SRV Owner Names"
<xref target="I-D.gudmundsson-dnsext-srv-clarify"/>.--></t>
<t>The development of new transport protocols is a major effort that the
IETF does not undertake very often. If a new transport protocol is
standardized in the future, it is expected to follow these guidelines and practices around using service names
and port numbers as
much as possible, for consistency.</t>
</section>
<section anchor="motivation" title="Motivation">
<t>Information about the assignment procedures for the port registry
has existed in three locations: the forms for requesting port number
assignments on the IANA web site <xref target="SYSFORM"></xref><xref
target="USRFORM"></xref>, an introductory text section in the file
listing the port number assignments themselves (known as the port numbers registry) <xref
target="PORTREG"></xref>, and two brief sections of the IANA Allocation
Guidelines <xref target="RFC2780"></xref>.</t>
<t>Similarly, the procedures surrounding service names have been
historically unclear. Service names were originally created as mnemonic
identifiers for port numbers without a well-defined syntax, apart from the
14-character limit mentioned on the IANA website <xref
target="SYSFORM"></xref><xref target="USRFORM"></xref>. Even that
length limit has not been consistently applied, and some assigned
service names are 15 characters long. When service identification via
DNS SRV Resource Records (RRs) was introduced <xref target="RFC2782"></xref>,
it became useful to start assigning service names alone, and because IANA
had no procedure for assigning a service name without an
associated port number, this lead to the creation of an informal temporary service name registry outside of the
control of IANA, which now
contains roughly 500 service names <xref target="SRVREG"></xref>.</t>
<!--
This text duplicates what's said elsewhere in the document.
I also don't think that RFC 0952 (DOD INTERNET HOST TABLE SPECIFICATION)
sheds any light on this issue. - SC
<t>It has also been historically unclear if the "name" entries registered
in the "Protocol and Service Names Registry" <xref target="PROTSERVREG"/>
can be used as service names. <xref target="RFC0952"/> defines the names
in that registry as either service names or protocol names. It is possible that
some of these names may have been interpreted as being valid service names and
consequently have been used, e.g., in SRV records. This motivates why
this document merges the 166 protocol and service names defined in that
registry into the service name and transport protocol port number registry
<xref target="PORTREG"/>.</t>
-->
<t>This document aggregates all this scattered information into a single
reference that aligns and clearly defines the management procedures for
both service names and port numbers. It gives more detailed guidance to
prospective requesters of service names and ports than the existing
documentation, and it streamlines the IANA procedures for the management
of the registry, so that requests can be completed in a timely manner.</t>
<t>This document defines rules for assignment of service names without
associated port numbers, for such usages as DNS SRV records <xref
target="RFC2782"></xref>, which was not possible under the previous IANA
procedures. The document also merges service name assignments from the
non-IANA ad hoc registry <xref target="SRVREG"></xref> and from the IANA
"Protocol and Service Names" registry <xref target="PROTSERVREG"></xref>
into the IANA "Service Name and Transport Protocol Port Number" registry
<xref target="PORTREG"></xref>, which from here on is the single
authoritative registry for service names and port numbers.</t>
<t>An additional purpose of this document is to describe the principles
that guide the IETF and IANA in their role as the long-term joint
stewards of the service name and port number registry. TCP and UDP have
had remarkable success over the last decades. Thousands of applications
and application-level protocols have service names and ports assigned
for their use, and there is every reason to believe that this trend will
continue into the future. It is hence extremely important that
management of the registry follow principles that ensure its long-term
usefulness as a shared resource. <xref target="principles"></xref>
discusses these principles in detail.<!-- Commented this out until we know what Joe's doc will actually say.
Guidelines for users seeking port numbers and/or service names, as well
as a detailed history of the port number registry and alternate means for
coordinating host agreement on service-to-port-number mappings, is
provided in a <xref target="I-D.touch-tsvwg-port-guidelines">companion
document</xref>.--></t>
</section>
<section anchor="background" title="Background">
<t>The Transmission Control Protocol (TCP) <xref
target="RFC0793"></xref> and the User Datagram Protocol (UDP) <xref
target="RFC0768"></xref> have enjoyed a remarkable success over the
decades as the two most widely used transport protocols on the Internet.
They have relied on the concept of "ports" as logical entities for
Internet communication. Ports serve two purposes: first, they provide a
demultiplexing identifier to differentiate transport sessions between
the same pair of endpoints, and second, they may also identify the
application protocol and associated service to which processes connect.
Newer transport protocols, such as the Stream Control Transmission
Protocol (SCTP) <xref target="RFC4960"></xref> and the Datagram
Congestion Control Protocol (DCCP) <xref target="RFC4342"></xref> have
also adopted the concept of ports for their communication sessions and
use 16-bit port numbers in the same way as TCP and UDP (and
UDP-Lite <xref target="RFC3828"></xref>, a variant of UDP).</t>
<t>Port numbers are the original and most widely used means for
application and service identification on the Internet. Ports are
16-bit numbers, and the combination of source and destination port
numbers together with the IP addresses of the communicating end systems
uniquely identifies a session of a given transport protocol. Port
numbers are also known by their associated service names such as
"telnet" for port number 23 and "http" (as well as "www" and "www-http")
for port number 80.</t>
<t>Hosts running services, hosts accessing services on other hosts, and
intermediate devices (such as firewalls and NATs) that restrict services
need to agree on which service corresponds to a particular destination
port. Although this is ultimately a local decision with meaning only
between the endpoints of a connection, it is common for many services to
have a default port upon which those servers usually listen, when
possible, and these ports are recorded by the Internet Assigned Numbers
Authority (IANA) through the service name and port number registry <xref
target="PORTREG"></xref>.</t>
<t>Over time, the assumption that a particular port number necessarily
implies a particular service may become less true. For example, multiple
instances of the same service on the same host cannot generally listen
on the same port, and multiple hosts behind the same NAT gateway cannot
all have a mapping for the same port on the external side of the NAT
gateway, whether using static port mappings configured by hand by the
user, or dynamic port mappings configured automatically using a port
mapping protocol like <xref target="I-D.cheshire-nat-pmp">NAT Port
Mapping Protocol (NAT-PMP) </xref> or <xref target="IGD">Internet
Gateway Device (IGD)</xref>.</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"/><xref
target="IGD"/>, 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 assigned ports.</t>
</list></t>
-->
<t>Applications may use port numbers directly, look up port
numbers based on service names via system calls such as getservbyname()
on UNIX, look up port numbers by performing queries for DNS SRV records
<xref target="RFC2782"></xref><xref
target="I-D.cheshire-dnsext-dns-sd"></xref>, or determine port numbers
in a variety of other ways like the TCP Port Service Multiplexer
(TCPMUX) <xref target="RFC1078"></xref>.</t>
<t>Designers of applications and application-level protocols may apply
to IANA for an assigned service name and port number for a specific
application, and may - after assignment - assume that no
other application will use that service name or port number for its
communication sessions. Alternatively, application designers may also
ask for only an assigned service name, if their application does not
require a fixed port number. The latter alternative is encouraged when
possible, in order to conserve the more limited port number space. This
is applicable, for example, to applications that use DNS SRV records to
look up port numbers at runtime.</t>
<!--
There have been many proposals over the years for putting names
instead of numbers into the TCP header. I think it's
inappropriate to list one such proposal here if we're not going
to list all the others too.
, or transports that use service names not coupled
to port numbers, e.g., TCP portnames
<xref target="I-D.touch-tcp-portnames"/>
-->
</section>
<section anchor="term" title="Conventions Used in this Document">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in "Key words for use in
RFCs to Indicate Requirement Levels" <xref target="RFC2119"></xref>.</t>
<t>This document uses the term "assignment" to refer to the procedure
by which IANA provides service names and/or port numbers to requesting
parties; other RFCs refer to this as "allocation" or "registration".
This document assumes that all these terms have the same meaning, and will use terms other than "assignment" when quoting from or referring to text in these other documents.</t>
</section>
<section anchor="srvname" title="Service Names">
<t>Service names are the unique key in the Service Name and Transport
Protocol Port Number Registry. This unique symbolic name for a service
may also be used for other purposes, such as in <xref
target="RFC2782">DNS SRV records</xref>. Within the registry, this
unique key ensures that different services can be unambiguously
distinguished, thus preventing name collisions and avoiding confusion
about who is the Assignee for a particular entry.</t>
<t>There may be more than one service name associated with a particular
transport protocol and port. There are three ways that such port number
overloading can occur: <list style="symbols">
<t>Overloading occurs when one service is an extension of another
service, and an in-band mechanism exists for determining if the
extension is present or not. One example is port 3478, which has the
service name aliases "stun" and "turn". TURN <xref
target="RFC5766"></xref> is an extension to the STUN <xref
target="RFC5389"></xref> service. TURN-enabled clients wishing to
locate TURN servers could attempt to discover "stun" services and
then check in-band if the server also supports TURN, but this would be
inefficient. Enabling them to directly query for "turn" servers by
name is a better approach. (Note that TURN servers in this case
should also be locatable via a "stun" discovery, because every TURN
server is also a STUN server.)</t>
<t>By historical accident, the service name "http" has two synonyms
"www" and "www-http". When used in SRV records <xref
target="RFC2782"></xref> and similar service discovery mechanisms,
only the service name "http" should be used, not these additional
names. If a
server were to advertise "www", it would not be discovered by
clients browsing for "http". Advertising or browsing for the aliases
as well as the primary service name is inefficient, and
achieves nothing that is not already achieved by using the service
name "http" exclusively.</t>
<t>As indicated in this document in
<xref target="consistency"></xref>, overloading has been used to
create replacement
names that are consistent with the
syntax this document prescribes for legacy names that do not conform
to this syntax already. For such cases, only the
new name should be used in SRV records, to avoid
the same issues as with historical cases of multiple names,
and also because the legacy names are incompatible with
SRV record use.</t>
</list> For future assignments, applications will not be permitted
that merely request a new name exactly duplicating an existing service.
Having multiple names for the same service serves no purpose.
Implementers are requested to inform IANA if they discover other cases
where a single service has multiple names, so that one name may be
recorded as the primary name for service discovery purposes.</t>
<t>Service names are assigned on a "first come, first served" basis, as
described in <xref target="assignment"></xref>. Names should be brief
and informative, avoiding words or abbreviations that are redundant in
the context of the registry (e.g., "port", "service", "protocol", etc.)
Names referring to discovery services, e.g., using multicast or
broadcast to identify endpoints capable of a given service, SHOULD use
an easily identifiable suffix (e.g., "-disc").</t>
<section anchor="sec-syntax" title="Service Name Syntax">
<t>Valid service names are hereby normatively defined as follows:
<list style="symbols">
<t>MUST be at least 1 character and no more than 15 characters
long</t>
<t>MUST contain only US-ASCII <xref
target="ANSI.X3-4.1986"></xref> letters 'A' - 'Z' and 'a' - 'z',
digits '0' - '9', and hyphens ('-', ASCII 0x2D or decimal 45)</t>
<t>MUST contain at least one letter ('A' - 'Z' or 'a' - 'z')</t>
<t>MUST NOT begin or end with a hyphen</t>
<t>hyphens MUST NOT be adjacent to other hyphens</t>
</list></t>
<t>The reason for requiring at least one letter is to avoid service
names like "23" (could be confused with a numeric port) or
"6000-6063" (could be confused with a numeric port range).
Although service names may contain both upper-case and lower-case
letters, case is ignored for comparison purposes, so both "http" and
"HTTP" denote the same service.</t>
<t>Service names are purely opaque identifiers, and no semantics are
implied by any superficial structure that a given service name may
appear to have. For example, a company called "Example" may choose to
register service names "Example-Foo" and "Example-Bar" for its "Foo"
and "Bar" products, but the "Example" company cannot claim to "own" all
service names beginning with "Example-"; they cannot prevent someone
else from registering "Example-Baz" for a different service, and they cannot
prevent other developers from using the "Example-Foo" and
"Example-Bar" service types in order to interoperate with the "Foo"
and "Bar" products. Technically speaking, in service discovery
protocols, service names are merely a series of byte values on the
wire; for the mnemonic convenience of human developers it can be
convenient to interpret those byte values as human-readable ASCII
characters, but software should treat them as purely opaque
identifiers and not attempt to parse them for any additional embedded
meaning.</t>
<t>In approximately 98% of cases, the new "service name" is exactly
the same as the old historic "short name" from the IANA web forms
<xref target="SYSFORM"></xref> <xref target="USRFORM"></xref>. In
approximately 2% of cases, the new "service name" is derived from the
old historic "short name" as described below in <xref
target="consistency"></xref>.</t>
<t>The rules for valid service names, excepting the limit of 15 characters
maximum, are also expressed below (as a non-normative convenience) using
<xref target="RFC5234">ABNF</xref>.</t>
<figure>
<artwork><![CDATA[
SRVNAME = *(1*DIGIT [HYPHEN]) ALPHA *([HYPHEN] ALNUM)
ALNUM = ALPHA / DIGIT ; A-Z, a-z, 0-9
HYPHEN = %x2d ; "-"
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z [RFC5234]
DIGIT = %x30-39 ; 0-9 [RFC5234]
]]></artwork>
</figure>
</section>
<section title="Service Name Usage in DNS SRV Records">
<t>The DNS SRV specification <xref target="RFC2782"></xref> states
that the Service Label part of the owner name of a DNS SRV record
includes a "Service" element, described as "the symbolic name of the
desired service", but as discussed above, it is not clear precisely
what this means.</t>
<t>This document clarifies that the Service Label MUST be a service
name as defined herein with an underscore prepended.
The service name SHOULD be registered with
IANA and recorded in the Service Name and Transport Protocol Port
Number Registry <xref target="PORTREG"></xref>.</t>
<t>The details of using Service Names in SRV Service Labels are
specified in the DNS SRV specification <xref target="RFC2782"></xref>.
This document does not change that specification.</t>
</section>
</section>
<section anchor="types" title="Port Number Ranges">
<t>TCP, UDP, UDP-Lite, SCTP and DCCP use 16-bit namespaces for
their port number registries. The port registries for all these
transport protocols are subdivided into three ranges of numbers, and
<xref target="variances"></xref> describes the IANA procedures for each
range in detail: <list style="symbols">
<t>the System Ports, also known as the Well Known Ports, from 0-1023
(assigned by IANA)</t>
<t>the User Ports, also known as the Registered Ports, from
1024-49151 (assigned by IANA)</t>
<t>the Dynamic Ports, also known as the Private Ports, from
49152-65535 (never assigned)</t>
</list></t>
<t>Of the assignable port ranges (System Ports and User Ports, i.e.,
port numbers 0-49151), individual port numbers are in one of three
states at any given time:</t>
<t><list style="symbols">
<t>Assigned: Assigned port numbers are currently assigned to the
service indicated in the registry.</t>
<t>Unassigned: Unassigned port numbers are currently available for
assignment upon request, as per the procedures outlined in this
document.</t>
<t>Reserved: Reserved port numbers are not available for regular
assignment; they are "assigned to IANA" for special purposes.
Reserved port numbers include values at the edges of each range,
e.g., 0, 1023, 1024, etc., which may be used to extend these ranges
or the overall port number space in the future.</t>
</list></t>
<t>In order to keep the size of the registry manageable, IANA typically
only records the Assigned and Reserved service names and port numbers in
the registry. Unassigned values are typically not explicitly listed.
(There are a near-infinite number of Unassigned service names and
enumerating them all would not be practical.)</t>
<t>As a data point, when this document was written, approximately 76% of
the TCP and UDP System Ports were assigned, and approximately 9% of the
User Ports were assigned. (As noted, Dynamic Ports are never
assigned.)</t>
<section anchor="udptcpexp"
title="Service names and Port Numbers for Experimentation">
<t>Of the System Ports, two TCP and UDP port numbers (1021 and 1022),
together with their respective service names ("exp1" and "exp2"), have
been assigned for experimentation with new applications and
application-layer protocols that require a port number in the assigned
ports ranges <xref target="RFC4727"></xref>.</t>
<t>Please refer to Sections 1 and 1.1 of "Assigning Experimental and
Testing Numbers Considered Useful" <xref target="RFC3692"></xref> for
how these experimental port numbers are to be used.<!-- I still think this could be useful to explicitly repeat - Lars
Specifically, they
SHOULD only be used for local experiments in controlled environments,
and they SHOULD NOT be used on the global Internet. Many new
applications and application-layer protocols can be experimented with
without requiring a port in the System or User ports range,
by using port numbers in the Dynamic Ports range. --></t>
<t>This document assigns the same two service names and port numbers
for experimentation with new application-layer protocols over SCTP and
DCCP in <xref target="sctpdccpexp"></xref>.</t>
<t>Unfortunately, it can be difficult to limit access to these ports.
Users SHOULD take measures to ensure that experimental ports are
connecting to the intended process. For example, users of these
experimental ports might include a 64-bit nonce, once on each segment
of a message-oriented channel (e.g., UDP), or once at the beginning of
a byte-stream (e.g., TCP), which is used to confirm that the port is
being used as intended. Such confirmation of intended use is
especially important when these ports are associated with privileged
(e.g., system or administrator) processes.</t>
</section>
</section>
<section anchor="principles"
title="Principles for Service Name and Transport Protocol Port Number Registry Management">
<t>Management procedures for the service name and transport protocol
port number registry include assignment of service names and port
numbers upon request, as well as management of information about
existing assignments. The latter includes maintaining contact and
description information about assignments, revoking abandoned
assignments, and redefining assignments when needed. Of these
procedures, careful port number assignment is most critical, in order to
continue to conserve the remaining port numbers.</t>
<t>As noted earlier, only about 9% of the User Port space is currently
assigned. The current rate of assignment is approximately 400 ports per
year, and has remained steady for the past 8 years. At that rate, if
similar conservation continues, this resource will sustain another 85
years of assignment - without the need to resort to reassignment of
released values or revocation. The namespace available for service names
is much larger, which allows for simpler management procedures.</t>
<section title="Past Principles">
<t>The principles for service
name and port number management are based on the recommendations
of the IANA "Expert Review" team. Until recently, that team followed a set of informal guidelines
developed based on the review experience from previous assignment requests. These original guidelines,
although informal, had never been publicly documented.
They are recorded here for historical purposes only; the current guidelines are described in <xref target="upprinc"></xref>.
These guidelines previously were:</t>
<t><list style="symbols">
<t>TCP and UDP ports were simultaneously assigned when either was
requested</t>
<t>Port numbers were the primary assignment; service names were
informative only, and did not have a well-defined syntax</t>
<t>Port numbers were conserved informally, and sometimes
inconsistently (e.g., some services were assigned ranges of many
port numbers even where not strictly necessary)</t>
<t>SCTP and DCCP service name and port number registries were
managed separately from the TCP/UDP registries</t>
<t>Service names could not be assigned in the old ports registry
without assigning an associated port number at the same time</t>
</list> <!-- This document describes the current management guidelines, which
manage the limited remaining port number space more conservatively
and enable and promote the use of service names for service
identification without associated port numbers, where possible. Please
note that these guidelines are provided only to describe the current
practices of the "Expert Review" team; that team is not bound to only these
guidelines, and IANA is not bound to follow the recommendations of the Expert Review team in all cases.-->
</t>
<!--
<t>Port numbers are intended to identify a service and
enable process demultiplexing at an endpoint; uses beyond
those basic requirements should be avoided
<xref target="I-D.touch-tsvwg-port-guidelines"/>. This
document also focuses on service names as a unique identifier,
to increase the space available (from 4 bytes to 14), and to
enable their use in the absence of associated port number
assignments.
<cref source="Lars" anchor="incr-space">I don't understand
where the "extend from 4 bytes to 14" bit comes
from.</cref></t>
-->
</section>
<section anchor="upprinc" title="Updated Principles">
<t>This section summarizes the current principles by which IANA handles
the Service Name and Transport Protocol Port Number Registry and
attempts to conserve the port number space. This description is
intended to inform applicants requesting service names and port
numbers. IANA has flexibility beyond these principles
when handling assignment requests; other factors may come into play,
and exceptions may be made to best serve the needs of the Internet.</t>
<t>IANA strives to assign service names that do not request an
associated port number assignment under a simple "First Come, First
Served" policy <xref target="RFC5226"></xref>. IANA MAY, at its
discretion, refer service name requests to "Expert Review" in cases of
mass assignment requests or other situations where IANA believes expert
review is advisable.</t>
<t>The basic principle of service name and port number registry
management is to conserve use of the port space where possible.
Extensions to support larger port number spaces would require changing
many core protocols of the current Internet in a way that would not be
backward compatible and interfere with both current and legacy
applications. To help ensure this conservation the policy for any
assignment request for port number assignments uses the "Expert
Review" policy <xref target="RFC5226"></xref>.</t>
<t>Conservation of the port number space is required because this
space is a limited resource, so applications are expected to
participate in the traffic demultiplexing process where feasible. The
port numbers are expected to encode as little information as possible that will
<?rfc needLines="18" ?>
still enable an application to perform further
demultiplexing by itself. In particular, the principles form a goal that IANA strives to achieve
for new applications (with exceptions as deemed appropriate, especially as for
extensions to legacy services) as follows:</t>
<t><list style="symbols">
<t>IANA strives to assign only one assigned port number per service or
application</t>
<t>IANA strives to assign only one assigned port number for all
variants of a service (e.g., for updated versions of a service)</t>
<t>IANA strives to encourage the deployment of secure protocols,
and so strives to avoid separate assignments for non-secure
variants</t>
<t>IANA strives to assign only one assigned port number for all
different types of device using or participating in the same
service</t>
<t>IANA strives to assign port numbers only for the transport
protocol(s) explicitly named in an assignment request</t>
<t>IANA may recover unused port numbers, via the new procedures of
de-assignment, revocation, and transfer</t>
</list> Where possible, a given service is expected to demultiplex
messages if necessary. For example, applications and protocols are
expected to include in-band version information, so that future
versions of the application or protocol can share the same assigned
port. Applications and protocols are also expected to be able to
efficiently use a single assigned port for multiple sessions, either
by demultiplexing multiple streams within one port, or using the
assigned port to coordinate using dynamic ports for subsequent
exchanges (e.g., in the spirit of FTP <xref
target="RFC0959"></xref>).</t>
<!-- Removed until doc is available:
These principles of port conservation are explained in
<xref target="I-D.touch-tsvwg-port-guidelines"/>.
That document explains in further detail how -->
<t>Ports are used in various ways, notably:</t>
<t><list style="symbols">
<t>as endpoint process identifiers</t>
<t>as application protocol identifiers</t>
<t>for firewall filtering purposes</t>
</list> Both the process identifier and the protocol identifier uses
suggest that anything a single process can demultiplex, or that can be
encoded into a single protocol, should be. The firewall filtering use
suggests that some uses that could be multiplexed or encoded could
instead be separated to allow for easier firewall management. Note
that this latter use is much less sound, because port numbers have
meaning only for the two endpoints involved in a connection, and
drawing conclusions about the service that generated a given flow
based on observed port numbers is not always reliable. <!-- (again, as discussed in detail in
<xref target="I-D.touch-tsvwg-port-guidelines"/>).--> Further,
the previous practice of separating protocol variants based on security
capabilities (e.g., HTTP on TCP port 80 vs. HTTPS on TCP port 443) is
not recommended for new protocols, because all new protocols should be
security-capable.</t>
<t>IANA will begin assigning port numbers for only those transport
protocols explicitly included in an assignment request. This ends the
long-standing practice of automatically assigning a port number to an
application for both TCP and a UDP, even if the request is for only
one of these transport protocols. The new assignment procedure
conserves resources by assigning a port number to an application for
only those transport protocols (TCP, UDP, SCTP and/or DCCP) it
actually uses. The port number will be marked as Reserved - instead of
Assigned - in the port number registries of the other transport
protocols. When applications start supporting the use of some of those
additional transport protocols, the Assignee for the
assignment MUST request IANA convert these reserved ports into
assignments. An application MUST NOT assume that it can use a
port number assigned to it for use with one transport protocol with
another transport protocol without asking IANA to convert the
reserved ports into an assignment.</t>
<t>When the available pool of unassigned numbers has run out in a
ports range, it will be necessary for IANA to consider the Reserved
ports for assignment. This is part of the motivation for not
automatically assigning ports for transport protocols other than the
requested one(s). This will allow more ports to be available for
assignment when that time comes. To help conserve ports, application
developers should request assignment of only the transport protocols that their
application currently uses.</t>
<t>Conservation of port numbers is improved by procedures that allow
previously allocated port numbers to become Unassigned, either through
de-assignment or through revocation, and by a procedure that lets
application designers transfer an assigned but unused port number to
a new application. <xref target="iana-procedures"></xref> describes
these procedures, which until now were undocumented. Port number
conservation is also improved by recommending that applications that
do not require an assigned port should register only a service name
without an associated port number.</t>
</section>
</section>
<section anchor="iana-procedures"
title="IANA Procedures for Managing the Service Name and Transport Protocol Port Number Registry">
<t>This section describes the process for handling requests associated
with IANA's management of the Service Name and Transport Protocol Port
Number Registry. Such requests include initial assignment,
de-assignment, reuse, changes to the service name, and updates to the
contact information or description associated with an assignment.
Revocation is as additional process, initiated by IANA.</t>
<section anchor="assignment"
title="Service Name and Port Number Assignment">
<t>Assignment refers to the process of providing service names or port
numbers to applicants. All such assignments are made from service
names or port numbers that are Unassigned or Reserved at the time of
the assignment. Unassigned names and numbers are allocated according
to the rules described in <xref target="variances"></xref> below.
Except as described below, Reserved
numbers and names are assigned only by a Standards Action or an IESG Approval,
and MUST accompanied by a statement explaining the reason a Reserved
number or name is appropriate for this action.</t>
<t>When an assignment for one or more transport protocols is
approved, the port number for any non-requested transport protocol(s)
will be marked as Reserved. IANA SHOULD NOT assign that port number to
any other application or service until no other port numbers remain
Unassigned in the requested range. The current Assignee
for a port number MAY request assignment of these Reserved port numbers for other
transport protocols when needed.</t>
<t><?rfc needLines="14" ?>A service name or port number
assignment request contains the following information. The service
name is the unique identifier of a given service:</t>
<t><list style="empty">
<t>Service Name (REQUIRED)<vspace /> Transport Protocol(s)
(REQUIRED)<vspace /> Assignee (REQUIRED)<vspace /> Contact
(REQUIRED)<vspace /> Description (REQUIRED)<vspace /> Reference
(REQUIRED)<vspace /> Port Number (OPTIONAL)<vspace /> Service Code
(REQUIRED for DCCP only)<vspace /> Known Unauthorized Uses
(OPTIONAL)<vspace /> Assignment Notes (OPTIONAL)</t>
</list></t>
<t><list style="symbols">
<t>Service Name: A desired unique service name for the service
associated with the assignment request MUST be provided, for use
in various service selection and discovery mechanisms (including,
but not limited to, DNS SRV records <xref
target="RFC2782"></xref>). The name MUST be compliant with the
syntax defined in <xref target="sec-syntax"></xref>. In order to
be unique, they MUST NOT be identical to any currently assigned
service name in the IANA registry <xref target="PORTREG"></xref>.
Service names are case-insensitive; they may be provided and
entered into the registry with mixed case for clarity, but for the
comparison purposes the case is ignored.</t>
<t>Transport Protocol(s): The transport protocol(s) for which an
assignment is requested MUST be provided. This field is currently
limited to one or more of TCP, UDP, SCTP, and DCCP. Requests
without any port assignment and only a service name are still required
to indicate which protocol the service uses. </t>
<t>Assignee: Name and email address of the party to whom the
assignment is made. This is
REQUIRED. The Assignee is the Organization or Company
responsible for the initial assignment. For assignments done
through IETF-published RFCs, the Assignee will be the IETF,
with the IESG <iesg@ietf.org> as the point of contact.</t>
<t>Contact: Name and email address of the Contact person for the
assignment. This is REQUIRED. The Contact person is the
responsible person for the Internet community to send questions
to. This person is also authorized to submit changes on
behalf of the Assignee; in cases of conflict between the
Assignee and the Contact, the Assignee decisions take precedence.
Additional address information MAY be
provided. For assignments done through IETF-published RFCs, the
Contact will be the IESG.</t>
<t>Description: A short description of the service associated with
the assignment request is REQUIRED. It should avoid all but the
most well-known acronyms.</t>
<t>Reference: A description of (or a reference to a document
describing) the protocol or application using this port. The
description must state whether the protocol uses broadcast,
multicast, or anycast communication. <vspace blankLines="1" /> For
assignments requesting only a Service Name, or a Service Name
and User Port, a statement that the protocol is proprietary and
not publicly documented is also acceptable provided that the
required information regarding use of broadcast, multicast, or
anycast is given. <vspace blankLines="1" /> For assignment
requests for a User Port, the assignment request MUST explain
why a port number in the Dynamic Ports range is unsuitable for the
given application. <vspace blankLines="1" /> For assignment
requests for a System Port, the assignment request MUST explain
why a port number in the User Ports or Dynamic Ports ranges is
unsuitable, and a reference to a stable protocol specification
document MUST be provided. For requests from IETF Working Groups,
IANA MAY accept early assignment <xref
target="RFC4020"></xref> requests (known as "early allocation" therein) referencing a sufficiently
stable Internet Draft instead of a published Standards-Track
RFC.</t>
<t>Port Number: If assignment of a port number is desired,
either the port number the requester suggests for assignment
or indication of port range (user or system)
MUST be provided. If only a service name is to be assigned,
this field is left empty. If a specific port number is
requested, IANA is encouraged to assign the requested
number. If a range is specified, IANA will choose a suitable
number from the User or System Ports ranges. Note that the
applicant MUST NOT use the requested port prior to the
completion of the assignment<!-- or the IETF will be very
very cross and will glare at you in a most disapproving
manner-->.</t>
<t>Service Code: If the assignment request includes DCCP as a
transport protocol then the request MUST include a desired unique
DCCP service code <xref target="RFC5595"></xref>, and MUST NOT
include a requested DCCP service code otherwise. Section 19.8 of
the DCCP specification <xref target="RFC4340"></xref> defines
requirements and rules for assignment, updated by this
document.</t>
<t>Known Unauthorized Uses: A list of uses by applications or
organizations who are not the Assignee. This list may be augmented
by IANA after assignment when unauthorized uses are reported.</t>
<t>Assignment Notes: Indications of owner/name change, or any
other assignment process issue. This list may be updated by IANA
after assignment to help track changes to an assignment, e.g.,
de-assignment, owner/name changes, etc.</t>
</list></t>
<t>If the assignment request is for the addition of a new transport
protocol to an already-assigned service name and the requester is not the
Assignee or Contact for the already-assigned service name, IANA needs to confirm
with the Assignee for the existing assignment whether
this addition is appropriate.</t>
<t>If the assignment request is for a new service name sharing the
same port as an already-assigned service name (see port number
overloading in <xref target="srvname"></xref>), IANA needs to confirm with the
Assignee for the existing service name and other appropriate experts whether
the overloading is appropriate.</t>
<t>When IANA receives an assignment request - containing the
above information - that is requesting a port number, IANA SHALL
initiate an "Expert Review" <xref target="RFC5226"></xref> in
order to determine whether an assignment should be made. For
requests that are not seeking a port number, IANA SHOULD
assign the service name under a simple "First Come First Served"
policy <xref target="RFC5226"></xref>.</t>
<section anchor="variances"
title="Variances for Specific Port Number Ranges">
<t><xref target="types"></xref> describes the different port number
ranges. It is important to note that IANA applies slightly different
procedures when managing the different port ranges of the service name
and port number registry: <list style="symbols">
<t>Ports in the Dynamic Ports range (49152-65535) have been
specifically set aside for local and dynamic use and cannot be
assigned through IANA. Application software may simply use
any dynamic port that is available on the local host,
without any sort of assignment. On the other
hand, application software MUST NOT assume that a specific port
number in the Dynamic Ports range will always be available for
communication at all times, and a port number in that range hence
MUST NOT be used as a service identifier.</t>
<t>Ports in the User Ports range (1024-49151) are available for
assignment through IANA, and MAY be used as service identifiers
upon successful assignment. Because assigning a port number
for a specific application consumes a fraction of the shared
resource that is the port number registry, IANA will require the
requester to document the intended use of the port number. This
documentation will be input to the "Expert Review"
procedure <xref target="RFC5226"></xref>, by which IANA will have
a technical expert review the request to determine whether to
grant the assignment. The submitted documentation MUST explain
why using a port number in the Dynamic Ports range is unsuitable
for the given application. Ports in the User Ports range may also
be assigned under the "IETF Review" or "IESG Approval"
procedures <xref target="RFC5226"></xref>, which is how most
assignments for IETF protocols are handled.</t>
<t>Ports in the System Ports range (0-1023) are also available for
assignment through IANA. Because the System Ports range is both
the smallest and the most densely allocated, the requirements for
new assignments are more strict than those for the User Ports
range, and will only be granted under the "IETF Review" or "IESG
Approval" procedures <xref target="RFC5226"></xref>. A
request for a System Port number MUST document *both* why using a
port number from the Dynamic Ports range is unsuitable *and* why using a
port number from the User Ports range is unsuitable for that application.</t>
</list></t>
</section>
</section>
<section anchor="deassignment"
title="Service Name and Port Number De-Assignment">
<t>The Assignee of a granted port number assignment can
return the port number to IANA at any time if they no longer have a
need for it. The port number will be de-assigned and will be marked
as Reserved. IANA should not re-assign port numbers that have been
de-assigned until all unassigned port numbers in the specific range
have been assigned.</t>
<t>Before proceeding with a port number de-assignment, IANA needs to
reasonably establish that the value is actually no longer in use.</t>
<t>Because there is much less danger of exhausting the service name
space compared to the port number space, it is RECOMMENDED that a
given service name remain assigned even after all associated port
number assignments have become de-assigned. Under this policy, it
will appear in the registry as if it had been created through a
service name assignment request that did not include any port
numbers.</t>
<t>On rare occasions, it may still be useful to de-assign a service
name. In such cases, IANA will mark the service name as Reserved. IANA
will involve their IESG-appointed expert in such cases.</t>
<t>IANA will include a comment in the registry when de-assignment
happens to indicate its historic usage.</t>
</section>
<section anchor="reuse" title="Service Name and Port Number Reuse">
<t>If the Assignee of a granted port number assignment
no longer has a need for the assigned number, but would like to
reuse it for a different application, they can submit a request to
IANA to do so.</t>
<t>Logically, port number reuse is to be thought of as a
de-assignment (<xref target="deassignment"></xref>) followed by an
immediate (re-)assignment (<xref target="assignment"></xref>) of the
same port number for a new application. Consequently, the information
that needs to be provided about the proposed new use of the port
number is identical to what would need to be provided for a new port
number assignment for the specific ports range.</t>
<t>Because there is much less danger of exhausting the service name
space compared to the port number space, it is RECOMMENDED that the
original service name associated with the prior use of the port number
remains assigned, and a new service name be created and associated with the
port number. This is again consistent with viewing a reuse request as
a de-assignment followed by an immediate (re-)assignment. Re-using
an assigned service name for a different application is NOT
RECOMMENDED.</t>
<t>IANA needs to carefully review such requests before approving them.
In some instances, the Expert Reviewer will determine that the
application the port number was assigned to has found usage
beyond the original Assignee, or that there is a concern that it may
have such users. This determination MUST be made quickly. A community
call concerning revocation of a port number (see below) MAY be
considered, if a broader use of the port number is suspected.</t>
</section>
<section anchor="revocation"
title="Service Name and Port Number Revocation">
<t>A port number revocation can be thought of as an IANA-initiated
de-assignment (<xref target="deassignment"></xref>), and has
exactly the same effect on the registry.</t>
<t>Sometimes, it will be clear that a specific port number is no
longer in use and that IANA can revoke it and mark it as Reserved. At
other times, it may be unclear whether a given assigned port number is
still in use somewhere in the Internet. In those cases, IANA must
carefully consider the consequences of revoking the port number, and
SHOULD only do so if there is an overwhelming need.</t>
<t>With the help of their IESG-appointed Expert Reviewer, IANA SHALL
formulate a request to the IESG to issue a four-week community call
concerning the pending port number revocation. The IESG and IANA, with
the Expert Reviewer's support, SHALL determine promptly after the end
of the community call whether revocation should proceed and then
communicate their decision to the community. This procedure typically
involves similar steps to de-assignment except that it is initiated
by IANA.</t>
<t>Because there is much less danger of exhausting the service name
space compared to the port number space, revoking service names is NOT
RECOMMENDED.</t>
</section>
<section anchor="transfer"
title="Service Name and Port Number Transfers">
<t>The value of service names and port numbers is defined by their
careful management as a shared Internet resource, whereas enabling
transfer allows the potential for associated monetary exchanges. As a
result, the IETF does not permit service name or port number
assignments to be transferred between parties, even when they are
mutually consenting.</t>
<t>The appropriate alternate procedure is a coordinated
de-assignment and assignment: The new party requests the service
name or port number via an assignment and the previous party releases
its assignment via the de-assignment procedure outlined above.</t>
<t>With the help of their IESG-appointed Expert Reviewer, IANA SHALL
carefully determine if there is a valid technical, operational or
managerial reason to grant the requested new assignment.</t>
</section>
<section title="Maintenance Issues">
<t>In addition to the formal procedures described above, updates
to the Description and Contact information are coordinated by
IANA in an informal manner, and may be initiated by either the
Assignee or by IANA, e.g., by the latter requesting an update
to current Contact information. (Note that the Assignee cannot be
changed as a separate procedure; see instead <xref target="transfer"></xref>
above.)</t>
</section>
<section title="Disagreements">
<t>In the case of disagreements around any request there is the
possibility of appeal following the normal appeals process for
IANA assignments as defined by Section 7 of <xref target="RFC5226">
"Guidelines for Writing an IANA Considerations Section in RFCs"</xref>.
</t>
</section>
</section>
<section anchor="seccons" title="Security Considerations">
<t>The IANA guidelines described in this document do not change the
security properties of UDP, TCP, SCTP, or DCCP.</t>
<t><!-- adapted from http://www.iana.org/assignments/port-numbers -->Assignment
of a service name or port number does not in any way imply an
endorsement of an application or product, and the fact that network
traffic is flowing to or from an assigned port number does not mean that
it is "good" traffic, or even that it is used by the assigned service.
Firewall and system administrators should choose how to configure their
systems based on their knowledge of the traffic in question, not based
on whether or not there is an assigned service name or port number.</t>
<t>Services are expected to include support for security, either as
default or dynamically negotiated in-band. The use of separate service
name or port number assignments for secure and insecure variants of the
same service is to be avoided in order to discourage the deployment of
insecure services.</t>
</section>
<section anchor="ianacons" title="IANA Considerations">
<!-- put all changes from 2780 into this section -->
<t>This document obsoletes Sections 8 and 9.1 of the March 2000 IANA
Allocation Guidelines <xref target="RFC2780"></xref>.</t>
<!-- This is trivia that belongs in an email message, not in a
public document that exists in perpetuity. A year from now what
people will care about is how to register their service, not a
tedious exhaustive history of how it came to be that way.
Lars says: No, it needs to be here, because all IANA actions need
to be described in the document.
-->
<t>Upon approval of this document, IANA is requested to contact Stuart
Cheshire, maintainer of the independent service name registry <xref
target="SRVREG"></xref>, in order to merge the contents of that private
registry into the official IANA registry. It is expected that the
independent registry web page will be updated with pointers to the IANA
registry and to this RFC.</t>
<t>IANA is instructed to create a new service name entry in the service
name and port number registry <xref target="PORTREG"></xref> for any
entry in the "Protocol and Service Names" registry <xref
target="PROTSERVREG"></xref> that does not already have one
assigned.</t>
<t>IANA is also instructed to indicate in the Assignment Notes for "www"
and "www-http" that they are duplicate terms that refer to the "http" service,
and should not be used for
discovery purposes. For this conceptual service (human-readable web
pages served over HTTP) the correct service name to use for
service discovery purposes is "http" (see <xref
target="srvname"></xref>).</t>
<section anchor="consistency" title="Service Name Consistency">
<t><xref target="assignment"></xref> defines which character strings
are well-formed service names, which until now had not been clearly
defined. The definition in <xref target="assignment"></xref> was
chosen to allow maximum compatibility of service names with current
and future service discovery mechanisms.</t>
<t>As of August 5, 2009 approximately 98% of the so-called "Short
Names" from existing port number assignments <xref
target="PORTREG"></xref> meet the rules for legal service names stated
in <xref target="assignment"></xref>, and hence for these services
their service name will be exactly the same as their "Short Name".</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, pluses, slashes,
or underscores. All existing "Short Names" conform to the length
requirement of 15 characters or fewer. 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 entry to the registry giving the new well-formed primary service
name for the existing service, that otherwise duplicates the original
assignment information. In the description field of this new entry
giving the primary service name, IANA SHALL record that it assigns a
well-formed service name for the previous service and reference the
original assignment. In the Assignment Notes field of the original
assignment, IANA SHALL add a note that this entry is an alias to the
new well-formed service name, and that the old service name is
historic, not usable for use with many common service discovery
mechanisms.</t>
<t><?rfc needLines="40" ?>Names containing illegal characters to be
replaced by hyphens:</t>
<texttable>
<ttcol></ttcol>
<ttcol></ttcol>
<ttcol></ttcol>
<c>914c/g</c>
<c>acmaint_dbd</c>
<c>acmaint_transd</c>
<c>atex_elmd</c>
<c>avanti_cdp</c>
<c>badm_priv</c>
<c>badm_pub</c>
<c>bdir_priv</c>
<c>bdir_pub</c>
<c>bmc_ctd_ldap</c>
<c>bmc_patroldb</c>
<c>boks_clntd</c>
<c>boks_servc</c>
<c>boks_servm</c>
<c>broker_service</c>
<c>bues_service</c>
<c>canit_store</c>
<c>cedros_fds</c>
<c>cl/1</c>
<c>contamac_icm</c>
<c>corel_vncadmin</c>
<c>csc_proxy</c>
<c>cvc_hostd</c>
<c>dbcontrol_agent</c>
<c>dec_dlm</c>
<c>dl_agent</c>
<c>documentum_s</c>
<c>dsmeter_iatc</c>
<c>dsx_monitor</c>
<c>elpro_tunnel</c>
<c>elvin_client</c>
<c>elvin_server</c>
<c>encrypted_admin</c>
<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>
<c>ibm_wrless_lan</c>
<c>iceedcp_rx</c>
<c>iceedcp_tx</c>
<c>iclcnet_svinfo</c>
<c>idig_mux</c>
<c>ife_icorp</c>
<c>instl_bootc</c>
<c>instl_boots</c>
<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>
<c>menandmice_noh</c>
<c>msl_lmd</c>
<c>nburn_id</c>
<c>ncr_ccl</c>
<c>nds_sso</c>
<c>netmap_lm</c>
<c>nms_topo_serv</c>
<c>notify_srvr</c>
<c>novell-lu6.2</c>
<c>nuts_bootp</c>
<c>nuts_dem</c>
<c>ocs_amu</c>
<c>ocs_cmu</c>
<c>pipe_server</c>
<c>pra_elmd</c>
<c>printer_agent</c>
<c>redstorm_diag</c>
<c>redstorm_find</c>
<c>redstorm_info</c>
<c>redstorm_join</c>
<c>resource_mgr</c>
<c>rmonitor_secure</c>
<c>rsvp_tunnel</c>
<c>sai_sentlm</c>
<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>
<c>udt_os</c>
<c>universe_suite</c>
<c>veritas_pbx</c>
<c>vision_elmd</c>
<c>vision_server</c>
<c>wrs_registry</c>
<c>z39.50</c>
</texttable>
<t>Following the example set by the "application/whoispp-query" MIME
Content-Type <xref target="RFC2957"></xref>, the service name for
"whois++" will be "whoispp".</t>
</section>
<section anchor="sctpdccpexp"
title="Port Numbers for SCTP and DCCP Experimentation">
<t>Two System UDP and TCP ports, 1021 and 1022, have been reserved for
experimental use <xref target="RFC4727"></xref>. This document assigns
the same port numbers for SCTP and DCCP, updates the TCP and UDP
assignments, and also instructs IANA to automatically assign these
two port numbers for any future transport protocol with a similar
16-bit port number namespace.</t>
<t>Note that these port numbers are meant for temporary
experimentation and development in controlled environments. Before
using these port numbers, carefully consider the advice in <xref
target="udptcpexp"></xref> in this document, as well as in Sections 1
and 1.1 of "Assigning Experimental and Testing Numbers Considered
Useful" <xref target="RFC3692"></xref>. Most importantly, application
developers must request a permanent port number assignment from IANA
as described in <xref target="assignment"></xref> before any kind of
non-experimental deployment.</t>
<texttable>
<ttcol></ttcol>
<ttcol></ttcol>
<c>Service Name</c>
<c>exp1</c>
<c>Transport Protocol</c>
<c>DCCP, SCTP, TCP, UDP</c>
<c>Assignee</c>
<c>IETF <iesg@ietf.org></c>
<c>Contact</c>
<c>IESG <iesg@ietf.org></c>
<c>Description</c>
<c>RFC3692-style Experiment 1</c>
<c>Reference</c>
<c>[RFC4727] [RFCyyyy]</c>
<c>Port Number</c>
<c>1021</c>
</texttable>
<texttable>
<ttcol></ttcol>
<ttcol></ttcol>
<c>Service Name</c>
<c>exp2</c>
<c>Transport Protocol</c>
<c>DCCP, SCTP, TCP, UDP</c>
<c>Assignee</c>
<c>IETF <iesg@ietf.org></c>
<c>Contact</c>
<c>IESG <iesg@ietf.org></c>
<c>Description</c>
<c>RFC3692-style Experiment 2</c>
<c>Reference</c>
<c>[RFC4727] [RFCyyyy]</c>
<c>Port Number</c>
<c>1022</c>
</texttable>
<t>[RFC Editor Note: Please change "yyyy" to the RFC number allocated
to this document before publication.]</t>
</section>
<section anchor="dccp" title="Updates to DCCP Registries">
<t>This document updates the IANA assignment procedures for the DCCP
Port Number and DCCP Service Codes Registries <xref
target="RFC4340"></xref>.</t>
<section title="DCCP Service Code Registry">
<t>Service Codes are assigned first-come-first-served according to
Section 19.8 of the DCCP specification <xref
target="RFC4340"></xref>. This document updates that section by
extending the guidelines given there in the following ways:</t>
<t><list style="symbols">
<t>IANA MAY assign new Service Codes without seeking Expert
Review using their discretion, but SHOULD seek expert review if
a request asks for more than five Service Codes.</t>
<t>IANA should feel free to contact the DCCP Expert Reviewer
with questions on any registry, regardless of the registry
policy, for clarification or if there is a problem with a
request <xref target="RFC4340"></xref>.</t>
</list></t>
</section>
<section title="DCCP Port Numbers Registry">
<t>The DCCP ports registry is defined by Section 19.9 of the DCCP
specification <xref target="RFC4340"></xref>. Assignments in this
registry require prior assignment of a Service Code. Not all Service
Codes require IANA-assigned ports. This document updates that
section by extending the guidelines given there in the following
way:</t>
<t><list style="symbols">
<t>IANA should normally assign a value in the range 1024-49151
to a DCCP server port. IANA requests to assign port
numbers in the System Ports range (0 through 1023), require an
"IETF Review" <xref target="RFC5226"></xref> prior to assignment
by IANA <xref target="RFC4340"></xref>.</t>
<t>IANA MUST NOT assign more than one DCCP server port to a
single service code value.</t>
<t>The assignment of multiple service codes to the same DCCP
port is allowed, but subject to expert review.</t>
<t>The set of Service Code values associated with a DCCP server
port should be recorded in the service name and port number
registry.</t>
<t>A request for additional Service Codes to be associated with
an already-allocated Port Number requires Expert Review. These
requests will normally be accepted when they originate from the
contact associated with the port assignment. In other cases,
these applications will be expected to use an unallocated port,
when this is available.</t>
</list></t>
<t>The DCCP specification <xref target="RFC4340"></xref> notes that
a short port name MUST be associated with each DCCP server port that
has been assigned. This document clarifies that this short port name
is the Service Name as defined here, and this name MUST be
unique.</t>
</section>
</section>
</section>
<section anchor="sec-contributors" title="Contributors">
<t>Alfred Hoenes (ah@tr-sys.de) and Allison Mankin (mankin@psg.com) have
contributed text and ideas to this document.</t>
</section>
<section anchor="ack" title="Acknowledgments">
<t>The text in <xref target="dccp"></xref> is based on a suggestion
originally proposed as a part of the DCCP Service Codes document <xref
target="RFC5595"></xref> by Gorry Fairhurst.</t>
<t>Lars Eggert is partly funded by the Trilogy Project <xref
target="TRILOGY"></xref>, a research project supported by the European
Commission under its Seventh Framework Program.</t>
</section>
</middle>
<!-- REFERENCE TEMPLATE
<reference anchor="reference.XXX">
<front>
<title>XXX</title>
<author initials="X." surname="XXX" fullname="XXX">
<organization abbrev="XXX">XXX</organization>
<address>
<postal>
<street>XXX</street>
<city>XXX</city>
<region>XXX</region>
<code>XXX</code>
<country>XXX</country>
</postal>
<phone>XXX</phone>
<facsimile>XXX</facsimile>
<email>XXX</email>
<uri>XXX</uri>
</address>
</author>
<date month="XXX" year="XXX"/>
</front>
<seriesInfo name="XXX" value="XXX"/>
<format type="XXX" target="XXX"/>
</reference>
-->
<back>
<references title="Normative References">
<?rfc include="reference.RFC.0768" ?>
<?rfc include="reference.RFC.0793" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2780" ?>
<?rfc include="reference.RFC.3828" ?>
<?rfc include="reference.RFC.4020" ?>
<?rfc include="reference.RFC.4340" ?>
<?rfc include="reference.RFC.4727" ?>
<?rfc include="reference.RFC.5226" ?>
<?rfc include="reference.RFC.5234" ?>
<?rfc include="reference.ANSI.X3-4.1986" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.0959" ?>
<?rfc include="reference.RFC.1078" ?>
<?rfc include="reference.RFC.1700" ?>
<?rfc include="reference.RFC.2782" ?>
<?rfc include="reference.RFC.2957" ?>
<?rfc include="reference.RFC.3232" ?>
<?rfc include="reference.RFC.3692" ?>
<?rfc include="reference.RFC.4342" ?>
<?rfc include="reference.RFC.4960" ?>
<?rfc include="reference.RFC.5237" ?>
<?rfc include="reference.RFC.5595" ?>
<?rfc include="reference.RFC.5766" ?>
<?rfc include="reference.RFC.5389" ?>
<?rfc include="reference.I-D.cheshire-dnsext-dns-sd" ?>
<?rfc include="reference.I-D.cheshire-nat-pmp" ?>
<!-- <?rfc include="reference.I-D.gudmundsson-dnsext-srv-clarify" ?> -->
<!--
<reference anchor="I-D.touch-tsvwg-port-guidelines">
<front>
<title>Guidelines for Transport Port Use</title>
<author fullname="Joe Touch" initials="J" surname="Touch">
<organization></organization>
</author>
</front>
<seriesInfo name="" value="Currently Unpublished"/>
</reference>
-->
<reference anchor="SYSFORM">
<front>
<title>Application for System (Well Known) Port Number</title>
<author surname="Internet Assigned Numbers Authority (IANA)">
<organization />
</author>
</front>
<seriesInfo name=""
value="http://www.iana.org/" />
</reference>
<reference anchor="USRFORM">
<front>
<title>Application for User (Registered) Port Number</title>
<author surname="Internet Assigned Numbers Authority (IANA)">
<organization />
</author>
</front>
<seriesInfo name=""
value="http://www.iana.org/" />
</reference>
<reference anchor="PORTREG">
<front>
<title>Service Name and Transport Protocol Port Number
Registry</title>
<author surname="Internet Assigned Numbers Authority (IANA)">
<organization />
</author>
</front>
<seriesInfo name=""
value="http://www.iana.org/assignments/port-numbers" />
</reference>
<reference anchor="PROTSERVREG">
<front>
<title>Protocol and Service Names Registry</title>
<author surname="Internet Assigned Numbers Authority (IANA)">
<organization />
</author>
</front>
<seriesInfo name=""
value="http://www.iana.org/assignments/service-names" />
</reference>
<reference anchor="SRVREG">
<front>
<title>DNS SRV Service Types Registry</title>
<author surname="">
<organization />
</author>
</front>
<seriesInfo name="" value="http://www.dns-sd.org/ServiceTypes.html" />
</reference>
<reference anchor="TRILOGY">
<front>
<title>Trilogy Project</title>
<author>
<organization />
</author>
</front>
<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 fullname="" initials="" surname="">
<organization/>
</author>
</front>
</reference>
-->
<reference anchor="IGD">
<front>
<title>Internet Gateway Device (IGD) V 1.0</title>
<author fullname="UPnP Forum">
<organization>UPnP Forum</organization>
</author>
<date day="12" month="November" year="2001" />
</front>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 04:27:18 |