Network Working Group E. Lear Internet-Draft Cisco Systems GmbH Expires: April 26, 2007 October 23, 2006 Procedures for SCTP, TCP, and UDP Port Assignments by IANA draft-lear-iana-no-more-well-known-ports-02.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 April 26, 2007. 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, the use of SRV records is encouraged, and documentation of port use is strongly encouraged. Lear Expires April 26, 2007 [Page 1] Internet-Draft Port Assignment Procedures October 2006 1. Introduction For decades the Internet Assigned Numbers Authority (IANA) [4] has managed the registry of port numbers for UDP [1] and TCP [2]. 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 [3] 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 whether use of SRV records are an appropriate 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 Lear Expires April 26, 2007 [Page 2] Internet-Draft Port Assignment Procedures October 2006 reference. Hence a large number of ports are likely assigned to protocols that are no longer in use. It has seemed a reasonable 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. More than a few times documentation for the protocol making use of a particular port has completely vanished, either with an individual or with an organization. While it is still advisable that statically assigned ports be reserved, and while the port address space is large, it is not infinite. Furthermore, unlike the IPv4 address space, it would be difficult if at all possible to even envision a market for ports should a scarcity arise. Hence, some care should be made to document a protocol running atop a port. This can be done in one of several ways: o publication of an RFC or similarly accessable and durable document that describes the protocol; o a periodic statement from the requesting individual that the port is still in use; or o an escrow of information that is held private until such time as the IANA is unable to determine that a protocol is in use. There may be other methods that the author has not considered. Some methods could cost the IANA some amount of money to manage a process that keeps track of those who requested the port assignment. It is important that any process put in place be sustainable over a long period of time. Finally, it should be pointed out that this memo makes no recommendation regarding those port numbers that are already assigned. 2. IANA Considerations: new port assignment procedure 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 reserved ports. As part of the request template or as part of IANA considerations, requestors shall be encouraged to consider use of a DNS SRV record. The IANA will continue to maintain a registry of SRV names and Lear Expires April 26, 2007 [Page 3] Internet-Draft Port Assignment Procedures October 2006 associated protocols. It should be noted that SRV records may not be appropriate in many circumstances, particularly in those cases where the risk of a circular dependency on DNS would pose substantial operational problems (one would not, for instance, want a routing protocol to make use of SRV records). As mentioned in the introduction, the IANA is requested to investigate the costs associated with maintaining a process that keeps track of those port assignments that are undocumented, and to make recommendations on how best to balance the conflicting goals of providing the traditional method of rendezvous for services between two hosts on the Internet, properly stewarding what could be come a scarce resource, and encouraging documentation of Internet services. 3. Security Considerations Regardless of methods used to assign ports, the common assumption made by two computers as to a ports usage should not be violated, as this could lead to unexpected results. In addition, reliance on the DNS for SRV records bounds the security and availability of that information to the limits of DNS security. 4. Normative References [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [4] Appendix A. Changes [The RFC Editor is requested to remove this section at publication.] o -02 Remove 2119 language altogether, rewrite to request a recommendation, and add an idea here or there. o -01 Relax demand that IANA implement a fee to a MAY. o -00 Initial publication. Lear Expires April 26, 2007 [Page 4] Internet-Draft Port Assignment Procedures October 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 April 26, 2007 [Page 5] Internet-Draft Port Assignment Procedures October 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 April 26, 2007 [Page 6]