One document matched: draft-cotton-tsvwg-iana-ports-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc strict="yes"?>
<?rfc tocompact="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc tocdepth="2"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes" ?>
<!--<?rfc rfcedstyle="yes"?>-->
<?rfc sortrefs="yes" ?>
<rfc category="bcp" docName="draft-cotton-tsvwg-iana-ports-00" ipr="full3978"
updates="2780">
<front>
<title abbrev="IANA Port Allocation Guidelines">IANA Allocation Guidelines
for TCP and UDP Port Numbers</title>
<!-- AUTHORS ALPHABETICAL -->
<author fullname="Michelle Cotton" initials="M." surname="Cotton">
<organization abbrev="ICANN">Internet Corporation for Assigned Names and
Numbers</organization>
<address>
<postal>
<street>4676 Admiralty Way, Suite 330</street>
<code>90292</code>
<city>Marina del Rey</city>
<region>CA</region>
<country>USA</country>
</postal>
<phone>+1 310 823 9358</phone>
<email>michelle.cotton@icann.org</email>
<uri>http://www.iana.org/</uri>
</address>
</author>
<author fullname="Lars Eggert" initials="L." surname="Eggert">
<organization abbrev="Nokia">Nokia Research Center</organization>
<address>
<postal>
<street>P.O. Box 407</street>
<code>00045</code>
<city>Nokia Group</city>
<country>Finland</country>
</postal>
<phone>+358 50 48 24461</phone>
<email>lars.eggert@nokia.com</email>
<uri>http://research.nokia.com/people/lars_eggert/</uri>
</address>
</author>
<author fullname="Allison Mankin" initials="A." surname="Mankin">
<organization abbrev="NSF">National Science Foundation</organization>
<address>
<postal>
<street>4102 Wilson Boulevard</street>
<city>Arlington</city>
<region>VA</region>
<code>22230</code>
<country>USA</country>
</postal>
<phone>+1 301 728 7199</phone>
<email>mankin@psg.com</email>
<uri>http://www.psg.com/~mankin/</uri>
</address>
</author>
<author fullname="Magnus Westerlund" initials="M. " surname="Westerlund">
<organization>Ericsson</organization>
<address>
<postal>
<street>Torshamsgatan 23</street>
<city>Stockholm</city>
<code>164 80</code>
<country>Sweden</country>
</postal>
<phone>+46 8 719 0000</phone>
<email>magnus.westerlund@ericsson.com</email>
</address>
</author>
<date year="2008" />
<area>Transport Area</area>
<workgroup>Transport Area Working Group</workgroup>
<keyword>IANA</keyword>
<keyword>transport</keyword>
<keyword>ports</keyword>
<keyword>port numbers</keyword>
<keyword>allocation</keyword>
<keyword>procedures</keyword>
<keyword>guidelines</keyword>
<abstract>
<t>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 the TCP
and UDP port number registries, important for their long-term management. It
updates <!-- can't have an xref in the abstract, else would use: <xref target="RFC2780"/> -->
RFC2780 by replacing Sections 8 and 9.1 of that RFC.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The Transmission Control Protocol (TCP) <xref
target="RFC0793"></xref> and the User Datagram Protocol (UDP) <xref
target="RFC0768"></xref> 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) <xref target="RFC4960"></xref> and the Datagram
Congestion Control Protocol (DCCP) <xref target="RFC4342"></xref> have
adopted the concept of ports for their communication sessions and use
port numbers in the same way as TCP and UDP.</t>
<t>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.</t>
<t>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 <xref target="SYSFORM"></xref><xref
target="USRFORM"></xref>, an introductory text section in the file
listing the port number registrations themselves <xref
target="REGISTRY"></xref>, and two brief sections of <xref
target="RFC2780"></xref>.</t>
<t>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.</t>
<t>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.
<xref target="principles"></xref> discusses these principles in
detail.</t>
<t>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 <xref target="proc"></xref> describes the IANA
procedures for each range in detail: <list style="symbols">
<t>the Well Known Ports, aka the System Ports, from 0-1023</t>
<t>the Registered Ports, aka the User Ports, from 1024-49151</t>
<t>the Dynamic Ports, aka the Private Ports, from 49152-65535</t>
</list> 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.)</t>
<t>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. <xref target="supplemental"></xref> discusses
the specifics of these procedures.</t>
<t>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 <xref
target="RFC4020"></xref>. Second, it discusses how the use of the
symbolic names for assigned ports (the "keyword" field in <xref
target="REGISTRY"></xref>) for Service Resource Records (SRV RRs) in the
Domain Name System (DNS) <xref target="RFC2782"></xref> relates to the
use of SRV RRs for applications without an assigned port.</t>
<t>This document updates <xref target="RFC2780"></xref> by replacing
Sections 8 and 9.1 of that RFC. Note that <xref
target="I-D.arkko-rfc2780-proto-update"></xref> updates a different
subset of the IANA allocation guidelines originally given in <xref
target="RFC2780"></xref> (specifically, the policies on the namespace of
the IP protocol number and IPv6 next header).</t>
</section>
<section anchor="term" title="Terminology">
<t>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 <xref
target="RFC2119"></xref>.</t>
</section>
<section anchor="principles"
title="Stewardship Principles for the Port Number Space">
<!-- general stuff goes here, including:
Service names
(without port numbers)
Registry not yet created.
Do we mention anything about service names and the difference between service names and
ports? Another document will create the service code registry.
Some type of early allocation procedure for standards development
mention system ports for experimental use registered by RFC4727 (1021/1022)
<t>
The conventions of the port number assignments have been to
assign both TCP and UDP even if only one was needed; and with the
arrival of SCTP and DCCP to offer the TCP and UDP space to those
requesters with a low bar. Publishing goals for prudent management
of the port number spaces will make it easier to support their being used
as-needed and mindfully.
</t>
-->
<t>
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.
</t>
<t>
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.
</t>
<t>
It is important to note that different IANA procedures apply to different ranges of the port number registry. <xref target="proc"/> discusses the details of these procedures; this section outlines the rationale for these differences:
<list style="symbols">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</list>
</t>
<t>
Several other practices stem from the conservation principle that guides management of the port numbers registry.
</t>
<t>
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.
</t>
<t>
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 packet payload.
</t>
<t>
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. <xref target="supplemental"/> describes these procedures, which so far were undocumented.</t>
</section>
<section anchor="proc"
title="Allocation Procedures for the Port Number Space">
<section title="Common Procedures">
<t>All registration requests for a TCP and/or UDP ports must contain
the following pieces of information:</t>
<t><list style="hanging">
<t hangText="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. </t>
<t hangText="Transport Protocol:">Which transport
protocol(s) is the registration request for, TCP, UDP or both?</t>
<t hangText="Broadcast or Multicast:">If multicast or broadcast is
used with the registered port, a description of this usage is
required.</t>
<t hangText="Port Name:">The long name (description) of the port. It should avoid all but the most well known acronyms.</t>
<t hangText="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]. </t>
</list></t>
<t>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 then sends a message back
to the client telling it to contact the new process on that port number. </t>
<t>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.</t>
</section>
<section anchor="systemports" title="Well Known (System) Ports">
<t>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. </t>
<t>Registration requests for a Well Known port number MUST follow the "IETF Review" policy of <xref target="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. </t>
<t>
Because of the special nature of port numbers in the Well Known range on several platforms, <xref target="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 <xref target="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 <xref target="RFC3692"/> apply as well.
</t>
<!--What is a system port?
When should it be used?
TCP/UDP
(possibly steal text from Bill's system port language)
-tcp/udp system ports by (high bar - ??? what did we decide? IETF Review)
WE DID DECIDE IETF REVIEW - Cite RFC2344bis
-->
</section>
<section anchor="userports" title="Registered (User) Ports">
<t>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.</t>
<t>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. </t>
<t>Registration requests for a Registered Port number MUST follow the "Expert Review" policy of <xref target="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. </t>
<!--
What is a user port
When should it be used?
TCP/UDP
How/when to multiplex?
ONLY WHEN THERE IS A CLEAR REQUIREMENT FOR BOTH/ALL THE PROTOCOLS
- tcp/udp user ports by expert review
-->
</section>
<section anchor="privateports" title="Dynamic (Private) Ports">
<t>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. </t>
<t>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. </t>
<!-- I disagree with this. - Lars
<t>It is expected that only application services that themselves are
of rendezvous or look-up type will in the future really need to
register ports or are required to operate without infrastructure
support. </t>
-->
<!--When private ports should be used instead of registering user ports.
List all options for folks to use besides needing to get a registered port
-->
</section>
</section>
<section anchor="supplemental"
title="Supplemental Procedures for the Port Number Space">
<section anchor="deregistration" title="Port Number De-Registration">
<t>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.</t>
<t>
Before proceeding with a de-registration, IANA needs to confirm that the port number is actually no longer in use.
</t>
</section>
<section anchor="reuse" title="Port Number Re-Use">
<t>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.
</t>
<t>
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 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.
</t>
<t>
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.</t>
</section>
<section anchor="revocation" title="Port Number Revocation">
<!--
check to see if the port number is still in use.
Have to make sure that the port number is not in use. Might need public last call for revocation.
-->
<t>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.
</t>
<t>
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</t>
</section>
</section>
<section anchor="seccons" title="Security Considerations">
<t>The IANA guidelines described in this document do not change the
security properties of either TCP or UDP.</t>
<t><!-- disclaimer from http://www.iana.org/assignments/port-numbers -->
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.</t>
</section>
<section anchor="ianacons" title="IANA Considerations">
<!-- put all changes from 2780 into this section
update web form guidance
update registry boilerplate
-->
<t>This document obsoletes Sections 8 and 9.1 of <xref
target="RFC2780"></xref>. Upon approval of this document, IANA is
requested to adopt the procedures described herein.</t>
<t>Values in the UDP Source and Destination Field may be assigned</t>
<t>Values in the TCP Source and Destination Field may be assigned</t>
<t>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.</t>
</section>
<section anchor="ack" title="Acknowledgments">
<t>Lars Eggert is partly funded by <xref target="TRILOGY"></xref>, a
research project supported by the European Commission under its Seventh
Framework Program.</t>
</section>
</middle>
<!-- REFERENCE TEMPLATE
<reference anchor="reference.XXX">
<front>
<title>XXX</title>
<author initials="X." surname="XXX" fullname="XXX">
<organization abbrev="XXX">XXX</organization>
<address>
<postal>
<street>XXX</street>
<city>XXX</city>
<region>XXX</region>
<code>XXX</code>
<country>XXX</country>
</postal>
<phone>XXX</phone>
<facsimile>XXX</facsimile>
<email>XXX</email>
<uri>XXX</uri>
</address>
</author>
<date month="XXX" year="XXX"/>
</front>
<seriesInfo name="XXX" value="XXX"/>
<format type="XXX" target="XXX"/>
</reference>
-->
<back>
<references title="Normative References">
<?rfc include="reference.RFC.0768" ?>
<?rfc include="reference.RFC.0793" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2780" ?>
<?rfc include="reference.RFC.4020" ?>
<?rfc include="reference.RFC.4727" ?>
<?rfc include='reference.I-D.narten-iana-considerations-rfc2434bis'?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2782" ?>
<?rfc include="reference.RFC.3692" ?>
<?rfc include="reference.RFC.4342" ?>
<?rfc include="reference.RFC.4960" ?>
<?rfc include="reference.I-D.arkko-rfc2780-proto-update" ?>
<reference anchor="SYSFORM">
<front>
<title>Application for System (Well Known) Port Number</title>
<author surname="Internet Assigned Numbers Authority (IANA)">
<organization />
</author>
</front>
<seriesInfo name=""
value="http://www.iana.org/cgi-bin/sys-port-number.pl" />
</reference>
<reference anchor="USRFORM">
<front>
<title>Application for User (Registered) Port Number</title>
<author surname="Internet Assigned Numbers Authority (IANA)">
<organization />
</author>
</front>
<seriesInfo name=""
value="http://www.iana.org/cgi-bin/usr-port-number.pl" />
</reference>
<reference anchor="REGISTRY">
<front>
<title>Port Numbers</title>
<author surname="Internet Assigned Numbers Authority (IANA)">
<organization />
</author>
</front>
<seriesInfo name=""
value="http://www.iana.org/assignments/port-numbers" />
</reference>
<reference anchor="TRILOGY">
<front>
<title>Trilogy Project</title>
<author>
<organization />
</author>
</front>
<seriesInfo name="" value="http://www.trilogy-project.org/" />
</reference>
</references>
<section title="Open Issues">
<t>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 here is final.
</t>
<!--
has several open issues, including but unlikely to be limited to:</t>
<t><list style="numbers">
<t>How to handle the normative reference to the service name
registry, as well as the absence of an IANA service name registry in the first place.</t>
<t>Which additional questions will be required to answer in a
registration request. </t>
-->
<!-- Don't know what this means. - Lars
<t>Whether the port number preference rule applies to more than UDP and TCP,
i.e. also for SCTP and DCCP?</t>
</list></t>
-->
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 09:08:19 |