Network Working Group E. Lear Internet-Draft Cisco Systems GmbH Expires: November 23, 2006 May 22, 2006 Procedures for SCTP, TCP, and UDP Port Assignments by IANA draft-lear-iana-no-more-well-known-ports-00.txt 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 November 23, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Amongst other things the IANA manages port assignments for TCP, UDP, and SCTP protocols. This document specifies the procedure by which those assignments take place. The distinction between so-called "well known ports" and other public static assignments is deprecated, and use of SRV records is encouraged. 1. Introduction Lear Expires November 23, 2006 [Page 1] Internet-Draft Port Assignment Procedures May 2006 For decades the Internet Assigned Numbers Authority (IANA) [5] has managed the registry of port numbers for UDP [2] and TCP [3]. It has been the policy of the IANA that regardless of how or if a protocol was documented it is best to assign a port upon request so that a single port would not end up used for different purposes. All modern general purpose operating systems have had a mapping from mnemonic to number. In earlier years most operating systems imposed a simple restriction on what processes could bind to a port: those ports below 1024 were reserved for system use while others were available to users. This restriction remains in some operating systems today. However, it is not imposed on many systems for several reasons: o Special purpose operating systems sometimes make no distinction between privileged and unprivileged users, and hence a distinction between port assignments is meaningless; o Most computers these days are designed for single user use, and the the administrative burden of limiting port access has not been shown to be worth the benefit; o The protection offered by restricting ports by number is better offered through a more granular approach, such as a file system analog. For example the UNIX approach root that requires privileges has been the source of numerous security bugs and complex methods to step down administrative access once a port has been opened. In addition to these problems, it is difficult to predict at the time of design whether a protocol and by extension its port will be well known. Further, it is unlikely that any designer would want to change code and introduce additional complexity in order to change a port assignment once a protocol became well known. 1.1. Use of SRV Records RFC 2782 [4] specifies a means by which ports need not be assigned at all. Instead the DNS SRV resource record is accessed to determine what host and port should be accessed. While it is a debatable point as to whether SRV records are appropriate for every service, they are assuredly appropriate for some. Hence protocol designers are encouraged to consider use of SRV records as an alternative to registering a port with IANA. 1.2. Improving the state of the registry The IANA maintains close to 10,000 entries in its port assignment registry. Of these entries a large number have no stable information reference. Hence a large number of ports are likely assigned to protocols that are no longer in use. It has seemed a reasonable Lear Expires November 23, 2006 [Page 2] Internet-Draft Port Assignment Procedures May 2006 policy to allow vendors to have port numbers assigned for their private use so that they may design and deploy protocols without having to worry about conflict. But individuals and companies come and go, and the use of particular protocols come and go. While it is still advisable that statically assigned ports be reserved, the IANA will be empowered to charge a periodic fee to recoup costs associated with keeping track of assignments relating to protocols that are not documented in the RFC series. Such a fee is also intended to encourage protocol developers to provide stable normative references. 2. IANA Considerations The IANA receives requests for new port allocations in a manner it deems appropriate, such as a web page or an email request. Those requests that correlate to protocol documents approved by the IESG or IRSG are given priority. The template for such a request shall be specified by the IANA, but shall make no distinction between well known ports and other ports. As part of the request template or as part of IANA considerations, requestors shall state why a DNS SRV record is not acceptable for a specific use. For protocols developed within the IETF, the IESG or their designate shall review such reasoning. The IANA will continue to maintain a registry of SRV names and associated protocols. For those requests made outside the IETF standards process, and in particular for those protocols that are not documented via an RFC, the IANA MAY charge a fee based on a structure that the IAB shall approve. The purpose of this fee is to recoup costs of keeping track of the port assignment. The IANA shall set reclamation policies to handle cases when the fee is not paid. Again, such policies shall be approved by the IAB. A recognized standard development organization shall be exempt from such a fee so long as it defines and implements a process acceptable to the IANA to keep the database updated. Beyond the fee, the IANA MAY on its own initiative deny undocumented requests or refer them to the IESG for further review. 3. Security Considerations With the collection of billing information and funds there is the risk to user privacy. The IANA will take steps it deems necessary to protect all such information collected in accordance with governing law and contemporary security safety standards. Lear Expires November 23, 2006 [Page 3] Internet-Draft Port Assignment Procedures May 2006 4. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [3] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [4] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [5] Appendix A. Changes [The RFC Editor is requested to remove this section at publication.] o -00 Initial publication. Lear Expires November 23, 2006 [Page 4] Internet-Draft Port Assignment Procedures May 2006 Author's Address Eliot Lear Cisco Systems GmbH Glatt-com Glattzentrum, ZH CH-8301 Switzerland Phone: +41 1 878 9200 Email: lear@cisco.com Lear Expires November 23, 2006 [Page 5] Internet-Draft Port Assignment Procedures May 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lear Expires November 23, 2006 [Page 6]