One document matched: draft-ietf-tsvwg-iana-ports-02.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-02"
ipr="pre5378Trust200902" updates="2780, 4340">
<front>
<title abbrev="Port Number and Service Name Procedures">
Internet Assigned Numbers Authority (IANA) Procedures for
the Management of the Transport Protocol Port Number and
Service Name Registry</title>
<!-- AUTHORS ALPHABETICAL -->
<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>Torshamsgatan 23</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>
<date year="2009" />
<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 transport
protocol port number and service name 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 RFC2780 by obsoleting Sections 8
and 9.1 of that RFC, and it updates the IANA allocation
procedures for DCCP as defined in RFC4340.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The Transmission Control Protocol (TCP)
<xref target="RFC0793" /> and the User Datagram Protocol
(UDP)
<xref target="RFC0768" /> have enjoyed a remarkable success
over the decades as the two most widely used transport
protocols on the Internet. They have introduced 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 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" /> and the Datagram Congestion
Control Protocol (DCCP)
<xref target="RFC4342" /> have adopted the concept of ports
for their communication sessions and use port numbers in
the same way as TCP and UDP. UDP-Lite
<xref target="RFC3828" />, a variant of UDP, is also
making use of UDP port numbers. For the purposes of this
document, all rules stated for UDP also apply to
UDP-Lite, because it uses the same assignments as 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 corresponding service
names such as "telnet" for port number 23 and both "http"
and "www" 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 can be a local decision between the
endpoints of a connection, most Internet components use a
single, shared view of this association, provided by the
Internet Assigned Numbers Authority (IANA) through the
port number registry
<xref target="REGISTRY" />.</t>
<t>Applications either use numeric port numbers directly,
look up port numbers based on service names via system
calls such as getservbyname() on UNIX, or - more recently
- use service names to look up a service resource records
(SRV RRs)
<xref target="RFC2782" /> via the Domain Name System (DNS)
<xref target="RFC1034" /> in a variety of ways
<xref target="RFC1078" />
<xref target="I-D.cheshire-dnsext-dns-sd" /><xref target="I-D.cheshire-dnsext-multicastdns" /> to
obtain the port number of a given service.</t>
<t>Designers of applications and application-level
protocols may apply to IANA for an assigned port number
and service name for a specific application, and may -
after successful registration - assume that no other
application will use that port number and service name for
its communication sessions. Alternatively, application
designers may also only ask for an assigned service name,
if their application does not require a port number. The
latter alternative is encouraged when possible, in order
to conserve the more limited port number space. It is
important to note that ownership of registered port
numbers and service names remains with IANA.</t>
<t>For protocols developed by IETF working groups, IANA
offers a method for the "early" assignment of port numbers
and service names, in line with
<xref target="RFC4020" />, as described in
<xref target="registration" />.</t>
<t>This document updates
<xref target="RFC2780" /> by obsoleting Sections 8 and 9.1
of that RFC. Note that
<xref target="RFC5237" /> updates a different subset of the
IANA allocation guidelines originally given in
<xref target="RFC2780" /> (specifically, the policies on
the namespace of the IP protocol number and IPv6 next
header).</t>
</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 BCP 14, RFC 2119
<xref target="RFC2119" />.</t>
</section>
<section anchor="motivation" title="Motivation">
<t>For many years, the allocation and registration of new
port number values and service names for use with TCP and
UDP have had less than clear guidelines. Information about
the registration procedures for the port registry existed
in three locations: the forms for requesting port number
registrations on the IANA web site
<xref target="SYSFORM" />
<xref target="USRFORM" />, an introductory text section in
the file listing the port number registrations themselves
<xref target="REGISTRY" />, and two brief sections of
<xref target="RFC2780" />.</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 target="USRFORM" />. (Even that length limit has not
been consistently applied, and some assigned service names
are 15 characters long.) When service identification via
DNS SRV RRs became popular, the ambiguities in the
syntactic definition of the service namespace, together
with a 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="SRVTYPE" />.</t>
<t>This document aggregates this scattered information
into a single reference that aligns and clearly defines
the management procedures for both port numbers and
service names. It gives more detailed guidance to
prospective requesters of ports and service names than the
existing documentation, and it streamlines the IANA
procedures for the management of the registry, so that
management requests can complete in a timely manner. It
also merges the service name registrations that have
occurred in the ad-hoc
<xref target="SRVTYPE" /> registry into the IANA registry
<xref target="REGISTRY" />, because under the new IANA
guidelines, registering service names without port numbers
has become possible.</t>
<t>A key factor of this procedural streamlining is to
establish identical registration procedures for all IETF
transport protocols. This document brings the IANA
procedures for TCP and UDP in line with those already in
effect for SCTP and DCCP, resulting in a single process
that requesters and IANA follow for all requests for all
transport protocols, including those not yet defined.</t>
<t>A second 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 port number registry.
TCP and UDP have been a remarkable success over the last
decades. Thousands of applications and application-level
protocols have registered ports and service names 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" /> 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>
<t>In addition to detailing the IANA procedures for the
initial assignment of port numbers and service names, 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 procedure by which IANA can unilaterally
revoke a prior port number registration.
<xref target="iana-procedures" /> discusses the specifics
of these procedures.</t>
</section>
<section anchor="types" title="Port Number Ranges">
<t>TCP, UDP (and 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" /> describes the IANA procedures
for each range in detail:
<list style="symbols">
<t>the Well Known Ports, also known as the System Ports,
from 0-1023 (assigned by IANA)</t>
<t>the Registered Ports, also known as the User 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 (Well Known and
Registered, 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 port
numbers and service names in the registry. Unassigned
values are typically not explicitly listed.</t>
<t>As a data point, when this document was written,
approximately 76% of the TCP and UDP Well Known Ports were
assigned, as were a significant fraction of the Registered
Ports. (As noted, Dynamic Ports are never assigned.)</t>
<section anchor="udptcpexp"
title="Port Numbers and Service Names for Experimentation">
<t>Of the Well Known 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" />. This document registers the
same two port numbers and service names for
experimentation with new application-layer protocols
over SCTP and DCCP in
<xref target="sctpdccpexp" />.</t>
<t>Please refer to Sections 1 and 1.1 of
<xref target="RFC3692" /> for how these experimental port
numbers are to be used. 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 Well Known or Registered ports range, and
port numbers in the Dynamic Ports range can be also
used.</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 Port Number and Service Name Registry Management">
<t>Management procedures for the port number and service
name registry include allocation of port numbers and
service names upon request, as well as coordination 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,
port number allocation is most critical, because of the
limited number of remaining port numbers. The namespace
available for service names is much larger, which allows
for simpler management procedures.</t>
<t>Before the publication of this document, the principles
of port number and service name management followed some
simple, mostly undocumented guidelines:</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 port number and service name registries
were managed separately from the TCP/UDP registries</t>
<t>Until recently, service names could not be assigned
without assigning a corresponding port number</t>
</list>This document attempts to document, clarify and
align 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 corresponding 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 title="Basic Principles of Port Number Conservation">
<t>This section summarizes the basic principles by which
IANA attempts to conserve the port number space. This
description is intended to inform applicants requesting
port numbers. IANA decisions are not required to be
bound to these principles, however; other factors may
come into play, and exceptions may occur where deemed in
the best interest of the Internet.</t>
<t>The basic principle of 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.</t>
<t>Conservation of the port number space recognizes that
because this space is a limited resource, 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, there should
be:</t>
<t>
<list style="symbols">
<t>only one assigned port number per service or
application</t>
<t>only one assigned port number for all versions of a
service (e.g., running the service with or without a
security mechanism)</t>
<t>only one assigned port number for all different
types of devices using or participating in the same
service</t>
</list>A given service is expected to further
demultiplex messages where possible. 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" />).</t>
<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 -->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>The process and protocol identifier use suggests
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 de-multiplexed or encoded must be separated to
allow for 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 inherently
problematic.
<!-- (again, as discussed in detail in <xref
target="I-D.touch-tsvwg-port-guidelines" />).--></t>
</section>
<section anchor="variances"
title="Variances for Specific Port Number Ranges">
<t>
<xref target="types" /> describes the different port
number ranges. It is important to note that IANA applies
slightly different procedures when managing the
different ranges of the 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 registered through IANA. Applications
may simply use them for communication without any sort
of registration. On the other hand, applications 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 Registered 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" />, 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.</t>
<t>Ports in the Well Known Ports range (0-1023) are
also available for registration through IANA. Because
the Well Known Ports range is both the smallest and
the most densely allocated one, the bar for new
allocations is higher than that for the Registered
Ports range, and will only be granted under the "IETF
Review" allocation procedure
<xref target="RFC5226" />. A request for a Well Known
port number MUST document why using a port number from
both the Registered Ports and Dynamic Ports ranges is
unsuitable for the given application.</t>
</list></t>
</section>
<section title="New Principles">
<t>Several new practices stem from the conservation
principle that guides management of the port number and
service name registry, and will take effect with the
approval of this document:</t>
<t>
<list style="symbols">
<t>IANA will allocate port numbers only to the
transport protocols explicitly named in an
allocation request</t>
<t>IANA will recover unused port numbers, via the
new procedures of de-registration, revocation, and
transfer</t>
<t>IANA will begin assigning service names without
requiring a corresponding port number allocation</t>
</list>
</t>
<t>IANA will begin assigning protocol numbers only for
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 only for one of these transport protocols. The new
allocation procedure conserves resources by only
allocating a port number to an application for 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, their implementors MUST
request IANA to convert the reservation into an
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>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" /> describes these
procedures, which so far were undocumented. Port number
conservation is also improved by recommending that
applications that do not require an allocated port,
e.g., because they can use service-name-based lookups,
chose this option and only register a service name.</t>
</section>
</section>
<section anchor="iana-procedures"
title="IANA Procedures for Managing the Port Number and Service Name Registry">
<t>This section describes the process for requests
associated with IANA's management of the port number
and service name registry. Such requests include initial
registration, de-registration, re-use, changes to the
service name, as well as updates to the contact
information or description associated with an assignment.
Revocation is initiated by IANA.</t>
<section anchor="registration"
title="Port Number or Service Name Registration">
<t>Registration refers to the allocation of port numbers
or service names to applicants. All such, registrations
are made from port numbers or service names that are
Unassigned or Reserved at the time of the allocation.
Unassigned numbers and names are allocated as needed,
and without further explanation. Reserved numbers and
names are assigned only after review by IANA and the
IETF, and are 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 (but not all)
transport protocols is approved, the port number for the
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
registration owner of a port number MAY register these
Reserved port numbers for other transport protocols when
needed.</t>
<t>Service names, on the other hand, are not tied to a
specific transport protocol, and registration requests
for only a service name (but not a port number) allocate
that service name for use with all transport
protocols.</t>
<t>A port number or service name registration consists
of the following information:</t>
<t>
<list style="symbols">
<t>Registration Technical Contact: Name and
email address of the technical contact person for the
registration. This is REQUIRED. Additional address
information MAY be provided. For registrations done
through IETF-published RFCs, one or more technical
contact persons SHALL be provided.</t>
<t>Registration Owner: Name and email
address of the owner of the registration. This is
REQUIRED. For individuals, this is the same as the
registration technical contact; for organizations,
this is a point of contact at that organization. For
registrations done through IETF-published RFCs, the
registration ownership will belong to the IETF and not
the technical contact persons.</t>
<t>Transport Protocol: The transport
protocol(s) for which the port number or service name
allocation is requested MUST be provided. This field
is currently limited to one or more of TCP, UDP, SCTP,
and DCCP.</t>
<t>Port Number: If assignment of port
number(s) is desired, either the currently Unassigned
port number(s) the requester suggests for allocation
or the tag "ANY" MUST be provided. If only a service
name is to be assigned, this field MUST be empty. If
specific port numbers are requested, IANA is
encouraged to allocate the suggested numbers. If the
tag "ANY" is specified, IANA will choose a suitable
number from the Registered Ports range. Note that the
applicant MUST NOT use the suggested ports prior to
the completion of the registration.</t>
<t>Service Name: A desired unique service
name for the service associated with the registration
request, for use in various service selection and
discovery mechanisms, MUST be provided. Valid service
names MUST only contain these US-ASCII
<xref target="ANSI.X3-4.1986" />
characters: letters from
A to Z, digits from 0 to 9, and hyphens
("-", ASCII 0x2D or decimal 45). They MUST
be at MOST fifteen characters long,
MUST NOT begin or end with a hyphen, and MUST NOT
consist of only digits, in order to be distinguishable from
port numbers. In order to be unique, they
MUST NOT be identical to any currently registered
service names in the IANA registry
<xref target="REGISTRY" />.
Service names are case-insensitive; they may be provided
and entered into the registry with mixed case (e.g., for
clarity), but for the purposes of comparison, the case is ignored.
</t>
<t>Service Code: A desired unique service
code for the service associated with the registration
request. Service codes are specific to the DCCP protocol
<xref target="I-D.ietf-dccp-serv-codes" />;
the request MUST include a desired service code when
the registration requests includes DCCP as a transport
protocol, and MUST NOT include one otherwise.</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 reference document
describing the protocol or application using this
port, including whether the protocol supports either
broadcast, multicast, or anycast communication.
For registration requests for Registered Ports,
this documentation MUST explain why a port number in
the Dynamic Ports range is unsuitable for the given
application. For registration requests for Well Known
Ports, this documentation MUST explain why a port
number in the Registered Ports or Dynamic Ports ranges
is unsuitable.
<vspace blankLines="1" /> "Early" registration requests
can be made by IETF working groups without including
such a reference document, although it is RECOMMENDED
that at least a reference to an Internet Draft
describing the work in progress is provided.</t>
</list></t>
</section>
<section anchor="deregistration"
title="Port Number and Service Name De-Registration">
<t>The original requesters 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 other available 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. It will afterwards 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.</t>
</section>
<section anchor="reuse" title="Port Number and Service Name Re-Use">
<t>If the original requesters of a granted port number
assignment no longer have a need for the registered
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" />)
followed by an immediate
re-registration (<xref target="registration" />)
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="Port Number and Service Name Revocation">
<t>A port number revocation can be thought of as an
IANA-initiated de-registration (<xref target="deregistration" />),
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="Port Number and Service Name Transfers">
<t>The value of port numbers and service names is defined
by their careful
management as a shared Internet resource, whereas
enabling transfer allows the potential for associated
monetary exchanges. As a
result, current IANA procedures do not permit port
number or service name 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
port number or service name 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 before performing the transfer.</t>
</section>
<section title="Maintenance Issues">
<t>The previous procedures help IANA manage the defining
properties of the port name and service name registry. There are
additional procedures which are administrative and help
IANA maintain non-defining information in a
registration. This includes changes to the Port Description
and changes to contact information.
These changes are coordinated by IANA in an informal
manner, and may be initiated by either the registrant or
by IANA, e.g., the latter when requesting an update to
current contact information.</t>
</section>
</section>
<section anchor="seccons" title="Security Considerations">
<t>The IANA guidelines described in this document do not
change the security properties of either TCP, SCTP, DCCP
or UDP.</t>
<t>
<!-- adapted from http://www.iana.org/assignments/port-numbers -->Assignment
of a port number or service name does not in any way imply an endorsement
of an application or product, and the fact that network
traffic is flowing to or from a registered 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 whether there is a port number or service name registered or
not.</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
<xref target="RFC2780" />. Upon approval of this document,
IANA is requested to adopt the procedures described
herein.</t>
<section anchor="consistency" title="Service Name Consistency">
<t><xref target="registration" /> defines which character strings
are well-formed service names, which until now had not been
clearly defined. The definition on <xref target="registration" />
was chosen to allow maximum compatibility of service names with
various service discovery mechanisms.</t>
<t>Unfortunately, the current port number registry
<xref target="REGISTRY" />
contains a few assigned service names that do not conform to the
new naming rules. In all cases, this is because they contain
illegal characters such as asterisks, dots, plusses, slashes,
or underscores. (All current service names conform to the length
requirement of 15 characters or less.)</t>
<t>Upon approval of this document, IANA SHALL take immediate
actions to resolve these inconsistencies. For any registry
assignment with an illegal service name, IANA SHALL
add an alias to the registry that assigns a well-formed service
name for the existing service but otherwise duplicates the
original assignment information. It is desirable if the alias
closely resembles the original service name, e.g., by remapping
underscores to dashes, etc.
In the description field of the
new alias, IANA SHALL record that it assigns a well-formed service
name for the previous service and point to the original assignment.
In the description field of the original assignment, IANA SHALL add
a note that the service name is historic, is not usable with
many common service discovery mechanisms, and provide a reference
to the new alias, which can be used in this way.</t>
<t>As of 2009-8-5 <xref target="REGISTRY" />, these service names
were illegal under the rules stated in
<xref target="registration" />:</t>
<texttable><ttcol/><ttcol/><ttcol/>
<c>914c/g </c>
<c>EtherNet/IP-1 </c>
<c>EtherNet/IP-2 </c>
<c>LiebDevMgmt_A </c>
<c>LiebDevMgmt_C </c>
<c>LiebDevMgmt_DM </c>
<c>acmaint_dbd </c>
<c>acmaint_transd </c>
<c>atex_elmd </c>
<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>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>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>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>whois++ </c>
<c>wrs_registry </c>
<c>z39.50 </c>
</texttable>
</section>
<section anchor="sctpdccpexp"
title="Port Numbers for SCTP and DCCP Experimentation">
<t>Two Well Known ports, 1021 and 1022, have been
reserved for experimentation UDP and TCP
<xref target="RFC4727" />. This document registers the
same port numbers for SCTP and DCCP, and also instructs
IANA to automatically register these two port numbers
for any new transport protocol that will in the future
share the 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" /> in this document, as well as
in Sections 1 and 1.1 of
<xref target="RFC3692" />. Most importantly, application
developers must request a permanent port number
assignment from IANA as described in
<xref target="registration" /> before any kind of
non-experimental deployment.</t>
<texttable><ttcol/><ttcol/>
<c>Registration Technical Contact</c><c>IESG <iesg@ietf.org></c>
<c>Registration Owner</c><c>IETF <iesg@ietf.org></c>
<c>Transport Protocol</c><c>SCTP, DCCP</c>
<c>Port Number</c><c> 1021</c>
<c>Port Name</c><c> RFC3692-style Experiment 1</c>
<c>Service Name</c><c> exp1</c>
<c>Reference</c><c> [RFCyyyy]</c>
</texttable>
<texttable><ttcol/><ttcol/>
<c>Registration Technical Contact</c><c>IESG <iesg@ietf.org></c>
<c>Registration Owner</c><c>IETF <iesg@ietf.org></c>
<c>Transport Protocol</c><c>SCTP, DCCP</c>
<c>Port Number</c><c> 1022</c>
<c>Port Name</c><c> RFC3692-style Experiment 2</c>
<c>Service Name</c><c> exp2</c>
<c>Reference</c><c> [RFCyyyy]</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 as defined in
<xref target="RFC4340" />.</t>
<section title="DCCP Service Code Registry">
<t>Service Codes are allocated first-come-first-served
according to Section 19.8 of
<xref target="RFC4340" />. This document updates
Section 19.8 of
<xref target="RFC4340" /> 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 when a request seeks an
appreciable number of Service Codes (e.g., more
than five).</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" />.</t>
</list>
</t>
</section>
<section title="DCCP Port Numbers Registry">
<t>The DCCP ports registry is defined by
<xref target="RFC4340" /> in Section 19.9. Allocations
in this registry require prior allocation of a Service
Code. Not all Service Codes require IANA-registered
ports. This document updates Section 19.9 of
<xref target="RFC4340" /> 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 Well Known Ports range (0 through 1023),
require an "IETF Review"
<xref target="RFC5226" /> prior to allocation by
IANA
<xref target="RFC4340" />.</t>
</list>
</t>
<t>Section 19.9 of
<xref target="RFC4340" /> requires each DCCP server
port assignment to be associated with at least one
Service Code value. This document updates
<xref target="RFC4340" /> in the following way:</t>
<t>
<list style="symbols">
<t>IANA MUST NOT allocate a single Service Code
value to more than one DCCP server port.</t>
<t>The set of Service Code values associated with
a DCCP server port should be recorded in the ports
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>
<xref target="RFC4340" /> notes that a short port name
MUST be associated with each DCCP server port that has
been registered. This document requires that this name
MUST be unique.</t>
</section>
</section>
</section>
<section anchor="ack" title="Acknowledgments">
<t>The text in
<xref target="dccp" /> is based on a suggestion by Tom
Phelan.</t>
<t>Lars Eggert is partly funded by
<xref target="TRILOGY" />, 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.ANSI.X3-4.1986" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.0959" ?>
<?rfc include="reference.RFC.1034" ?>
<?rfc include="reference.RFC.1078" ?>
<?rfc include="reference.RFC.2782" ?>
<?rfc include="reference.RFC.3692" ?>
<?rfc include="reference.RFC.4342" ?>
<?rfc include="reference.RFC.4960" ?>
<?rfc include="reference.RFC.5237" ?>
<?rfc include="reference.I-D.cheshire-dnsext-dns-sd" ?>
<?rfc include="reference.I-D.cheshire-dnsext-multicastdns" ?>
<?rfc include="reference.I-D.ietf-dccp-serv-codes" ?>
<!-- <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="REGISTRY">
<front>
<title>Port Numbers</title>
<author surname="Internet Assigned Numbers Authority (IANA)">
<organization />
</author>
</front>
<seriesInfo name=""
value="http://www.iana.org/assignments/port-numbers" />
</reference>
<reference anchor="SRVTYPE">
<front>
<title>DNS SRV (RFC 2782) Service Types</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>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 22:39:00 |