Skip to main content

Recommendations for Transport Port Uses
draft-ietf-tsvwg-port-use-04

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7605.
Author Dr. Joseph D. Touch
Last updated 2014-05-14
Replaces draft-touch-tsvwg-port-use
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd Gorry Fairhurst
IESG IESG state Became RFC 7605 (Best Current Practice)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Spencer Dawkins
Send notices to tsvwg-chairs@tools.ietf.org, draft-ietf-tsvwg-port-use@tools.ietf.org
draft-ietf-tsvwg-port-use-04
TSVWG                                                          J. Touch
Internet Draft                                                 USC/ISI
Intended status: Best Current Practice                     May 14, 2014
Expires: November 2014

                  Recommendations for Transport Port Uses
                     draft-ietf-tsvwg-port-use-04.txt

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on November 14, 2014.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

Touch                 Expires November 14, 2014                [Page 1]
Internet-Draft  Recommendations for Transport Port Use         May 2014

Abstract

   This document provides recommendations to application and service
   designers on how to use the transport protocol port number space to
   help in its preservation.

Table of Contents

   1. Introduction...................................................2
   2. Conventions used in this document..............................2
   3. History........................................................3
   4. Current Port Use...............................................4
   5. What is a Port?................................................5
   6. Conservation...................................................6
      6.1. Firewall and NAT Considerations...........................7
   7. How to Use Assigned Ports......................................8
      7.1. Is a port assignment necessary?...........................8
      7.2. How Many Ports?..........................................10
      7.3. Picking a Port Number....................................10
      7.4. Support for Security.....................................11
      7.5. Support for Future Versions..............................12
      7.6. Transport Protocols......................................13
      7.7. When to Request an Assignment............................14
      7.8. Squatting................................................15
      7.9. Other Considerations.....................................16
   8. Security Considerations.......................................16
   9. IANA Considerations...........................................16
   10. References...................................................16
      10.1. Normative References....................................16
      10.2. Informative References..................................17
   11. Acknowledgments..............................................19

1. Introduction

   This document provides information and advice to system designers on
   the use of transport port numbers and services. It provides a
   detailed historical background of the evolution of transport port
   numbers and their multiple meanings. It also provides specific
   recommendations on how to use assigned ports.

2. Conventions used in this document

   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 RFC-2119 [RFC2119].

Touch                 Expires November 14, 2014                [Page 2]
Internet-Draft  Recommendations for Transport Port Use         May 2014

   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.

   In this document, the characters ">>" preceding an indented line(s)
   indicates a compliance requirement statement using the key words
   listed above. This convention aids reviewers in quickly identifying
   or finding the explicit compliance requirements of this RFC.

3. History

   The term 'port' was first used in [RFC33] to indicate a simplex
   communication path from an individual process. At a meeting
   described in [RFC37], an idea was presented to decouple connections
   between processes and links that they use as paths, and thus to
   include source and destination socket identifiers in packets.
   [RFC38] provides further detail, describing how processes might have
   more than one of these paths and that more than one path may be
   active at a time. As a result, there was the need to add a process
   identifier to the header of each message so that incoming messages
   could be demultiplexed to the appropriate process. [RFC38] further
   suggested that 32 bits would be used for these identifiers. [RFC48]
   discusses the current notion of listening on a specific port, but
   does not discuss the issue of port determination. [RFC61] notes that
   the challenge of knowing the appropriate port numbers is "left to
   the processes" in general, but introduces the concept of a "well-
   known" port for common services.

   [RFC76] proposed a "telephone book" by which an index would allow
   ports to be used by name, but still assumed that both source and
   destination ports are fixed by such a system. [RFC333] proposed that
   a port pair, rather than an individual port, would be used on both
   sides of the connection for demultiplexing messages. This is the
   final view in [RFC793] (and its predecessors, including [IEN112]),
   and brings us to their current meaning. [RFC739] introduced the
   notion of generic reserved ports for groups of protocols, such as
   "any private RJE server" [RFC739]. Although the overall range of
   such ports was (and remains) 16 bits, only the first 256 (high 8
   bits cleared) in the range were considered assigned.

   [RFC758] is the first to describe a list of such well-known ports,
   as well as describing ranges used for different purposes:

Touch                 Expires November 14, 2014                [Page 3]
Internet-Draft  Recommendations for Transport Port Use         May 2014

      Binary    Octal

      -----------------------------------------------------------

      0-63      0-77      Network Wide Standard Function

      64-127    100-177   Hosts Specific Functions

      128-223   200-337   Reserved for Future Use

      224-255   340-377   Any Experimental Function

   In [RFC820] those range meanings disappeared, and a single list of
   assignments is presented. By [RFC900] the ranges appeared as decimal
   numbers rather than the octal ranges used previously. [RFC1340]
   increased this range from 0..255 to 0..1023, and began to list TCP
   and UDP port assignments individually (although the assumption was,
   and remains, that once assigned a port applies to all transport
   protocols, including TCP, UDP, recently SCTP and DCCP, as well as
   ISO-TP4 for a brief period in the early 1990s). [RFC1340] also
   established the Registered range of 1024-59151, though it notes that
   it is not controlled by the IANA at that point. The list provided by
   [RFC1700] in 1994 remained the standard until it was declared
   replaced by an on-line version, as of [RFC3232] in 2002.

4. Current Port Use

   The current IANA website (www.iana.org) indicates three ranges of
   port assignments:

      Binary         Hex

      -----------------------------------------------------------

      0-1023         0x03FF         Well-Known (also System)

      1024-49151     0x0400-0xBFFF  Registered (also User)

      49152-65535    0xC000-0xFFFF  Dynamic (also Private)

   Well-known encompasses the range 0..1023. On some systems, use of
   these ports requires privileged access, e.g., that the process run
   as 'root', which is why these are referred to as System ports. The
   ports from 1024..49151 denotes non-privileged services, known as
   Registered; because these ports do not run with special privileges,
   they are often referred to as User ports. Dynamic (also known as
   Private) ports are not assigned.

Touch                 Expires November 14, 2014                [Page 4]
Internet-Draft  Recommendations for Transport Port Use         May 2014

   Both Well-Known and Registered ports are assigned through IANA, so
   both are sometimes called 'registered ports'. As a result, the term
   'registered' is ambiguous, referring either to the entire range 0-
   49151 or to the User ports. Complicating matters further, System
   ports do not always require special (i.e., 'root') privilege. For
   clarity, the remainder of this document refers to the port ranges as
   System, User, and Dynamic.

5. What is a Port?

   A port is a 16-bit number used for two distinct purposes:

      o  Demultiplexing transport connections within an end host

      o  Identifying a service

   The first purpose requires that each transport connection between a
   given pair of IP addresses use a different pair of ports, but does
   not require either coordination or registration of port use. It is
   the second purpose that drives the need for a common registry.

   Consider a user wanting to run a web server. That service could run
   on any port, provided that all clients knew what port to use to
   access that service at that host. Such information can be
   distributed out-of-band, e.g., in the URI:

      http://www.example.com:51509/

   Ultimately, the correlation of a service with a port number is an
   agreement between just the two endpoints of the connection. A web
   server can run on port 53, which might appear as DNS traffic to
   others but will connect to browsers that know to use port 53 rather
   than 80.

   As a concept, a service is the combination of ISO Layers 5-7 that
   represents an application protocol capability. For example www (port
   80) is a service that uses HTTP as an application protocol and
   provides access to a web server [RFC2616]. However, it is possible
   to use HTTP for other purposes, such as command and control. This is
   why some current service names (HTTP, e.g.) are a bit overloaded -
   they describe not only the application protocol, but a particular
   service.

   IANA assigns ports so that Internet endpoints do not need pairwise,
   explicit coordination of the meaning of their port numbers. This is
   the primary reason for requesting assigned ports with IANA - to have

Touch                 Expires November 14, 2014                [Page 5]
Internet-Draft  Recommendations for Transport Port Use         May 2014

   a common agreement between all endpoints on the Internet as to the
   meaning of a port.

   Ports are sometimes used by intermediate devices on a network path,
   either to monitor available services, to monitor traffic (e.g., to
   indicate the data contents), or to intercept traffic (to block,
   proxy, relay, aggregate, or otherwise process it). In each case, the
   intermediate device interprets traffic based on the port number. It
   is important to recognize that any interpretation of ports - except
   at the endpoints - may be incorrect, because ports are meaningful
   only at the endpoints. Further, ports may not be visible to these
   intermediate devices, such as when the transport protocol is
   encrypted (as in network- or link-layer tunnels), or when a packet
   is fragmented (in which case only the first fragment has the port
   information). Such port invisibility may interfere with these in-
   network port-based capabilities.

   Ports can also be useful for other purposes. Assigned ports can
   simplify end system configuration, so that individual installations
   do not need to coordinate their use of arbitrary ports. Such
   assignments can also simplify firewall management, so that a single,
   fixed firewall configuration can either permit or deny a service.

6. Conservation

   Assigned ports are a scarce resource that is globally shared by the
   entire Internet community. As a result, every attempt should be made
   to conserve ports and request assignments only for those that are
   absolutely necessary.

   There are a variety of ways that systems can conserve port numbers:

      o  A single assigned port number can support different functions
         over separate connections, determined using in-band
         information. FTP data connection can transfer binary or text
         files, the latter translating line-terminators, as indicated
         in-band over the control port [RFC959].

      o  A single assigned port can indicate the Dynamic port(s) on
         which different capabilities are supported, as with passive-
         mode FTP [RFC959].

      o  Several existing services can indicate the Dynamic port(s) on
         which other services are supported, such as with mDNS and
         portmapper [RFC1833] [RFC6762] [RFC6763].

Touch                 Expires November 14, 2014                [Page 6]
Internet-Draft  Recommendations for Transport Port Use         May 2014

      o  Copies of an existing service can be differentiated by using
         different IP addresses, either on different hosts or as
         different real or virtual interfaces (or even operating
         systems) on the same host.

      o  Copies of some existing services can be differentiated using
         in-band information (e.g., URIs in HTTP Host field and TLS
         Server Name Indication extension) [RFC2616] [RFC3546].

      o  Different performance requirements can already be supported
         using separate connections or endpoints with different
         capabilities or configurations.

   Port numbers are intended to differentiate services, not
   performance, replicas, connections, or payload types. Port numbers
   are also a very small space, so it is never appropriate to consume
   port numbers to save larger spaces, such as IP addresses.

   Others have noted "think twice about modifying TCP, then don't"
   [RFC1263]. In this case, similar advice might be:

      o  Think twice before asking for an assigned port, then try not
         to.

      o  If more than one port is desired, consider revising the
         architecture until only one is needed, or, preferably, none.

6.1. Firewall and NAT Considerations

   Assigned ports are useful for configuring firewalls and other port-
   based systems for access control. Ultimately, these ports indicate
   services only to the endpoints, and any intermediate device that
   assigns meaning to a value can be incorrect. End systems might agree
   to run web services (HTTP) over port 53 (typically used for DNS)
   rather than port 80, at which point a firewall that blocks port 80
   but permits port 53 would not have the desired effect. However,
   assigned ports often are important in helping configure firewalls.

   Using Dynamic ports, or explicitly-indicated ports indicated in-band
   over another service (such as with FTP) often complicates firewall
   and NAT interactions [RFC959]. FTP over firewalls often requires
   direct support for deep-packet inspection (to snoop for the Dynamic
   port for the NAT to correctly map) or passive-mode FTP (in which
   both connections are opened from the client side).

Touch                 Expires November 14, 2014                [Page 7]
Internet-Draft  Recommendations for Transport Port Use         May 2014

7. How to Use Assigned Ports

   Ports are assigned by IANA by a set of documented procedures [RFC
   6335]. The following section describes the steps users can take to
   help assist with the use of assigned ports, and with preparing an
   application for a port assignment.

7.1. Is a port assignment necessary?

   First, it is useful to consider whether a port assignment is
   required. In many cases, a new assignment may not be needed, for
   example:

      o  Is this really a new service, or can an existing service
         suffice?

      o  Is this an experimental service [RFC3692]? If so, consider
         using the current experimental ports [RFC2780].

      o  Is this service independently useful? Some systems are
         composed from collections of different service capabilities,
         but not all component functions are useful as independent
         services. Ports are typically shared among the smallest
         independently-useful set of functions. Different service uses
         or properties can be supported in separate connections after
         an initial negotiation, e.g., to support software
         decomposition.

      o  Can this service use a Dynamic port that is coordinated out-
         of-band, e.g.:

          o By explicit configuration of both endpoints.

          o By shared information within the same host (e.g., a
             configuration file or indicated within a URI).

          o Using information exchanged on a related service: FTP, SIP,
             etc. [RFC959] [RFC2543].

          o Using an existing port discovery service: portmapper, mDNS,
             etc. [RFC1833] [RFC6762] [RFC6763].

   There are a few good examples of reasons that more directly suggest
   that not only is a port not necessary, but it is directly counter-
   indicated:

Touch                 Expires November 14, 2014                [Page 8]
Internet-Draft  Recommendations for Transport Port Use         May 2014

      o  Ports are not for performance. Performance enhancement can
         occur within separate connections.

      o  Additional ports are not to replicate an existing service. For
         example, a device is configured using a typical web browser
         then it is a copy of HTTP port 80 and does not warrant a new
         assignment. However, an automated system that happens to use
         HTTP framing - but cannot be accessed by a browser - might be
         a new service. A good way to tell is "can an unmodified client
         of the existing service interact with the proposed service"?
         If so, that service would be a copy of an existing service and
         does not merit a new assignment.

      o  Separate ports are not for insecure versions of existing (or
         new) secure services. Consider that a service that includes
         required security would be made vulnerable by having the same
         capability accessible without security.

         Note that the converse is different, i.e., it can be useful to
         create a new, secure service that replicates an existing
         insecure service on a new port assignment. This can be
         necessary when the existing service is not backward-compatible
         with security enhancements, such as the use of TLS or SSL
         [Hi95] [RFC5246].

         New services should support security or should consider
         optional security. A new service should not need a port for an
         insecure version; at best, this would be a performance issue
         (see the first bullet), and at worst this presents a new
         vulnerability.

      o  Ports are not for indicating different service versions.
         Version differentiation should be handled in-band, e.g., using
         a version number at the beginning of a connection or
         transaction. This may not be possible with legacy assignments,
         but all new assignments should incorporate support for version
         indication.

   Some users may not need assigned port numbers at all, e.g., SIP
   allows voice calls to use Dynamic ports [RFC2543]. Some systems can
   register services in the DNS, using SRV entries. These services can
   be discovered by a variety of means, including mDNS, or via direct
   query [RFC6762] [RFC6763]. In such cases, users can more easily
   request a SRV name, which are assigned first-come, first-served from
   a much larger namespace.

Touch                 Expires November 14, 2014                [Page 9]
Internet-Draft  Recommendations for Transport Port Use         May 2014

   IANA assigns port numbers, but this assignment is typically used
   only for servers, i.e., the host that listens for incoming
   connections. Clients, i.e., hosts that initiate connections,
   typically refer to those assigned ports but do not need port
   assignments for their endpoint.

7.2. How Many Ports?

   As noted earlier, systems might require a single port assignment,
   but rarely require multiple ports. There are a variety of known ways
   to reduce port use. Although some may be cumbersome or inefficient,
   they are always preferable to consuming additional ports.

   Such techniques include:

      o  Use of a discovery service, either a shared service (mDNS), or
         a discovery service for a given system [RFC6762] [RFC6763].

      o  Multiplex packet types using in-band information, either on a
         per-message or per-connection basis. Such demultiplexing can
         even hand-off different connections and types of connections
         among different processes, such as is done with FTP [RFC959].

   There are some cases where it is still important to have assigned
   port numbers, largely to traverse either NATs or firewalls. Although
   automatic configuration protocols have been proposed and developed,
   system designers cannot yet rely on their presence.

   In the past, some services were assigned multiple ports or sometimes
   fairly large port ranges (e.g., X11). This occurred for a variety of
   reasons: port conservation was not widely understood, assignments
   were not as ardently reviewed, etc. This no longer reflects current
   practice and such assignments are not considered to constitute a
   precedent for future assignments.

7.3. Picking a Port Number

   Given a demonstrated need for a port number assignment, the next
   question is how to pick the desired port number. An application for
   a port assignment does not need to include a desired port number; in
   that case, IANA will select from those currently available.

   Users should consider whether the requested port number is
   important. For example, would an assignment be acceptable if IANA
   picked the port number value? Would a TCP port number assignment be
   needed useful if the corresponding UDP one were unavailable
   (assuming the proposed service needed only a TCP port)?

Touch                 Expires November 14, 2014               [Page 10]
Internet-Draft  Recommendations for Transport Port Use         May 2014

   The most critical issue in picking a number is selecting the desired
   range, i.e., System vs. User ports. The distinction was intended to
   indicate a difference in privilege; originally, System ports
   required privileged ('root') access, while User ports did not. That
   distinction has since blurred because some current systems do not
   limit access control to System ports and because some System
   services have been replicated on User numbers (e.g., IRC). Even so,
   System port assignments have continued at an average rate of 3-4 per
   year over the past 7 years (2007-2013), indicating that the desire
   to keep this distinction continues.

   As a result, the difference between System and User ports needs to
   be treated with caution. Developers are advised to treat services as
   if they are always run without privilege. As a result:

   >> Developers SHOULD NOT apply for System ports because the
   increased privilege they provide is not always enforced.

   Even when developers seek a System port, it may be very difficult to
   obtain. System port assignment requires IETF Review or IESG Approval
   and justification that both User and Dynamic port ranges are
   insufficient [RFC6335].

   >> System implementers SHOULD enforce the need for privilege for
   processes to listen on System ports.

   At some future date, it might be useful to deprecate the distinction
   between System and User ports altogether. Services typically require
   elevated ('root') privileges to bind to a System port, but many such
   services go to great lengths to immediately drop those privileges
   just after connection establishment to reduce the impact of an
   attack using their capabilities. Such services might be more
   securely operated on User ports than on System ports. Further, if
   System ports were no longer assigned, it would cost only 180 of the
   1024 system values (17%), or 180 of the overall 49152 assigned
   values (<0.04%).

7.4. Support for Security

   Just as a service is a way to obtain information or processing from
   a host over a network, an service can also be the opening through
   which to attack that host. Given the current state of cybersecurity
   in the Internet, the following advice is prudent:

   >> New services SHOULD support security, either directly or via a
   secure transport such as TLS [RFC5246].

Touch                 Expires November 14, 2014               [Page 11]
Internet-Draft  Recommendations for Transport Port Use         May 2014

   >> Insecure versions of new secure services SHOULD be avoided
   because of the new vulnerability they create.

   >> Security SHOULD NOT rely on port number distinctions alone; every
   service, whether secure or not, SHOULD expect to be attacked.

   There is debate as to how to secure legacy insecure services
   [RFC6335]. Some argue that secure variants should share the existing
   port assignment, such that security is enabled on a per-connection
   basis [RFC2817]. Others argue that security should be supported on a
   new port assignment and be enabled by default. IANA currently
   permits either approach, although use of a single port is consistent
   with port conservation. A separate port might be important for
   security coordination (e.g., firewall management), but this might
   further argue for deprecation of the insecure variant.

   Optional security can penalize performance, requiring additional
   round-trip exchanges before a connection can be established. As
   discussed earlier, ports are a critical resource and it is
   inappropriate to consume assignments to increase performance.

   Note however that a new service might not be eligible for IANA
   assignment of both an insecure and a secure variant of the same
   service, and similarly IANA might be skeptical of an assignment for
   an insecure port for a secure service. In both cases, security of
   the service is compromised by adding the insecure port assignment.

7.5. Support for Future Versions

   Current IANA assignments are expected to support the multiple
   versions on the same assigned port [RFC6335]. Versions are typically
   indicated in-band, either at the beginning of a connection or
   association, or in each protocol message.

   >> Version support SHOULD be included in new services.

   >> Version numbers SHOULD NOT be included in either the service name
   or service description.

   Again, the port number space is far too limited to be used as an
   indicator of protocol version or message type. Although this has
   happened in the past (e.g., for NFS), it should be avoided in new
   requests.

Touch                 Expires November 14, 2014               [Page 12]
Internet-Draft  Recommendations for Transport Port Use         May 2014

7.6. Transport Protocols

   IANA assigns port numbers specific to one or more transport
   protocols, typically UDP and TCP, but also SCTP, DCCP, and any other
   standard transport protocol [RFC768] [RFC793] [RFC4340] [RFC4960].
   Originally, IANA port assignments were concurrent for both UDP and
   TCP; other transports were not indicated. However, to conserve space
   and to reflect increasing use of other transports, assignments are
   now specific only to the transport being used.

   In general, a service should request assignments for multiple
   transports using the same service name and description on the same
   port number only when they all reflect essentially the same service.
   Good examples of such use are DNS and NFS, where the difference
   between the UDP and TCP services are specific to supporting each
   transport. E.g., the UDP variant of a service might add sequence
   numbers and the TCP variant of the same service might add in-band
   message delimiters.

   >> Service names and descriptions for multiple transport port
   assignments SHOULD match only when they describe the same service,
   excepting only enhancements for each supported transport.

   When the services differ, their service names and descriptions
   should reflect that difference. E.g., if TCP is used for the basic
   control protocol and UDP for an alarm protocol, then the services
   might be "name-ctl" and "name-alarm". A common example is when TCP
   is used for a service and UDP is used to determine whether that
   service is active (e.g., via a unicast, broadcast, or multicast test
   message) [RFC1122]. The following convention has been used by IANA
   for several years to indicate this case:

   >> When UDP is used for discovery of an active TCP service, the UDP
   service name SHOULD end in "-disc".

   Some services are used for discovery, either in conjunction with a
   TCP service or as a stand-alone capability. Such services will be
   more reliable when using multicast rather than broadcast (over IPv4)
   because IP routers do not forward "all nodes" (all 1's, i.e.,
   255.255.255.255 for IPv4) broadcasts and have not been required to
   support subnet-directed broadcasts since 1999 [RFC1812] [RFC2644].
   This issue is relevant only for IPv4 because IPv6 does not support
   broadcast.

   >> UDP over IPv4 multi-host services SHOULD use multicast rather
   than broadcast.

Touch                 Expires November 14, 2014               [Page 13]
Internet-Draft  Recommendations for Transport Port Use         May 2014

   Designers should be very careful in creating services over
   transports that do not support congestion control or error recovery,
   notably UDP. There are several issues that should be considered in
   such cases, each summarized from [RFC5405]:

   >> UDP services SHOULD be rate limited so that they use only nominal
   network capacity. Users should keep in mind that "nominal" may vary
   depending on the deployment environment and may be very low.

   >> UDP services that use multipoint communication SHOULD be
   scalable, and SHOULD NOT rely solely on the efficiency of multicast
   transmission for scalability.

   >> UDP services SHOULD include congestion detection and back-off.

   >> UDP SHOULD NOT be used as a performance enhancement over TCP,
   i.e., to circumnavigate TCP's congestion control.

7.7. When to Request an Assignment

   Assignments are typically requested when a user has enough
   information to reasonably answer the questions in the IANA
   application. IANA applications typically take up to a few weeks to
   process, with some complex cases taking up to a month. The process
   typically involves a few exchanges between the IANA Ports Expert
   Review team and the applicant.

   An application needs to include a description of the service, as
   well as to address key questions designed to help IANA determine
   whether the assignment is justified.

   Services that are independently developed can be requested at any
   time, but are typically best requested in the last stages of design
   and initial experimentation, before any deployment has occurred that
   cannot easily be updated.

   >> Users MUST NOT deploy implementations that use assigned ports
   prior their assignment by IANA.

   >> Users MUST NOT deploy implementations that default to using the
   experimental System ports (1021 and 1022 [RFC4727]) outside a
   controlled environment where they can be updated with a subsequent
   assigned port [RFC3692].

   Deployments that use ports before deployment complicate IANA
   management of the port space. Keep in mind that this recommendation
   protects existing assignees, users of current services, and

Touch                 Expires November 14, 2014               [Page 14]
Internet-Draft  Recommendations for Transport Port Use         May 2014

   applicants for new assignments; it helps ensure that a desired
   number and service name are available when assigned. The list of
   currently unassigned numbers is just that - *currently* unassigned.
   It does not reflect pending applications. Waiting for an official
   IANA assignment reduces the chance that an assignment request will
   conflict with another deployed service.

   Applications made through Internet Draft / RFC publication typically
   use a placeholder ("PORTNUM") in the text, and use an experimental
   port number until a final assignment has been made [RFC6335]. That
   assignment is initially indicated in the IANA Considerations section
   of the document, and is tracked by the RFC Editor. When the RFC
   reaches the last stages of publication, that request is forwarded to
   IANA for handling. At that time, IANA typically requests that the
   applicant fill out the application form on their website, because
   not every protocol document addresses the information required.
   "Early" assignments can be made when justified, e.g., for early
   interoperability testing, according to existing process [RFC4020]
   [RFC6335].

   Using this single application process also ensures that IANA has
   complete information even if the RFC publication is interrupted. For
   this reason as well, the application should be complete and not
   refer solely to the Internet Draft, RFC, a website, or any other
   external documentation.

   >> Users writing specifications SHOULD use symbolic names for port
   numbers and service names until an IANA assignment has been
   completed.

7.8. Squatting

   "Squatting" describes the use of a number from the assigned range in
   deployed software without IANA assignment. It is hazardous because
   IANA cannot track such usage and thus cannot avoid making legitimate
   assignments that conflict with such unauthorized usage.

   Note that there are numerous services that have squatted on such
   numbers that are in widespread use. Even such widespread de-facto
   use may not justify a later IANA assignment of that value,
   especially if either the value has already been assigned to a
   legitimate applicant or if the service would not qualify for an
   assignment of its own accord.

Touch                 Expires November 14, 2014               [Page 15]
Internet-Draft  Recommendations for Transport Port Use         May 2014

7.9. Other Considerations

   As noted earlier, System ports should be used sparingly, and it is
   better to avoid them altogether. This avoids the potentially
   incorrect assumption that the service on such ports run in a
   privileged mode.

   Port names and numbers are not intended to be changed. Once
   deployed, it can be very difficult to recall every implementation,
   so the assignment should be retained. However, in cases where the
   current assignee of a name or number has reasonable knowledge of the
   impact on such uses, and is willing to accept that impact, the name
   or number of an assignment can be changed [RFC6335]

   Aliases, or multiple service names for the same port number, are no
   longer considered appropriate [RFC6335].

8. Security Considerations

   This document discusses ways to conserve port numbers, notably
   through encouraging demultiplexing within a single port.  As such,
   there may be cases where two variants of a protocol - insecure and
   secure (such as using optional TLS) or different versions - are
   suggested to share the same port.

   This document reminds protocol designers that port numbers are not a
   substitute for security, and should not alone be used to avoid
   denial of service or firewall traffic, notably because their use is
   not regulated or validated.

9. IANA Considerations

   The entirety of this document focuses on IANA issues, notably
   suggestions that help ensure the conservation of port numbers and
   provide useful hints for issuing informative requests thereof.

10. References

10.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2780] Bradner, S., and V. Paxson, "IANA Allocation Guidelines
             For Values In the Internet Protocol and Related Headers",
             BCP 37, RFC 2780, March 2000.

Touch                 Expires November 14, 2014               [Page 16]
Internet-Draft  Recommendations for Transport Port Use         May 2014

   [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
             Considered Useful", BCP 82, RFC 3962, Jan. 2004.

   [RFC4727] Fenner, B., "Experimental Values in IPv4, IPv6, ICMPv4,
             ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.

   [RFC5405] Eggert, L., and G. Fairhurst, "Unicast UDP Usage
             Guidelines for Application Designers", BCP 145, RFC 5405,
             Nov. 2008.

   [RFC6335] Cotton, M., L. Eggert, J. Touch, M. Westerlund, and S.
             Cheshire, "Internet Assigned Numbers Authority (IANA)
             Procedures for the Management of the Service Name and
             Transport Protocol Port Number Registry", BCP 165, RFC
             6335, August 2011.

10.2. Informative References

   [Hi95]    Hickman, K., "The SSL Protocol", February 1995.

   [IEN112]  Postel, J., "Transmission Control Protocol", IEN 112,
             August 1979.

   [RFC33]   Crocker, S., "New Host-Host Protocol", RFC 33 February
             1970.

   [RFC37]   Crocker, S., "Network Meeting Epilogue", RFC 37, March
             1970.

   [RFC38]   Wolfe, S., "Comments on Network Protocol from NWG/RFC
             #36", RFC 38, March 1970.

   [RFC48]   Postel, J., and S. Crocker, "Possible protocol plateau",
             RFC 48, April 1970.

   [RFC61]   Walden, D., "Note on Interprocess Communication in a
             Resource Sharing Computer Network", RFC 61, July 1970.

   [RFC76]   Bouknight, J., J. Madden, and G. Grossman, "Connection by
             name: User oriented protocol", RFC 76, October 1970.

   [RFC333]  Bressler, R., D. Murphy, and D. Walden. "Proposed
             experiment with a Message Switching Protocol", RFC 333,
             May 1972.

   [RFC739]  Postel, J., "Assigned numbers", RFC 739, November 1977.

Touch                 Expires November 14, 2014               [Page 17]
Internet-Draft  Recommendations for Transport Port Use         May 2014

   [RFC758]  Postel, J., "Assigned numbers", RFC 758, August 1979.

   [RFC768]  Postel, J., "User Datagram Protocol", RFC 768, August
             1980.

   [RFC793]  Postel, J., "Transmission Control Protocol" RFC 793,
             September 1981

   [RFC820]  Postel, J., "Assigned numbers", RFC 820, August 1982.

   [RFC900]  Reynolds, J., and J. Postel, "Assigned numbers", RFC 900,
             June 1984.

   [RFC959]  Postel, J., and J. Reynolds, "FILE TRANSFER PROTOCOL
             (FTP)", RFC 959, October 1985.

   [RFC1122] Braden, B. (Ed.), "Requirements for Internet Hosts --
             Communication Layers", RFC 1122, October 1989.

   [RFC1263] O'Malley, S., and L. Peterson, "TCP Extensions Considered
             Harmful", RFC 1263, October 1991.

   [RFC1340] Reynolds, J., and J. Postel, "Assigned numbers", RFC 1340,
             July 1992.

   [RFC1700] Reynolds, J., and J. Postel, "Assigned numbers", RFC 1700,
             October 1994.

   [RFC1812] Baker, F. (Ed.), "Requirements for IP Version 4 Routers",
             RFC 1812, June 1995.

   [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
             RFC 1833, August 1995.

   [RFC2543] Handley, M., H. Schulzrinne, E. Schooler, and J.
             Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
             March 1999.

   [RFC2616] Fielding, R., J. Gettys, J. Mogul, H. Frystyk, L.
             Masinter, P. Leach, and T. Berners-Lee, "Hypertext
             Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts
             in Routers", RFC 2644, August 1999.

   [RFC2817] Khare, R., and S. Lawrence, "Upgrading to TLS Within
             HTTP/1.1", RFC 2817, May 2000.

Touch                 Expires November 14, 2014               [Page 18]
Internet-Draft  Recommendations for Transport Port Use         May 2014

   [RFC3232] Reynolds, J. (Ed.), "Assigned Numbers: RFC 1700 is
             Replaced by an On-line Database", RFC 3232, January 2002.

   [RFC3546] Blake-Wilson, S., D. Hopwood, and T. Wright, "Transport
             Layer Security (TLS) Extensions", RFC 3546, June 2003.

   [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of
             Standards Track Code Points", BCP 100, RFC 4020, February
             2005.

   [RFC4340] Kohler, E., M. Handley, and S. Floyd, "Datagram Congestion
             Control Protocol (DCCP)", RFC 4340, March 2006.

   [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol",
             RFC 4960, September 2007.

   [RFC5246] Dierks, T., and E. Rescorla, "The Transport Layer Security
             (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC6762] Cheshire, S., and M. Krochmal, "Multicast DNS", RFC 6762,
             February 2013.

   [RFC6763] Cheshire, S., and M. Krochmal, "DNS-Based Service
             Discovery", RFC 6763, February 2013.

11. Acknowledgments

   This work benefitted from the feedback from Lars Eggert, Gorry
   Fairhurst, and Eliot Lear, as well as discussions of the IETF TSVWG
   WG.

   This document was prepared using 2-Word-v2.0.template.dot.

Authors' Addresses

   Joe Touch
   USC/ISI
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695
   U.S.A.

   Phone: +1 (310) 448-9151
   EMail: touch@isi.edu

Touch                 Expires November 14, 2014               [Page 19]