One document matched: draft-lear-iana-no-more-well-known-ports-01.txt

Differences from draft-lear-iana-no-more-well-known-ports-00.txt

Network Working Group                                            E. Lear
Internet-Draft                                        Cisco Systems GmbH
Expires: December 8, 2006                                   June 6, 2006


       Procedures for SCTP, TCP, and UDP Port Assignments by IANA
            draft-lear-iana-no-more-well-known-ports-01.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 December 8, 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,
   the use of SRV records is encouraged, and documentation of port use
   is strongly encouraged.






Lear                    Expires December 8, 2006                [Page 1]

Internet-Draft         Port Assignment Procedures              June 2006


1.  Introduction

   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



Lear                    Expires December 8, 2006                [Page 2]

Internet-Draft         Port Assignment Procedures              June 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, the IANA will be empowered to charge a reasonable
   periodic fee to recoup costs associated with keeping track of
   assignments relating to protocols that are not documented through
   some stable reference.

   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 [1].


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 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 or
   designate shall approve.  The purpose of this fee is to recoup costs
   of keeping track of the port assignment.  The IANA MAY 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 at its discretion deny undocumented
   requests or refer them to the IESG for further review.




Lear                    Expires December 8, 2006                [Page 3]

Internet-Draft         Port Assignment Procedures              June 2006


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.

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]  <http://www.iana.org>


Appendix A.  Changes

   [The RFC Editor is requested to remove this section at publication.]
   o  -01 Relax demand that IANA implement a fee to a MAY.
   o  -00 Initial publication.





















Lear                    Expires December 8, 2006                [Page 4]

Internet-Draft         Port Assignment Procedures              June 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 December 8, 2006                [Page 5]

Internet-Draft         Port Assignment Procedures              June 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 December 8, 2006                [Page 6]