Transport Area Working Group                                   M. Cotton
Internet-Draft                                                     ICANN
Updates: 2780 (if approved)                                    L. Eggert
Intended status: Best Current                                      Nokia
Practice                                                       A. Mankin
Expires: August 21, 2008                                             NSF
                                                           M. Westerlund
                                                       February 18, 2008

        IANA Allocation Guidelines for TCP and UDP Port Numbers

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 21, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).


   This document defines the IANA guidelines for registering new port
   number values for use with the Transmission Control Protocol (TCP)
   and User Datagram Protocol (UDP).  It provides clear processes for

Cotton, et al.           Expires August 21, 2008                [Page 1]

Internet-Draft       IANA Port Allocation Guidelines       February 2008

   the TCP and UDP port number registries, important for their long-term
   management.  It updates RFC2780 by replacing Sections 8 and 9.1 of
   that RFC.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Stewardship Principles for the Port Number Space . . . . . . .  5
   4.  Allocation Procedures for the Port Number Space  . . . . . . .  7
     4.1.  Common Procedures  . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Well Known (System) Ports  . . . . . . . . . . . . . . . .  8
     4.3.  Registered (User) Ports  . . . . . . . . . . . . . . . . .  8
     4.4.  Dynamic (Private) Ports  . . . . . . . . . . . . . . . . .  9
   5.  Supplemental Procedures for the Port Number Space  . . . . . .  9
     5.1.  Port Number De-Registration  . . . . . . . . . . . . . . .  9
     5.2.  Port Number Re-Use . . . . . . . . . . . . . . . . . . . .  9
     5.3.  Port Number Revocation . . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Appendix A.  Open Issues . . . . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 14

Cotton, et al.           Expires August 21, 2008                [Page 2]

Internet-Draft       IANA Port Allocation Guidelines       February 2008

1.  Introduction

   The Transmission Control Protocol (TCP) [RFC0793] and the User
   Datagram Protocol (UDP) [RFC0768] have enjoyed a remarkable success
   over the decades as the two most widely used transport protocols on
   the Internet.  They have introduced the concept of ports as logical
   entities that end system applications bind their transport sessions
   to.  Ports are identified by 16-bit numbers, and the combination of
   source and destination port numbers together with the IP addresses
   communicating end systems uniquely identifies a session of a given
   transport protocol.  Newer transport protocols, such as the Stream
   Control Transmission Protocol (SCTP) [RFC4960] and the Datagram
   Congestion Control Protocol (DCCP) [RFC4342] have adopted the concept
   of ports for their communication sessions and use port numbers in the
   same way as TCP and UDP.

   Port numbers are the original and most widely used means for
   application and service identification on the Internet.  Designers of
   applications and application-level protocols may apply to the
   Internet Assigned Numbers Authority (IANA) for a registered port
   number for a specific application, and may after successful
   registration assume that no other application will use that port
   number for its communication sessions.  It is important to note that
   ownership of registered port numbers remains with IANA.

   For many years, the allocation and registration of new port number
   values for use with TCP and UDP have had less than clear guidelines.
   Information about the registration procedures for the port namespace
   existed in three locations: the forms for requesting port number
   registrations on the IANA web site [SYSFORM][USRFORM], an
   introductory text section in the file listing the port number
   registrations themselves [REGISTRY], and two brief sections of

   This document aggregates this scattered information into a single
   reference and at the same time clarifies the guidelines for the
   management of the TCP and UDP port number space.  It gives more
   detailed guidance to prospective requesters of TCP and UDP ports than
   the existing documentation, and it streamlines the IANA procedures
   for the management of the port number space, so that management
   requests can complete in a timely manner.  A key factor of this
   streamlining is to establish identical registration procedures for
   transport protocol ports, independent of a specific transport
   protocol.  This document brings the IANA procedures for TCP and UDP
   in line with those already in effect for SCTP and DCCP, resulting in
   a single process that requesters and IANA follow for all port number
   requests for all transport protocols.

Cotton, et al.           Expires August 21, 2008                [Page 3]

Internet-Draft       IANA Port Allocation Guidelines       February 2008

   A second purpose of this document is to describe the principles that
   guide the IETF and IANA in their role as the long-term joint stewards
   of the port number space.  TCP and UDP have been a remarkable success
   over the last decades.  Thousands of applications and application-
   level protocols have registered ports for their use, and there is
   every reason to believe that this trend will continue into the
   future.  It is hence extremely important that management of the port
   number space follow principles that ensure its long-term usefulness
   as a shared resource.  Section 3 discusses these principles in

   TCP and UDP use 16-bit namespaces for their port number registries,
   as do SCTP and DCCP.  These ports registries are subdivided into
   three port number ranges, and Section 4 describes the IANA procedures
   for each range in detail:

   o  the Well Known Ports, aka the System Ports, from 0-1023

   o  the Registered Ports, aka the User Ports, from 1024-49151

   o  the Dynamic Ports, aka the Private Ports, from 49152-65535

   When this document was being written, approximately 76% of the Well
   Known Ports for TCP and UDP were assigned, as was a significant
   fraction of the Registered Ports.  (Dynamic Ports are not available
   for assignment through IANA.)

   In addition to detailing the IANA procedures for the initial
   assignment of port numbers, this document also specifies supplemental
   procedures that until now have been handled in an ad hoc manner.
   These include procedures to de-register a port number that is no
   longer in use, to re-use a port number allocated for one application
   that is no longer in use for another application, and procedure by
   which IANA can unilaterally revoke a prior port number registration.
   Section 5 discusses the specifics of these procedures.

   Finally, this document also addresses two technical issues with ports
   registry that are tangential to long-term stewardship.  First, it
   clarifies that a method for the early allocation of TCP and UDP ports
   for IETF working group documents is available, in line with
   [RFC4020].  Second, it discusses how the use of the symbolic names
   for assigned ports (the "keyword" field in [REGISTRY]) for Service
   Resource Records (SRV RRs) in the Domain Name System (DNS) [RFC2782]
   relates to the use of SRV RRs for applications without an assigned

   This document updates [RFC2780] by replacing Sections 8 and 9.1 of
   that RFC.  Note that [I-D.arkko-rfc2780-proto-update] updates a

Cotton, et al.           Expires August 21, 2008                [Page 4]

Internet-Draft       IANA Port Allocation Guidelines       February 2008

   different subset of the IANA allocation guidelines originally given
   in [RFC2780] (specifically, the policies on the namespace of the IP
   protocol number and IPv6 next header).

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in BCP 14, RFC 2119

3.  Stewardship Principles for the Port Number Space

   The overriding principle that governs the IANA and IETF procedures
   governing the management of the port number registry for the
   different transport protocols is conservation.  The port number
   registry is one of the basic resources of the Internet and requires
   careful management.  Exhaustion is likely to require fundamental
   changes to Internet communication, which is undesirable.

   At the same time, it is of great benefit to all Internet applications
   to request and receive port number allocations from IANA for their
   communication needs.  This means that although IANA should require
   and verify that applicants for port numbers document their intended
   use to a degree that lets a technical expert review the desired
   allocation, this process must not appear to be an insurmountable
   burden.  Otherwise, there is the danger that application designers
   turn to using ports in an undocumented fashion, which is harmful to
   Internet communications as a whole.  Clearly stated and motivated
   procedures support this goal.

   It is important to note that different IANA procedures apply to
   different ranges of the port number registry.  Section 4 discusses
   the details of these procedures; this section outlines the rationale
   for these differences:

   o  Ports in the Dynamic Ports range (49152-65535) have been
      specifically set aside for local and dynamic use and cannot be
      registered through IANA.  Applications may simply use them for
      communication without any sort of registration.  On the other
      hand, applications must not assume that a specific port number in
      the Dynamic Ports range will always be available for communication
      at all times, and a port number in that range hence cannot be used
      as a service identifier.

Cotton, et al.           Expires August 21, 2008                [Page 5]

Internet-Draft       IANA Port Allocation Guidelines       February 2008

   o  Ports in the Registered Ports range (1024-49151) are available for
      registration through IANA, and can be used as service identifiers
      upon successful registration.  Because registering a port number
      for a specific application consumes a fraction of the shared
      resource that is the port number registry, IANA will require the
      requester to document the intended use of the port number, and
      have a technical expert review this documentation to determine
      whether to grant the registration request.  This documentation
      must explain why a port number in the Dynamic Ports range is
      unsuitable for the given application.

   o  Ports in the Well Known Ports range (0-1023) are also available
      for registration through IANA.  Because the Well Known Ports range
      is both the smallest and the most densely allocated one, the bar
      for new allocations is higher than that for the Registered Ports
      range (1024-49551).  A request for a Well Known port number must
      document why a port number in the Registered Ports of Dynamic
      Ports ranges are unsuitable.

   Several other practices stem from the conservation principle that
   guides management of the port numbers registry.

   First, with the approval of this document, IANA will begin assigning
   protocol numbers only for those transport protocols explicitly
   included in the registration request.  This ends the long-standing
   practice of automatically assigning a port number to an application
   for both TCP and a UDP, even if the request is only for one of these
   transport protocols.  The new allocation procedure conserves
   resources by only allocating a port number to an application for
   those transport protocols (TCP, UDP, SCTP and/or DCCP) it actually
   uses.  The port number will be marked as reserved - instead of
   assigned - in the port number registries of the other transport
   protocols.  When applications start supporting the use of some of
   those additional transport protocols, they must request IANA to
   convert the reservation to an assignment.  An application must not
   assume that it can use a port number assigned to it for use with one
   transport protocol with another transport protocol without a
   registration with IANA.

   Second, IANA will continue its long-standing practice of refusing
   allocations for applications that request the assignments of multiple
   port numbers.  Registered port numbers are application identifiers,
   and extremely few applications require multiple identifiers.  For
   applications that do require a registered port number in the first
   place, the vast majority of them can operate without restrictions
   using a single registered port number.  Such applications can often
   simply use several ports taken on-demand from the Dynamic Ports
   range, or they can use a demultiplexing field that is part of their

Cotton, et al.           Expires August 21, 2008                [Page 6]

Internet-Draft       IANA Port Allocation Guidelines       February 2008

   packet payload.

   Third, conservation for the port numbers registry is improved by
   procedures that allow previously allocated port numbers to become
   unassigned, either through de-registration or revocation, and by a
   procedure that lets application designers transfer an unused port
   number to a new application.  Section 5 describes these procedures,
   which so far were undocumented.

4.  Allocation Procedures for the Port Number Space

4.1.  Common Procedures

   All registration requests for a TCP and/or UDP ports must contain the
   following pieces of information:

   Registration Contact:  Name and email address of the contact for the
      registration.  This is mandatory.  Additional address information
      may be provided.  For registrations done through IETF-published
      RFCs, one or more technical contact persons shall be provided.  In
      addition, in this case the registration ownership will belong to
      the IETF and not the technical contact persons.

   Transport Protocol:  Which transport protocol(s) is the registration
      request for, TCP, UDP or both?

   Broadcast or Multicast:  If multicast or broadcast is used with the
      registered port, a description of this usage is required.

   Port Name:  The long name (description) of the port.  It should avoid
      all but the most well known acronyms.

   Service Name:  This short name for the port number is used in the
      service name registry for DNS SRV RRs and has a 14-character
      maximum length.  It must not conflict with already-allocated names
      in the service name registry [TBD].

   Note that a particular application or service should be able to
   operate using only one well known or registered port.  For
   applications or services that offer multiple functions, it is usually
   possible to use one port number for a multiplexing or rendezvous
   service.  That is, the client always initiates the use of a service
   by contacting the rendezvous port number with a message that
   indicates which function is needed.  The rendezvous service then
   either (A) creates (forks, spawns) a process to perform that function
   and passes the connection to it; or (B) dynamically selects a (high-
   numbered) port and starts a process to listen on that port number and

Cotton, et al.           Expires August 21, 2008                [Page 7]

Internet-Draft       IANA Port Allocation Guidelines       February 2008

   then sends a message back to the client telling it to contact the new
   process on that port number.

   When a registration for only TCP or UDP is approved, the port number
   for the other transport protocol will remain unassigned but is marked
   as reserved.  However, IANA SHOULD NOT assign that port number to any
   other application or service until no port numbers exist in the
   request range that are u for both protocols.  The current
   registration owner of a port number MAY register the same port number
   for other transport protocols when needed.

4.2.  Well Known (System) Ports

   The Well Known Ports are assigned by IANA and cover the range 0-1023.
   On many systems, they can only be used by system (or root) processes
   or by programs executed by privileged users.

   Registration requests for a Well Known port number MUST follow the
   "IETF Review" policy of [I-D.narten-iana-considerations-rfc2434bis].
   Registrations for a port number in this range MUST document why a
   port number in the Registered Ports range will not fulfill the
   application needs.  Registrations requesting more than a single port
   number for a single application in this space SHOULD be denied.

   Because of the special nature of port numbers in the Well Known range
   on several platforms, [RFC4727] has registered two port numbers in
   this range (1021 and 1022) for temporary, experimental use.  Use of
   these two port numbers must comply to the guidelines set out in
   [RFC3692], most importantly, they are not intended to be used in
   general deployments or be enabled by default in products or other
   general releases.  The other restrictions as defined in [RFC3692]
   apply as well.

4.3.  Registered (User) Ports

   The Registered Ports are assigned by IANA and on most systems can be
   used by ordinary user processes or programs executed by ordinary
   users.  The Registered Ports are in the range 1024-49151.

   This port number range is the main range for any application or
   service requiring a known and stable port number across all hosts.
   Before requesting a registration, requesters should carefully
   consider if a rendezvous mechanism, such as DNS SRV RRs, together
   with the use of port numbers in the Dynamic Ports range can satisfy
   the application requirements.  It is expected that primarily
   rendezvous or look-up services or applications and services that must
   operate in environments where such services are unavailable will need
   to use registered ports.

Cotton, et al.           Expires August 21, 2008                [Page 8]

Internet-Draft       IANA Port Allocation Guidelines       February 2008

   Registration requests for a Registered Port number MUST follow the
   "Expert Review" policy of
   [I-D.narten-iana-considerations-rfc2434bis].  Registration requests
   for more than a single port number for a single application are NOT
   RECOMMENDED and MUST come with an extremely strong justification when
   brought forward.

4.4.  Dynamic (Private) Ports

   The Dynamic Ports range from 49152-65535.  These ports cannot be
   registered through IANA or by any other means.  IANA SHALL refuse all
   such registration requests.

   Private ports are usable by any application in a dynamic fashion.
   Usage of private ports for server type applications or services are
   possible through the use of rendezvous or location look-up
   mechanisms, e.g., the DNS.  Applications acquire a particular dynamic
   port number on an end system and register the port number of the
   contact port for that service with a rendezvous or look-up service.
   It is RECOMMENDED that application that are capable of using such
   mechanisms utilize them, in order to minimize consumption of the
   finite port number space.

5.  Supplemental Procedures for the Port Number Space

5.1.  Port Number De-Registration

   The original requesters of a granted port number assignment can
   return the port number to IANA at any time if there no longer is a
   need for it.  The port number will be de-registered and will be
   marked as unassigned.  IANA will not assign port numbers that have
   been de-registered until all other available port numbers in the
   specific range have been assigned.

   Before proceeding with a de-registration, IANA needs to confirm that
   the port number is actually no longer in use.

5.2.  Port Number Re-Use

   If the original requesters of a granted port number assignment no
   longer have a need for the registered number, but would like to re-
   use it for a different application, they can submit a request to IANA
   to do so.

   Logically, port number re-use is to be thought of as a de-
   registration followed by an immediate re-registration of the same
   port number for a new application.  Consequently, the information

Cotton, et al.           Expires August 21, 2008                [Page 9]

Internet-Draft       IANA Port Allocation Guidelines       February 2008

   that needs to be provided about the proposed new use of the port
   number is identical to what would need to be provided for a new port
   number allocation for the specific ports range.

   IANA needs to carefully review such requests before approving them.
   In some instances, the Expert Reviewer will determine that the
   application that the port number was assigned to has found usage
   beyond the original requester, or that there is a concern that it may
   have such users.  This determination MUST be made quickly.  A
   community call concerning revocation of a port number (see below) MAY
   be considered, if a broader use of the port number is suspected.

5.3.  Port Number Revocation

   Often, it will be clear that a specific port number is no longer in
   use and that IANA can de-register it and mark it as unassigned.  But
   at other times, it may be unclear whether a given assigned port
   number is still in use somewhere in the Internet.  In those cases,
   despite the requester's wish to de-register, IANA must consider the
   consequences that de-registering the port number.

   With the help of their IESG-appointed Expert Reviewer, IANA SHALL
   formulate a request to the IESG to issue a four-week community call
   concerning the pending port number revocation.  The IESG and IANA,
   with the Expert Reviewer's support, SHALL determine promptly after
   the end of the community call whether de-registration should proceed
   and then communicate their decision to the community

6.  Security Considerations

   The IANA guidelines described in this document do not change the
   security properties of either TCP or UDP.

   Assignment of a port number does not in any way imply an endorsement
   of an application or product, and the fact that network traffic is
   flowing to or from a registered port number does not mean that it is
   "good" traffic.  Firewall and system administrators should choose how
   to configure their systems based on their knowledge of the traffic in
   question, not whether there is a port number registered or not.

7.  IANA Considerations

   This document obsoletes Sections 8 and 9.1 of [RFC2780].  Upon
   approval of this document, IANA is requested to adopt the procedures
   described herein.

Cotton, et al.           Expires August 21, 2008               [Page 10]

Internet-Draft       IANA Port Allocation Guidelines       February 2008

   Values in the UDP Source and Destination Field may be assigned

   Values in the TCP Source and Destination Field may be assigned

   Upon approval of this document or sooner, the IESG SHALL appoint a
   TCP/UDP Ports Expert Reviewer to work with IANA in support of the
   port registry and to uphold the principles described in this
   document.  The Expert Reviewer will provide rapid advice to IANA as
   to whether to grant a port number assignment, including whether
   requests for more than one transport are merited.  IANA MAY ask the
   TCP/UDP Expert Reviewer to co-review an SCTP or DCCP request if it
   also asks for a TCP or UDP port.  The Expert Reviewer SHALL support
   IANA in the analysis for determining when a request to re-purpose a
   port number or de-assign it requires a community call on port number

8.  Acknowledgments

   Lars Eggert is partly funded by [TRILOGY], a research project
   supported by the European Commission under its Seventh Framework

9.  References

9.1.  Normative References

              Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs",
              draft-narten-iana-considerations-rfc2434bis-08 (work in
              progress), October 2007.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2780]  Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
              Values In the Internet Protocol and Related Headers",
              BCP 37, RFC 2780, March 2000.

   [RFC4020]  Kompella, K. and A. Zinin, "Early IANA Allocation of

Cotton, et al.           Expires August 21, 2008               [Page 11]

Internet-Draft       IANA Port Allocation Guidelines       February 2008

              Standards Track Code Points", BCP 100, RFC 4020,
              February 2005.

   [RFC4727]  Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
              ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.

9.2.  Informative References

              Arkko, J. and S. Bradner, "IANA Allocation Guidelines for
              the Protocol Field", draft-arkko-rfc2780-proto-update-02
              (work in progress), January 2008.

              Internet Assigned Numbers Authority (IANA), "Port

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
              Considered Useful", BCP 82, RFC 3692, January 2004.

   [RFC4342]  Floyd, S., Kohler, E., and J. Padhye, "Profile for
              Datagram Congestion Control Protocol (DCCP) Congestion
              Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,
              March 2006.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

   [SYSFORM]  Internet Assigned Numbers Authority (IANA), "Application
              for System (Well Known) Port Number",

   [TRILOGY]  "Trilogy Project",

   [USRFORM]  Internet Assigned Numbers Authority (IANA), "Application
              for User (Registered) Port Number",

Appendix A.  Open Issues

   This document is an initial version submitted for discussion at
   IETF-71 in Philadelphia, PA, USA.  Expect nearly all sections of this
   document to see significant revisions in the near future.  Nothing in

Cotton, et al.           Expires August 21, 2008               [Page 12]

Internet-Draft       IANA Port Allocation Guidelines       February 2008

   here is final.

Authors' Addresses

   Michelle Cotton
   Internet Corporation for Assigned Names and Numbers
   4676 Admiralty Way, Suite 330
   Marina del Rey, CA  90292

   Phone: +1 310 823 9358

   Lars Eggert
   Nokia Research Center
   P.O. Box 407
   Nokia Group  00045

   Phone: +358 50 48 24461

   Allison Mankin
   National Science Foundation
   4102 Wilson Boulevard
   Arlington, VA  22230

   Phone: +1 301 728 7199

   Magnus Westerlund
   Torshamsgatan 23
   Stockholm  164 80

   Phone: +46 8 719 0000

Cotton, et al.           Expires August 21, 2008               [Page 13]

Internet-Draft       IANA Port Allocation Guidelines       February 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

   This document and the information contained herein are provided on an

Intellectual Property

   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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Cotton, et al.           Expires August 21, 2008               [Page 14]