One document matched: draft-ietf-tsvwg-iana-ports-08.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-08"
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="Allison Mankin" initials="A." surname="Mankin">
<organization abbrev="Johns Hopkins Univ.">Johns Hopkins
University</organization>
<address>
<postal>
<street>4102 Wilson Boulevard</street>
<city>Arlington</city>
<region>VA</region>
<code>22230</code>
<country>USA</country>
</postal>
<phone>+1 301 728 7199</phone>
<email>mankin@psg.com</email>
<uri>http://www.psg.com/~mankin/</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>procedures</keyword>
<abstract>
<t>This document defines the procedures that the Internet Assigned
Numbers Authority (IANA) uses when handling registration 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 Sections 8 and
9.1 of the IANA allocation guidelines [RFC2780], and it updates the IANA
allocation 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 allocation 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-register a port number
that is no longer in use, to re-use a port number allocated for one
application that is no longer in use for another application, 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 registrations 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="registration"></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 allocation guidelines <xref
target="RFC2780"></xref>. (Note that other sections of the IANA
allocation 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
allocation procedures for DCCP <xref target="RFC4340"></xref> and SCTP
<xref target="RFC4960"></xref>.</t>
<t>The Lightweight User Datagram Protocol (UDP-Lite) <xref
target="RFC5237"></xref> shares the port space with UDP. The UDP-Lite
specification 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
registered. 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, for consistency it is expected to follow as
much as possible the guidelines and practices around using service names
and port numbers.</t>
</section>
<section anchor="motivation" title="Motivation">
<t>Information about the registration procedures for the port registry
has existed in three locations: the forms for requesting port number
registrations on the IANA web site <xref target="SYSFORM"></xref> <xref
target="USRFORM"></xref>, an introductory text section in the file
listing the port number registrations themselves <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, beyond 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, the requirement by IANA
to only assign service names and port numbers in combination, led to the
creation of an ad hoc service name registry outside of the control of
IANA <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 registration 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 registrations 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 bind.
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 allocated ports.</t>
</list></t>
-->
<t>Applications may 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 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 successful registration - 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>
</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 Registrant 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 service name
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 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" corresponds to
the same port number as
"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" then it would not be discovered by
clients browsing for "http". Advertising or browsing for the aliases
as well as the primary service name would be inefficient, and
achieves nothing that it not already achieved by using the service
name "http" exclusively.</t>
<t>As indicated in this document, in
<xref target="consistency"></xref>, to enable
legacy names to be replaced with names consistent with the
syntax this document prescribes. In this case, only the
new name should be used in SRV records, both to avoid
the same issues as with historical cases of multiple names,
as well as 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="registration"></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 number) or
"6000-6063" (could be confused with a numeric port number 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 can't claim to "own" all
service names beginning with "Example-", they can't prevent someone
else registering "Example-Baz" for a different service, and they can't
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. 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 allocated 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 an 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 registers 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 allocation of service names and port
numbers upon request, as well as management of information about
existing allocations. The latter includes maintaining contact and
description information about assignments, revoking abandoned
assignments, and redefining assignments when needed. Of these
procedures, careful port number allocation 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>Before the publication of this document, the principles of service
name and port number management followed a few mostly-undocumented
guidelines. They are recorded here for historical purposes, and this
document updates them in <xref target="upprinc"></xref>. These
principles were:</t>
<t><list style="symbols">
<t>TCP and UDP ports were simultaneously allocated when either was
requested</t>
<t>Port numbers were the primary allocation; 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 allocated 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 clarifies and aligns these guidelines in order
to more conservatively manage the limited remaining port number space
and to enable and promote the use of service names for service
identification without associated port numbers, where possible.</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 basic 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 are not required to be bound by these principles
when handling requests; other factors may come into play,
and exceptions may occur where deemed in the best interest of
the Internet.</t>
<t>IANA will begin assigning service names that do not request an
associated port number allocation 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 registrations 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
registration request for port number allocations 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 still enable an application to perform further
demultiplexing by itself. In particular:</t>
<t><list style="symbols">
<t>IANA will allocate only one assigned port number per service or
application</t>
<t>IANA will allocate only one assigned port number for all
versions of a service (e.g., running the service with or without a
security mechanism, or for updated variants of a service)</t>
<t>IANA will allocate only one assigned port number for all
different types of device using or participating in the same
service</t>
<t>IANA will allocate port numbers only for the transport
protocol(s) explicitly named in a registration request</t>
<t>IANA may recover unused port numbers, via the new procedures of
de-registration, 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 allocated
port. Applications and protocols are also expected to be able to
efficiently use a single allocated port for multiple sessions, either
by demultiplexing multiple streams within one port, or using the
allocated 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,
previous separation of 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 and capable of negotiating the use of security
in-band.</t>
<t>IANA will begin assigning port numbers for only those transport
protocols explicitly included in a registration 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 allocation procedure
conserves resources by allocating 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 Registrant for the
registration MUST request IANA to convert the reservation into a
proper assignment. 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
reservation 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 register 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-registration or through revocation, and by a procedure that lets
application designers transfer an allocated 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 allocated 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 registration,
de-registration, re-use, 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="registration"
title="Service Name and Port Number Registration">
<t>Registration refers to the allocation of service names or port
numbers to applicants. All such registrations are made from service
names or port numbers that are Unassigned or Reserved at the time of
the allocation. Unassigned names and numbers are allocated according
to the rules described in <xref target="variances"></xref> below. Reserved
numbers and names are assigned only by Standards Action or IESG Approval,
and MUST accompanied by a statement explaining the reason a Reserved
number or name is appropriate for this action.</t>
<t>When a registration 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 Registrant
for a port number MAY register these Reserved port numbers for other
transport protocols when needed.</t>
<t><vspace blankLines="14" />A service name or port number
registration 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 /> Registrant (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 registration 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 a
allocation is requested MUST be provided. This field is currently
limited to one or more of TCP, UDP, SCTP, and DCCP. Requests
without any port allocation and only a service name are still required
to indicate which protocol the service uses. </t>
<t>Registrant: Name and email address of the Registrant. This is
REQUIRED. The Registrant is the Organization or Company
responsible for the initial registration. For registrations done
through IETF-published RFCs, the Registrant will be the IESG.</t>
<t>Contact: Name and email address of the Contact person for the
registration. This is REQUIRED. The Contact person is the
responsible person for the Internet community to send questions
to. This person would also be authorized to submit changes on
behalf of the Registrant; in cases of conflict between the
Registrant and the Contact, the Registrant decisions take precedence.
Additional address information MAY be
provided. For registrations done through IETF-published RFCs, the
Contact will be the IESG.</t>
<t>Description: A short description of the service associated with
the registration 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
registrations 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 registration
requests for a User Port, the registration request MUST explain
why a port number in the Dynamic Ports range is unsuitable for the
given application. <vspace blankLines="1" /> For registration
requests for a System Port, the registration 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 registration" <xref
target="RFC4020"></xref> requests 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 currently Unassigned or Reserved port number the
requester suggests for allocation, or indication of which
port range, user or system, that the requester requires,
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 allocate 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 registration<!-- or the IETF will be very
very cross and will glare at you in a most disapproving
manner-->.</t>
<t>Service Code: If the registration 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 allocation, updated by this
document.</t>
<t>Known Unauthorized Uses: A list of uses by applications or
organizations who are not the Registrant. 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-registration, owner/name changes, etc.</t>
</list></t>
<t>If the registration request is for the addition of a new transport
protocol to an already assigned service name, IANA needs to confirm
with the Registrant for the existing assignment whether
this addition is appropriate.</t>
<t>If the registration request is for a service name overloading a
port number (see Section 5), IANA needs to confirm with the
Registrant for the existing service name whether the registration of
the overloading is appropriate.</t>
<t>When IANA receives a registration 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 requesting 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 them
for communication without any sort of registration. 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
registration through IANA, and MAY be used as service identifiers
upon successful registration. Because registering 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" allocation
procedure <xref target="RFC5226"></xref>, by which IANA will have
a technical expert review the request to determine whether to
grant the registration. 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" allocation
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
registration through IANA. Because the System Ports range is both
the smallest and the most densely allocated, the requirements for
new allocations are more strict than those for the User Ports
range, and will only be granted under the "IETF Review" or "IESG
Approval" allocation procedures <xref target="RFC5226"></xref>. A
request for a System Port number MUST document *both* why using a
port number from the User Ports is unsuitable *and* why using a
port number from the Dynamic Ports ranges is unsuitable for that
application.</t>
</list></t>
</section>
</section>
<section anchor="deregistration"
title="Service Name and Port Number De-Registration">
<t>The Registrant 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-registered and will be marked
as Reserved. IANA should not re-assign port numbers that have been
de-registered until all unassigned port numbers in the specific range
have been assigned.</t>
<t>Before proceeding with a port number de-registration, 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-registered. Under this policy, it
will appear in the registry as if it had been created through a
service name registration request that did not include any port
numbers.</t>
<t>On rare occasions, it may still be useful to de-register 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-registration
happens to indicate its historic usage.</t>
</section>
<section anchor="reuse" title="Service Name and Port Number Re-Use">
<t>If the Registrant of a granted port number assignment
no longer have a need for the assigned number, but would like to
re-use it for a different application, they can submit a request to
IANA to do so.</t>
<t>Logically, port number re-use is to be thought of as a
de-registration (<xref target="deregistration"></xref>) followed by an
immediate re-registration (<xref target="registration"></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 allocation 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 be created and associated with the
port number. This is again consistent with viewing a re-use request as
a de-registration followed by an immediate re-registration. 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 that the port number was assigned to has found usage
beyond the original requester, 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-registration (<xref target="deregistration"></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-registration 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-registration and registration: The new party requests the service
name or port number via a registration and the previous party releases
its assignment via the de-registration 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
registrant or by IANA, e.g., by the latter requesting an update
to current contact information. (Note that Registrant cannot be
changed; see <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 appelas process for
IANA registrations 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="registration"></xref> defines which character strings
are well-formed service names, which until now had not been clearly
defined. The definition in <xref target="registration"></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 registrations <xref
target="PORTREG"></xref> meet the rules for legal service names stated
in <xref target="registration"></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><vspace blankLines="42" />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
registrations, 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="registration"></xref> before any kind of
non-experimental deployment.</t>
<texttable>
<ttcol></ttcol>
<ttcol></ttcol>
<c>Registrant</c>
<c>IETF <iesg@ietf.org></c>
<c>Contact</c>
<c>IESG <iesg@ietf.org></c>
<c>Service Name</c>
<c>exp1</c>
<c>Port Number</c>
<c>1021</c>
<c>Transport Protocol</c>
<c>DCCP, SCTP, TCP, UDP</c>
<c>Description</c>
<c>RFC3692-style Experiment 1</c>
<c>Reference</c>
<c>[RFCyyyy],RFC 4727]</c>
</texttable>
<texttable>
<ttcol></ttcol>
<ttcol></ttcol>
<c>Registrant</c>
<c>IETF <iesg@ietf.org></c>
<c>Contact</c>
<c>IESG <iesg@ietf.org></c>
<c>Service Name</c>
<c>exp2</c>
<c>Port Number</c>
<c>1022</c>
<c>Transport Protocol</c>
<c>DCCP, SCTP, TCP, UDP</c>
<c>Description</c>
<c>RFC3692-style Experiment 2</c>
<c>Reference</c>
<c>[RFCyyyy], [RFC4727]</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 allocation 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 allocated 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 seeks 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>. Allocations in this
registry require prior allocation 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 allocation requests to allocate port
numbers in the System Ports range (0 through 1023), require an
"IETF Review" <xref target="RFC5226"></xref> prior to allocation
by IANA <xref target="RFC4340"></xref>.</t>
<t>IANA MUST NOT allocate more than one DCCP server port to a
single service code value.</t>
<t>The allocation 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 registration. 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/cgi-bin/sys-port-number.pl" />
</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/cgi-bin/usr-port-number.pl" />
</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 22:38:49 |