One document matched: draft-cotton-tsvwg-iana-ports-00.txt
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
Ericsson
February 18, 2008
IANA Allocation Guidelines for TCP and UDP Port Numbers
draft-cotton-tsvwg-iana-ports-00
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 August 21, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
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
[RFC2780].
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
detail.
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
port.
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
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
revocation.
8. Acknowledgments
Lars Eggert is partly funded by [TRILOGY], a research project
supported by the European Commission under its Seventh Framework
Program.
9. References
9.1. Normative References
[I-D.narten-iana-considerations-rfc2434bis]
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
[I-D.arkko-rfc2780-proto-update]
Arkko, J. and S. Bradner, "IANA Allocation Guidelines for
the Protocol Field", draft-arkko-rfc2780-proto-update-02
(work in progress), January 2008.
[REGISTRY]
Internet Assigned Numbers Authority (IANA), "Port
Numbers", http://www.iana.org/assignments/port-numbers.
[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",
http://www.iana.org/cgi-bin/sys-port-number.pl.
[TRILOGY] "Trilogy Project", http://www.trilogy-project.org/.
[USRFORM] Internet Assigned Numbers Authority (IANA), "Application
for User (Registered) Port Number",
http://www.iana.org/cgi-bin/usr-port-number.pl.
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
USA
Phone: +1 310 823 9358
Email: michelle.cotton@icann.org
URI: http://www.iana.org/
Lars Eggert
Nokia Research Center
P.O. Box 407
Nokia Group 00045
Finland
Phone: +358 50 48 24461
Email: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert/
Allison Mankin
National Science Foundation
4102 Wilson Boulevard
Arlington, VA 22230
USA
Phone: +1 301 728 7199
Email: mankin@psg.com
URI: http://www.psg.com/~mankin/
Magnus Westerlund
Ericsson
Torshamsgatan 23
Stockholm 164 80
Sweden
Phone: +46 8 719 0000
Email: magnus.westerlund@ericsson.com
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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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.
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
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Cotton, et al. Expires August 21, 2008 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 09:11:02 |