IANA Allocation Guidelines for TCP and UDP Port Numbers
draft-cotton-tsvwg-iana-ports-00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 August 21, 2008.

Abstract

This document defines the IANA guidelines for registering new port number values for use with the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). It provides clear processes for the TCP and UDP port number registries, important for their long-term management. It updates RFC2780 by replacing Sections 8 and 9.1 of that RFC.

Table of Contents

1.  Introduction
2.  Terminology
3.  Stewardship Principles for the Port Number Space
4.  Allocation Procedures for the Port Number Space
    4.1.  Common Procedures
    4.2.  Well Known (System) Ports
    4.3.  Registered (User) Ports
    4.4.  Dynamic (Private) Ports
5.  Supplemental Procedures for the Port Number Space
    5.1.  Port Number De-Registration
    5.2.  Port Number Re-Use
    5.3.  Port Number Revocation
6.  Security Considerations
7.  IANA Considerations
8.  Acknowledgments
9.  References
    9.1.  Normative References
    9.2.  Informative References
Appendix A.  Open Issues
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

The Transmission Control Protocol (TCP) [RFC0793] (Postel, J., “Transmission Control Protocol,” September 1981.) and the User Datagram Protocol (UDP) [RFC0768] (Postel, J., “User Datagram Protocol,” August 1980.) 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 that end system applications bind their transport sessions to. Ports are identified by 16-bit numbers, and the combination of source and destination port numbers together with the IP addresses communicating end systems uniquely identifies a session of a given transport protocol. Newer transport protocols, such as the Stream Control Transmission Protocol (SCTP) [RFC4960] (Stewart, R., “Stream Control Transmission Protocol,” September 2007.) and the Datagram Congestion Control Protocol (DCCP) [RFC4342] (Floyd, S., Kohler, E., and J. Padhye, “Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC),” March 2006.) have adopted the concept of ports for their communication sessions and use port numbers in the same way as TCP and UDP.

Port numbers are the original and most widely used means for application and service identification on the Internet. Designers of applications and application-level protocols may apply to the Internet Assigned Numbers Authority (IANA) for a registered port number for a specific application, and may after successful registration assume that no other application will use that port number for its communication sessions. It is important to note that ownership of registered port numbers remains with IANA.

For many years, the allocation and registration of new port number values for use with TCP and UDP have had less than clear guidelines. Information about the registration procedures for the port namespace existed in three locations: the forms for requesting port number registrations on the IANA web site [SYSFORM] (Internet Assigned Numbers Authority (IANA), “Application for System (Well Known) Port Number,” .)[USRFORM] (Internet Assigned Numbers Authority (IANA), “Application for User (Registered) Port Number,” .), an introductory text section in the file listing the port number registrations themselves [REGISTRY] (Internet Assigned Numbers Authority (IANA), “Port Numbers,” .), and two brief sections of [RFC2780] (Bradner, S. and V. Paxson, “IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers,” March 2000.).

This document aggregates this scattered information into a single reference and at the same time clarifies the guidelines for the management of the TCP and UDP port number space. It gives more detailed guidance to prospective requesters of TCP and UDP ports than the existing documentation, and it streamlines the IANA procedures for the management of the port number space, so that management requests can complete in a timely manner. A key factor of this streamlining is to establish identical registration procedures for transport protocol ports, independent of a specific transport protocol. 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 port number requests for all transport protocols.

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 space. TCP and UDP have been a remarkable success over the last decades. Thousands of applications and application-level protocols have registered ports 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 port number space follow principles that ensure its long-term usefulness as a shared resource. Section 3 (Stewardship Principles for the Port Number Space) discusses these principles in detail.

TCP and UDP use 16-bit namespaces for their port number registries, as do SCTP and DCCP. These ports registries are subdivided into three port number ranges, and Section 4 (Allocation Procedures for the Port Number Space) describes the IANA procedures for each range in detail:

• the Well Known Ports, aka the System Ports, from 0-1023
• the Registered Ports, aka the User Ports, from 1024-49151
• the Dynamic Ports, aka the Private Ports, from 49152-65535

When this document was being written, approximately 76% of the Well Known Ports for TCP and UDP were assigned, as was a significant fraction of the Registered Ports. (Dynamic Ports are not available for assignment through IANA.)

In addition to detailing the IANA procedures for the initial assignment of port numbers, this document also specifies supplemental 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. Section 5 (Supplemental Procedures for the Port Number Space) discusses the specifics of these procedures.

Finally, this document also addresses two technical issues with ports registry that are tangential to long-term stewardship. First, it clarifies that a method for the early allocation of TCP and UDP ports for IETF working group documents is available, in line with [RFC4020] (Kompella, K. and A. Zinin, “Early IANA Allocation of Standards Track Code Points,” February 2005.). Second, it discusses how the use of the symbolic names for assigned ports (the "keyword" field in [REGISTRY] (Internet Assigned Numbers Authority (IANA), “Port Numbers,” .)) for Service Resource Records (SRV RRs) in the Domain Name System (DNS) [RFC2782] (Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” February 2000.) relates to the use of SRV RRs for applications without an assigned port.

This document updates [RFC2780] (Bradner, S. and V. Paxson, “IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers,” March 2000.) by replacing Sections 8 and 9.1 of that RFC. Note that [I‑D.arkko‑rfc2780‑proto‑update] (Arkko, J. and S. Bradner, “IANA Allocation Guidelines for the Protocol Field,” January 2008.) updates a different subset of the IANA allocation guidelines originally given in [RFC2780] (Bradner, S. and V. Paxson, “IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers,” March 2000.) (specifically, the policies on the namespace of the IP protocol number and IPv6 next header).

2.  Terminology

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Stewardship Principles for the Port Number Space

The overriding principle that governs the IANA and IETF procedures governing the management of the port number registry for the different transport protocols is conservation. The port number registry is one of the basic resources of the Internet and requires careful management. Exhaustion is likely to require fundamental changes to Internet communication, which is undesirable.

At the same time, it is of great benefit to all Internet applications to request and receive port number allocations from IANA for their communication needs. This means that although IANA should require and verify that applicants for port numbers document their intended use to a degree that lets a technical expert review the desired allocation, this process must not appear to be an insurmountable burden. Otherwise, there is the danger that application designers turn to using ports in an undocumented fashion, which is harmful to Internet communications as a whole. Clearly stated and motivated procedures support this goal.

It is important to note that different IANA procedures apply to different ranges of the port number registry. Section 4 (Allocation Procedures for the Port Number Space) discusses the details of these procedures; this section outlines the rationale for these differences:

• 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 cannot be used as a service identifier.
• Ports in the Registered Ports range (1024-49151) are available for registration through IANA, and can 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, and have a technical expert review this documentation to determine whether to grant the registration request. This documentation must explain why a port number in the Dynamic Ports range is unsuitable for the given application.
• 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 (1024-49551). A request for a Well Known port number must document why a port number in the Registered Ports of Dynamic Ports ranges are unsuitable.

Several other practices stem from the conservation principle that guides management of the port numbers registry.

First, with the approval of this document, IANA will begin assigning protocol numbers only for those transport protocols explicitly included in the 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, they must request IANA to convert the reservation to 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 a registration with IANA.

Second, IANA will continue its long-standing practice of refusing allocations for applications that request the assignments of multiple port numbers. Registered port numbers are application identifiers, and extremely few applications require multiple identifiers. For applications that do require a registered port number in the first place, the vast majority of them can operate without restrictions using a single registered port number. Such applications can often simply use several ports taken on-demand from the Dynamic Ports range, or they can use a demultiplexing field that is part of their packet payload.

Third, conservation for the port numbers registry is improved by procedures that allow previously allocated port numbers to become unassigned, either through de-registration or revocation, and by a procedure that lets application designers transfer an unused port number to a new application. Section 5 (Supplemental Procedures for the Port Number Space) describes these procedures, which so far were undocumented.

4.  Allocation Procedures for the Port Number Space

4.1.  Common Procedures

All registration requests for a TCP and/or UDP ports must contain the following pieces of information:

Registration Contact:

Name and email address of the contact for the registration. This is mandatory. Additional address information may be provided. For registrations done through IETF-published RFCs, one or more technical contact persons shall be provided. In addition, in this case the registration ownership will belong to the IETF and not the technical contact persons.

Transport Protocol:

Which transport protocol(s) is the registration request for, TCP, UDP or both?

Broadcast or Multicast:

If multicast or broadcast is used with the registered port, a description of this usage is required.

Port Name:

The long name (description) of the port. It should avoid all but the most well known acronyms.

Service Name:

This short name for the port number is used in the service name registry for DNS SRV RRs and has a 14-character maximum length. It must not conflict with already-allocated names in the service name registry [TBD].

Note that a particular application or service should be able to operate using only one well known or registered port. For applications or services that offer multiple functions, it is usually possible to use one port number for a multiplexing or rendezvous service. That is, the client always initiates the use of a service by contacting the rendezvous port number with a message that indicates which function is needed. The rendezvous service then either (A) creates (forks, spawns) a process to perform that function and passes the connection to it; or (B) dynamically selects a (high-numbered) port and starts a process to listen on that port number and then sends a message back to the client telling it to contact the new process on that port number.

When a registration for only TCP or UDP is approved, the port number for the other transport protocol will remain unassigned but is marked as reserved. However, IANA SHOULD NOT assign that port number to any other application or service until no port numbers exist in the request range that are u for both protocols. The current registration owner of a port number MAY register the same port number for other transport protocols when needed.

4.2.  Well Known (System) Ports

The Well Known Ports are assigned by IANA and cover the range 0-1023. On many systems, they can only be used by system (or root) processes or by programs executed by privileged users.

Registration requests for a Well Known port number MUST follow the "IETF Review" policy of [I‑D.narten‑iana‑considerations‑rfc2434bis] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” March 2008.). Registrations for a port number in this range MUST document why a port number in the Registered Ports range will not fulfill the application needs. Registrations requesting more than a single port number for a single application in this space SHOULD be denied.

Because of the special nature of port numbers in the Well Known range on several platforms, [RFC4727] (Fenner, B., “Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers,” November 2006.) has registered two port numbers in this range (1021 and 1022) for temporary, experimental use. Use of these two port numbers must comply to the guidelines set out in [RFC3692] (Narten, T., “Assigning Experimental and Testing Numbers Considered Useful,” January 2004.), most importantly, they are not intended to be used in general deployments or be enabled by default in products or other general releases. The other restrictions as defined in [RFC3692] (Narten, T., “Assigning Experimental and Testing Numbers Considered Useful,” January 2004.) apply as well.

4.3.  Registered (User) Ports

The Registered Ports are assigned by IANA and on most systems can be used by ordinary user processes or programs executed by ordinary users. The Registered Ports are in the range 1024-49151.

This port number range is the main range for any application or service requiring a known and stable port number across all hosts. Before requesting a registration, requesters should carefully consider if a rendezvous mechanism, such as DNS SRV RRs, together with the use of port numbers in the Dynamic Ports range can satisfy the application requirements. It is expected that primarily rendezvous or look-up services or applications and services that must operate in environments where such services are unavailable will need to use registered ports.

Registration requests for a Registered Port number MUST follow the "Expert Review" policy of [I‑D.narten‑iana‑considerations‑rfc2434bis] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” March 2008.). Registration requests for more than a single port number for a single application are NOT RECOMMENDED and MUST come with an extremely strong justification when brought forward.

4.4.  Dynamic (Private) Ports

The Dynamic Ports range from 49152-65535. These ports cannot be registered through IANA or by any other means. IANA SHALL refuse all such registration requests.

Private ports are usable by any application in a dynamic fashion. Usage of private ports for server type applications or services are possible through the use of rendezvous or location look-up mechanisms, e.g., the DNS. Applications acquire a particular dynamic port number on an end system and register the port number of the contact port for that service with a rendezvous or look-up service. It is RECOMMENDED that application that are capable of using such mechanisms utilize them, in order to minimize consumption of the finite port number space.

5.  Supplemental Procedures for the Port Number Space

5.1.  Port Number De-Registration

The original requesters of a granted port number assignment can return the port number to IANA at any time if there no longer is a need for it. The port number will be de-registered and will be marked as unassigned. IANA will not assign port numbers that have been de-registered until all other available port numbers in the specific range have been assigned.

Before proceeding with a de-registration, IANA needs to confirm that the port number is actually no longer in use.

5.2.  Port Number Re-Use

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.

Logically, port number re-use is to be thought of as a de-registration followed by an immediate re-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.

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.

5.3.  Port Number Revocation

Often, it will be clear that a specific port number is no longer in use and that IANA can de-register it and mark it as unassigned. But at other times, it may be unclear whether a given assigned port number is still in use somewhere in the Internet. In those cases, despite the requester's wish to de-register, IANA must consider the consequences that de-registering the port number.

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 de-registration should proceed and then communicate their decision to the community

6.  Security Considerations

The IANA guidelines described in this document do not change the security properties of either TCP or UDP.

Assignment of a port number does not in any way imply an endorsement of an application or product, and the fact that network traffic is flowing to or from a registered port number does not mean that it is "good" traffic. 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 registered or not.

7.  IANA Considerations

This document obsoletes Sections 8 and 9.1 of [RFC2780] (Bradner, S. and V. Paxson, “IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers,” March 2000.). Upon approval of this document, IANA is requested to adopt the procedures described herein.

Values in the UDP Source and Destination Field may be assigned

Values in the TCP Source and Destination Field may be assigned

Upon approval of this document or sooner, the IESG SHALL appoint a TCP/UDP Ports Expert Reviewer to work with IANA in support of the port registry and to uphold the principles described in this document. The Expert Reviewer will provide rapid advice to IANA as to whether to grant a port number assignment, including whether requests for more than one transport are merited. IANA MAY ask the TCP/UDP Expert Reviewer to co-review an SCTP or DCCP request if it also asks for a TCP or UDP port. The Expert Reviewer SHALL support IANA in the analysis for determining when a request to re-purpose a port number or de-assign it requires a community call on port number revocation.

8.  Acknowledgments

Lars Eggert is partly funded by [TRILOGY] (, “Trilogy Project,” .), a research project supported by the European Commission under its Seventh Framework Program.

9.  References

9.1. Normative References

9.2. Informative References

Appendix A.  Open Issues

This document is an initial version submitted for discussion at IETF-71 in Philadelphia, PA, USA. Expect nearly all sections of this document to see significant revisions in the near future. Nothing in here is final.

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.