draft-ietf-tsvwg-port-use-02.txt   draft-ietf-tsvwg-port-use-03.txt 
TSVWG J. Touch TSVWG J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Intended status: Best Current Practice July 15, 2013 Intended status: Best Current Practice November 4, 2013
Expires: January 2014 Expires: May 2014
Recommendations for Transport Port Uses Recommendations for Transport Port Uses
draft-ietf-tsvwg-port-use-02.txt draft-ietf-tsvwg-port-use-03.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 January 15, 2014. This Internet-Draft will expire on May 4, 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 21 skipping to change at page 2, line 21
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..............................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 6.1. Firewall and NAT Considerations...........................7
7. How to Use Assigned Ports......................................7 7. How to Use Assigned Ports......................................8
7.1. Do You Need a Port?.......................................7 7.1. Do You Need a Port?.......................................8
7.2. How Many Ports?...........................................9 7.2. How Many Ports?..........................................10
7.3. Picking a Port Number.....................................9 7.3. Picking a Port Number....................................10
7.4. Support for Security.....................................10 7.4. Support for Security.....................................11
7.5. Support for Future Versions..............................11 7.5. Support for Future Versions..............................12
7.6. Transport Protocols......................................11 7.6. Transport Protocols......................................12
7.7. When to Request an Assignment............................13 7.7. When to Request an Assignment............................14
7.8. Squatting................................................14 7.8. Squatting................................................15
7.9. Other Considerations.....................................14 7.9. Other Considerations.....................................15
8. Security Considerations.......................................15 8. Security Considerations.......................................15
9. IANA Considerations...........................................15 9. IANA Considerations...........................................16
10. References...................................................15 10. References...................................................16
10.1. Normative References....................................15 10.1. Normative References....................................16
10.2. Informative References..................................15 10.2. Informative References..................................16
11. Acknowledgments..............................................17 11. Acknowledgments..............................................18
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 33 skipping to change at page 3, line 33
communication path from a process [RFC33]. At a meeting described in communication path from a process [RFC33]. At a meeting described in
[RFC37], an idea was presented to decouple connections between [RFC37], an idea was presented to decouple connections between
processes and links that they use as paths, and thus to include processes and links that they use as paths, and thus to include
source and destination socket identifiers in packets. RFC38 explains source and destination socket identifiers in packets. RFC38 explains
this in detail, in which processes might have more than one of these this in detail, in which processes might have more than one of these
paths, and that more than one may be active at a time [RFC38]. As a paths, and that more than one may be active at a time [RFC38]. As a
result, there was the need to add a process identifier to the header result, there was the need to add a process identifier to the header
of each message, so that the incoming data could be demultiplexed to of each message, so that the incoming data could be demultiplexed to
the appropriate process. RFC38 further suggested that 32 bits would the appropriate process. RFC38 further suggested that 32 bits would
be used for these identifiers. RFC48 discusses the current notion of be used for these identifiers. RFC48 discusses the current notion of
listening on a given port, but does not discuss how the issue of listening on a given port, but does not discuss the issue of port
port determination [RFC48]. RFC61 notes that the challenge of determination [RFC48]. RFC61 notes that the challenge of knowing the
knowing the appropriate port numbers is "left to the processes" in appropriate port numbers is "left to the processes" in general, but
general, but introduces the concept of a "well-known" port for introduces the concept of a "well-known" port for common services
common services [RFC61]. [RFC61].
RFC76 addresses this issue more constructively, proposing a RFC76 addresses this issue more constructively, proposing a
"telephone book" by which an index would allow ports to be used by "telephone book" by which an index would allow ports to be used by
name, but still assumes that both source and destination ports are name, but still assumes that both source and destination ports are
fixed by such a system [RFC76]. RFC333 suggests that the port pair, fixed by such a system [RFC76]. RFC333 suggests that the port pair,
rather than an individual port, would be used on both sides of the rather than an individual port, would be used on both sides of the
connection for demultiplexing messages [RFC333]. This is the final connection for demultiplexing messages [RFC333]. This is the final
view in RFC793 (and its predecessors, including IEN 112 [IEN112]), view in RFC793 (and its predecessors, including IEN 112 [IEN112]),
and brings us to their current meaning. RFC739 introduces the notion and brings us to their current meaning. RFC739 introduces the notion
of generic reserved ports, used for groups of protocols, such as of generic reserved ports, used for groups of protocols, such as
skipping to change at page 4, line 32 skipping to change at page 4, line 32
decimal numbers rather than the octal ranges used previously decimal numbers rather than the octal ranges used previously
[RFC900]. RFC1340 increased this range from 0..255 to 0..1023, and [RFC900]. RFC1340 increased this range from 0..255 to 0..1023, and
began to list TCP and UDP port assignments individually (although began to list TCP and UDP port assignments individually (although
the assumption was, and remains, that once assigned a port applies the assumption was, and remains, that once assigned a port applies
to all transport protocols, including TCP, UDP, recently SCTP and to all transport protocols, including TCP, UDP, recently SCTP and
DCCP, as well as ISO-TP4 for a brief period in the early 1990s) DCCP, as well as ISO-TP4 for a brief period in the early 1990s)
[RFC1340]. RFC1340 also established the Registered space of 1024- [RFC1340]. RFC1340 also established the Registered space of 1024-
59151, though it notes that it is not controlled by the IANA at that 59151, though it notes that it is not controlled by the IANA at that
point. The list provided by RFC1700 in 1994 remained the standard point. The list provided by RFC1700 in 1994 remained the standard
until it was declared replaced by an on-line version, as of RFC3232 until it was declared replaced by an on-line version, as of RFC3232
in 2002 [RFC1700][RFC3232]. 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
----------------------------------------------------------- -----------------------------------------------------------
skipping to change at page 6, line 13 skipping to change at page 6, line 13
command and control. This is why some current service names (HTTP, command and control. This is why some current service names (HTTP,
e.g.) are a bit overloaded - they describe not only the application e.g.) are a bit overloaded - they describe not only the application
protocol, but a particular service. protocol, but a particular service.
IANA assigns ports so that endpoints on the Internet do not need to IANA assigns ports so that endpoints on the Internet do not need to
pairwise, explicitly coordinate the meaning of their port numbers. pairwise, explicitly coordinate the meaning of their port numbers.
This is the primary reason for requesting assigned ports with IANA - This is the primary reason for requesting assigned ports with IANA -
to have a common agreement between all endpoints on the Internet as to have a common agreement between all endpoints on the Internet as
to the meaning of a port. to the meaning of a port.
Ports are used for other purposes as well, however. The other Ports are sometimes used by intermediate devices on a network path,
primary reason for requesting assigned ports with IANA is to either to monitor available services, to monitor traffic (e.g., to
simplify end system configuration, so individual installations do indicate the data contents), or to intercept traffic (to block,
not need to coordinate their use of arbitrary ports. A similar proxy, relay, aggregate, or otherwise process it). In each case, the
reason is to simplify firewall management, so that a single, fixed intermediate device interprets traffic based on the port number. It
firewall configuration can either permit or deny a service. is again important to recognize that any interpretation of ports
except at the endpoints may be incorrect, because ports are
meaningful only at the endpoints. Further, the ports may not be
visible to these intermediate devices, such as when the transport
protocol is encrypted (as in network- or link-layer tunnels), or
when a packet is fragmented (in which only the first fragment has
the port information). Such port invisibility may interfere with
these in-network port-based capabilities.
Ports are used for other purposes as well. The other primary reason
for requesting assigned ports with IANA is to simplify end system
configuration, so individual installations do not need to coordinate
their use of arbitrary ports. A similar reason is to simplify
firewall management, so that a single, fixed firewall configuration
can either permit or deny a service.
6. Conservation 6. Conservation
Ports are a scarce resource that are globally shared by the entire Ports are a scarce resource that is globally shared by the entire
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
skipping to change at page 7, line 40 skipping to change at page 8, line 7
Using dynamic ports, or dynamically-indicated ports over known ports Using dynamic ports, or dynamically-indicated ports over known ports
(such as with FTP) often complicates firewall and NAT interactions. (such as with FTP) often complicates firewall and NAT interactions.
FTP over firewalls often requires direct support for deep-packet FTP over firewalls often requires direct support for deep-packet
inspection (to snoop for the dynamic port to open) and "passive inspection (to snoop for the dynamic port to open) and "passive
mode" FTP, in which both FTP connections are opened from the client mode" FTP, in which both FTP connections are opened from the client
to the server (useful for NAT traversal). 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 Ports are assigned by IANA by a set of documented procedures [RFC
assist with the use of assigned ports. 6335]. The following section describes the steps users can take to
help assist with the use of assigned ports, and with preparing an
application for a port.
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:
o Is this really a new service, or can you use an existing o Is this really a new service, or can you use an existing
service? service?
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
group should share a port. Different service uses or
properties can be provided in separate connections after an
initial negotiation.
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).
o Using an existing port discovery service: portmapper, mDNS, o Using an existing port discovery service: portmapper, mDNS,
etc. [RFC6762] [RFC6763] etc. [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
counterindicated: counterindicated:
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, if you have a device that is configured using a web
browser, that is a copy of HTTP port 80, and does not warrant browser, that is a copy of HTTP port 80, and does not warrant
a new assignment. However, if you develop an automated system a new assignment. However, if you develop an automated system
that happens to use HTTP framing, that could be a new service. that happens to use HTTP framing, that could be a new service.
A good way to tell is "can an unmodified client of the A good way to tell is "can an unmodified client of the
existing service interact with your service"? If so, that existing service interact with your service"? If so, that
would be a copy, and should not request a new assignment. would be a copy, and should not request a new assignment.
o Ports are not for insecure versions of existing secure o Separate ports are not for insecure versions of existing (or
services. Consider that a service that includes required new) secure services. Consider that a service that includes
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
optional security. A new service should not need a port for an
insecure version; at best, this would be a performance issue
(see the first bullet), and at worst this presents a new
vulnerability.
o Ports are not for versioning. Versioning should be handled in-
band. This may not be possible with legacy assignments, but
all new assignments should incorporate versioning support.
Some users may not need assigned port numbers at all. Some systems Some users may not need assigned port numbers at all. 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 can be discovered by a variety of means, including mDNS, or via
direct query. In such cases, users can more easily request a SRV direct query. In such cases, users can more easily request a SRV
name, which are assigned first-come, first-served from a much larger name, which are assigned first-come, first-served from a much larger
namespace. 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,
skipping to change at page 9, line 23 skipping to change at page 10, line 15
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.
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 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 even
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
skipping to change at page 10, line 18 skipping to change at page 11, line 9
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; system ports required privileged
('root') access, while user ports did not. That distinction has ('root') access, while user ports did not. That distinction has
blurred because some current systems do not limit access control to blurred because some current systems do not limit access control to
system ports, and because some system services have been replicated system ports, and because some system services have been replicated
on user numbers (e.g., IRC). Even so, system port assignments have on user numbers (e.g., IRC). Even so, system port assignments have
continued at an average rate of 3-4 per year over the past 6 years continued at an average rate of 3-4 per year over the past 6 years
(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 difference between user and
ports be treated with caution. Developers are advised to treat system ports be treated with caution. Developers are advised to
services as if they are always run without privilege. As a result: treat 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 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 to
reduce the impact of an attack using their capabilities. As a result 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 it can be more secure to run such services on user ports than on
system ports. Further, avoiding system ports would potentially waste system ports. Further, avoiding system ports would potentially waste
only approximately 180 of 1024 values (17%). only approximately 180 of the 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 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 8 skipping to change at page 12, line 47
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 [RFC4340] [RFC4960]. Originally, IANA
port assignments were made for both UDP and TCP together; other port assignments were made for both UDP and TCP together; other
transports were not indicated. However, to conserve space, and to transports were not indicated. However, to conserve space, and to
reflect increasing use of other transports, assignments are now reflect increasing use of other transports, assignments are now
specific only to the transport requested. specific only to the transport requested.
In general, a service should request assignments for multiple In general, a service should request assignments for multiple
transports the same service name and description on the same port transports using the same service name and description on the same
number only when they all reflect essentially the same service. Good port number only when they all reflect essentially the same service.
examples of such use are DNS and NFS, where the difference between Good examples of such use are DNS and NFS, where the difference
the UDP and TCP services are specific to supporting each transport. between the UDP and TCP services are specific to supporting each
E.g., the UDP variant of a service might add sequence numbers, and transport. E.g., the UDP variant of a service might add sequence
the TCP variant of the same service might add in-band message numbers, and the TCP variant of the same service might add in-band
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. with the exception of 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 (via a multicast test message) [RFC1122]. The
following convention has been used by IANA for several years to following convention has been used by IANA for several years to
indicate this case: indicate this case:
>> When UDP is used for multicast discovery of an active TCP >> When UDP is used for multicast discovery of an active TCP
service, the UDP service name SHOULD end in "-disc". service, the UDP 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, because IP more reliable when using multicast rather than broadcast (over
routers do not forward "all nodes" (all 1's, i.e., 255.255.255.255 IPv4), because IP routers do not forward "all nodes" (all 1's, i.e.,
for IPv4) broadcasts, and are have not been required to support 255.255.255.255 for IPv4) broadcasts, and have not been required to
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
>> UDP multi-host services SHOULD use multicast rather than
broadcast. broadcast.
>> UDP over IPv4 multi-host services SHOULD use multicast rather
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 [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
skipping to change at page 15, line 10 skipping to change at page 16, line 4
or number of an assignment can be changed [RFC6335] or number of an assignment can be changed [RFC6335]
Aliases, or multiple service names for the same port number, are no Aliases, or multiple service names for the same port number, are no
longer considered appropriate [RFC6335]. longer considered appropriate [RFC6335].
8. Security Considerations 8. Security Considerations
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, are suggested to share the same port (e.g., HTTP and HTTPS, secure (such as using optional TLS) or different versions - are
though currently those are assigned different ports) [RFC2818]. 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 authenticated.
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
skipping to change at page 17, line 8 skipping to change at page 18, line 5
[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 [RFC2780] Bradner, S., V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", RFC Values In the Internet Protocol and Related Headers", RFC
2780, March 2000. 2780, March 2000.
[RFC2817] Khare, R., S. Lawrence, "Upgrading to TLS Within [RFC2817] Khare, R., S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000. HTTP/1.1", RFC 2817, May 2000.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 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 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3962, Jan. 2004. Considered Useful", BCP 82, RFC 3962, Jan. 2004.
[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",
 End of changes. 23 change blocks. 
62 lines changed or deleted 95 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/