draft-ietf-tsvwg-port-use-03.txt   draft-ietf-tsvwg-port-use-04.txt 
TSVWG J. Touch TSVWG J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Intended status: Best Current Practice November 4, 2013 Intended status: Best Current Practice May 14, 2014
Expires: May 2014 Expires: November 2014
Recommendations for Transport Port Uses Recommendations for Transport Port Uses
draft-ietf-tsvwg-port-use-03.txt draft-ietf-tsvwg-port-use-04.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 4, 2014. This Internet-Draft will expire on November 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
skipping to change at page 2, line 15 skipping to change at page 2, line 14
Abstract Abstract
This document provides recommendations to application and service This document provides recommendations to application and service
designers on how to use the transport protocol port number space to designers on how to use the transport protocol port number space to
help in its preservation. help in its preservation.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
2. Conventions used in this document..............................3 2. Conventions used in this document..............................2
3. History........................................................3 3. History........................................................3
4. Current Port Use...............................................4 4. Current Port Use...............................................4
5. What is a Port?................................................5 5. What is a Port?................................................5
6. Conservation...................................................6 6. Conservation...................................................6
6.1. Firewall and NAT Considerations...........................7 6.1. Firewall and NAT Considerations...........................7
7. How to Use Assigned Ports......................................8 7. How to Use Assigned Ports......................................8
7.1. Do You Need a Port?.......................................8 7.1. Is a port assignment necessary?...........................8
7.2. How Many Ports?..........................................10 7.2. How Many Ports?..........................................10
7.3. Picking a Port Number....................................10 7.3. Picking a Port Number....................................10
7.4. Support for Security.....................................11 7.4. Support for Security.....................................11
7.5. Support for Future Versions..............................12 7.5. Support for Future Versions..............................12
7.6. Transport Protocols......................................12 7.6. Transport Protocols......................................13
7.7. When to Request an Assignment............................14 7.7. When to Request an Assignment............................14
7.8. Squatting................................................15 7.8. Squatting................................................15
7.9. Other Considerations.....................................15 7.9. Other Considerations.....................................16
8. Security Considerations.......................................15 8. Security Considerations.......................................16
9. IANA Considerations...........................................16 9. IANA Considerations...........................................16
10. References...................................................16 10. References...................................................16
10.1. Normative References....................................16 10.1. Normative References....................................16
10.2. Informative References..................................16 10.2. Informative References..................................17
11. Acknowledgments..............................................18 11. Acknowledgments..............................................19
1. Introduction 1. Introduction
This document provides information and advice to system designers on This document provides information and advice to system designers on
the use of transport port numbers and services. It provides a the use of transport port numbers and services. It provides a
detailed historical background of the evolution of transport port detailed historical background of the evolution of transport port
numbers and their multiple meanings. It also provides specific numbers and their multiple meanings. It also provides specific
recommendations on how to use assigned ports. recommendations on how to use assigned ports.
2. Conventions used in this document 2. Conventions used in this document
skipping to change at page 3, line 22 skipping to change at page 3, line 16
only when in ALL CAPS. Lower case uses of these words are not to be only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance. interpreted as carrying RFC-2119 significance.
In this document, the characters ">>" preceding an indented line(s) In this document, the characters ">>" preceding an indented line(s)
indicates a compliance requirement statement using the key words indicates a compliance requirement statement using the key words
listed above. This convention aids reviewers in quickly identifying listed above. This convention aids reviewers in quickly identifying
or finding the explicit compliance requirements of this RFC. or finding the explicit compliance requirements of this RFC.
3. History 3. History
The term 'port' was first used in RFC33 to describe a simplex The term 'port' was first used in [RFC33] to indicate a simplex
communication path from a process [RFC33]. At a meeting described in communication path from an individual process. At a meeting
[RFC37], an idea was presented to decouple connections between described in [RFC37], an idea was presented to decouple connections
processes and links that they use as paths, and thus to include between processes and links that they use as paths, and thus to
source and destination socket identifiers in packets. RFC38 explains include source and destination socket identifiers in packets.
this in detail, in which processes might have more than one of these [RFC38] provides further detail, describing how processes might have
paths, and that more than one may be active at a time [RFC38]. As a more than one of these paths and that more than one path may be
result, there was the need to add a process identifier to the header active at a time. As a result, there was the need to add a process
of each message, so that the incoming data could be demultiplexed to identifier to the header of each message so that incoming messages
the appropriate process. RFC38 further suggested that 32 bits would could be demultiplexed to the appropriate process. [RFC38] further
be used for these identifiers. RFC48 discusses the current notion of suggested that 32 bits would be used for these identifiers. [RFC48]
listening on a given port, but does not discuss the issue of port discusses the current notion of listening on a specific port, but
determination [RFC48]. RFC61 notes that the challenge of knowing the does not discuss the issue of port determination. [RFC61] notes that
appropriate port numbers is "left to the processes" in general, but the challenge of knowing the appropriate port numbers is "left to
introduces the concept of a "well-known" port for common services the processes" in general, but introduces the concept of a "well-
[RFC61]. known" port for common services.
RFC76 addresses this issue more constructively, proposing a [RFC76] proposed a "telephone book" by which an index would allow
"telephone book" by which an index would allow ports to be used by ports to be used by name, but still assumed that both source and
name, but still assumes that both source and destination ports are destination ports are fixed by such a system. [RFC333] proposed that
fixed by such a system [RFC76]. RFC333 suggests that the port pair, a port pair, rather than an individual port, would be used on both
rather than an individual port, would be used on both sides of the sides of the connection for demultiplexing messages. This is the
connection for demultiplexing messages [RFC333]. This is the final final view in [RFC793] (and its predecessors, including [IEN112]),
view in RFC793 (and its predecessors, including IEN 112 [IEN112]), and brings us to their current meaning. [RFC739] introduced the
and brings us to their current meaning. RFC739 introduces the notion notion of generic reserved ports for groups of protocols, such as
of generic reserved ports, used for groups of protocols, such as
"any private RJE server" [RFC739]. Although the overall range of "any private RJE server" [RFC739]. Although the overall range of
such ports was (and remains) 16 bits, only the first 256 (high 8 such ports was (and remains) 16 bits, only the first 256 (high 8
bits cleared) in the range were considered assigned. bits cleared) in the range were considered assigned.
RFC758 is the first to describe a list of such well-known ports, as [RFC758] is the first to describe a list of such well-known ports,
well as describing ranges used for different purposes [RFC758]: as well as describing ranges used for different purposes:
Binary Octal Binary Octal
----------------------------------------------------------- -----------------------------------------------------------
0-63 0-77 Network Wide Standard Function 0-63 0-77 Network Wide Standard Function
64-127 100-177 Hosts Specific Functions 64-127 100-177 Hosts Specific Functions
128-223 200-337 Reserved for Future Use 128-223 200-337 Reserved for Future Use
224-255 340-377 Any Experimental Function 224-255 340-377 Any Experimental Function
In RFC820, those range meanings disappeared, and a single list of In [RFC820] those range meanings disappeared, and a single list of
assignments is presented [RFC820]. By RFC900, they appeared as assignments is presented. By [RFC900] the ranges appeared as decimal
decimal numbers rather than the octal ranges used previously numbers rather than the octal ranges used previously. [RFC1340]
[RFC900]. RFC1340 increased this range from 0..255 to 0..1023, and increased this range from 0..255 to 0..1023, and began to list TCP
began to list TCP and UDP port assignments individually (although and UDP port assignments individually (although the assumption was,
the assumption was, and remains, that once assigned a port applies and remains, that once assigned a port applies to all transport
to all transport protocols, including TCP, UDP, recently SCTP and protocols, including TCP, UDP, recently SCTP and DCCP, as well as
DCCP, as well as ISO-TP4 for a brief period in the early 1990s) ISO-TP4 for a brief period in the early 1990s). [RFC1340] also
[RFC1340]. RFC1340 also established the Registered space of 1024- established the Registered range of 1024-59151, though it notes that
59151, though it notes that it is not controlled by the IANA at that it is not controlled by the IANA at that point. The list provided by
point. The list provided by RFC1700 in 1994 remained the standard [RFC1700] in 1994 remained the standard until it was declared
until it was declared replaced by an on-line version, as of RFC3232 replaced by an on-line version, as of [RFC3232] in 2002.
in 2002 [RFC1700] [RFC3232].
4. Current Port Use 4. Current Port Use
The current IANA website (www.iana.org) indicates three ranges of The current IANA website (www.iana.org) indicates three ranges of
port assignments: port assignments:
Binary Hex Binary Hex
----------------------------------------------------------- -----------------------------------------------------------
0-1023 0x03FF Well-Known (a.k.a. 'system') 0-1023 0x03FF Well-Known (also System)
1024-49151 0x0400-0xBFFF Registered (a.k.a. 'user') 1024-49151 0x0400-0xBFFF Registered (also User)
49152-65535 0xC000-0xFFFF Dynamic/Private 49152-65535 0xC000-0xFFFF Dynamic (also Private)
Well-known encompasses the range 0..1023. On some systems, use of Well-known encompasses the range 0..1023. On some systems, use of
these ports requires privileged access, e.g., that the process run these ports requires privileged access, e.g., that the process run
as 'root', which is why these are referred to as 'system' ports. The as 'root', which is why these are referred to as System ports. The
ports from 1024..49151 denotes non-privileged services, known as ports from 1024..49151 denotes non-privileged services, known as
'registered'; because these ports do not run with special Registered; because these ports do not run with special privileges,
privileges, they are often referred to as 'user' ports. Dynamic or they are often referred to as User ports. Dynamic (also known as
Private ports are not assigned through IANA. Private) ports are not assigned.
Both Well-Known and Registered ports are assigned through IANA, so Both Well-Known and Registered ports are assigned through IANA, so
both are sometimes called "registered ports". As a result, the term both are sometimes called 'registered ports'. As a result, the term
'registered' is ambiguous, referring either to the entire range 0- 'registered' is ambiguous, referring either to the entire range 0-
49151 or to the user ports. Complicating matters further, 'system' 49151 or to the User ports. Complicating matters further, System
ports do not always require special (i.e., 'root') privilege. ports do not always require special (i.e., 'root') privilege. For
Regardless, for clarity, throughout the remainder of this document clarity, the remainder of this document refers to the port ranges as
we will refer to the port ranges as 'system', 'user', and 'private'. System, User, and Dynamic.
5. What is a Port? 5. What is a Port?
A port is a 16-bit number used for two distinct purposes: A port is a 16-bit number used for two distinct purposes:
o Demultiplexing transport connections within an end host o Demultiplexing transport connections within an end host
o Identifying a service o Identifying a service
The first reason requires that each transport connection between a The first purpose requires that each transport connection between a
given pair of IP addresses use a different pair of ports, but does given pair of IP addresses use a different pair of ports, but does
not require either coordination or registration of port use. It is not require either coordination or registration of port use. It is
the second reason that drives the need for a common registry. the second purpose that drives the need for a common registry.
Consider a user wanting to run a web server. That service could run Consider a user wanting to run a web server. That service could run
on any port, provided that all clients knew what port to use to on any port, provided that all clients knew what port to use to
access that service at that host. Such information can be access that service at that host. Such information can be
distributed out of band, e.g., in the URL, such as: distributed out-of-band, e.g., in the URI:
http://www.example.com:51509/ http://www.example.com:51509/
Ultimately, it's important to keep in mind that the correlation of a Ultimately, the correlation of a service with a port number is an
service with a port number is an agreement between the two endpoints agreement between just the two endpoints of the connection. A web
of the connection only. The rest of the world might think that server can run on port 53, which might appear as DNS traffic to
you're sending DNS packets on port 53, but you can run a web server others but will connect to browsers that know to use port 53 rather
on that port just fine, provided the server and client both decide than 80.
that port 53 is for HTTP web server traffic.
Which brings us to the concept of a service. A service is the As a concept, a service is the combination of ISO Layers 5-7 that
combination of ISO Layers 5-7 that represent an application protocol represents an application protocol capability. For example www (port
capability. For example www (port 80) is a service that uses HTTP as 80) is a service that uses HTTP as an application protocol and
an application protocol, and provides a common web server [RFC2616]. provides access to a web server [RFC2616]. However, it is possible
However, it is possible to use HTTP for other purposes, such as to use HTTP for other purposes, such as command and control. This is
command and control. This is why some current service names (HTTP, why some current service names (HTTP, e.g.) are a bit overloaded -
e.g.) are a bit overloaded - they describe not only the application they describe not only the application protocol, but a particular
protocol, but a particular service. service.
IANA assigns ports so that endpoints on the Internet do not need to IANA assigns ports so that Internet endpoints do not need pairwise,
pairwise, explicitly coordinate the meaning of their port numbers. explicit coordination of the meaning of their port numbers. This is
This is the primary reason for requesting assigned ports with IANA - the primary reason for requesting assigned ports with IANA - to have
to have a common agreement between all endpoints on the Internet as a common agreement between all endpoints on the Internet as to the
to the meaning of a port. meaning of a port.
Ports are sometimes used by intermediate devices on a network path, Ports are sometimes used by intermediate devices on a network path,
either to monitor available services, to monitor traffic (e.g., to either to monitor available services, to monitor traffic (e.g., to
indicate the data contents), or to intercept traffic (to block, indicate the data contents), or to intercept traffic (to block,
proxy, relay, aggregate, or otherwise process it). In each case, the proxy, relay, aggregate, or otherwise process it). In each case, the
intermediate device interprets traffic based on the port number. It intermediate device interprets traffic based on the port number. It
is again important to recognize that any interpretation of ports is important to recognize that any interpretation of ports - except
except at the endpoints may be incorrect, because ports are at the endpoints - may be incorrect, because ports are meaningful
meaningful only at the endpoints. Further, the ports may not be only at the endpoints. Further, ports may not be visible to these
visible to these intermediate devices, such as when the transport intermediate devices, such as when the transport protocol is
protocol is encrypted (as in network- or link-layer tunnels), or encrypted (as in network- or link-layer tunnels), or when a packet
when a packet is fragmented (in which only the first fragment has is fragmented (in which case only the first fragment has the port
the port information). Such port invisibility may interfere with information). Such port invisibility may interfere with these in-
these in-network port-based capabilities. network port-based capabilities.
Ports are used for other purposes as well. The other primary reason Ports can also be useful for other purposes. Assigned ports can
for requesting assigned ports with IANA is to simplify end system simplify end system configuration, so that individual installations
configuration, so individual installations do not need to coordinate do not need to coordinate their use of arbitrary ports. Such
their use of arbitrary ports. A similar reason is to simplify assignments can also simplify firewall management, so that a single,
firewall management, so that a single, fixed firewall configuration fixed firewall configuration can either permit or deny a service.
can either permit or deny a service.
6. Conservation 6. Conservation
Ports are a scarce resource that is globally shared by the entire Assigned ports are a scarce resource that is globally shared by the
Internet community. As a result, every attempt should be made to entire Internet community. As a result, every attempt should be made
conserve ports and request only those that are absolutely necessary. to conserve ports and request assignments only for those that are
absolutely necessary.
There are a variety of ways that systems can conserve port numbers: There are a variety of ways that systems can conserve port numbers:
o A single assigned port number can provide access to different o A single assigned port number can support different functions
capabilities over different connections (or equivalent, e.g., over separate connections, determined using in-band
for UDP [RFC768]), using in-band information. information. FTP data connection can transfer binary or text
files, the latter translating line-terminators, as indicated
in-band over the control port [RFC959].
o A single assigned port can indicate the dynamic port(s) on o A single assigned port can indicate the Dynamic port(s) on
which different capabilities are supported, as is done for which different capabilities are supported, as with passive-
FTP. mode FTP [RFC959].
o An existing service can indicate the dynamic port(s) on which o Several existing services can indicate the Dynamic port(s) on
services are supported, such as with mDNS and portmapper which other services are supported, such as with mDNS and
[RFC6762] [RFC6763]. portmapper [RFC1833] [RFC6762] [RFC6763].
o Copies of an existing service can be differentiated by using o Copies of an existing service can be differentiated by using
different IP addresses (even on the same host). different IP addresses, either on different hosts or as
different real or virtual interfaces (or even operating
systems) on the same host.
o Copies of some existing services can be differentiated using o Copies of some existing services can be differentiated using
in-band information (e.g., HTTP). in-band information (e.g., URIs in HTTP Host field and TLS
Server Name Indication extension) [RFC2616] [RFC3546].
o Different performance requirements or capabilities can already o Different performance requirements can already be supported
be supported using different connections or endpoint using separate connections or endpoints with different
associations. capabilities or configurations.
The key observation is that port numbers are intended to Port numbers are intended to differentiate services, not
differentiate services, not performance, replicas, connections, or performance, replicas, connections, or payload types. Port numbers
payload types. Port numbers are a very small space, so it is never are also a very small space, so it is never appropriate to consume
appropriate to consume port numbers to save larger spaces, such as port numbers to save larger spaces, such as IP addresses.
IP addresses.
Others have noted "think twice about modifying TCP, then don't" Others have noted "think twice about modifying TCP, then don't"
[RFC1263]. In this case, similar advice might be: [RFC1263]. In this case, similar advice might be:
o Think twice before asking for a port, then try not to. o Think twice before asking for an assigned port, then try not
to.
o If you need more than one port assignment, revise your o If more than one port is desired, consider revising the
architecture until you can get by with only one, or, architecture until only one is needed, or, preferably, none.
preferably, none.
6.1. Firewall and NAT Considerations 6.1. Firewall and NAT Considerations
Assigned numbers are useful for configuring firewalls and other Assigned ports are useful for configuring firewalls and other port-
port-based systems for access control. Ultimately, these ports based systems for access control. Ultimately, these ports indicate
indicate services only to the endpoints, and any intermediate device services only to the endpoints, and any intermediate device that
that assigns meaning to a value can be incorrect. End systems might assigns meaning to a value can be incorrect. End systems might agree
agree to run web services (HTTP) over port 53 (typically used for to run web services (HTTP) over port 53 (typically used for DNS)
DNS) rather than port 80, at which point a firewall that blocks port rather than port 80, at which point a firewall that blocks port 80
80 would have no effect. However, assigned values often are but permits port 53 would not have the desired effect. However,
important in helping configure firewalls to known values. assigned ports often are important in helping configure firewalls.
Using dynamic ports, or dynamically-indicated ports over known ports Using Dynamic ports, or explicitly-indicated ports indicated in-band
(such as with FTP) often complicates firewall and NAT interactions. over another service (such as with FTP) often complicates firewall
FTP over firewalls often requires direct support for deep-packet and NAT interactions [RFC959]. FTP over firewalls often requires
inspection (to snoop for the dynamic port to open) and "passive direct support for deep-packet inspection (to snoop for the Dynamic
mode" FTP, in which both FTP connections are opened from the client port for the NAT to correctly map) or passive-mode FTP (in which
to the server (useful for NAT traversal). both connections are opened from the client side).
7. How to Use Assigned Ports 7. How to Use Assigned Ports
Ports are assigned by IANA by a set of documented procedures [RFC Ports are assigned by IANA by a set of documented procedures [RFC
6335]. The following section describes the steps users can take to 6335]. The following section describes the steps users can take to
help assist with the use of assigned ports, and with preparing an help assist with the use of assigned ports, and with preparing an
application for a port. application for a port assignment.
7.1. Do You Need a Port? 7.1. Is a port assignment necessary?
First, ask whether you really need a port assignment. In many cases, First, it is useful to consider whether a port assignment is
a new assignment may not be needed, for example: required. In many cases, a new assignment may not be needed, for
example:
o Is this really a new service, or can you use an existing o Is this really a new service, or can an existing service
service? suffice?
o Is this an experimental service [RFC3692]? If so, consider o Is this an experimental service [RFC3692]? If so, consider
using the current experimental ports [RFC2780]. using the current experimental ports [RFC2780].
o Is this service independently useful? If not, then the entire o Is this service independently useful? Some systems are
group should share a port. Different service uses or composed from collections of different service capabilities,
properties can be provided in separate connections after an but not all component functions are useful as independent
initial negotiation. services. Ports are typically shared among the smallest
independently-useful set of functions. Different service uses
or properties can be supported in separate connections after
an initial negotiation, e.g., to support software
decomposition.
o Can this service use a dynamic port that is coordinated out- o Can this service use a Dynamic port that is coordinated out-
of-band, e.g.: of-band, e.g.:
o By explicit configuration of both endpoints. o By explicit configuration of both endpoints.
o By shared information within the same host (e.g., a o By shared information within the same host (e.g., a
configuration file). configuration file or indicated within a URI).
o Using information exchanged on a related service: FTP, SIP,
etc. [RFC959] [RFC2543].
o Using an existing port discovery service: portmapper, mDNS, o Using an existing port discovery service: portmapper, mDNS,
etc. [RFC6762] [RFC6763]. etc. [RFC1833] [RFC6762] [RFC6763].
There are a few good examples of reasons that more directly suggest There are a few good examples of reasons that more directly suggest
that not only is a port not necessary, but it is directly that not only is a port not necessary, but it is directly counter-
counterindicated: indicated:
o Ports are not for performance. Performance enhancement can o Ports are not for performance. Performance enhancement can
occur within separate connections. occur within separate connections.
o Additional ports are not to replicate an existing service. For o Additional ports are not to replicate an existing service. For
example, if you have a device that is configured using a web example, a device is configured using a typical web browser
browser, that is a copy of HTTP port 80, and does not warrant then it is a copy of HTTP port 80 and does not warrant a new
a new assignment. However, if you develop an automated system assignment. However, an automated system that happens to use
that happens to use HTTP framing, that could be a new service. HTTP framing - but cannot be accessed by a browser - might be
A good way to tell is "can an unmodified client of the a new service. A good way to tell is "can an unmodified client
existing service interact with your service"? If so, that of the existing service interact with the proposed service"?
would be a copy, and should not request a new assignment. If so, that service would be a copy of an existing service and
does not merit a new assignment.
o Separate ports are not for insecure versions of existing (or o Separate ports are not for insecure versions of existing (or
new) secure services. Consider that a service that includes new) secure services. Consider that a service that includes
required security would be made vulnerable by having the same required security would be made vulnerable by having the same
capability accessible without security. capability accessible without security.
Note that the converse is different, i.e., it can be useful to Note that the converse is different, i.e., it can be useful to
create a new, secure service that replicates an existing create a new, secure service that replicates an existing
insecure service on a new port assignment. This can be insecure service on a new port assignment. This can be
necessary when the existing service is not backward-compatible necessary when the existing service is not backward-compatible
with security enhancements, such as the use of TLS or SSL with security enhancements, such as the use of TLS or SSL
[Hi95] [RFC5246]. [Hi95] [RFC5246].
New services should support security or should consider New services should support security or should consider
optional security. A new service should not need a port for an optional security. A new service should not need a port for an
insecure version; at best, this would be a performance issue insecure version; at best, this would be a performance issue
(see the first bullet), and at worst this presents a new (see the first bullet), and at worst this presents a new
vulnerability. vulnerability.
o Ports are not for versioning. Versioning should be handled in- o Ports are not for indicating different service versions.
band. This may not be possible with legacy assignments, but Version differentiation should be handled in-band, e.g., using
all new assignments should incorporate versioning support. a version number at the beginning of a connection or
transaction. This may not be possible with legacy assignments,
but all new assignments should incorporate support for version
indication.
Some users may not need assigned port numbers at all. Some systems Some users may not need assigned port numbers at all, e.g., SIP
can register services in the DNS, using SRV entries. These services allows voice calls to use Dynamic ports [RFC2543]. Some systems can
can be discovered by a variety of means, including mDNS, or via register services in the DNS, using SRV entries. These services can
direct query. In such cases, users can more easily request a SRV be discovered by a variety of means, including mDNS, or via direct
name, which are assigned first-come, first-served from a much larger query [RFC6762] [RFC6763]. In such cases, users can more easily
namespace. request a SRV name, which are assigned first-come, first-served from
a much larger namespace.
IANA assigns port numbers, but this assignment is typically used IANA assigns port numbers, but this assignment is typically used
only for servers, i.e., the host that listens for incoming only for servers, i.e., the host that listens for incoming
connections. Clients, i.e., hosts that initiate connections, connections. Clients, i.e., hosts that initiate connections,
typically refer to those assigned ports but do not need port typically refer to those assigned ports but do not need port
assignments for their endpoint. assignments for their endpoint.
7.2. How Many Ports? 7.2. How Many Ports?
As noted earlier, systems might require a single port assignment, As noted earlier, systems might require a single port assignment,
but rarely require multiple ports. There are a variety of known ways but rarely require multiple ports. There are a variety of known ways
to reduce port use. Although some may be cumbersome or inefficient, to reduce port use. Although some may be cumbersome or inefficient,
they are always preferable to consuming additional ports. they are always preferable to consuming additional ports.
Such techniques include: Such techniques include:
o Use of a discovery service, either a shared service (mDNS), or o Use of a discovery service, either a shared service (mDNS), or
a discovery service for a given system. a discovery service for a given system [RFC6762] [RFC6763].
o Multiplex packet types using in-band information, either on a o Multiplex packet types using in-band information, either on a
per-message or per-connection basis. Such demultiplexing can per-message or per-connection basis. Such demultiplexing can
even hand-off connections among different processes. even hand-off different connections and types of connections
among different processes, such as is done with FTP [RFC959].
There are some cases where it is still important to have assigned There are some cases where it is still important to have assigned
port numbers, largely to traverse either NATs or firewalls. Although port numbers, largely to traverse either NATs or firewalls. Although
automatic configuration protocols have been proposed and developed, automatic configuration protocols have been proposed and developed,
system designers cannot yet rely on their presence. system designers cannot yet rely on their presence.
In the past, some services were assigned multiple ports, or even In the past, some services were assigned multiple ports or sometimes
fairly large port ranges (e.g., X11). This occurred for a variety of fairly large port ranges (e.g., X11). This occurred for a variety of
reasons - port conservation was not widely understood, assignments reasons: port conservation was not widely understood, assignments
were not as ardently reviewed, etc. This no longer reflects current were not as ardently reviewed, etc. This no longer reflects current
practice, and such assignments are not considered to constitute a practice and such assignments are not considered to constitute a
precedent for future assignments. precedent for future assignments.
7.3. Picking a Port Number 7.3. Picking a Port Number
Given a demonstrated need for a port number assignment, the next Given a demonstrated need for a port number assignment, the next
question is how to pick the desired port number. An application for question is how to pick the desired port number. An application for
a port assignment does not need to include a desired port number; in a port assignment does not need to include a desired port number; in
that case, IANA will select from those currently available. that case, IANA will select from those currently available.
Users should consider whether the requested port number is Users should consider whether the requested port number is
important. For example, would you accept an assignment if IANA important. For example, would an assignment be acceptable if IANA
picked the value? Would you want a TCP port number assignment if the picked the port number value? Would a TCP port number assignment be
corresponding UDP one were unavailable (assuming your service needed needed useful if the corresponding UDP one were unavailable
only a TCP port) [RFC793]? (assuming the proposed service needed only a TCP port)?
The most critical issue in picking a number is selecting the desired The most critical issue in picking a number is selecting the desired
range, i.e.., system vs. user ports. The distinction was intended to range, i.e., System vs. User ports. The distinction was intended to
indicate a difference in privilege; system ports required privileged indicate a difference in privilege; originally, System ports
('root') access, while user ports did not. That distinction has required privileged ('root') access, while User ports did not. That
blurred because some current systems do not limit access control to distinction has since blurred because some current systems do not
system ports, and because some system services have been replicated limit access control to System ports and because some System
on user numbers (e.g., IRC). Even so, system port assignments have services have been replicated on User numbers (e.g., IRC). Even so,
continued at an average rate of 3-4 per year over the past 6 years System port assignments have continued at an average rate of 3-4 per
(2007-2012), indicating that the desire to keep this distinction year over the past 7 years (2007-2013), indicating that the desire
continues. to keep this distinction continues.
As a result, we recommend that the difference between user and As a result, the difference between System and User ports needs to
system ports be treated with caution. Developers are advised to be treated with caution. Developers are advised to treat services as
treat services as if they are always run without privilege. As a if they are always run without privilege. As a result:
result:
>> Developers SHOULD NOT apply for system ports because the >> Developers SHOULD NOT apply for System ports because the
increased privilege they provide is not always enforced. increased privilege they provide is not always enforced.
Even when developers seek a system port, it may be very difficult to Even when developers seek a System port, it may be very difficult to
obtain. System port assignment requires IETF Review or IESG Approval obtain. System port assignment requires IETF Review or IESG Approval
and justification that both user and dynamic port ranges are and justification that both User and Dynamic port ranges are
insufficient [RFC6335]. insufficient [RFC6335].
>> System implementers SHOULD enforce the need for privilege for >> System implementers SHOULD enforce the need for privilege for
processes to listen on system ports. processes to listen on System ports.
At some future date, it might be useful to deprecate the distinction At some future date, it might be useful to deprecate the distinction
between system and user ports altogether. Services typically require between System and User ports altogether. Services typically require
elevated ('root') privileges to bind to a system port, but many such elevated ('root') privileges to bind to a System port, but many such
services go to great lengths to immediately drop those privileges to services go to great lengths to immediately drop those privileges
reduce the impact of an attack using their capabilities. As a result just after connection establishment to reduce the impact of an
it can be more secure to run such services on user ports than on attack using their capabilities. Such services might be more
system ports. Further, avoiding system ports would potentially waste securely operated on User ports than on System ports. Further, if
only approximately 180 of the 1024 system values (17%), or 180 of System ports were no longer assigned, it would cost only 180 of the
the overall 49152 assigned values (<0.04%). 1024 system values (17%), or 180 of the overall 49152 assigned
values (<0.04%).
7.4. Support for Security 7.4. Support for Security
Services represent a potential system vulnerability. Given the Just as a service is a way to obtain information or processing from
current state of cybersecurity in the Internet, we recommend that: a host over a network, an service can also be the opening through
which to attack that host. Given the current state of cybersecurity
in the Internet, the following advice is prudent:
>> New services SHOULD support security, either directly or via a >> New services SHOULD support security, either directly or via a
secure transport such as TLS [RFC5246]. secure transport such as TLS [RFC5246].
>> Insecure versions of new secure services SHOULD be avoided >> Insecure versions of new secure services SHOULD be avoided
because of the vulnerability they create. because of the new vulnerability they create.
>> Security SHOULD NOT rely on port number distinctions alone; every >> Security SHOULD NOT rely on port number distinctions alone; every
service, whether secure or not, SHOULD expect to be attacked. service, whether secure or not, SHOULD expect to be attacked.
There is debate as to how to secure legacy insecure services There is debate as to how to secure legacy insecure services
[RFC6335]. Some argue that secure variants should share the existing [RFC6335]. Some argue that secure variants should share the existing
port assignment, such that security is enabled on a per-connection port assignment, such that security is enabled on a per-connection
basis [RFC2817]. Others argue that security should be supported on a basis [RFC2817]. Others argue that security should be supported on a
new port assignment and be enabled by default. IANA currently new port assignment and be enabled by default. IANA currently
permits either approach. permits either approach, although use of a single port is consistent
with port conservation. A separate port might be important for
security coordination (e.g., firewall management), but this might
further argue for deprecation of the insecure variant.
Optional security can penalize performance, requiring additional Optional security can penalize performance, requiring additional
round-trip exchanges before a connection can be established. As we round-trip exchanges before a connection can be established. As
discussed earlier, ports are a critical resource and it is discussed earlier, ports are a critical resource and it is
inappropriate to consume assignments to increase performance. inappropriate to consume assignments to increase performance.
Note however that a new service might not be eligible for IANA Note however that a new service might not be eligible for IANA
assignment of both an insecure and a secure variant of the same assignment of both an insecure and a secure variant of the same
service, and similarly IANA might be skeptical of an assignment for service, and similarly IANA might be skeptical of an assignment for
an insecure port for a secure service. In both cases, security of an insecure port for a secure service. In both cases, security of
the service is compromised by adding the insecure port assignment. the service is compromised by adding the insecure port assignment.
7.5. Support for Future Versions 7.5. Support for Future Versions
Current IANA assignments are expected to support versioning Current IANA assignments are expected to support the multiple
[RFC6335]. Versions are typically indicated in-band, either at the versions on the same assigned port [RFC6335]. Versions are typically
beginning of a connection or association, or in each protocol indicated in-band, either at the beginning of a connection or
message. association, or in each protocol message.
>> Version support SHOULD be included in new services. >> Version support SHOULD be included in new services.
>> Version numbers SHOULD NOT be included in either the service name >> Version numbers SHOULD NOT be included in either the service name
or service description. or service description.
Again, the port number space is far too limited to be used as an Again, the port number space is far too limited to be used as an
indicator of protocol version or message type. Although this has indicator of protocol version or message type. Although this has
happened in the past (e.g., for NFS), it should be avoided. happened in the past (e.g., for NFS), it should be avoided in new
requests.
7.6. Transport Protocols 7.6. Transport Protocols
IANA assigns port numbers specific to one or more transport IANA assigns port numbers specific to one or more transport
protocols, typically UDP and TCP, but also SCTP, DCCP, and any other protocols, typically UDP and TCP, but also SCTP, DCCP, and any other
standard transport protocol [RFC4340] [RFC4960]. Originally, IANA standard transport protocol [RFC768] [RFC793] [RFC4340] [RFC4960].
port assignments were made for both UDP and TCP together; other Originally, IANA port assignments were concurrent for both UDP and
transports were not indicated. However, to conserve space, and to TCP; other transports were not indicated. However, to conserve space
reflect increasing use of other transports, assignments are now and to reflect increasing use of other transports, assignments are
specific only to the transport requested. now specific only to the transport being used.
In general, a service should request assignments for multiple In general, a service should request assignments for multiple
transports using the same service name and description on the same transports using the same service name and description on the same
port number only when they all reflect essentially the same service. port number only when they all reflect essentially the same service.
Good examples of such use are DNS and NFS, where the difference Good examples of such use are DNS and NFS, where the difference
between the UDP and TCP services are specific to supporting each between the UDP and TCP services are specific to supporting each
transport. E.g., the UDP variant of a service might add sequence transport. E.g., the UDP variant of a service might add sequence
numbers, and the TCP variant of the same service might add in-band numbers and the TCP variant of the same service might add in-band
message delimiters. message delimiters.
>> Service names and descriptions for multiple transport port >> Service names and descriptions for multiple transport port
assignments SHOULD match only when they describe the same service, assignments SHOULD match only when they describe the same service,
with the exception of enhancements for each supported transport. excepting only enhancements for each supported transport.
When the services differ, their service names and descriptions When the services differ, their service names and descriptions
should reflect that difference. E.g., if TCP is used for the basic should reflect that difference. E.g., if TCP is used for the basic
control protocol and UDP for an alarm protocol, then the services control protocol and UDP for an alarm protocol, then the services
might be "name-ctl" and "name-alarm". A common example is when TCP might be "name-ctl" and "name-alarm". A common example is when TCP
is used for a service, and UDP is used to determine whether that is used for a service and UDP is used to determine whether that
service is active (via a multicast test message) [RFC1122]. The service is active (e.g., via a unicast, broadcast, or multicast test
following convention has been used by IANA for several years to message) [RFC1122]. The following convention has been used by IANA
indicate this case: for several years to indicate this case:
>> When UDP is used for multicast discovery of an active TCP >> When UDP is used for discovery of an active TCP service, the UDP
service, the UDP service name SHOULD end in "-disc". service name SHOULD end in "-disc".
Some services are used for discovery, either in conjunction with a Some services are used for discovery, either in conjunction with a
TCP service, or as a stand-alone capability. Such services will be TCP service or as a stand-alone capability. Such services will be
more reliable when using multicast rather than broadcast (over more reliable when using multicast rather than broadcast (over IPv4)
IPv4), because IP routers do not forward "all nodes" (all 1's, i.e., because IP routers do not forward "all nodes" (all 1's, i.e.,
255.255.255.255 for IPv4) broadcasts, and have not been required to 255.255.255.255 for IPv4) broadcasts and have not been required to
support subnet-directed broadcasts since 1999 [RFC1812] [RFC2644]. support subnet-directed broadcasts since 1999 [RFC1812] [RFC2644].
This issue is relevant only for IPv4 because IPv6 does not support This issue is relevant only for IPv4 because IPv6 does not support
broadcast. broadcast.
>> UDP over IPv4 multi-host services SHOULD use multicast rather >> UDP over IPv4 multi-host services SHOULD use multicast rather
than broadcast. than broadcast.
Designers should be very careful in creating services over Designers should be very careful in creating services over
transports that do not support congestion control or error recovery, transports that do not support congestion control or error recovery,
notably UDP. There are several issues that should be considered in notably UDP. There are several issues that should be considered in
such cases [RFC5405]: such cases, each summarized from [RFC5405]:
>> UDP services SHOULD be bandwidth limited, using only nominal >> UDP services SHOULD be rate limited so that they use only nominal
network capacity. Users should keep in mind that "nominal" may vary network capacity. Users should keep in mind that "nominal" may vary
depending on the deployment environment, and may be very low. depending on the deployment environment and may be very low.
>> UDP services that use multipoint communication SHOULD be >> UDP services that use multipoint communication SHOULD be
scalable, and SHOULD NOT rely solely on the efficiency of multicast scalable, and SHOULD NOT rely solely on the efficiency of multicast
transmission for scalability. transmission for scalability.
>> UDP services SHOULD include congestion detection and backoff. >> UDP services SHOULD include congestion detection and back-off.
>> UDP SHOULD NOT be used as a performance enhancement over TCP, >> UDP SHOULD NOT be used as a performance enhancement over TCP,
i.e., to circumnavigate TCP's congestion control. i.e., to circumnavigate TCP's congestion control.
7.7. When to Request an Assignment 7.7. When to Request an Assignment
Assignments are typically requested when a user has enough Assignments are typically requested when a user has enough
information to reasonably answer the questions in the IANA information to reasonably answer the questions in the IANA
application. IANA applications typically take up to a few weeks to application. IANA applications typically take up to a few weeks to
process, with some complex cases taking up to a month. The process process, with some complex cases taking up to a month. The process
skipping to change at page 14, line 26 skipping to change at page 14, line 41
An application needs to include a description of the service, as An application needs to include a description of the service, as
well as to address key questions designed to help IANA determine well as to address key questions designed to help IANA determine
whether the assignment is justified. whether the assignment is justified.
Services that are independently developed can be requested at any Services that are independently developed can be requested at any
time, but are typically best requested in the last stages of design time, but are typically best requested in the last stages of design
and initial experimentation, before any deployment has occurred that and initial experimentation, before any deployment has occurred that
cannot easily be updated. cannot easily be updated.
>> Users MUST NOT deploy implementations that use ports prior their >> Users MUST NOT deploy implementations that use assigned ports
assignment by IANA. prior their assignment by IANA.
>> Users MUST NOT deploy implementations that default to using the
experimental System ports (1021 and 1022 [RFC4727]) outside a
controlled environment where they can be updated with a subsequent
assigned port [RFC3692].
Deployments that use ports before deployment complicate IANA Deployments that use ports before deployment complicate IANA
management of the port space. Keep in mind that this recommendation management of the port space. Keep in mind that this recommendation
protects both other parties and you; it helps ensure that your protects existing assignees, users of current services, and
desired number and service name are available when assigned. The applicants for new assignments; it helps ensure that a desired
list of currently unassigned numbers is just that - *currently* number and service name are available when assigned. The list of
unassigned. It does not reflect pending applications, nor currently unassigned numbers is just that - *currently* unassigned.
applications that might arrive before yours. Waiting for an official It does not reflect pending applications. Waiting for an official
IANA assignment reduces the chance that your assignment will IANA assignment reduces the chance that an assignment request will
conflict with another deployed service. conflict with another deployed service.
Applications made through Internet Draft / RFC publication typically Applications made through Internet Draft / RFC publication typically
use a placeholder ("PORTNUM") in the text, and use an experimental use a placeholder ("PORTNUM") in the text, and use an experimental
port number until a final assignment has been made [RFC6335]. That port number until a final assignment has been made [RFC6335]. That
assignment is initially indicated in the IANA Considerations section assignment is initially indicated in the IANA Considerations section
of the document, and is tracked by the RFC Editor. When the RFC of the document, and is tracked by the RFC Editor. When the RFC
reaches the last stages of publication, that request is forwarded to reaches the last stages of publication, that request is forwarded to
IANA for handling. At that time, IANA typically requests that the IANA for handling. At that time, IANA typically requests that the
applicant fill out the application form on their website, because applicant fill out the application form on their website, because
not every protocol document addresses the information required. not every protocol document addresses the information required.
"Early" assignments can be made when justified, e.g., for early
interoperability testing, according to existing process [RFC4020]
[RFC6335].
Using this single application process also ensures that IANA has Using this single application process also ensures that IANA has
complete information even if the RFC publication is interrupted. For complete information even if the RFC publication is interrupted. For
this reason as well, the application should be complete and not this reason as well, the application should be complete and not
refer solely to the Internet Draft, RFC, a website, or any other refer solely to the Internet Draft, RFC, a website, or any other
external documentation. external documentation.
>> Users writing specifications SHOULD use symbolic names for port >> Users writing specifications SHOULD use symbolic names for port
numbers and service names until an IANA assignment has been numbers and service names until an IANA assignment has been
completed. completed.
7.8. Squatting 7.8. Squatting
"Squatting" describes the use of a number from the assigned range in "Squatting" describes the use of a number from the assigned range in
deployed software without IANA assignment. It is hazardous because deployed software without IANA assignment. It is hazardous because
IANA cannot track such usage, and thus cannot avoid making IANA cannot track such usage and thus cannot avoid making legitimate
legitimate assignments that conflict with such unauthorized usage. assignments that conflict with such unauthorized usage.
Note that there are numerous services that have squatted on such Note that there are numerous services that have squatted on such
numbers that are in widespread use. Even such widespread de-facto numbers that are in widespread use. Even such widespread de-facto
use may not justify a later IANA assignment of that value, use may not justify a later IANA assignment of that value,
especially if either the value has already been assigned to a especially if either the value has already been assigned to a
legitimate applicant or if the service would not qualify for an legitimate applicant or if the service would not qualify for an
assignment of its own accord. assignment of its own accord.
7.9. Other Considerations 7.9. Other Considerations
There are a few other points worth mentioning, which are summarized As noted earlier, System ports should be used sparingly, and it is
in this section.
As noted earlier, system ports should be used sparingly, and it is
better to avoid them altogether. This avoids the potentially better to avoid them altogether. This avoids the potentially
incorrect assumption that the service on such ports run in a incorrect assumption that the service on such ports run in a
privileged mode. privileged mode.
Port names and numbers are not intended to be changed. Once Port names and numbers are not intended to be changed. Once
deployed, it can be very difficult to recall every implementation, deployed, it can be very difficult to recall every implementation,
so the assignment should be retained. However, in cases where the so the assignment should be retained. However, in cases where the
current assignee of a name or number has reasonable knowledge of the current assignee of a name or number has reasonable knowledge of the
impact on such uses, and is willing to accept that impact, the name impact on such uses, and is willing to accept that impact, the name
or number of an assignment can be changed [RFC6335] or number of an assignment can be changed [RFC6335]
skipping to change at page 16, line 10 skipping to change at page 16, line 33
This document discusses ways to conserve port numbers, notably This document discusses ways to conserve port numbers, notably
through encouraging demultiplexing within a single port. As such, through encouraging demultiplexing within a single port. As such,
there may be cases where two variants of a protocol - insecure and there may be cases where two variants of a protocol - insecure and
secure (such as using optional TLS) or different versions - are secure (such as using optional TLS) or different versions - are
suggested to share the same port. suggested to share the same port.
This document reminds protocol designers that port numbers are not a This document reminds protocol designers that port numbers are not a
substitute for security, and should not alone be used to avoid substitute for security, and should not alone be used to avoid
denial of service or firewall traffic, notably because their use is denial of service or firewall traffic, notably because their use is
not regulated or authenticated. not regulated or validated.
9. IANA Considerations 9. IANA Considerations
The entirety of this document focuses on IANA issues, notably The entirety of this document focuses on IANA issues, notably
suggestions that help ensure the conservation of port numbers and suggestions that help ensure the conservation of port numbers and
provide useful hints for issuing informative requests thereof. provide useful hints for issuing informative requests thereof.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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 Values In the Internet Protocol and Related Headers",
BCP 37, RFC 2780, March 2000.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3962, Jan. 2004.
[RFC4727] Fenner, B., "Experimental Values in IPv4, IPv6, ICMPv4,
ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC5405] Eggert, L., and G. Fairhurst, "Unicast UDP Usage
Guidelines for Application Designers", BCP 145, RFC 5405,
Nov. 2008.
[RFC6335] Cotton, M., L. Eggert, J. Touch, M. Westerlund, and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, RFC
6335, August 2011.
10.2. Informative References 10.2. Informative References
[Hi95] Hickman, K., "The SSL Protocol", February 1995. [Hi95] Hickman, K., "The SSL Protocol", February 1995.
[IEN112] Postel, J., "Transmission Control Protocol", IEN 112, [IEN112] Postel, J., "Transmission Control Protocol", IEN 112,
August 1979. August 1979.
[RFC33] Crocker, S., "New Host-Host Protocol", RFC 33 February [RFC33] Crocker, S., "New Host-Host Protocol", RFC 33 February
1970. 1970.
[RFC37] Crocker, S., "Network Meeting Epilogue", RFC 37, March [RFC37] Crocker, S., "Network Meeting Epilogue", RFC 37, March
1970. 1970.
[RFC38] Wolfe, S., "Comments on Network Protocol from NWG/RFC [RFC38] Wolfe, S., "Comments on Network Protocol from NWG/RFC
#36", RFC 38, March 1970. #36", RFC 38, March 1970.
[RFC48] Postel, J., S. Crocker, "Possible protocol plateau", RFC [RFC48] Postel, J., and S. Crocker, "Possible protocol plateau",
48, April 1970. RFC 48, April 1970.
[RFC61] Walden, D., "Note on Interprocess Communication in a [RFC61] Walden, D., "Note on Interprocess Communication in a
Resource Sharing Computer Network", RFC 61, July 1970. Resource Sharing Computer Network", RFC 61, July 1970.
[RFC76] Bouknight, J., J. Madden, G. Grossman, "Connection by [RFC76] Bouknight, J., J. Madden, and G. Grossman, "Connection by
name: User oriented protocol", RFC 76, October 1970. name: User oriented protocol", RFC 76, October 1970.
[RFC333] Bressler, R., D. Murphy, D. Walden. "Proposed experiment [RFC333] Bressler, R., D. Murphy, and D. Walden. "Proposed
with a Message Switching Protocol", RFC 333, May 1972. experiment with a Message Switching Protocol", RFC 333,
May 1972.
[RFC739] Postel, J., "Assigned numbers", RFC 739, November 1977. [RFC739] Postel, J., "Assigned numbers", RFC 739, November 1977.
[RFC758] Postel, J., "Assigned numbers", RFC 758, August 1979. [RFC758] Postel, J., "Assigned numbers", RFC 758, August 1979.
[RFC768] Postel, J., "User Datagram Protocol", RFC 768, August [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August
1980. 1980.
[RFC793] Postel, J., "Transmission Control Protocol" RFC 793, [RFC793] Postel, J., "Transmission Control Protocol" RFC 793,
September 1981 September 1981
[RFC820] Postel, J., "Assigned numbers", RFC 820, August 1982. [RFC820] Postel, J., "Assigned numbers", RFC 820, August 1982.
[RFC900] Reynolds, J., J. Postel, "Assigned numbers", RFC 900, June [RFC900] Reynolds, J., and J. Postel, "Assigned numbers", RFC 900,
1984. June 1984.
[RFC1122] Deering, S., "Host extensions for IP multicasting", RFC [RFC959] Postel, J., and J. Reynolds, "FILE TRANSFER PROTOCOL
1122, August 1989. (FTP)", RFC 959, October 1985.
[RFC1263] O'Malley, S., L. Peterson, "TCP Extensions Considered [RFC1122] Braden, B. (Ed.), "Requirements for Internet Hosts --
Communication Layers", RFC 1122, October 1989.
[RFC1263] O'Malley, S., and L. Peterson, "TCP Extensions Considered
Harmful", RFC 1263, October 1991. Harmful", RFC 1263, October 1991.
[RFC1340] Reynolds, J., J. Postel, "Assigned numbers", RFC 1340, [RFC1340] Reynolds, J., and J. Postel, "Assigned numbers", RFC 1340,
July 1992. July 1992.
[RFC1700] Reynolds, J., J. Postel, "Assigned numbers", RFC 1700, [RFC1700] Reynolds, J., and J. Postel, "Assigned numbers", RFC 1700,
October 1994. October 1994.
[RFC1812] Baker, F. (Ed.), "Requirements for IP Version 4 Routers", [RFC1812] Baker, F. (Ed.), "Requirements for IP Version 4 Routers",
RFC 1812, June 1995. RFC 1812, June 1995.
[RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
RFC 1833, August 1995.
[RFC2543] Handley, M., H. Schulzrinne, E. Schooler, and J.
Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
March 1999.
[RFC2616] Fielding, R., J. Gettys, J. Mogul, H. Frystyk, L. [RFC2616] Fielding, R., J. Gettys, J. Mogul, H. Frystyk, L.
Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer Masinter, P. Leach, and T. Berners-Lee, "Hypertext
Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2644] Senie, D., "Changing the Default for Directed Broadcasts [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts
in Routers", RFC 2644, August 1999. in Routers", RFC 2644, August 1999.
[RFC2780] Bradner, S., V. Paxson, "IANA Allocation Guidelines For [RFC2817] Khare, R., and S. Lawrence, "Upgrading to TLS Within
Values In the Internet Protocol and Related Headers", RFC
2780, March 2000.
[RFC2817] Khare, R., S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000. HTTP/1.1", RFC 2817, May 2000.
[RFC3232] Reynolds, J. (Ed.), "Assigned Numbers: RFC 1700 is [RFC3232] Reynolds, J. (Ed.), "Assigned Numbers: RFC 1700 is
Replaced by an On-line Database", RFC 3232, January 2002. Replaced by an On-line Database", RFC 3232, January 2002.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers [RFC3546] Blake-Wilson, S., D. Hopwood, and T. Wright, "Transport
Considered Useful", BCP 82, RFC 3962, Jan. 2004. Layer Security (TLS) Extensions", RFC 3546, June 2003.
[RFC4340] Kohler, E., M. Handley, S. Floyd, "Datagram Congestion [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of
Standards Track Code Points", BCP 100, RFC 4020, February
2005.
[RFC4340] Kohler, E., M. Handley, and S. Floyd, "Datagram Congestion
Control Protocol (DCCP)", RFC 4340, March 2006. Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
[RFC5246] Dierks, T., E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T., and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5405] Eggert, L., G. Fairhurst, "Unicast UDP Usage Guidelines [RFC6762] Cheshire, S., and M. Krochmal, "Multicast DNS", RFC 6762,
for Application Designers," RFC 5405, Nov. 2008.
[RFC6335] Cotton, M., L. Eggert, J. Touch, M. Westerlund, S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", RFC 6335, August
2011.
[RFC6762] Cheshire, S., M. Krochmal, "Multicast DNS", RFC 6762,
February 2013. February 2013.
[RFC6763] Cheshire, S., M. Krochmal, "DNS-Based Service Discovery", [RFC6763] Cheshire, S., and M. Krochmal, "DNS-Based Service
RFC 6763, February 2013. Discovery", RFC 6763, February 2013.
11. Acknowledgments 11. Acknowledgments
TBD This work benefitted from the feedback from Lars Eggert, Gorry
Fairhurst, and Eliot Lear, as well as discussions of the IETF TSVWG
WG.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses Authors' Addresses
Joe Touch Joe Touch
USC/ISI USC/ISI
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, CA 90292-6695 Marina del Rey, CA 90292-6695
U.S.A. U.S.A.
 End of changes. 105 change blocks. 
288 lines changed or deleted 338 lines changed or added

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