draft-ietf-tsvwg-iana-ports-09.txt   draft-ietf-tsvwg-iana-ports.txt 
Transport Area Working Group M. Cotton Transport Area Working Group M. Cotton
Internet-Draft ICANN Internet-Draft ICANN
Updates: 2780, 2782, 3828, 4340, L. Eggert Updates: 2780, 2782, 3828, 4340, L. Eggert
4960 (if approved) Nokia 4960 (if approved) Nokia
Intended status: BCP J. Touch Intended status: BCP J. Touch
Expires: June 5, 2011 USC/ISI Expires: July 29, 2011 USC/ISI
M. Westerlund M. Westerlund
Ericsson Ericsson
S. Cheshire S. Cheshire
Apple Apple
December 2, 2010 January 25, 2011
Internet Assigned Numbers Authority (IANA) Procedures for the Management Internet Assigned Numbers Authority (IANA) Procedures for the Management
of the Service Name and Transport Protocol Port Number Registry of the Service Name and Transport Protocol Port Number Registry
draft-ietf-tsvwg-iana-ports-09 draft-ietf-tsvwg-iana-ports-10
Abstract Abstract
This document defines the procedures that the Internet Assigned This document defines the procedures that the Internet Assigned
Numbers Authority (IANA) uses when handling assignment and other Numbers Authority (IANA) uses when handling assignment and other
requests related to the Service Name and Transport Protocol Port requests related to the Service Name and Transport Protocol Port
Number Registry. It also discusses the rationale and principles Number Registry. It also discusses the rationale and principles
behind these procedures and how they facilitate the long-term behind these procedures and how they facilitate the long-term
sustainability of the registry. sustainability of the registry.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 5, 2011. This Internet-Draft will expire on July 29, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 10 skipping to change at page 3, line 10
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Conventions Used in this Document . . . . . . . . . . . . . . 7 4. Conventions Used in this Document . . . . . . . . . . . . . . 8
5. Service Names . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Service Names . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Service Name Syntax . . . . . . . . . . . . . . . . . . . 9 5.1. Service Name Syntax . . . . . . . . . . . . . . . . . . . 9
5.2. Service Name Usage in DNS SRV Records . . . . . . . . . . 10 5.2. Service Name Usage in DNS SRV Records . . . . . . . . . . 10
6. Port Number Ranges . . . . . . . . . . . . . . . . . . . . . . 11 6. Port Number Ranges . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Service names and Port Numbers for Experimentation . . . . 11 6.1. Service names and Port Numbers for Experimentation . . . . 12
7. Principles for Service Name and Transport Protocol Port 7. Principles for Service Name and Transport Protocol Port
Number Registry Management . . . . . . . . . . . . . . . . . . 12 Number Registry Management . . . . . . . . . . . . . . . . . . 12
7.1. Past Principles . . . . . . . . . . . . . . . . . . . . . 12 7.1. Past Principles . . . . . . . . . . . . . . . . . . . . . 13
7.2. Updated Principles . . . . . . . . . . . . . . . . . . . . 13 7.2. Updated Principles . . . . . . . . . . . . . . . . . . . . 13
8. IANA Procedures for Managing the Service Name and 8. IANA Procedures for Managing the Service Name and
Transport Protocol Port Number Registry . . . . . . . . . . . 16 Transport Protocol Port Number Registry . . . . . . . . . . . 16
8.1. Service Name and Port Number Assignment . . . . . . . . . 16 8.1. Service Name and Port Number Assignment . . . . . . . . . 16
8.2. Service Name and Port Number De-Assignment . . . . . . . . 20 8.2. Service Name and Port Number De-Assignment . . . . . . . . 20
8.3. Service Name and Port Number Reuse . . . . . . . . . . . . 20 8.3. Service Name and Port Number Reuse . . . . . . . . . . . . 21
8.4. Service Name and Port Number Revocation . . . . . . . . . 21 8.4. Service Name and Port Number Revocation . . . . . . . . . 21
8.5. Service Name and Port Number Transfers . . . . . . . . . . 21 8.5. Service Name and Port Number Transfers . . . . . . . . . . 22
8.6. Maintenance Issues . . . . . . . . . . . . . . . . . . . . 22 8.6. Maintenance Issues . . . . . . . . . . . . . . . . . . . . 22
8.7. Disagreements . . . . . . . . . . . . . . . . . . . . . . 22 8.7. Disagreements . . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10.1. Service Name Consistency . . . . . . . . . . . . . . . . . 23 10.1. Service Name Consistency . . . . . . . . . . . . . . . . . 23
10.2. Port Numbers for SCTP and DCCP Experimentation . . . . . . 24 10.2. Port Numbers for SCTP and DCCP Experimentation . . . . . . 25
10.3. Updates to DCCP Registries . . . . . . . . . . . . . . . . 25 10.3. Updates to DCCP Registries . . . . . . . . . . . . . . . . 26
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
13.1. Normative References . . . . . . . . . . . . . . . . . . . 27 13.1. Normative References . . . . . . . . . . . . . . . . . . . 28
13.2. Informative References . . . . . . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
For many years, the assignment of new service names and port number For many years, the assignment of new service names and port number
values for use with the Transmission Control Protocol (TCP) [RFC0793] values for use with the Transmission Control Protocol (TCP) [RFC0793]
and the User Datagram Protocol (UDP) [RFC0768] have had less than and the User Datagram Protocol (UDP) [RFC0768] have had less than
clear guidelines. New transport protocols have been added - the clear guidelines. New transport protocols have been added - the
Stream Control Transmission Protocol (SCTP) [RFC4960] and the Stream Control Transmission Protocol (SCTP) [RFC4960] and the
Datagram Congestion Control Protocol (DCCP) [RFC4342] - and new Datagram Congestion Control Protocol (DCCP) [RFC4342] - and new
mechanisms like DNS SRV records [RFC2782] have been developed, each mechanisms like DNS SRV records [RFC2782] have been developed, each
skipping to change at page 4, line 45 skipping to change at page 4, line 45
IANA is the authority for assigning service names and port numbers. IANA is the authority for assigning service names and port numbers.
The registries that are created to store these assignments are The registries that are created to store these assignments are
maintained by IANA. For protocols developed by IETF working groups, maintained by IANA. For protocols developed by IETF working groups,
IANA now also offers a method for the "early assignment" [RFC4020] of IANA now also offers a method for the "early assignment" [RFC4020] of
service names and port numbers, as described in Section 8.1. service names and port numbers, as described in Section 8.1.
This document updates IANA's procedures for UDP and TCP port numbers This document updates IANA's procedures for UDP and TCP port numbers
by obsoleting Sections 8 and 9.1 of the IANA assignment guidelines by obsoleting Sections 8 and 9.1 of the IANA assignment guidelines
[RFC2780]. (Note that other sections of the IANA assignment [RFC2780]. (Note that other sections of the IANA assignment
guidelines, relating to the protocol field values in IPv4 header, guidelines, relating to the protocol field values in IPv4 headers,
were also updated in February 2008 [RFC5237].) This document also were also updated in February 2008 [RFC5237].) This document also
updates the IANA assignment procedures for DCCP [RFC4340] and SCTP updates the IANA assignment procedures for DCCP [RFC4340] and SCTP
[RFC4960]. [RFC4960].
The Lightweight User Datagram Protocol (UDP-Lite) shares the port The Lightweight User Datagram Protocol (UDP-Lite) shares the port
space with UDP. The UDP-Lite specification [RFC5237] says: "UDP-Lite space with UDP. The UDP-Lite specification [RFC3828] says: "UDP-Lite
uses the same set of port number values assigned by the IANA for use uses the same set of port number values assigned by the IANA for use
by UDP". Thus the update of UDP procedures result in an update also by UDP". An update of the UDP procedures therefore also results in a
of the UDP-Lite procedures. corresponding update of the UDP-Lite procedures.
This document also clarifies what a service name is and how it is This document also clarifies what a service name is and how it is
assigned. This will impact the DNS SRV specification [RFC2782], assigned. This will impact the DNS SRV specification [RFC2782],
because that specification merely makes a brief mention that the because that specification merely makes a brief mention that the
symbolic names of services are defined in "Assigned Numbers" symbolic names of services are defined in "Assigned Numbers"
[RFC1700], without stating to which section it refers within that [RFC1700], without stating to which section it refers within that
230-page document. The DNS SRV specification may have been referring 230-page document. The DNS SRV specification may have been referring
to the list of Port Assignments (known as /etc/services on Unix), or to the list of Port Assignments (known as /etc/services on Unix), or
to the "Protocol And Service Names" section, or to both, or to some to the "Protocol And Service Names" section, or to both, or to some
other section. Furthermore, "Assigned Numbers" is now obsolete other section. Furthermore, "Assigned Numbers" [RFC1700] has been
[RFC3232] and has been replaced by on-line registries obsoleted [RFC3232] and has been replaced by on-line registries
[PORTREG][PROTSERVREG]. [PORTREG][PROTSERVREG].
The development of new transport protocols is a major effort that the The development of new transport protocols is a major effort that the
IETF does not undertake very often. If a new transport protocol is IETF does not undertake very often. If a new transport protocol is
standardized in the future, it is expected to follow these guidelines standardized in the future, it is expected to follow these guidelines
and practices around using service names and port numbers as much as and practices around using service names and port numbers as much as
possible, for consistency. possible, for consistency.
2. Motivation 2. Motivation
skipping to change at page 6, line 24 skipping to change at page 6, line 24
Names" registry [PROTSERVREG] into the IANA "Service Name and Names" registry [PROTSERVREG] into the IANA "Service Name and
Transport Protocol Port Number" registry [PORTREG], which from here Transport Protocol Port Number" registry [PORTREG], which from here
on is the single authoritative registry for service names and port on is the single authoritative registry for service names and port
numbers. numbers.
An additional purpose of this document is to describe the principles An additional purpose of this document is to describe the principles
that guide the IETF and IANA in their role as the long-term joint that guide the IETF and IANA in their role as the long-term joint
stewards of the service name and port number registry. TCP and UDP stewards of the service name and port number registry. TCP and UDP
have had remarkable success over the last decades. Thousands of have had remarkable success over the last decades. Thousands of
applications and application-level protocols have service names and applications and application-level protocols have service names and
ports assigned for their use, and there is every reason to believe port numbers assigned for their use, and there is every reason to
that this trend will continue into the future. It is hence extremely believe that this trend will continue into the future. It is hence
important that management of the registry follow principles that extremely important that management of the registry follow principles
ensure its long-term usefulness as a shared resource. Section 7 that ensure its long-term usefulness as a shared resource. Section 7
discusses these principles in detail. discusses these principles in detail.
3. Background 3. Background
The Transmission Control Protocol (TCP) [RFC0793] and the User The Transmission Control Protocol (TCP) [RFC0793] and the User
Datagram Protocol (UDP) [RFC0768] have enjoyed a remarkable success Datagram Protocol (UDP) [RFC0768] have enjoyed a remarkable success
over the decades as the two most widely used transport protocols on over the decades as the two most widely used transport protocols on
the Internet. They have relied on the concept of "ports" as logical the Internet. They have relied on the concept of "ports" as logical
entities for Internet communication. Ports serve two purposes: entities for Internet communication. Ports serve two purposes:
first, they provide a demultiplexing identifier to differentiate first, they provide a demultiplexing identifier to differentiate
skipping to change at page 7, line 41 skipping to change at page 7, line 41
based on service names via system calls such as getservbyname() on based on service names via system calls such as getservbyname() on
UNIX, look up port numbers by performing queries for DNS SRV records UNIX, look up port numbers by performing queries for DNS SRV records
[RFC2782][I-D.cheshire-dnsext-dns-sd], or determine port numbers in a [RFC2782][I-D.cheshire-dnsext-dns-sd], or determine port numbers in a
variety of other ways like the TCP Port Service Multiplexer (TCPMUX) variety of other ways like the TCP Port Service Multiplexer (TCPMUX)
[RFC1078]. [RFC1078].
Designers of applications and application-level protocols may apply Designers of applications and application-level protocols may apply
to IANA for an assigned service name and port number for a specific to IANA for an assigned service name and port number for a specific
application, and may - after assignment - assume that no other application, and may - after assignment - assume that no other
application will use that service name or port number for its application will use that service name or port number for its
communication sessions. Alternatively, application designers may communication sessions. Application designers also have the option
also ask for only an assigned service name, if their application does of requesting only an assigned service name without a corresponding
not require a fixed port number. The latter alternative is fixed port number if their application does not require one, such as
encouraged when possible, in order to conserve the more limited port applications that use DNS SRV records to look up port numbers
number space. This is applicable, for example, to applications that dynamically at runtime. Because the port number space is finite (and
use DNS SRV records to look up port numbers at runtime. therefore conservation is an important goal) the alternative of using
service names instead of port numbers is RECOMMENDED whenever
possible.
4. Conventions Used in this Document 4. Conventions Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in "Key words for use in document are to be interpreted as described in "Key words for use in
RFCs to Indicate Requirement Levels" [RFC2119]. RFCs to Indicate Requirement Levels" [RFC2119].
This document uses the term "assignment" to refer to the procedure by This document uses the term "assignment" to refer to the procedure by
which IANA provides service names and/or port numbers to requesting which IANA provides service names and/or port numbers to requesting
skipping to change at page 9, line 13 skipping to change at page 9, line 15
exclusively. exclusively.
o As indicated in this document in Section 10.1, overloading has o As indicated in this document in Section 10.1, overloading has
been used to create replacement names that are consistent with the been used to create replacement names that are consistent with the
syntax this document prescribes for legacy names that do not syntax this document prescribes for legacy names that do not
conform to this syntax already. For such cases, only the new name conform to this syntax already. For such cases, only the new name
should be used in SRV records, to avoid the same issues as with should be used in SRV records, to avoid the same issues as with
historical cases of multiple names, and also because the legacy historical cases of multiple names, and also because the legacy
names are incompatible with SRV record use. names are incompatible with SRV record use.
For future assignments, applications will not be permitted that From now on, assignment requests for new names for already-registered
merely request a new name exactly duplicating an existing service. services will be rejected, because having multiple names for the same
Having multiple names for the same service serves no purpose. service serves no purpose. Implementers are requested to inform IANA
Implementers are requested to inform IANA if they discover other if they discover other cases where a single service has multiple
cases where a single service has multiple names, so that one name may names, so that one name may be recorded as the primary name for
be recorded as the primary name for service discovery purposes. service discovery purposes.
Service names are assigned on a "first come, first served" basis, as Service names are assigned on a "first come, first served" basis, as
described in Section 8.1. Names should be brief and informative, described in Section 8.1. Names should be brief and informative,
avoiding words or abbreviations that are redundant in the context of avoiding words or abbreviations that are redundant in the context of
the registry (e.g., "port", "service", "protocol", etc.) Names the registry (e.g., "port", "service", "protocol", etc.) Names
referring to discovery services, e.g., using multicast or broadcast referring to discovery services, e.g., using multicast or broadcast
to identify endpoints capable of a given service, SHOULD use an to identify endpoints capable of a given service, SHOULD use an
easily identifiable suffix (e.g., "-disc"). easily identifiable suffix (e.g., "-disc").
5.1. Service Name Syntax 5.1. Service Name Syntax
skipping to change at page 10, line 31 skipping to change at page 10, line 34
[SYSFORM] [USRFORM]. In approximately 2% of cases, the new "service [SYSFORM] [USRFORM]. In approximately 2% of cases, the new "service
name" is derived from the old historic "short name" as described name" is derived from the old historic "short name" as described
below in Section 10.1. below in Section 10.1.
The rules for valid service names, excepting the limit of 15 The rules for valid service names, excepting the limit of 15
characters maximum, are also expressed below (as a non-normative characters maximum, are also expressed below (as a non-normative
convenience) using ABNF [RFC5234]. convenience) using ABNF [RFC5234].
SRVNAME = *(1*DIGIT [HYPHEN]) ALPHA *([HYPHEN] ALNUM) SRVNAME = *(1*DIGIT [HYPHEN]) ALPHA *([HYPHEN] ALNUM)
ALNUM = ALPHA / DIGIT ; A-Z, a-z, 0-9 ALNUM = ALPHA / DIGIT ; A-Z, a-z, 0-9
HYPHEN = %x2d ; "-" HYPHEN = %x2D ; "-"
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z [RFC5234] ALPHA = %x41-5A / %x61-7A ; A-Z / a-z [RFC5234]
DIGIT = %x30-39 ; 0-9 [RFC5234] DIGIT = %x30-39 ; 0-9 [RFC5234]
5.2. Service Name Usage in DNS SRV Records 5.2. Service Name Usage in DNS SRV Records
The DNS SRV specification [RFC2782] states that the Service Label The DNS SRV specification [RFC2782] states that the Service Label
part of the owner name of a DNS SRV record includes a "Service" part of the owner name of a DNS SRV record includes a "Service"
element, described as "the symbolic name of the desired service", but element, described as "the symbolic name of the desired service", but
as discussed above, it is not clear precisely what this means. as discussed above, it is not clear precisely what this means.
This document clarifies that the Service Label MUST be a service name This document clarifies that the Service Label MUST be a service name
as defined herein with an underscore prepended. The service name as defined herein with an underscore prepended. The service name
SHOULD be registered with IANA and recorded in the Service Name and SHOULD be registered with IANA and recorded in the Service Name and
Transport Protocol Port Number Registry [PORTREG]. Transport Protocol Port Number Registry [PORTREG].
The details of using Service Names in SRV Service Labels are The details of using Service Names in SRV Service Labels are
specified in the DNS SRV specification [RFC2782]. This document does specified in the DNS SRV specification [RFC2782].
not change that specification.
6. Port Number Ranges 6. Port Number Ranges
TCP, UDP, UDP-Lite, SCTP and DCCP use 16-bit namespaces for their TCP, UDP, UDP-Lite, SCTP and DCCP use 16-bit namespaces for their
port number registries. The port registries for all these transport port number registries. The port registries for all of these
protocols are subdivided into three ranges of numbers, and transport protocols are subdivided into three ranges of numbers
Section 8.1.1 describes the IANA procedures for each range in detail: [RFC1340], and Section 8.1.2 describes the IANA procedures for each
range in detail:
o the System Ports, also known as the Well Known Ports, from 0-1023 o the System Ports, also known as the Well Known Ports, from 0-1023
(assigned by IANA) (assigned by IANA)
o the User Ports, also known as the Registered Ports, from 1024- o the User Ports, also known as the Registered Ports, from 1024-
49151 (assigned by IANA) 49151 (assigned by IANA)
o the Dynamic Ports, also known as the Private Ports, from 49152- o the Dynamic Ports, also known as the Private or Ephemeral Ports,
65535 (never assigned) from 49152-65535 (never assigned)
Of the assignable port ranges (System Ports and User Ports, i.e., Of the assignable port ranges (System Ports and User Ports, i.e.,
port numbers 0-49151), individual port numbers are in one of three port numbers 0-49151), individual port numbers are in one of three
states at any given time: states at any given time:
o Assigned: Assigned port numbers are currently assigned to the o Assigned: Assigned port numbers are currently assigned to the
service indicated in the registry. service indicated in the registry.
o Unassigned: Unassigned port numbers are currently available for o Unassigned: Unassigned port numbers are currently available for
assignment upon request, as per the procedures outlined in this assignment upon request, as per the procedures outlined in this
skipping to change at page 11, line 41 skipping to change at page 11, line 43
o Reserved: Reserved port numbers are not available for regular o Reserved: Reserved port numbers are not available for regular
assignment; they are "assigned to IANA" for special purposes. assignment; they are "assigned to IANA" for special purposes.
Reserved port numbers include values at the edges of each range, Reserved port numbers include values at the edges of each range,
e.g., 0, 1023, 1024, etc., which may be used to extend these e.g., 0, 1023, 1024, etc., which may be used to extend these
ranges or the overall port number space in the future. ranges or the overall port number space in the future.
In order to keep the size of the registry manageable, IANA typically In order to keep the size of the registry manageable, IANA typically
only records the Assigned and Reserved service names and port numbers only records the Assigned and Reserved service names and port numbers
in the registry. Unassigned values are typically not explicitly in the registry. Unassigned values are typically not explicitly
listed. (There are a near-infinite number of Unassigned service listed. (There are very many Unassigned service names and
names and enumerating them all would not be practical.) enumerating them all would not be practical.)
As a data point, when this document was written, approximately 76% of As a data point, when this document was written, approximately 76% of
the TCP and UDP System Ports were assigned, and approximately 9% of the TCP and UDP System Ports were assigned, and approximately 9% of
the User Ports were assigned. (As noted, Dynamic Ports are never the User Ports were assigned. (As noted, Dynamic Ports are never
assigned.) assigned.)
6.1. Service names and Port Numbers for Experimentation 6.1. Service names and Port Numbers for Experimentation
Of the System Ports, two TCP and UDP port numbers (1021 and 1022), Of the System Ports, two TCP and UDP port numbers (1021 and 1022),
together with their respective service names ("exp1" and "exp2"), together with their respective service names ("exp1" and "exp2"),
have been assigned for experimentation with new applications and have been assigned for experimentation with new applications and
application-layer protocols that require a port number in the application-layer protocols that require a port number in the
assigned ports ranges [RFC4727]. assigned ports range [RFC4727].
Please refer to Sections 1 and 1.1 of "Assigning Experimental and Please refer to Sections 1 and 1.1 of "Assigning Experimental and
Testing Numbers Considered Useful" [RFC3692] for how these Testing Numbers Considered Useful" [RFC3692] for how these
experimental port numbers are to be used. experimental port numbers are to be used.
This document assigns the same two service names and port numbers for This document assigns the same two service names and port numbers for
experimentation with new application-layer protocols over SCTP and experimentation with new application-layer protocols over SCTP and
DCCP in Section 10.2. DCCP in Section 10.2.
Unfortunately, it can be difficult to limit access to these ports. Unfortunately, it can be difficult to limit access to these ports.
skipping to change at page 13, line 29 skipping to change at page 13, line 34
port numbers even where not strictly necessary) port numbers even where not strictly necessary)
o SCTP and DCCP service name and port number registries were managed o SCTP and DCCP service name and port number registries were managed
separately from the TCP/UDP registries separately from the TCP/UDP registries
o Service names could not be assigned in the old ports registry o Service names could not be assigned in the old ports registry
without assigning an associated port number at the same time without assigning an associated port number at the same time
7.2. Updated Principles 7.2. Updated Principles
This section summarizes the current principles by which IANA handles This section summarizes the current principles by which IANA both
the Service Name and Transport Protocol Port Number Registry and handles the Service Name and Transport Protocol Port Number Registry
attempts to conserve the port number space. This description is and attempts to conserve the port number space. This description is
intended to inform applicants requesting service names and port intended to inform applicants requesting service names and port
numbers. IANA has flexibility beyond these principles when handling numbers. IANA has flexibility beyond these principles when handling
assignment requests; other factors may come into play, and exceptions assignment requests; other factors may come into play, and exceptions
may be made to best serve the needs of the Internet. may be made to best serve the needs of the Internet. Applicants
should be aware that IANA decisions are not required to be bound to
these principles.
IANA strives to assign service names that do not request an IANA strives to assign service names that do not request an
associated port number assignment under a simple "First Come, First associated port number assignment under a simple "First Come, First
Served" policy [RFC5226]. IANA MAY, at its discretion, refer service Served" policy [RFC5226]. IANA MAY, at its discretion, refer service
name requests to "Expert Review" in cases of mass assignment requests name requests to "Expert Review" in cases of mass assignment requests
or other situations where IANA believes expert review is advisable. or other situations where IANA believes expert review is advisable
[RFC5226].
The basic principle of service name and port number registry The basic principle of service name and port number registry
management is to conserve use of the port space where possible. management is to conserve use of the port space where possible.
Extensions to support larger port number spaces would require Extensions to support larger port number spaces would require
changing many core protocols of the current Internet in a way that changing many core protocols of the current Internet in a way that
would not be backward compatible and interfere with both current and would not be backward compatible and interfere with both current and
legacy applications. To help ensure this conservation the policy for legacy applications. To help ensure this conservation the policy for
any assignment request for port number assignments uses the "Expert any assignment request for port number assignments uses the "Expert
Review" policy [RFC5226]. Review" policy [RFC5226].
Conservation of the port number space is required because this space Conservation of the port number space is required because this space
is a limited resource, so applications are expected to participate in is a limited resource, so applications are expected to participate in
the traffic demultiplexing process where feasible. The port numbers the traffic demultiplexing process where feasible. The port numbers
skipping to change at page 15, line 14 skipping to change at page 15, line 22
that anything a single process can demultiplex, or that can be that anything a single process can demultiplex, or that can be
encoded into a single protocol, should be. The firewall filtering encoded into a single protocol, should be. The firewall filtering
use suggests that some uses that could be multiplexed or encoded use suggests that some uses that could be multiplexed or encoded
could instead be separated to allow for easier firewall management. could instead be separated to allow for easier firewall management.
Note that this latter use is much less sound, because port numbers Note that this latter use is much less sound, because port numbers
have meaning only for the two endpoints involved in a connection, and have meaning only for the two endpoints involved in a connection, and
drawing conclusions about the service that generated a given flow drawing conclusions about the service that generated a given flow
based on observed port numbers is not always reliable. Further, the based on observed port numbers is not always reliable. Further, the
previous practice of separating protocol variants based on security previous practice of separating protocol variants based on security
capabilities (e.g., HTTP on TCP port 80 vs. HTTPS on TCP port 443) is capabilities (e.g., HTTP on TCP port 80 vs. HTTPS on TCP port 443) is
not recommended for new protocols, because all new protocols should strongly discouraged for new protocols, because all new protocols
be security-capable. should be security-capable.
IANA will begin assigning port numbers for only those transport IANA will begin assigning port numbers for only those transport
protocols explicitly included in an assignment request. This ends protocols explicitly included in an assignment request. This ends
the long-standing practice of automatically assigning a port number the long-standing practice of automatically assigning a port number
to an application for both TCP and a UDP, even if the request is for to an application for both TCP and UDP, even if the request is for
only one of these transport protocols. The new assignment procedure only one of these transport protocols. The new assignment procedure
conserves resources by assigning a port number to an application for conserves resources by assigning a port number to an application for
only those transport protocols (TCP, UDP, SCTP and/or DCCP) it only those transport protocols (TCP, UDP, SCTP and/or DCCP) it
actually uses. The port number will be marked as Reserved - instead actually uses. The port number will be marked as Reserved - instead
of Assigned - in the port number registries of the other transport of Assigned - in the port number registries of the other transport
protocols. When applications start supporting the use of some of protocols. When applications start supporting the use of some of
those additional transport protocols, the Assignee for the assignment those additional transport protocols, the Assignee for the assignment
MUST request IANA convert these reserved ports into assignments. An MUST request IANA convert these reserved ports into assignments. An
application MUST NOT assume that it can use a port number assigned to application MUST NOT assume that it can use a port number assigned to
it for use with one transport protocol with another transport it for use with one transport protocol with another transport
protocol without asking IANA to convert the reserved ports into an protocol without IANA converting the reservation into an assignment.
assignment.
When the available pool of unassigned numbers has run out in a ports When the available pool of unassigned numbers has run out in a port
range, it will be necessary for IANA to consider the Reserved ports range, it will be necessary for IANA to consider the Reserved ports
for assignment. This is part of the motivation for not automatically for assignment. This is part of the motivation for not automatically
assigning ports for transport protocols other than the requested assigning ports for transport protocols other than the requested
one(s). This will allow more ports to be available for assignment one(s). This will allow more ports to be available for assignment at
when that time comes. To help conserve ports, application developers that point. To help conserve ports, application developers SHOULD
should request assignment of only the transport protocols that their request assignment of only those transport protocols that their
application currently uses. application currently uses.
Conservation of port numbers is improved by procedures that allow Conservation of port numbers is improved by procedures that allow
previously allocated port numbers to become Unassigned, either previously allocated port numbers to become Unassigned, either
through de-assignment or through revocation, and by a procedure that through de-assignment or through revocation, and by a procedure that
lets application designers transfer an assigned but unused port lets application designers transfer an assigned but unused port
number to a new application. Section 8 describes these procedures, number to a new application. Section 8 describes these procedures,
which until now were undocumented. Port number conservation is also which until now were undocumented. Port number conservation is also
improved by recommending that applications that do not require an improved by recommending that applications that do not require an
assigned port should register only a service name without an assigned port should register only a service name without an
skipping to change at page 16, line 20 skipping to change at page 16, line 26
Port Number Registry. Such requests include initial assignment, de- Port Number Registry. Such requests include initial assignment, de-
assignment, reuse, changes to the service name, and updates to the assignment, reuse, changes to the service name, and updates to the
contact information or description associated with an assignment. contact information or description associated with an assignment.
Revocation is as additional process, initiated by IANA. Revocation is as additional process, initiated by IANA.
8.1. Service Name and Port Number Assignment 8.1. Service Name and Port Number Assignment
Assignment refers to the process of providing service names or port Assignment refers to the process of providing service names or port
numbers to applicants. All such assignments are made from service numbers to applicants. All such assignments are made from service
names or port numbers that are Unassigned or Reserved at the time of names or port numbers that are Unassigned or Reserved at the time of
the assignment. Unassigned names and numbers are allocated according the assignment.
to the rules described in Section 8.1.1 below. Except as described
below, Reserved numbers and names are assigned only by a Standards o Unassigned names and numbers are allocated according to the rules
Action or an IESG Approval, and MUST accompanied by a statement described in Section 8.1.2 below.
explaining the reason a Reserved number or name is appropriate for
this action. o Reserved numbers and names are generally only assigned by a
Standards Action or an IESG Approval, and MUST be accompanied by a
statement explaining the reason a Reserved number or name is
appropriate for this action. The only exception to this rule is
that the current Assignee of a port number MAY request the
assignment of the corresponding Reserved port number for other
transport protocols when needed. IANA will initiate an "Expert
Review" [RFC5226] for such requests.
When an assignment for one or more transport protocols is approved, When an assignment for one or more transport protocols is approved,
the port number for any non-requested transport protocol(s) will be the port number for any non-requested transport protocol(s) will be
marked as Reserved. IANA SHOULD NOT assign that port number to any marked as Reserved. IANA SHOULD NOT assign that port number to any
other application or service until no other port numbers remain other application or service until no other port numbers remain
Unassigned in the requested range. The current Assignee for a port Unassigned in the requested range.
number MAY request assignment of these Reserved port numbers for
other transport protocols when needed.
8.1.1. General Assignment Procedure
A service name or port number assignment request contains the A service name or port number assignment request contains the
following information. The service name is the unique identifier of following information. The service name is the unique identifier of
a given service: a given service:
Service Name (REQUIRED) Service Name (REQUIRED)
Transport Protocol(s) (REQUIRED) Transport Protocol(s) (REQUIRED)
Assignee (REQUIRED) Assignee (REQUIRED)
Contact (REQUIRED) Contact (REQUIRED)
Description (REQUIRED) Description (REQUIRED)
Reference (REQUIRED) Reference (REQUIRED)
Port Number (OPTIONAL) Port Number (OPTIONAL)
Service Code (REQUIRED for DCCP only) Service Code (REQUIRED for DCCP only)
Known Unauthorized Uses (OPTIONAL) Known Unauthorized Uses (OPTIONAL)
Assignment Notes (OPTIONAL) Assignment Notes (OPTIONAL)
o Service Name: A desired unique service name for the service o Service Name: A desired unique service name for the service
associated with the assignment request MUST be provided, for use associated with the assignment request MUST be provided. This
in various service selection and discovery mechanisms (including, name may be used with various service selection and discovery
but not limited to, DNS SRV records [RFC2782]). The name MUST be mechanisms (including, but not limited to, DNS SRV records
compliant with the syntax defined in Section 5.1. In order to be [RFC2782]). The name MUST be compliant with the syntax defined in
unique, they MUST NOT be identical to any currently assigned Section 5.1. In order to be unique, they MUST NOT be identical to
service name in the IANA registry [PORTREG]. Service names are any currently assigned service name in the IANA registry
case-insensitive; they may be provided and entered into the [PORTREG]. Service names are case-insensitive; they may be
registry with mixed case for clarity, but for the comparison provided and entered into the registry with mixed case for
purposes the case is ignored. clarity, but for the comparison purposes the case is ignored.
o Transport Protocol(s): The transport protocol(s) for which an o Transport Protocol(s): The transport protocol(s) for which an
assignment is requested MUST be provided. This field is currently assignment is requested MUST be provided. This field is currently
limited to one or more of TCP, UDP, SCTP, and DCCP. Requests limited to one or more of TCP, UDP, SCTP, and DCCP. Requests
without any port assignment and only a service name are still without any port assignment and only a service name are still
required to indicate which protocol the service uses. required to indicate which protocol the service uses.
o Assignee: Name and email address of the party to whom the o Assignee: Name and email address of the party to whom the
assignment is made. This is REQUIRED. The Assignee is the assignment is made. This is REQUIRED. The Assignee is the
Organization or Company responsible for the initial assignment. organization, company or individual person responsible for the
For assignments done through IETF-published RFCs, the Assignee initial assignment. For assignments done through RFCs published
will be the IETF, with the IESG <iesg@ietf.org> as the point of via the "IETF Document Stream" [RFC4844], the Assignee will be the
contact. IESG <iesg@ietf.org>.
o Contact: Name and email address of the Contact person for the o Contact: Name and email address of the Contact person for the
assignment. This is REQUIRED. The Contact person is the assignment. This is REQUIRED. The Contact person is the
responsible person for the Internet community to send questions responsible person for the Internet community to send questions
to. This person is also authorized to submit changes on behalf of to. This person is also authorized to submit changes on behalf of
the Assignee; in cases of conflict between the Assignee and the the Assignee; in cases of conflict between the Assignee and the
Contact, the Assignee decisions take precedence. Additional Contact, the Assignee decisions take precedence. Additional
address information MAY be provided. For assignments done through address information MAY be provided. For assignments done through
IETF-published RFCs, the Contact will be the IESG. RFCs published via the "IETF Document Stream" [RFC4844], the
Contact will be the IETF Chair <chair@ietf.org>.
o Description: A short description of the service associated with o Description: A short description of the service associated with
the assignment request is REQUIRED. It should avoid all but the the assignment request is REQUIRED. It should avoid all but the
most well-known acronyms. most well-known acronyms.
o Reference: A description of (or a reference to a document o Reference: A description of (or a reference to a document
describing) the protocol or application using this port. The describing) the protocol or application using this port. The
description must state whether the protocol uses broadcast, description must state whether the protocol uses IP-layer
multicast, or anycast communication. broadcast, multicast, or anycast communication.
For assignments requesting only a Service Name, or a Service Name For assignments requesting only a Service Name, or a Service Name
and User Port, a statement that the protocol is proprietary and and User Port, a statement that the protocol is proprietary and
not publicly documented is also acceptable provided that the not publicly documented is also acceptable, provided that the
required information regarding use of broadcast, multicast, or required information regarding the use of IP broadcast, multicast,
anycast is given. or anycast is given.
For assignment requests for a User Port, the assignment request For any assignment request that includes a User Port, the
MUST explain why a port number in the Dynamic Ports range is assignment request MUST explain why a port number in the Dynamic
unsuitable for the given application. Ports range is unsuitable for the given application.
For assignment requests for a System Port, the assignment request For any assignment request that includes a System Port, the
MUST explain why a port number in the User Ports or Dynamic Ports assignment request MUST explain why a port number in the User
ranges is unsuitable, and a reference to a stable protocol Ports or Dynamic Ports ranges is unsuitable, and a reference to a
specification document MUST be provided. For requests from IETF stable protocol specification document MUST be provided.
Working Groups, IANA MAY accept early assignment [RFC4020]
requests (known as "early allocation" therein) referencing a IANA MAY accept early assignment [RFC4020] requests (known as
sufficiently stable Internet Draft instead of a published "early allocation" therein) from IETF Working Groups that
Standards-Track RFC. reference a sufficiently stable Internet Draft instead of a
published Standards-Track RFC.
o Port Number: If assignment of a port number is desired, either the o Port Number: If assignment of a port number is desired, either the
port number the requester suggests for assignment or indication of port number the requester suggests for assignment or indication of
port range (user or system) MUST be provided. If only a service port range (user or system) MUST be provided. If only a service
name is to be assigned, this field is left empty. If a specific name is to be assigned, this field is left empty. If a specific
port number is requested, IANA is encouraged to assign the port number is requested, IANA is encouraged to assign the
requested number. If a range is specified, IANA will choose a requested number. If a range is specified, IANA will choose a
suitable number from the User or System Ports ranges. Note that suitable number from the User or System Ports ranges. Note that
the applicant MUST NOT use the requested port prior to the the applicant MUST NOT use the requested port prior to the
completion of the assignment. completion of the assignment.
skipping to change at page 19, line 12 skipping to change at page 19, line 31
existing service name and other appropriate experts whether the existing service name and other appropriate experts whether the
overloading is appropriate. overloading is appropriate.
When IANA receives an assignment request - containing the above When IANA receives an assignment request - containing the above
information - that is requesting a port number, IANA SHALL initiate information - that is requesting a port number, IANA SHALL initiate
an "Expert Review" [RFC5226] in order to determine whether an an "Expert Review" [RFC5226] in order to determine whether an
assignment should be made. For requests that are not seeking a port assignment should be made. For requests that are not seeking a port
number, IANA SHOULD assign the service name under a simple "First number, IANA SHOULD assign the service name under a simple "First
Come First Served" policy [RFC5226]. Come First Served" policy [RFC5226].
8.1.1. Variances for Specific Port Number Ranges 8.1.2. Variances for Specific Port Number Ranges
Section 6 describes the different port number ranges. It is Section 6 describes the different port number ranges. It is
important to note that IANA applies slightly different procedures important to note that IANA applies slightly different procedures
when managing the different port ranges of the service name and port when managing the different port ranges of the service name and port
number registry: number registry:
o Ports in the Dynamic Ports range (49152-65535) have been o Ports in the Dynamic Ports range (49152-65535) have been
specifically set aside for local and dynamic use and cannot be specifically set aside for local and dynamic use and cannot be
assigned through IANA. Application software may simply use any assigned through IANA. Application software may simply use any
dynamic port that is available on the local host, without any sort dynamic port that is available on the local host, without any sort
skipping to change at page 25, line 15 skipping to change at page 26, line 15
Note that these port numbers are meant for temporary experimentation Note that these port numbers are meant for temporary experimentation
and development in controlled environments. Before using these port and development in controlled environments. Before using these port
numbers, carefully consider the advice in Section 6.1 in this numbers, carefully consider the advice in Section 6.1 in this
document, as well as in Sections 1 and 1.1 of "Assigning Experimental document, as well as in Sections 1 and 1.1 of "Assigning Experimental
and Testing Numbers Considered Useful" [RFC3692]. Most importantly, and Testing Numbers Considered Useful" [RFC3692]. Most importantly,
application developers must request a permanent port number application developers must request a permanent port number
assignment from IANA as described in Section 8.1 before any kind of assignment from IANA as described in Section 8.1 before any kind of
non-experimental deployment. non-experimental deployment.
+--------------------+----------------------------+ +--------------------+-----------------------------+
| Service Name | exp1 | | Service Name | exp1 |
| Transport Protocol | DCCP, SCTP, TCP, UDP | | Transport Protocol | DCCP, SCTP, TCP, UDP |
| Assignee | IETF <iesg@ietf.org> | | Assignee | IESG <iesg@ietf.org> |
| Contact | IESG <iesg@ietf.org> | | Contact | IETF Chair <chair@ietf.org> |
| Description | RFC3692-style Experiment 1 | | Description | RFC3692-style Experiment 1 |
| Reference | [RFC4727] [RFCyyyy] | | Reference | [RFC4727] [RFCyyyy] |
| Port Number | 1021 | | Port Number | 1021 |
+--------------------+----------------------------+ +--------------------+-----------------------------+
+--------------------+----------------------------+ +--------------------+-----------------------------+
| Service Name | exp2 | | Service Name | exp2 |
| Transport Protocol | DCCP, SCTP, TCP, UDP | | Transport Protocol | DCCP, SCTP, TCP, UDP |
| Assignee | IETF <iesg@ietf.org> | | Assignee | IESG <iesg@ietf.org> |
| Contact | IESG <iesg@ietf.org> | | Contact | IETF Chair <chair@ietf.org> |
| Description | RFC3692-style Experiment 2 | | Description | RFC3692-style Experiment 2 |
| Reference | [RFC4727] [RFCyyyy] | | Reference | [RFC4727] [RFCyyyy] |
| Port Number | 1022 | | Port Number | 1022 |
+--------------------+----------------------------+ +--------------------+-----------------------------+
[RFC Editor Note: Please change "yyyy" to the RFC number allocated to [RFC Editor Note: Please change "yyyy" to the RFC number allocated to
this document before publication.] this document before publication.]
10.3. Updates to DCCP Registries 10.3. Updates to DCCP Registries
This document updates the IANA assignment procedures for the DCCP This document updates the IANA assignment procedures for the DCCP
Port Number and DCCP Service Codes Registries [RFC4340]. Port Number and DCCP Service Codes Registries [RFC4340].
10.3.1. DCCP Service Code Registry 10.3.1. DCCP Service Code Registry
Service Codes are assigned first-come-first-served according to Service Codes are assigned first-come-first-served according to
Section 19.8 of the DCCP specification [RFC4340]. This document Section 19.8 of the DCCP specification [RFC4340]. This document
updates that section by extending the guidelines given there in the updates that section by extending the guidelines given there in the
following ways: following ways:
o IANA MAY assign new Service Codes without seeking Expert Review o IANA MAY assign new Service Codes without seeking Expert Review
using their discretion, but SHOULD seek expert review if a request using their discretion, but SHOULD seek expert review if a request
asks for more than five Service Codes. asks for more than five Service Codes.
o IANA should feel free to contact the DCCP Expert Reviewer with o IANA should feel free to contact the DCCP Expert Reviewer with any
questions on any registry, regardless of the registry policy, for questions related to requests for DCCP-related codepoints.
clarification or if there is a problem with a request [RFC4340].
10.3.2. DCCP Port Numbers Registry 10.3.2. DCCP Port Numbers Registry
The DCCP ports registry is defined by Section 19.9 of the DCCP The DCCP ports registry is defined by Section 19.9 of the DCCP
specification [RFC4340]. Assignments in this registry require prior specification [RFC4340]. Assignments in this registry require prior
assignment of a Service Code. Not all Service Codes require IANA- assignment of a Service Code. Not all Service Codes require IANA-
assigned ports. This document updates that section by extending the assigned ports. This document updates that section by extending the
guidelines given there in the following way: guidelines given there in the following way:
o IANA should normally assign a value in the range 1024-49151 to a o IANA should normally assign a value in the range 1024-49151 to a
skipping to change at page 27, line 37 skipping to change at page 28, line 37
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", Values In the Internet Protocol and Related Headers",
BCP 37, RFC 2780, March 2000. BCP 37, RFC 2780, March 2000.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004. (UDP-Lite)", RFC 3828, July 2004.
[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of
Standards Track Code Points", BCP 100, RFC 4020, Standards Track Code Points", BCP 100, RFC 4020,
February 2005. February 2005.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006. Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
skipping to change at page 28, line 10 skipping to change at page 29, line 15
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol
(DCCP) Service Codes", RFC 5595, September 2009.
13.2. Informative References 13.2. Informative References
[I-D.cheshire-dnsext-dns-sd] [I-D.cheshire-dnsext-dns-sd]
Cheshire, S. and M. Krochmal, "DNS-Based Service Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", draft-cheshire-dnsext-dns-sd-07 (work in Discovery", draft-cheshire-dnsext-dns-sd-08 (work in
progress), October 2010. progress), January 2011.
[I-D.cheshire-nat-pmp] [I-D.cheshire-nat-pmp]
Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
draft-cheshire-nat-pmp-03 (work in progress), April 2008. draft-cheshire-nat-pmp-03 (work in progress), April 2008.
[IGD] UPnP Forum, "Internet Gateway Device (IGD) V 1.0", [IGD] UPnP Forum, "Internet Gateway Device (IGD) V 1.0",
November 2001. November 2001.
[PORTREG] Internet Assigned Numbers Authority (IANA), "Service Name [PORTREG] Internet Assigned Numbers Authority (IANA), "Service Name
and Transport Protocol Port Number Registry", and Transport Protocol Port Number Registry",
skipping to change at page 28, line 39 skipping to change at page 29, line 47
Internet Assigned Numbers Authority (IANA), "Protocol and Internet Assigned Numbers Authority (IANA), "Protocol and
Service Names Registry", Service Names Registry",
http://www.iana.org/assignments/service-names. http://www.iana.org/assignments/service-names.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, October 1985. STD 9, RFC 959, October 1985.
[RFC1078] Lottor, M., "TCP port service Multiplexer (TCPMUX)", [RFC1078] Lottor, M., "TCP port service Multiplexer (TCPMUX)",
RFC 1078, November 1988. RFC 1078, November 1988.
[RFC1340] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1340,
July 1992.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994. October 1994.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC2957] Daigle, L. and P. Faltstrom, "The application/ [RFC2957] Daigle, L. and P. Faltstrom, "The application/
whoispp-query Content-Type", RFC 2957, October 2000. whoispp-query Content-Type", RFC 2957, October 2000.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002. an On-line Database", RFC 3232, January 2002.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004. Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for
Datagram Congestion Control Protocol (DCCP) Congestion Datagram Congestion Control Protocol (DCCP) Congestion
Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,
March 2006. March 2006.
[RFC4844] Daigle, L. and Internet Architecture Board, "The RFC
Series and RFC Editor", RFC 4844, July 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
[RFC5237] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for [RFC5237] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for
the Protocol Field", BCP 37, RFC 5237, February 2008. the Protocol Field", BCP 37, RFC 5237, February 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol
(DCCP) Service Codes", RFC 5595, September 2009.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[SRVREG] "DNS SRV Service Types Registry", [SRVREG] "DNS SRV Service Types Registry",
http://www.dns-sd.org/ServiceTypes.html. http://www.dns-sd.org/ServiceTypes.html.
[SYSFORM] Internet Assigned Numbers Authority (IANA), "Application [SYSFORM] Internet Assigned Numbers Authority (IANA), "Application
for System (Well Known) Port Number", for System (Well Known) Port Number",
http://www.iana.org/. http://www.iana.org/.
 End of changes. 55 change blocks. 
136 lines changed or deleted 154 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/