idnits 2.17.1 draft-lear-iana-no-more-well-known-ports-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 229. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 206. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 213. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 219. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 183: '...nd that IANA implement a fee to a MAY....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 23, 2006) is 6395 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (ref. '2') (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft Cisco Systems GmbH 4 Expires: April 26, 2007 October 23, 2006 6 Procedures for SCTP, TCP, and UDP Port Assignments by IANA 7 draft-lear-iana-no-more-well-known-ports-02.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 26, 2007. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 Amongst other things the IANA manages port assignments for TCP, UDP, 41 and SCTP protocols. This document specifies the procedure by which 42 those assignments take place. The distinction between so-called 43 "well known ports" and other public static assignments is deprecated, 44 the use of SRV records is encouraged, and documentation of port use 45 is strongly encouraged. 47 1. Introduction 49 For decades the Internet Assigned Numbers Authority (IANA) [4] has 50 managed the registry of port numbers for UDP [1] and TCP [2]. It has 51 been the policy of the IANA that regardless of how or if a protocol 52 was documented it is best to assign a port upon request so that a 53 single port would not end up used for different purposes. All modern 54 general purpose operating systems have had a mapping from mnemonic to 55 number. 57 In earlier years most operating systems imposed a simple restriction 58 on what processes could bind to a port: those ports below 1024 were 59 reserved for system use while others were available to users. This 60 restriction remains in some operating systems today. However, it is 61 not imposed on many systems for several reasons: 62 o Special purpose operating systems sometimes make no distinction 63 between privileged and unprivileged users, and hence a distinction 64 between port assignments is meaningless; 65 o Most computers these days are designed for single user use, and 66 the the administrative burden of limiting port access has not been 67 shown to be worth the benefit; 68 o The protection offered by restricting ports by number is better 69 offered through a more granular approach, such as a file system 70 analog. For example the UNIX approach root that requires 71 privileges has been the source of numerous security bugs and 72 complex methods to step down administrative access once a port has 73 been opened. 75 In addition to these problems, it is difficult to predict at the time 76 of design whether a protocol and by extension its port will be well 77 known. Further, it is unlikely that any designer would want to 78 change code and introduce additional complexity in order to change a 79 port assignment once a protocol became well known. 81 1.1. Use of SRV Records 83 RFC 2782 [3] specifies a means by which ports need not be assigned at 84 all. Instead the DNS SRV resource record is accessed to determine 85 what host and port should be accessed. While it is a debatable point 86 as to whether SRV records are appropriate for every service, they are 87 assuredly appropriate for some. Hence protocol designers are 88 encouraged to consider whether use of SRV records are an appropriate 89 alternative to registering a port with IANA. 91 1.2. Improving the state of the registry 93 The IANA maintains close to 10,000 entries in its port assignment 94 registry. Of these entries a large number have no stable information 95 reference. Hence a large number of ports are likely assigned to 96 protocols that are no longer in use. It has seemed a reasonable 97 policy to allow vendors to have port numbers assigned for their 98 private use so that they may design and deploy protocols without 99 having to worry about conflict. But individuals and companies come 100 and go, and the use of particular protocols come and go. More than a 101 few times documentation for the protocol making use of a particular 102 port has completely vanished, either with an individual or with an 103 organization. 105 While it is still advisable that statically assigned ports be 106 reserved, and while the port address space is large, it is not 107 infinite. Furthermore, unlike the IPv4 address space, it would be 108 difficult if at all possible to even envision a market for ports 109 should a scarcity arise. Hence, some care should be made to document 110 a protocol running atop a port. This can be done in one of several 111 ways: 112 o publication of an RFC or similarly accessable and durable document 113 that describes the protocol; 114 o a periodic statement from the requesting individual that the port 115 is still in use; or 116 o an escrow of information that is held private until such time as 117 the IANA is unable to determine that a protocol is in use. 119 There may be other methods that the author has not considered. 121 Some methods could cost the IANA some amount of money to manage a 122 process that keeps track of those who requested the port assignment. 123 It is important that any process put in place be sustainable over a 124 long period of time. 126 Finally, it should be pointed out that this memo makes no 127 recommendation regarding those port numbers that are already 128 assigned. 130 2. IANA Considerations: new port assignment procedure 132 The IANA receives requests for new port allocations in a manner it 133 deems appropriate, such as a web page or an email request. Those 134 requests that correlate to protocol documents approved by the IESG or 135 IRSG are given priority. The template for such a request shall be 136 specified by the IANA, but shall make no distinction between well 137 known ports and other reserved ports. 139 As part of the request template or as part of IANA considerations, 140 requestors shall be encouraged to consider use of a DNS SRV record. 141 The IANA will continue to maintain a registry of SRV names and 142 associated protocols. It should be noted that SRV records may not be 143 appropriate in many circumstances, particularly in those cases where 144 the risk of a circular dependency on DNS would pose substantial 145 operational problems (one would not, for instance, want a routing 146 protocol to make use of SRV records). 148 As mentioned in the introduction, the IANA is requested to 149 investigate the costs associated with maintaining a process that 150 keeps track of those port assignments that are undocumented, and to 151 make recommendations on how best to balance the conflicting goals of 152 providing the traditional method of rendezvous for services between 153 two hosts on the Internet, properly stewarding what could be come a 154 scarce resource, and encouraging documentation of Internet services. 156 3. Security Considerations 158 Regardless of methods used to assign ports, the common assumption 159 made by two computers as to a ports usage should not be violated, as 160 this could lead to unexpected results. In addition, reliance on the 161 DNS for SRV records bounds the security and availability of that 162 information to the limits of DNS security. 164 4. Normative References 166 [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 167 August 1980. 169 [2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 170 September 1981. 172 [3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 173 specifying the location of services (DNS SRV)", RFC 2782, 174 February 2000. 176 [4] 178 Appendix A. Changes 180 [The RFC Editor is requested to remove this section at publication.] 181 o -02 Remove 2119 language altogether, rewrite to request a 182 recommendation, and add an idea here or there. 183 o -01 Relax demand that IANA implement a fee to a MAY. 184 o -00 Initial publication. 186 Author's Address 188 Eliot Lear 189 Cisco Systems GmbH 190 Glatt-com 191 Glattzentrum, ZH CH-8301 192 Switzerland 194 Phone: +41 1 878 9200 195 Email: lear@cisco.com 197 Intellectual Property Statement 199 The IETF takes no position regarding the validity or scope of any 200 Intellectual Property Rights or other rights that might be claimed to 201 pertain to the implementation or use of the technology described in 202 this document or the extent to which any license under such rights 203 might or might not be available; nor does it represent that it has 204 made any independent effort to identify any such rights. Information 205 on the procedures with respect to rights in RFC documents can be 206 found in BCP 78 and BCP 79. 208 Copies of IPR disclosures made to the IETF Secretariat and any 209 assurances of licenses to be made available, or the result of an 210 attempt made to obtain a general license or permission for the use of 211 such proprietary rights by implementers or users of this 212 specification can be obtained from the IETF on-line IPR repository at 213 http://www.ietf.org/ipr. 215 The IETF invites any interested party to bring to its attention any 216 copyrights, patents or patent applications, or other proprietary 217 rights that may cover technology that may be required to implement 218 this standard. Please address the information to the IETF at 219 ietf-ipr@ietf.org. 221 Disclaimer of Validity 223 This document and the information contained herein are provided on an 224 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 225 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 226 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 227 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 228 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 229 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 231 Copyright Statement 233 Copyright (C) The Internet Society (2006). This document is subject 234 to the rights, licenses and restrictions contained in BCP 78, and 235 except as set forth therein, the authors retain all their rights. 237 Acknowledgment 239 Funding for the RFC Editor function is currently provided by the 240 Internet Society.