draft-ietf-tsvwg-port-use-01.txt   draft-ietf-tsvwg-port-use-02.txt 
TSVWG J. Touch TSVWG J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Intended status: Best Current Practice February 25, 2013 Intended status: Best Current Practice July 15, 2013
Expires: August 2013 Expires: January 2014
Recommendations for Transport Port Uses Recommendations for Transport Port Uses
draft-ietf-tsvwg-port-use-01.txt draft-ietf-tsvwg-port-use-02.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 August 25, 2013. This Internet-Draft will expire on January 15, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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..............................2 2. Conventions used in this document..............................3
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
7. How to Use Assigned Ports......................................7 7. How to Use Assigned Ports......................................7
7.1. Do You Need a Port?.......................................7 7.1. Do You Need a Port?.......................................7
7.2. How Many Ports?...........................................8 7.2. How Many Ports?...........................................9
7.3. Picking a Port Number.....................................9 7.3. Picking a Port Number.....................................9
7.4. Support for Security.....................................10 7.4. Support for Security.....................................10
7.5. Support for Future Versions..............................10 7.5. Support for Future Versions..............................11
7.6. Transport Protocols......................................11 7.6. Transport Protocols......................................11
7.7. When to Request an Assignment............................12 7.7. When to Request an Assignment............................13
7.8. Other Considerations.....................................13 7.8. Squatting................................................14
8. Security Considerations.......................................13 7.9. Other Considerations.....................................14
9. IANA Considerations...........................................14 8. Security Considerations.......................................15
10. References...................................................14 9. IANA Considerations...........................................15
10.1. Normative References....................................14 10. References...................................................15
10.2. Informative References..................................14 10.1. Normative References....................................15
11. Acknowledgments..............................................16 10.2. Informative References..................................15
11. Acknowledgments..............................................17
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 4, line 42 skipping to change at page 4, line 45
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 (a.k.a. 'system')
1024-49151 0x0300-0xBFFF Registered (a.k.a. 'user') 1024-49151 0x0400-0xBFFF Registered (a.k.a. 'user')
49152-65535 0xC000-0xFFFF Dynamic/Private 49152-65535 0xC000-0xFFFF Dynamic/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, they are often referred to as 'user' ports. Dynamic or privileges, they are often referred to as 'user' ports. Dynamic or
Private ports are not assigned through IANA. Private ports are not assigned through IANA.
skipping to change at page 5, line 33 skipping to change at page 5, line 35
The first reason requires that each transport connection between a The first reason 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 reason 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 URL, such as:
http:51509//www.example.com/ http://www.example.com:51509/
Ultimately, it's important to keep in mind that the correlation of a Ultimately, it's important to keep in mind that the correlation of a
service with a port number is an agreement between the two endpoints service with a port number is an agreement between the two endpoints
of the connection only. The rest of the world might think that of the connection only. The rest of the world might think that
you're sending DNS packets on port 53, but you can run a web server you're sending DNS packets on port 53, but you can run a web server
on that port just fine, provided the server and client both decide on that port just fine, provided the server and client both decide
that port 53 is for HTTP web server traffic. that port 53 is for HTTP web server traffic.
Which brings us to the concept of a service. A service is the Which brings us to the concept of a service. A service is the
combination of ISO Layers 5-7 that represent an application protocol combination of ISO Layers 5-7 that represent an application protocol
skipping to change at page 6, line 31 skipping to change at page 6, line 33
Internet community. As a result, every attempt should be made to Internet community. As a result, every attempt should be made to
conserve ports and request only those that are absolutely necessary. conserve ports and request only 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 provide access to different
capabilities over different connections (or equivalent, e.g., capabilities over different connections (or equivalent, e.g.,
for UDP [RFC768]), using in-band information. for UDP [RFC768]), using in-band information.
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. which different capabilities are supported, as is done for
FTP.
o An existing service can indicate the dynamic port(s) on which o An existing service can indicate the dynamic port(s) on which
services are supported, such as with mDNS and portmapper services are supported, such as with mDNS and portmapper
[RFC6762] [RFC6763]. [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 (even 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., HTTP).
skipping to change at page 7, line 14 skipping to change at page 7, line 20
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 a port, then try not to.
o If you need more than one port assignment, revise your o If you need more than one port assignment, revise your
architecture until you can get by with only one, or, architecture until you can get by with only one, or,
preferably, none. preferably, none.
6.1. Firewall and NAT Considerations
Assigned numbers are useful for configuring firewalls and other
port-based systems for access control. Ultimately, these ports
indicate services only to the endpoints, and any intermediate device
that assigns meaning to a value can be incorrect. End systems might
agree to run web services (HTTP) over port 53 (typically used for
DNS) rather than port 80, at which point a firewall that blocks port
80 would have no effect. However, assigned values often are
important in helping configure firewalls to known values.
Using dynamic ports, or dynamically-indicated ports over known ports
(such as with FTP) often complicates firewall and NAT interactions.
FTP over firewalls often requires direct support for deep-packet
inspection (to snoop for the dynamic port to open) and "passive
mode" FTP, in which both FTP connections are opened from the client
to the server (useful for NAT traversal).
7. How to Use Assigned Ports 7. How to Use Assigned Ports
The following section describes the steps users can take to help The following section describes the steps users can take to help
assist with the use of assigned ports. assist with the use of assigned ports.
7.1. Do You Need a Port? 7.1. Do You Need a Port?
First, ask whether you really need a port assignment. In many cases, First, ask whether you really need a port assignment. In many cases,
a new assignment may not be needed, for example: a new assignment may not be needed, for example:
skipping to change at page 9, line 14 skipping to change at page 9, line 34
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 connections among different processes.
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 their presence. system designers cannot yet their presence.
In the past, some services were assigned multiple ports, or even
fairly large port ranges (e.g., X11). This occurred for a variety of
reasons - port conservation was not widely understood, assignments
were not as ardently reviewed, etc. This no longer reflects current
practice, and such assignments are not considered to constitute a
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 you accept an assignment if IANA
picked the value? Would you want a TCP port number assignment if the picked the value? Would you want a TCP port number assignment if the
skipping to change at page 9, line 45 skipping to change at page 10, line 25
(2007-2012), indicating that the desire to keep this distinction (2007-2012), indicating that the desire to keep this distinction
continues. continues.
As a result, we recommend that the different between user and system As a result, we recommend that the different between user and system
ports be treated with caution. Developers are advised to treat ports be treated with caution. Developers are advised to treat
services as if they are always run without privilege. As a result: services as if they are always run without privilege. As a 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
obtain. System port assignment requires IETF Review or IESG Approval
and justification that both user and dynamic port ranges are
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, but merely avoiding system between system and user ports altogether. Services typically require
ports would potentially waste only approximately 180 of 1024 values elevated ('root') privileges to bind to a system port, but many such
(17%). services go to great lengths to immediately drop those privileges to
reduce the impact of an attack using their capabilities. As a result
it can be more secure to run such services on user ports than on
system ports. Further, avoiding system ports would potentially waste
only approximately 180 of 1024 values (17%).
7.4. Support for Security 7.4. Support for Security
Services represent a potential system vulnerability. Given the Services represent a potential system vulnerability. Given the
current state of cybersecurity in the Internet, we recommend that: current state of cybersecurity in the Internet, we recommend that:
>> 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
skipping to change at page 12, line 5 skipping to change at page 12, line 45
routers do not forward "all nodes" (all 1's, i.e., 255.255.255.255 routers do not forward "all nodes" (all 1's, i.e., 255.255.255.255
for IPv4) broadcasts, and are have not been required to support for IPv4) broadcasts, and are have not been required to support
subnet-directed broadcasts since 1999 [RFC1812] [RFC2644]. subnet-directed broadcasts since 1999 [RFC1812] [RFC2644].
>> UDP multi-host services SHOULD use multicast rather than >> UDP multi-host services SHOULD use multicast rather than
broadcast. 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: such cases [RFC5405]:
>> UDP services SHOULD be bandwidth limited, using only nominal >> UDP services SHOULD be bandwidth limited, using 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 backoff.
>> 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. An application needs to include a description of the application. IANA applications typically take up to a few weeks to
service, as well as to address key questions designed to help IANA process, with some complex cases taking up to a month. The process
determine whether the assignment is justified. typically involves a few exchanges between the IANA Ports Expert
Review team and the applicant.
An application needs to include a description of the service, as
well as to address key questions designed to help IANA determine
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 ports prior their
assignment by IANA. assignment by IANA.
Deployments that use ports before deployment complicate IANA Deployments that use ports before deployment complicate IANA
skipping to change at page 13, line 18 skipping to change at page 14, line 16
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. Other Considerations 7.8. Squatting
"Squatting" describes the use of a number from the assigned range in
deployed software without IANA assignment. It is hazardous because
IANA cannot track such usage, and thus cannot avoid making
legitimate assignments that conflict with such unauthorized usage.
Note that there are numerous services that have squatted on such
numbers that are in widespread use. Even such widespread de-facto
use may not justify a later IANA assignment of that value,
especially if either the value has already been assigned to a
legitimate applicant or if the service would not qualify for an
assignment of its own accord.
7.9. Other Considerations
There are a few other points worth mentioning, which are summarized There are a few other points worth mentioning, which are summarized
in this section. in this section.
As noted earlier, system ports should be used sparingly, and it is 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
skipping to change at page 16, line 11 skipping to change at page 17, line 25
[RFC4340] Kohler, E., M. Handley, S. Floyd, "Datagram Congestion [RFC4340] Kohler, E., M. Handley, 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., 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
for Application Designers," RFC 5405, Nov. 2008.
[RFC6335] Cotton, M., L. Eggert, J. Touch, M. Westerlund, S. [RFC6335] Cotton, M., L. Eggert, J. Touch, M. Westerlund, S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", RFC 6335, August Transport Protocol Port Number Registry", RFC 6335, August
2011. 2011.
[RFC6762] Cheshire, S., M. Krochmal, "Multicast DNS", RFC 6762, [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., M. Krochmal, "DNS-Based Service Discovery",
 End of changes. 19 change blocks. 
26 lines changed or deleted 85 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/