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

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

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


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]