DCCP WG G.Fairhurst
Internet Draft University of Aberdeen
Intended status: Proposed Standard October 15, 2007
Expires: September 2007
The DCCP Service Code
draft-ietf-dccp-serv-codes-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 15, 2008.
Abstract
This document describes the usage of Service Codes by the Datagram
Congestion Control Protocol, RFC 4340. This document motivates the
setting of Service Codes by applications. Service Codes provide a
method to identify the intended service/application to process a DCCP
connection request. This provides improved flexibility in the use and
assignment of port numbers for connection multiplexing. The use of a
DCCP Service Code can also enable more explicit coordination of
services with middleboxes (e.g. network address translators and
firewalls). It updates the description provided in RFC 4340.
G. Fairhurst Expires April 15, 2008 [Page 1]
Internet-Draft DCCP Service Codes October 2007
Table of Contents
1. Introduction...................................................3
1.1. History...................................................3
1.2. Conventions used in this document.........................6
2. An Architecture for Service Codes..............................6
2.1. IANA Port Numbers.........................................6
2.2. DCCP Service Code Values..................................7
2.3. Service Code Registry.....................................8
2.4. Zero Service Code.........................................8
2.5. SDP for describing Service Codes..........................9
3. Use of the DCCP Service Code...................................9
3.1. Setting Service Codes at the Sender......................10
3.2. Using Service Codes in the Network.......................10
3.3. Using Service Codes at the Receiver......................11
3.3.1. Reception of a DCCP-Request.........................12
3.3.2. Multiple Associations of Service Codes and Ports....13
3.3.3. Automatically launching a Server....................13
4. Benchmarking Services Described in this document..............13
4.1. Echo.....................................................14
4.2. Daytime..................................................14
4.3. Character generator......................................14
4.4. Time service.............................................14
4.5 PerfTest service.........................................15
5. Security Considerations.......................................15
5.1. Interactions of Service Codes and port numbers...........16
5.2. Interactions with IPsec..................................16
6. IANA Considerations...........................................17
6.1. Port number values allocated by this document............17
6.2. Service Code values allocated by this document...........18
7. Acknowledgments...............................................19
8. References....................................................19
8.1. Normative References.....................................19
8.2. Informative References...................................19
9. Author's Addresses............................................21
9.1. Intellectual Property Statement..........................21
9.2. Disclaimer of Validity...................................22
9.3. Copyright Statement......................................22
APPENDIX A: API support for Service Codes........................23
Fairhurst Expires April 15, 2008 [Page 2]
Internet-Draft DCCP Service Codes October 2007
1. Introduction
DCCP specifies a Service Code as a 4-byte value (32 bits) that
describes the application-level service to which a client application
wishes to connect ([RFC4340], Section 8.1.2). A Service Code
identifies the protocol (or a standard profile, e.g. [ID.DCCP.RTP])
to be used at the application layer. It is not intended to be used to
specify a variant of an application, or a specific variant of a
protocol (section 2.2).
Service Codes allow a flexible correspondence between application-
layer services and port numbers, which affects how applications
interact with DCCP. This decouples the use of ports for connection
demultiplexing and state management from their use to indicate a
desired service. An application identifies the requested service by
the Service Code value in a DCCP-REQUEST. Each application may listen
on one or more ports associated with one or more Service Codes
([RFC4340], 8.1.2).
The use of Service Codes can assist in identifying the intended
service when the server by a Middleboxes (a network address
translator (NAT) [RFC2663], NAT-PT [RFC2766], Firewalls, etc).
Middleboxes that desire to identify the type of data being
transported by a flow, should utilize the Service Code for this
purpose. When consistently used, the Service Code can provide a more
specific indication of the actual service (e.g. indicating the type
of multimedia flow, or intended application behaviour).
The more flexible use of server ports can offer benefit to
applications where servers need to handle very large numbers of
simultaneous open ports to the same service.
RFC 4340 omits to describe the motivation behind Service Codes, nor
does it describe properly how well-known ports relate to Service
Codes. The intent of this document is to clarify these issues.
1.1. History
It is simplest to understand the motivation for defining Service
Codes by describing the history of the DCCP protocol.
Most current Internet transport protocols (TCP [RFC793], UDP
[RFC768], SCTP [RFC2960], UDP-Lite [RFC3828]) used "well-known" port
numbers [RFC814]. These 16-bit values indicate the application
service associated with a connection or message. The server port must
be known to the client to allow a connection to be established. This
Fairhurst Expires April 15, 2008 [Page 3]
Internet-Draft DCCP Service Codes October 2007
may be achieved using out-of-band signaling (e.g. described using SDP
[RFC4566]), but more commonly a well-known port is allocated to a
particular protocol or application; for example HTTP commonly uses
port 80 and SMTP commonly uses port 25. Making a port number well-
known [RFC1122] involves registration with the Internet Assigned
Numbers Authority (IANA), which includes defining a service by a
unique keyword and reserving a port number from among a fixed pool
[IANA]. This fixed space of port numbers is globally reserved
[ID.Portnames].
In the earliest draft of DCCP the authors wanted to address the issue
of well-known ports in a future-proof manner, since this method
suffers from several problems:
o The port space is not sufficiently large for ports to be easily
allocated (e.g. in an unregulated manner). Thus, many
applications operate on unregistered ports, possibly colliding
with use by other applications.
o The use of port-based firewalls encourages application-writers to
disguise one application as another in an attempt to bypass
firewall filter rules. Firewall writers are encouraged to use deep
packet inspection in an attempt to identify the service associated
with a port number.
o ISPs often deploy transparent proxies, primarily to improve
performance and reduce costs. For example, TCP requests destined
to TCP port 80 are often redirected to a web proxy.
These issues are coupled. When applications collide on the same
"well-known", but unregistered port, there is no simple way for
network security equipment to tell them apart, with the likelihood of
introducing problems with interaction of features.
There is little that a transport protocol designer can do about
applications that attempt to masquerade as other applications. For
ones that are not attempting to hide, the problem may be simply that
they cannot trivially obtain a well-known port. Ideally, it should
be sufficiently easy that every application-writer can request a
well-known port and get one instantly with no questions asked. The
16-bit port space traditionally used is not large enough to support
such a trivial allocation of well-known ports.
Thus, the design of DCCP sought an alternative solution. The idea
was simple. A 32-bit server port space should be sufficiently large
that it enables use of very simple allocation policies. However,
Fairhurst Expires April 15, 2008 [Page 4]
Internet-Draft DCCP Service Codes October 2007
overhead considerations made a 32-bit port value undesirable (DCCP
needed to be useful for low rate applications).
The solution in DCCP to this problem was the use of a 32-bit Service
Code [RFC4340] that is included only in the DCCP-Request packet. This
was intended to perform the primary role of a well-known server port,
in that it would be trivially simply to obtain a unique value for
each application. Placing the value in a request packet, requires no
additional overhead for the actual data flow. It is however
sufficient for both the end-systems, and provides any stateful
middleboxe(s) along the path with additional information to
understand what applications are being used.
The original draft of the DCCP specification did not use traditional
ports; instead the client allocated a 32-bit identifier to uniquely
identified the connection. The server listened on a socket bound only
to a Service Code. This solution was unambiguous; the Service Code
was the only identifier for a listening socket at the server side.
The DCCP client included a Service Code in the request to allow it to
reach the corresponding listening application. This design suffered
from the downside of being sufficiently different from existing
protocols that there were concerns that it would hinder the use of
DCCP through NATs and other middleboxes.
RFC 4340 abandoned the use of a 32-bit connection identifier in
favour of two traditional 16-bit ports, one chosen by the server and
one by the client. This allows middleboxes to utilize similar
techniques for DCCP, UDP, TCP, etc. (e.g. NAT). This also has the
advantage that two servers associated with the same Service Code
could co-exist on the same server host. However, it introduced a new
problem: "How does the server port relate to the Service Code?" The
intent was that the Service Code identified the application or
protocol using DCCP, providing middleboxes with information about the
intended use of a connection, and that the pair of ports effectively
formed a 32-bit connection identifier, which was unique between a
pair of end-systems.
The large number of available unique Service Code values allows all
applications to be assigned a Service Code. However, there remains a
current problem: The server port is chosen by the server, but the
client needs to know this to establish a connection. It was
undesirable to mandate out-of-band communication to discover the
server port.
The solution is to register well-known DCCP ports. The limited
availability of well-known ports appears to contradict the benefits
of DCCP service codes, because although it may be trivial to obtain a
Fairhurst Expires April 15, 2008 [Page 5]
Internet-Draft DCCP Service Codes October 2007
service code, it has not traditionally been trivial to obtain a well-
known port from IANA and in the long-run it may not be possible to
uniquely allocate a well-known port to new applications. As port
numbers become scarce, this motivates the need to associate more than
one Service Code with a listening port (e.g. two different
applications could be assigned the same well-known port, and need to
run on the same host at the same time). No protocols issues arise
from a port being associated with two Service Codes, each bound to
different applications does not raise any protocol issues. An
incoming DCCP-Request is directed to the correct application.
Service Codes provide flexibility in the way clients identify the
server application to which they wish to communicate. The Service
Code mechanism allows a server to associate a set of server ports
with a service. The set may be common with other services available
at the same server host, allowing a larger number of concurrent
connections for a particular service than possible when the service
is identified by a single well-known port number.
There has been confusion concerning how well-known ports relate to
well-known Service Codes. The goal of this document is to clarify the
issues concerning the use and allocation of Service Codes.
RFC4340 states that Service Codes are not intended to be DCCP-
specific. Service Codes, or similar concepts may therefore also be
useful to other IETF transport protocols.
1.2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
All protocol code points and values are transmitted in network byte
order (most significant byte first), with the most significant bit of
each byte is placed in the left-most position of an 8-bit field.
2. An Architecture for Service Codes
DCCP defines the use of a combination of ports and Service Codes to
identify the server application ([RFC4340], 8.1.2). These are
described in the following sections.
2.1. IANA Port Numbers
In DCCP the packets belonging to a connection are de-multiplexed
based on a combination of four values {source IP address, source
Fairhurst Expires April 15, 2008 [Page 6]
Internet-Draft DCCP Service Codes October 2007
port, dest IP address, dest port}, as in TCP. An endpoint address is
associated with a port number, (e.g. forming a socket); and a pair of
associations uniquely identifies each connection. Ports provide the
fundamental per-packet de-multiplexing function.
The Internet Assigned Numbers Authority currently manages the set of
globally reserved port numbers [IANA]. The source port associated
with a connection request, often known as the "ephemeral port",
traditionally includes the range 49152-65535, and should also include
the 1024-49151 range. The value used for the ephemeral port is
usually chosen by the client operating system. It has been suggested
that a randomized choice of port number value can help defend against
"blind" attacks [ID.TSVWG.RAND] in TCP. This method may be applicable
to other IETF-defined transport protocols, including DCCP.
Traditionally, the destination (server) port value that is associated
with a service is determined either by an operating system index to a
copy of the IANA table (e.g., getportbyname() in Unix, which indexes
the /etc/services file), or directly mapped by the application.
The UDP and TCP port number space: 0..65535, is split into three
ranges [RFC2780]:
o 0..1023 "well-known", also called "system" ports
o 1024..49151 "registered", also called "user" ports
o 49152..65535 "dynamic", also called "private" ports
DCCP supports well-known and reserved ports, which are allocated in
the DCCP IANA port numbers registry ([RFC4340], 19.9). Each
registered DCCP port MUST be associated with at least one pre-defined
Service Code.
2.2. DCCP Service Code Values
DCCP specifies a 4 byte Service Code ([RFC4340],8.1.2) represented in
one of three forms as: a decimal number (the canonical method), a
four character ASCII string, or an eight digit hexadecimal number.
The Service Code identifies the application-level service to which a
client application wishes to connect. Examples of services are RTP,
TIME, ECHO. In a different example, DTLS provides a transport-service
(not an application-layer service), therefore applications using DTLS
are individually identified by a set of corresponding service codes.
Fairhurst Expires April 15, 2008 [Page 7]
Internet-Draft DCCP Service Codes October 2007
A single passive listening port may be associated with more than one
Service Code value, which may be associated with one or different
server applications.
Endpoints MUST associate a Service Code with every DCCP socket
[RFC4340], both actively and passively opened. The application will
generally supply this Service Code. It permits a more flexible
correspondence between services and port numbers than possible using
the corresponding socket pair (4-tuple of layer-3 addresses and
layer-4 ports). This decouples the use of ports for connection
demultiplexing and state management, from their use to indicate a
desired endpoint service. The Service Code value is present only in
DCCP-Request ([RFC4340],5.2)and DCCP-Response packets
([RFC4340],5.3).
Applications/protocols that provide version negotiation or indication
in the protocol operating over DCCP do not require a new server port
for each new protocol version. New versions of such
applications/protocols SHOULD continue to use the same Service Code.
If the application developers feel that the new version provides
significant new capabilities (e.g. that will change the behavior of
middleboxes), they MAY allocate a new Service Code associated with
the same or a different set of well-known ports. If the new Service
Code is associated with well-known ports, the DCCP Well-Known Ports
registry MUST also be updated to include the new Service Code value.
2.3. Service Code Registry
The set of registered Service Codes specified for use within the
general Internet are defined in an IANA-controlled name space. IANA
manages new allocations of Service Codes in this space ([RFC4340],
19.8, updated by this document). Private service codes are not
centrally allocated and are denoted by the range 1056964608-
1073741823 (i.e. whose first hexadecimal digit has the ASCII value
for '?').
Associations of Service Code with Well-Known Ports may also be
defined in the IANA DCCP Port Registry (section 2.1).
2.4. Zero Service Code
A Service Code of zero is "permanently reserved (it represents the
absence of a meaningful Service Code)" [RFC4340]. This indicates
that no application information was provided. RFC 4340 stated that
applications MAY be associated with this Service Code in the same way
as other Service Code values. This use is permitted for any server
port.
Fairhurst Expires April 15, 2008 [Page 8]
Internet-Draft DCCP Service Codes October 2007
This document clarifies section 19.8 of RFC 4340:
"Applications SHOULD NOT use a Service Code of zero.
Application writers that need a temporary Service Code value SHOULD
choose a value from the private range (Section 2.3).
Applications intended for deployment in the Internet are encouraged
to use an IANA-defined Service Code. If no specific Service Code
exists, they SHOULD request a new assignment for their protocols from
the IANA."
2.5. Invalid Service Code
RFC4340 defines the Service Code value of 0xFFFFFFFF as Invalid. The
Invalid Service Code is provided so implementations can use a special
four-byte value to indicate "no valid service code". Implementations
MUST NOT accept a DCCP-Connect with this value, and SHOULD NOT allow
applications to bind to this Service Code value.
2.6. SDP for describing Service Codes
Methods that currently signal destination port numbers, such as the
Session Description Protocol (SDP) [RFC4566] require extension to
support DCCP Service Codes [ID.DCCP.RTP].
3. Use of the DCCP Service Code
The basic operation of Service Codes is as follows:
o A sending host:
. issues a DCCP-Request with a Service Code and chooses a
destination port number that is expected to be associated with
the specified Service Code at the destination.
o A server that receives a DCCP-Request:
. determines whether an available service matching the Service
Code is supported for the specified destination server port.
The session is associated with the Service Code and a
corresponding server. A DCCP-Response is returned.
. if the service is not available, the session is rejected and a
DCCP-Reset packet is returned.
Fairhurst Expires April 15, 2008 [Page 9]
Internet-Draft DCCP Service Codes October 2007
This section explicitly updates RFC 4340 as follows:
"A DCCP implementation SHOULD allow multiple applications using
different DCCP service codes to listen on the same server port.
A DCCP implementation SHOULD provide a method that informs a server
of the Service Code value that was selected by an active connection."
The remainder of this section describes processing of DCCP Service
Codes at the sending and receiving hosts and within the network by
middleboxes.
3.1. Setting Service Codes at the Sender
A client application MUST associate every DCCP connection (and hence
every DCCP active socket) with a single Service Code value
[RFC4340]). This value is used in the corresponding DCCP-Request
packet.
3.2. Using Service Codes in the Network
Port numbers and IP addresses are the traditional methods to identify
a flow within an IP network. When the DCCP header has not been
encrypted, Middleboxes [RFC3234] SHOULD use the Service Code to
identify the application-service (even when running on a non-standard
port). When consistently used, the Service Code can provide a more
specific indication of the actual service (e.g. indicate the type of
multimedia flow, or intended application behaviour). Middlebox
devices are therefore expected to check Service Code values as well
as, or even instead of port numbers for DCCP.
DCCP connections identified by the Service Code continue to use IP
addresses and ports, although neither port number may be well-
known/reserved. Network address and port translators, known
collectively as NATs [RFC2663][RFC2766], not only interpret DCCP
ports, but may also translate/modify them [RFC2993]. Interpreting
DCCP Service Codes can reduce the need to correctly interpret port
numbers, leading to new opportunities for network address and port
translators. The DCCP Service Code may allow services to be
identified behind NATs, if NATs are not further extended to translate
Service Codes.
Although Service Codes label a connection and can (and is encouraged
to) associate specific delivery properties (e.g. use Service Codes to
identify the real-time nature of a flow that claims to be using RTP),
there is no guarantee that the actual connection data corresponds to
the associated Service Code. A Middlebox implementor may still
Fairhurst Expires April 15, 2008 [Page 10]
Internet-Draft DCCP Service Codes October 2007
therefore desire to use deep packet inspection, and other means, in
an attempt to verify the content of a connection.
The use of the DCCP Service Code can potentially lead to interactions
with other protocols that interpret or modify DCCP port numbers
[RFC3234]. The following recommendations are provided:
o A middlebox SHOULD use the Service Code value to assist in
determining the behaviour to be applied to a packet flow (e.g.
default keep-alive interval, NAT translation, etc).
o A middlebox SHOULD NOT modify the Service Code, unless they also
change the service that a connection is accessing.
o A middlebox MAY send a DCCP-Reset in response to a packet with a
Service Code that is considered unsuitable.
3.3. Using Service Codes at the Receiver
A Service Code is used by a host that receives a DCCP-Request to
associate a DCCP connection with the corresponding application
service. At the server, this association must be explicit, i.e. if
the connection is accepted, the requested Service Code must have been
previously associated with the listening port at the server.
A number of options are presented for servers using passively
listening sockets. As an example, consider the four cases that could
arise when two DCCP server applications listen on the same host:
o The simplest case is when the two servers are associated with
different Service Codes and are bound to different server ports
(section 3.3.1).
o The two servers may be associated with the same DCCP Service Code,
but be bound to different server ports (section 3.3.1).
o The two servers could use different DCCP Service Code values, and
be bound to the same port (section 3.3.2).
o The two servers could attempt to use the same DCCP Service Code
and bind to the same port. A DCCP implementation MUST disallow
this, since there is no way for the DCCP host to direct a new
connection to the correct server application.
RFC 4340 ([RFC4340, 8.1.2) states that an implementation:
Fairhurst Expires April 15, 2008 [Page 11]
Internet-Draft DCCP Service Codes October 2007
o MUST associate each active socket with exactly one Service Code on
a specified server port.
o MAY, at the discretion of an implementation, associate more than
one Service Code with a passive socket.
This document updates RFC4340 in the following way:
o SHOULD allow more than one Service Code to be associated with a
passive socket, enabling multiple applications, or multiple
versions of an application, to listen on the same port,
differentiated by Service Code.
o MUST also allow a server to use a single Service Code for more
than one server port.
o SHOULD provide a method that informs a server of the Service Code
value that was selected by an active connection.
3.3.1. Reception of a DCCP-Request
When a DCCP-Request is received, and the specified destination port
is not bound to a server, the host MUST reject the connection by
issuing a DCCP-Reset with Reset Code "Connection Refused". A host MAY
also use the Reset Code "Too Busy" ([RFC4340], 8.1.3).
When the destination port is bound to a server, the host MUST also
verify that the server port has been associated with the specified
Service Code. Two cases can occur:
o If the receiving host is listening on the specified destination
port number and the Service Code of the DCCP-Request matches one
of the Service Codes associated with this Port, the host accepts
the connection. Once connected, the server returns a copy of the
Service Code in the DCCP-Response packet completing the initial
handshake [RFC4340].
o If the port is not associated with the requested Service Code, the
server MUST reject the request by sending a DCCP-Reset packet with
Reset Code 8, "Bad Service Code" ([RFC4340], 8.1.2).
After a connection has been accepted, the protocol control block is
associated with the pair of ports and the pair of IP addresses and
one Service Code value.
Fairhurst Expires April 15, 2008 [Page 12]
Internet-Draft DCCP Service Codes October 2007
3.3.2. Multiple Associations of Service Codes and Ports at the Server
RFC4340 states that a single passively opened (listening) port MAY be
associated with multiple Service Codes, although an active (open)
connection can only be associated with a single Service Code. This
document updates RFC4340 to add:
"A Service Code MAY be associated with more than one destination port
(corresponding to a specified set of server port values)."
A single application may wish to accept connections for more than one
Service Code using the same port. This approach can simplify
middlebox processing, e.g. it should not be necessary to create more
than one hole in a firewall for this to be the case; for example DTLS
connections and unencrypted connections for the same application will
normally use different Service Codes to distinguish them, but because
this is the same application, it makes sense to use the same port.
3.3.3. Automatically launching a Server
A host implementation may permit a service to be associated with a
port (or range of ports) that is not permanently running at the
Server. In this case, the arrival of a DCCP-Request may require a
method to associate a DCCP-Request with a server that handles the
corresponding Service Code. This operation could resemble that of
"inetd". This may allow a server to offer more than the limit of
65,536 services determined by the size of the Port field (fewer if
system/user/dynamic boundaries are preserved). The upper limit is
based solely on the number of unique connections between two hosts
(i.e., 4,294,967,296).
As in the previous section, when the specified Service Code is not
associated with the specified port, the connection MUST be aborted
and a DCCP Reset message sent [RFC4340].
4. Benchmarking Services Described in this document
A number of simple services are commonly supported by systems using
DCCP and UDP, this section defines corresponding services for DCCP.
These services are useful to debug and benchmark bidirectional DCCP
connections. The IANA section of this document allocates a
corresponding set of code points for these services.
Fairhurst Expires April 15, 2008 [Page 13]
Internet-Draft DCCP Service Codes October 2007
4.1. Echo
The operation of the DCCP echo service follows that specified for UDP
[RFC862]: a server listens for DCCP connections; once a client has
set up a connection, each data packet sent to the server will be
copied (echoed) back to the client.
4.2. Daytime
The DCCP daytime service is operationally equivalent to the
connection-based TCP daytime service [RFC867]: any data received is
discarded by the server; and generates a response sent in a DCCP data
packet containing the current time and data as an ASCII string; after
which the connection is closed.
4.3. Character generator
The operation of the DCCP chargen service corresponds to the
connection-based TCP chargen protocol [RFC864]: A server listens for
incoming requests and, once a client has established a connection,
continuously sends datagrams containing a random number (between 0
and 512, up to the current path MTU) of characters. The service
terminates when the user either closes or aborts the connection.
Congestion control is enforced using the mechanisms [RFC4340] and
related documents.
If necessary the receiver can enforce flow control on this service by
using either or both of the Slow Receiver ([RFC4340], 11.6) and Data
Dropped ([RFC4340], 11.7) options to signal the server to slow down.
The chargen protocol provides a useful service that may be used for
testing and measurement of bidirectional DCCP connectivity, as well
as congestion control responsiveness. The datagram-based variant of
chargen can be emulated with the DCCP ECHO service by changing the
format of the datagrams sent by the client, hence these services
complement each other.
4.4. Time service
The format of timestamps and the operation of the DCCP time service
is equivalent with the TCP time protocol variant [RFC868]: a server
listens for incoming connections; after a client has established a
new connection, the server sends a 4-byte timestamp; whereupon the
client closes the connection.
Fairhurst Expires April 15, 2008 [Page 14]
Internet-Draft DCCP Service Codes October 2007
4.5. Generic PerfTest service
The PerfTest service specified by this document provides a generic
service that may be used to benchmark and measure both unidirectional
and bidirectional DCCP connections, as well as server and host DCCP
stacks. These services are identified by the Service Code "XPER".
This document does not specify a specific port number for this
service.
The payload of DCCP packets associated with this service does not
have a specified format. They are silently discarded by the receiver,
and used only for gathering numerical performance data.
Tools that have specific payload formats should register their own
Service Code value with IANA (e.g. section 4.6).
>>> Note from Eddie on suggested alternative text: This Service Code
is for benchmarking applications that transmit data in one-direction
only. An benchmarking application that does expect responses to
messages it sends requires a different Service Code. (This could
result in different Middlebox treatment.)
4.6. PERF service
The PERF service specified by this document describes the service
supported by the open-source iperf benchmarking program [iperf].
This may be used to benchmark and measure both unidirectional and
bidirectional DCCP connections, as well as server and host DCCP
stacks. This service is identified by a Service Code "PERF" and is
associated with a well-known port number that currently coincides
with that used by the iperf benchmarking program [iperf].
5. Security Considerations
This document does not describe new protocol functions.
The document discusses the usage of Service Codes. There are three
areas of security that are important:
1. Interaction with NATs and firewalls (section 3.2 describes
middlebox behaviour).
2. Interpretation of DCCP Service Codes over-riding traditional use
of reserved/well-known port numbers (section 5.1)
Fairhurst Expires April 15, 2008 [Page 15]
Internet-Draft DCCP Service Codes October 2007
3. Interaction with IPsec and DTLS security (section 5.2).
4. Services used for benchmarking and testing may also be used to
generate traffic for other purposes, and pose an opportunity for a
Denial of Service attack. Care needs to be exercised when enabling
these services in an operational network, or appropriate rate-
limits should be provided to mitigate these effects.
5.1. Interactions of Service Codes and port numbers
The same service (application) may be accessed using more than one
Service Code. Examples include the use of separate Service Codes for
an application layered directly upon DCCP and one using DTLS
transport over DCCP. Other possibilities include the use of a private
Service Code that maps to the same application as assigned to an
IANA-defined Service Code value, or a single application that
provides more than one service. Different versions of a service
(application) may also be mapped to a corresponding set of Service
Code values. Care needs to be exercised when interpreting the mapping
of a Service Code value to the corresponding service.
Processing of Service Codes may imply more processing than currently
associated with incoming port numbers. Implementers need to guard
against increasing opportunities for Denial of Service attack.
5.2. Interactions with IPsec
IPsec uses port numbers to perform access control in transport mode
[RFC4301]. Security policies can define port-specific access control
(PROTECT, BYPASS, DISCARD), as well as port-specific algorithms and
keys. Similarly, firewall policies allow or block traffic based on
port numbers.
Use of port numbers in IPsec selectors and firewalls may assume that
the numbers correspond to well-known services. It is useful to note
that there is no such requirement; any service may run on any port,
subject to mutual agreement between the endpoint hosts. Use of the
Service Code may interfere with this assumption both within IPsec and
in other firewall systems, but it does not add a new vulnerability.
New implementations of IPsec and firewall systems may interpret the
Service Code when implementing policy rules, but should not rely on
either port numbers or Service Codes to indicate a specific service.
This is not an issue for IPsec because the entire DCCP header and
payload are protected by all IPsec modes. None of the DCCP header is
protected by application-layer security, e.g., DTLS [ID.DTLS.DCCP],
so again this is not an issue [RFC4347].
Fairhurst Expires April 15, 2008 [Page 16]
Internet-Draft DCCP Service Codes October 2007
6. IANA Considerations
A set of new services are defined in section 6 and are summarized in
this section.
>>> Author Note: This section requires consideration by the IANA and
the DCCP WG - - issues need to be identified.
>>> Author Note: Which port-numbering space should this apply to? - -
Free-allocation may be easier to manage in the dynamic port-space
using a separate DCCP registry that is independent of TCP, UDP, and
other IETF-defined transport protocols?
To encourage application writers to register their applications, and
to avoid restricting DCCP service codes to a 16-bit space, we revise
RFC 4340 as follows:
"IANA should allocate well-known DCCP ports on demand to anyone to
applies, without requiring a specification or additional
justification. Each well-known port request MUST be for a specific
registered DCCP Service Code. The procedure may allow both to be
assigned in the same request.
IANA MUST use an allocation policy that attempts to minimize server
port collisions, but it is expected that the same well-known port
will sometimes be allocated to more than one Service Code."
6.1. Port number values allocated by this document
IANA action is required to assign ports for use by DCCP. This
document requests allocation of the following code points from the
IANA DCCP Port numbers registry:
>>>>>> IANA ACTION Please replace IANA THIS RFC, with the allocated
RFC number. <<<
Fairhurst Expires April 15, 2008 [Page 17]
Internet-Draft DCCP Service Codes October 2007
echo 7/dccp Echo SC:ECHO
# IETF dccp WG, [IANA - THIS RFC]
daytime 13/dccp DayTime SC:DTIM
# IETF dccp WG, [IANA - THIS RFC]
chatgen 19/dccp Chargen SC:CHAR
# IETF dccp WG, [IANA - THIS RFC]
time 37/dccp Timeserver SC:TIME
# IETF dccp WG, [IANA - THIS RFC]
perf 5001/dccp iPerf SC:PERF
# IETF dccp WG, [IANA - THIS RFC]
6.2. Service Code values allocated by this document
This document solicits IANA action to allocate the following code
points from the Service Code registry [IANA-SC]. The requested
assignments are listed below and summarized in table 1. This set of
Service Codes may be utilized for testing DCCP implementations and
transmission paths.
>>> IANA Please replace tbd by the assigned a port number in section
6.1.
+----------+------+----+-------------------------------+----------+
| Service | ASCII|Port| Description | Ref |
| Code (SC)| Code | | | |
+----------+------+----+-------------------------------+----------+
|1162037327| ECHO | 7| Echo service | [RFC862] |
|0x4543484f| | | | |
|1146374477| DTIM | 13| Daytime server | [RFC867] |
|0x4454494d| | | | |
|1128808786| CHAR | 19| Character generator (chargen) | [RFC864] |
|0x43484152| | | | |
|1414090053| TIME | 37| Timeserver | [RFC868] |
|0x54494d45| | | | |
|1346720326| PERF |5001| iPerf | [*] |
|0x50455246| | | | |
|1481655634| XPER | - | | [*] |
|0x58504552| | | | |
+----------+------+----+-------------------------------+----------+
Table 1: Allocation of Service Codes by this document.
Notes:
1) Port is the default port associated with this service.
2) * Reference is this document.
Fairhurst Expires April 15, 2008 [Page 18]
Internet-Draft DCCP Service Codes October 2007
This document notes that it is NOT required to supply an approved
document (e.g. a published RFC) to support an application for a DCCP
Service Code or port number value, although RFCs may be used to
request Service Code values via the IANA Considerations section (e.g.
[ID.DTLS.DCCP], [ID.DCCP.RTP]).
7. Acknowledgments
This work has been supported by the EC IST SatSix Project.
Significant contributions to this document resulted from discussion
with Joe Touch, and this is gratefully acknowledged. The author also
thanks Ian McDonald, Fernando Gont, Eddie Kohler and the DCCP WG for
helpful comments on this topic, and Gerrit Renker for his help in
determining DCCP behaviour, review of the document, and compilation
of useful test applications defined in the IANA section of this
document. Mark Handley provided significant input to the definition
of Service Codes and their usage. He also contributed much of the
material that has formed the historical background section.
8. References
8.1. Normative References
[RFC1122] Braden, R. (ed.), "Requirements for Internet Hosts:
Communication Layers, " STD 3, RFC 1122, Oct. 1989
(STANDARD).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997 (BEST
CURRENT PRACTICE).
[RFC4340] Kohler, E., M. Handley, S. Floyd, "Datagram Congestion
Control Protocol (DCCP)", RFC 4340, Mar. 2006 (PROPOSED
STANDARD).
8.2. Informative References
[IANA] Internet Assigned Numbers Authority, www.iana.org
[IANA-SC] IANA DCCP Service Code Registry
http://www.iana.org/assignments/service-codes
[ID.Portnames] J. Touch, "A TCP Option for Port Names", IETF Work in
Progress, draft-touch-tcp-portnames-00.txt.
Fairhurst Expires April 15, 2008 [Page 19]
Internet-Draft DCCP Service Codes October 2007
[ID.DTLS.DCCP] T.Phelan, "Datagram Transport Layer Security (DTLS)
over the Datagram Congestion Control Protocol (DCCP)", IETF
Work in Progress, draft-phelan-dccp-dtls-xx.txt.
[ID.DCCP.RTP] C. Perkins, "RTP and the Datagram Congestion Control
Protocol (DCCP)", IETF Work in Progress, draft-ietf-dccp-
rtp-xx.txt.
[ID.TSVWG.RAND] M. Larsen, F. Gont, "Port Randomization", IETF Work
in Progress, draft-larsen-tsvwg-port-randomization-00.
[iperf] http://dast.nlanr.net/Projects/Iperf/
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, Sept. 1981 (STANDARD).
[RFC814] Clark, D., "NAME, ADDRESSES, PORTS, AND ROUTES", RFC 814,
July 1982 (UNKNOWN).
[RFC862] Postel, J., "Echo Protocol", STD 20, RFC 862, May 1983.
[RFC864] Postel, J., "Character Generator Protocol", STD 22, RFC
864, May 1983.
[RFC867] Postel, J., "Daytime Protocol", STD 25, RFC 867, May 1983.
[RFC868] Postel, J. and K. Harrenstien, "Time Protocol", STD 26,
RFC 868, May 1983.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC 2663,
August 1999.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation
- Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", BCP
37, RFC 2780, March 2000.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang,
L., and V. Paxson, "Stream Control Transmission Protocol",
RFC 2960, October 2000.
Fairhurst Expires April 15, 2008 [Page 20]
Internet-Draft DCCP Service Codes October 2007
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", RFC
3493, February 2003.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-
Lite)", RFC 3828, July 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4347] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
9. Author's Addresses
Godred (Gorry) Fairhurst
Department of Engineering
University of Aberdeen
Kings College
Aberdeen, AB24 3UE
UK
Email: gorry@erg.abdn.ac.uk
URL: http://www.erg.abdn.ac.uk/users/gorry
9.1. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Fairhurst Expires April 15, 2008 [Page 21]
Internet-Draft DCCP Service Codes October 2007
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
9.2. Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
9.3. Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Fairhurst Expires April 15, 2008 [Page 22]
Internet-Draft DCCP Service Codes October 2007
APPENDIX A: API support for Service Codes
A potential issue in defining an API for DCCP arises when an
application binds to a port it needs to specify the associated DCCP
Service Code. This requires an API that allows a service to be
associated with a Service Code in addition to a port number. One
approach is to use separate commands as follows:
o Extend the existing port number indicator command (e.g., Unix
bind() or connect() calls) to also select a specific Service Code
where desired.
o Extend the existing socket parameterization command (e.g., Unix
setsockopt()) to set a service-code option. This is implemented in
the present Linux API for a DCCP socket (where the Service Code
should be wrapped by htonl/ntohl to ensure network byte order).
o An information base (table) may be used by servers to identify the
set of Service Codes that are associated with each port and the
corresponding set of server applications.
The current socket API generally requires separate requests to bind
the port and to set the Service Code for the socket. This is not a
problem, providing that an implementation requires both to be
specified before the socket is allowed to accept connections.
The host API SHOULD provide a method that returns the Service code of
an incoming connection request to the application. This may be used
by an application to correctly process a connection that arrives at a
port for which it has registered more than one Service Code.
>>> Author note:
May need to discuss:
get_port_and_service_code_by_name(char *what_service_do_you_want)
char *get_service_code_by_number(unsigned sc)
and interactions with getadddrinfo() address/port lookup routine,
which has been introduced to simplify the migration to IPv6
([RFC3493], 6.1).
Functions such as getnameinfo and getservent may also need to be
updated. >>> End Author Note.
Fairhurst Expires April 15, 2008 [Page 23]
Internet-Draft DCCP Service Codes October 2007
>>> RFC Editor please remove this section prior to publication.
Change Log.
01 introduced:
- a replacement of the word *range* when referring to sets of dccp
ports (they are not necessarily contiguous), noted by E. Kohler.
- Addition of some Service Codes in IANA section.
02 introduced:
- add the use of profiles with DCCP, identified by Service Code, but
not the use of protocol variants.
- further detail on implementation levels (more input would be good)
- added security consideration for traffic generators
- added ref to UDPL for completeness
- Corrected NiTs found by Gerrit Renker
+++++++++++++++++++++++++++
WG 00 (first WG version)
This introduced revisions to make it a WG document.
- Corrected language and responded to many helpful comments from
Fernando Gont and Ian McDonald.
- Added a test for which server behaviour is used.
- Added some speculative text on how to implement the SC.
- More input and discussion is requested from the WG.
- Added an informative appendix on host configuration.
- Merging of some sections to remove repetition and clarify wording.
+++++++++++++++++++++++++++
Fairhurst Expires April 15, 2008 [Page 24]
Internet-Draft DCCP Service Codes October 2007
WG 01
Historical material was added.
Comments from the list have been included.
The concept of adding weak semantics to a SC=0 was removed. This was
added at the request of implementers, with the aim of offering easier
implementation on at least one target platform. It has been removed
in this document because it weakens interoperability and complicates
the Spec.
The proposal to allow several levels of support was introduced in
previous drafts following suggestions from the WG, but was removed in
this revision. The method was seen to introduce complexity, and
resulted in complex interoperability scenarios.
Removed "test" method, this was no longer required.
Draft was reorganized to improve clarity and simplify concepts.
----
WG 02
Updated following comments from Eddie Kohler.
>>> Need to check changes relative to RFC4340!
Fairhurst Expires April 15, 2008 [Page 25]
