draft-ietf-tsvwg-port-use-05.txt   draft-ietf-tsvwg-port-use-06.txt 
TSVWG J. Touch TSVWG J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Intended status: Best Current Practice September 17, 2014 Intended status: Best Current Practice November 11, 2014
Expires: March 2015 Expires: May 2015
Recommendations for Transport Port Number Uses Recommendations for Transport Port Number Uses
draft-ietf-tsvwg-port-use-05.txt draft-ietf-tsvwg-port-use-06.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 March 17, 2015. This Internet-Draft will expire on May 11, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
2. Conventions used in this document..............................3 2. Conventions used in this document..............................3
3. History........................................................3 3. History........................................................3
4. Current Port Number Use........................................4 4. Current Port Number Use........................................4
5. What is a Port Number?.........................................5 5. What is a Port Number?.........................................5
6. Conservation...................................................7 6. Conservation...................................................7
6.1. Guiding Principles........................................7 6.1. Guiding Principles........................................7
6.2. Firewall and NAT Considerations...........................8 6.2. Firewall and NAT Considerations...........................8
7. How to Use Assigned Port Numbers...............................9 7. How to Use Assigned Port Numbers...............................9
7.1. Is a port number assignment necessary?....................9 7.1. Is a port number assignment necessary?....................9
7.2. How Many Port Numbers?...................................11 7.2. How Many Port Numbers?...................................11
7.3. Picking a Port Number....................................11 7.3. Picking a Port Number....................................12
7.4. Support for Security.....................................13 7.4. Support for Security.....................................13
7.5. Support for Future Versions..............................14 7.5. Support for Future Versions..............................14
7.6. Transport Protocols......................................14 7.6. Transport Protocols......................................14
7.7. When to Request an Assignment............................15 7.7. When to Request an Assignment............................15
7.8. Squatting................................................17 7.8. Squatting................................................17
7.9. Other Considerations.....................................17 7.9. Other Considerations.....................................17
8. Security Considerations.......................................17 8. Security Considerations.......................................18
9. IANA Considerations...........................................18 9. IANA Considerations...........................................18
10. References...................................................18 10. References...................................................18
10.1. Normative References....................................18 10.1. Normative References....................................18
10.2. Informative References..................................19 10.2. Informative References..................................19
11. Acknowledgments..............................................21 11. Acknowledgments..............................................21
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. It provides a detailed historical the use of transport port numbers. It provides a detailed historical
skipping to change at page 6, line 18 skipping to change at page 6, line 18
Ultimately, the correlation of a service with a port number is an Ultimately, the correlation of a service with a port number is an
agreement between just the two endpoints of the association. A web agreement between just the two endpoints of the association. A web
server can run on port number 53, which might appear as DNS traffic server can run on port number 53, which might appear as DNS traffic
to others but will connect to browsers that know to use port number to others but will connect to browsers that know to use port number
53 rather than 80. 53 rather than 80.
As a concept, a service is the combination of ISO Layers 5-7 that As a concept, a service is the combination of ISO Layers 5-7 that
represents an application protocol capability. For example www (port represents an application protocol capability. For example www (port
number 80) is a service that uses HTTP as an application protocol number 80) is a service that uses HTTP as an application protocol
and provides access to a web server [RFC2616]. However, it is and provides access to a web server [RFC7230]. However, it is
possible to use HTTP for other purposes, such as command and possible to use HTTP for other purposes, such as command and
control. This is why some current service names (HTTP, e.g.) are a control. This is why some current service names (HTTP, e.g.) are a
bit overloaded - they describe not only the application protocol, bit overloaded - they describe not only the application protocol,
but a particular service. but a particular service.
IANA assigns port numbers so that Internet endpoints do not need IANA assigns port numbers so that Internet endpoints do not need
pairwise, explicit coordination of the meaning of their port pairwise, explicit coordination of the meaning of their port
numbers. This is the primary reason for requesting assigned port numbers. This is the primary reason for requesting assigned port
numbers with IANA - to have a common agreement between all endpoints numbers with IANA - to have a common agreement between all endpoints
on the Internet as to the default meaning of a port number. on the Internet as to the default meaning of a port number.
skipping to change at page 8, line 16 skipping to change at page 8, line 16
number(s) on which other services are supported, such as with number(s) on which other services are supported, such as with
mDNS and portmapper [RFC1833] [RFC6762] [RFC6763]. mDNS and 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, either on different hosts or as different IP addresses, either on different hosts or as
different real or virtual interfaces (or even operating different real or virtual interfaces (or even operating
systems) on the same host. 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., URIs in HTTP Host field and TLS in-band information (e.g., URIs in HTTP Host field and TLS
Server Name Indication extension) [RFC2616] [RFC3546]. Server Name Indication extension) [RFC7230] [RFC6066].
o Services requiring varying performance properties can already o Services requiring varying performance properties can already
be supported using separate endpoint associations (connections be supported using separate endpoint associations (connections
or other associations), each configured to support the desired or other associations), each configured to support the desired
properties. properties.
Port numbers are intended to differentiate services, not variations Port numbers are intended to differentiate services, not variations
of performance, replicas, pairwise endpoint associations, or payload of performance, replicas, pairwise endpoint associations, or payload
types. Port numbers are also a small space compared to other types. Port numbers are also a small space compared to other
Internet number spaces; it is never appropriate to consume port Internet number spaces; it is never appropriate to consume port
skipping to change at page 9, line 38 skipping to change at page 9, line 38
independently-useful set of functions. Different service uses independently-useful set of functions. Different service uses
or properties can be supported in separate pairwise endpoint or properties can be supported in separate pairwise endpoint
associations after an initial negotiation, e.g., to support associations after an initial negotiation, e.g., to support
software decomposition. software decomposition.
o Can this service use a Dynamic port number that is coordinated o Can this service use a Dynamic port number that is coordinated
out-of-band, e.g.: out-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 internal mechanisms within the same host (e.g., a
configuration file or indicated within a URI). configuration file, indicated within a URI, or using
interprocess communication).
o Using information exchanged on a related service: FTP, SIP, o Using information exchanged on a related service: FTP, SIP,
etc. [RFC959] [RFC2543]. etc. [RFC959] [RFC3261].
o Using an existing port discovery service: portmapper, mDNS, o Using an existing port discovery service: portmapper, mDNS,
etc. [RFC1833] [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 number not necessary, but it is directly that not only is a port number not necessary, but it is directly
counter-indicated: counter-indicated:
o Port numbers are not intended to differentiate performance o Port numbers are not intended to differentiate performance
variations within the same service, e.g., high-speed vs. variations within the same service, e.g., high-speed vs.
skipping to change at page 10, line 21 skipping to change at page 10, line 21
o Additional port numbers are not intended to replicate an o Additional port numbers are not intended to replicate an
existing service. For example, if a device is configured to existing service. For example, if a device is configured to
use a typical web browser then it the port number used for use a typical web browser then it the port number used for
that service is a copy of the http service that is already that service is a copy of the http service that is already
assigned to port number 80 and does not warrant a new assigned to port number 80 and does not warrant a new
assignment. However, an automated system that happens to use assignment. However, an automated system that happens to use
HTTP framing - but cannot be accessed by a browser - might be HTTP framing - but cannot be accessed by a browser - might be
a new service. A good way to tell is "can an unmodified client a new service. A good way to tell is "can an unmodified client
of the existing service interact with the proposed service"? of the existing service interact with the proposed service"?
If so, that service would be a copy of an existing service and If so, that service would be a copy of an existing service and
does not merit a new assignment. would not merit a new assignment.
o Port numbers not intended for intra-machine communication.
Such communication can already be supported by internal
mechanisms (interprocess communication, shared memory, shared
files, etc.). When Internet communication within a host is
desired, the server can bind to a Dynamic port that is
indicated to the client using these internal mechanisms.
o Separate port numbers are not intended for insecure versions o Separate port numbers are not intended for insecure versions
of existing (or new) secure services. A service that already of existing (or new) secure services. A service that already
requires security would be made more vulnerable by having the requires security would be made more vulnerable by having the
same capability accessible without security. same 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 number assignment. This can be insecure service on a new port number 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 [RFC5246]. with security enhancements, such as the use of TLS [RFC5246].
o Port numbers are not intended for indicating different service o Port numbers are not intended for indicating different service
versions. Version differentiation should be handled in-band, versions. Version differentiation should be handled in-band,
e.g., using a version number at the beginning of an e.g., using a version number at the beginning of an
association (e.g., connection or other transaction). This may association (e.g., connection or other transaction). This may
not be possible with legacy assignments, but all new not be possible with legacy assignments, but all new
assignments should incorporate support for version indication. assignments should incorporate support for version indication.
Some users may not need assigned port numbers at all, e.g., SIP Some users may not need assigned port numbers at all, e.g., SIP
allows voice calls to use Dynamic ports [RFC2543]. Some systems can allows voice calls to use Dynamic ports [RFC3261]. Some systems can
register services in the DNS, using SRV entries. These services can register services in the DNS, using SRV entries. These services can
be discovered by a variety of means, including mDNS, or via direct be discovered by a variety of means, including mDNS, or via direct
query [RFC6762] [RFC6763]. In such cases, users can more easily query [RFC6762] [RFC6763]. In such cases, users can more easily
request a SRV name, which are assigned first-come, first-served from request a SRV name, which are assigned first-come, first-served from
a much larger namespace. 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 or other associations. Clients, i.e., hosts that connections or other associations. Clients, i.e., hosts that
initiate connections or other associations, typically refer to those initiate connections or other associations, typically refer to those
skipping to change at page 16, line 42 skipping to change at page 16, line 49
implementations use an experimental port number until a final implementations use an experimental port number until a final
assignment has been made [RFC6335]. That assignment is initially assignment has been made [RFC6335]. That assignment is initially
indicated in the IANA Considerations section of the document, which indicated in the IANA Considerations section of the document, which
is tracked by the RFC Editor. When a document has been approved for is tracked by the RFC Editor. When a document has been approved for
publication and proceeds to IESG Approval, that request is forwarded publication and proceeds to IESG Approval, that request is forwarded
to IANA for handling. IANA will make the new assignment accordingly. to IANA for handling. IANA will make the new assignment accordingly.
At that time, IANA may also request that the applicant fill out the At that time, IANA may also request that the applicant fill out the
application form on their website, e.g., when the RFC does not application form on their website, e.g., when the RFC does not
directly address the information expected as per [RFC6335]. "Early" directly address the information expected as per [RFC6335]. "Early"
assignments can be made when justified, e.g., for early assignments can be made when justified, e.g., for early
interoperability testing, according to existing process [RFC4020] interoperability testing, according to existing process [RFC7120]
[RFC6335]. [RFC6335].
>> 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. Implementations SHOULD use experimental port numbers completed. Implementations SHOULD use experimental port numbers
during this time, but those numbers MUST NOT be cited in during this time, but those numbers MUST NOT be cited in
documentation except as interim. documentation except as interim.
7.8. Squatting 7.8. Squatting
skipping to change at page 20, line 17 skipping to change at page 20, line 23
[RFC1700] Reynolds, J., and 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", [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
RFC 1833, August 1995. 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.
Masinter, P. Leach, and T. Berners-Lee, "Hypertext
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.
[RFC2817] Khare, R., and S. Lawrence, "Upgrading to TLS Within [RFC2817] Khare, R., and 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.
[RFC3546] Blake-Wilson, S., D. Hopwood, and T. Wright, "Transport [RFC3261] Rosenberg, J., H. Schulzrinne, G. Camarillo, A. Johnston,
Layer Security (TLS) Extensions", RFC 3546, June 2003. J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[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 [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.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245, April
skipping to change at page 21, line 15 skipping to change at page 21, line 9
[RFC5246] Dierks, T., and 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.
[RFC5389] Rosenberg, J., R. Mahy, P. Matthews, and D. Wing, "Session [RFC5389] Rosenberg, J., R. Mahy, P. Matthews, and D. Wing, "Session
Traversal Utilities for NAT", RFC 5389, October 2008. Traversal Utilities for NAT", RFC 5389, October 2008.
[RFC5766] Mahy, R., P. Matthews, and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., P. Matthews, and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, January
2011.
[RFC6762] Cheshire, S., and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S., and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013. February 2013.
[RFC6763] Cheshire, S., and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S., and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013. Discovery", RFC 6763, February 2013.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, January 2014.
[RFC7230] Fielding, R., (Ed.), and J. Reshke, (Ed.), "Hypertext
Transfer Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, June 2014.
11. Acknowledgments 11. Acknowledgments
This work benefitted from the feedback from Lars Eggert, Gorry This work benefitted from the feedback from David Black, Lars
Fairhurst, and Eliot Lear, as well as discussions of the IETF TSVWG Eggert, Gorry Fairhurst, and Eliot Lear, as well as discussions of
WG. 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. 17 change blocks. 
31 lines changed or deleted 39 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/