[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-fairhurst-dccp-serv-codes) 00 01 02 03 04 05 06 07 08 09 10 11 RFC 5595

DCCP WG                                                     G.Fairhurst
Internet-Draft                                   University of Aberdeen
Intended status: Proposed Standard                    February 18, 2008
Expires: July 18, 2008


                           The DCCP Service Code
                     draft-ietf-dccp-serv-codes-04.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 August 18, 2008.

Abstract

   This document describes the usage of Service Codes by the Datagram
   Congestion Control Protocol, RFC 4340. It 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). The document updates the specification provided in RFC
   4340.



G. Fairhurst           Expires August 18, 2008                 [Page 1]

Internet-Draft            DCCP Service Codes              February 2008


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..................................8
         2.2.1. New versions of Applications or Protocols............8
      2.3. Service Code Registry.....................................8
      2.4. Zero Service Code.........................................9
      2.5. Invalid Service Code......................................9
      2.6. SDP for describing Service Codes..........................9
      2.7. A method to hash the Service Code to a Dynamic Port.......9
   3. Use of the DCCP Service Code..................................10
      3.1. Setting Service Codes at the Client......................11
      3.2. Using Service Codes in the Network.......................11
      3.3. Using Service Codes at the Server........................12
         3.3.1. Reception of a DCCP-Request.........................13
         3.3.2. Multiple Associations of a Service Code with Ports..14
         3.3.3. Automatically launching a Server....................14
   4. DCCP Benchmarking Services....................................14
      4.1. Echo.....................................................14
      4.2. Daytime..................................................14
      4.3. Character generator......................................15
      4.4. Time service.............................................15
      4.5. Generic PerfTest service.................................15
      4.6. PERF service.............................................16
   5. Security Considerations.......................................16
      5.1. Association of applications with Service Codes...........16
      5.2. Interactions with IPsec..................................17
      5.3. Security Considerations for Benchmarking Services........17
   6. IANA Considerations...........................................17
      6.1. Service Code Registry....................................18
      6.2. Port Numbers Registry....................................18
      6.3. IANA Assignments for Benchmarking Applications...........19
         6.3.1. Port number values allocated by this document.......19
         6.3.2. Service Code values allocated by this document......20
   7. Acknowledgments...............................................20
   8. References....................................................21
      8.1. Normative References.....................................21
      8.2. Informative References...................................21
   9. Author's Addresses............................................23
      9.1. Intellectual Property Statement..........................23
      9.2. Disclaimer of Validity...................................23
      9.3. Copyright Statement......................................24



G. Fairhurst           Expires August 18, 2008                 [Page 2]

Internet-Draft            DCCP Service Codes              February 2008


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.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 server 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 by a firewall and may assist other Middleboxes (e.g., a proxy
   server, network address translator (NAT) [RFC2663]. 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 also 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 (server) 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 [RFC4960], 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


G. Fairhurst           Expires August 18, 2008                 [Page 3]

Internet-Draft            DCCP Service Codes              February 2008


   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].

   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 using 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. This motivates firewall writers 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,
   overhead considerations made a 32-bit port value undesirable (DCCP
   needed to be useful for low rate applications).


G. Fairhurst           Expires August 18, 2008                 [Page 4]

Internet-Draft            DCCP Service Codes              February 2008


   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
   identify 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, allowing 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 favor
   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). 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 unique 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.

   A solution is to register Well Known DCCP ports.  The limited
   availability of Well Known DCCP ports appears to contradict the
   benefits of DCCP Service Codes, because although it may be trivial to
   obtain a 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 unique Well Known DCCP 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.


G. Fairhurst           Expires August 18, 2008                 [Page 5]

Internet-Draft            DCCP Service Codes              February 2008


   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
   this and the issues concerning the use 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
   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.


G. Fairhurst           Expires August 18, 2008                 [Page 6]

Internet-Draft            DCCP Service Codes              February 2008


   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.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 registered ports. These 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.

   Applications that do not need to use a server port in the Well Known
   range SHOULD use a dynamic server port (i.e. that does not require to
   be registered in the DCCP port registry). Clients can identify the
   server port value for the services to which they wish to connect
   using a range of methods. One common method is by reception of a SDP
   record (section 2.6) exchanged out-of-band (e.g. using SIP [RFC3261]
   or RTSP [RFC2326]). DNS SRV resource records also provide a way to
   identify a server port for a particular service based on the services
   string name [RFC2782].

   Applications that do not use out-of-band signalling can still
   communicate, providing both client and server agree the port value
   to be used. This eliminates the need for each registered Service
   Code to be allocated an IANA-assigned server port (see also section
   2.7).





G. Fairhurst           Expires August 18, 2008                 [Page 7]

Internet-Draft            DCCP Service Codes              February 2008


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
   [ID.RTP], TIME (this document), ECHO (this document). In a different
   example, DTLS [ID.DTLS] provides a transport-service (not an
   application-layer service), therefore applications using DTLS are
   individually identified by a set of corresponding Service Code
   values.

   Endpoints MUST associate a Service Code with every DCCP socket
   [RFC4340], both actively and passively opened. The application will
   generally supply this Service Code. A single passive listening port
   may be associated with more than one Service Code value. The set of
   Service Codes could be associated with one or more server
   applications. This permits a flexible correspondence between services
   and port numbers than possible using the corresponding socket pair
   (4-tuple of layer-3 addresses and layer-4 ports). In the currently
   defined set of packet types, the Service Code value is present only
   in DCCP-Request ([RFC4340],5.2)and DCCP-Response packets
   ([RFC4340],5.3).

2.2.1. New versions of Applications or Protocols

   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,
   but MAY share the same port assignment(s).

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-


G. Fairhurst           Expires August 18, 2008                 [Page 8]

Internet-Draft            DCCP Service Codes              February 2008


   1073741823 (i.e. whose first hexadecimal digit has the ASCII value
   for '?').

   Associations of Service Code with Well Known Ports are 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 states 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.

   This document clarifies section 19.8 of RFC 4340 in the following
   way:

   "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 from the IANA."

2.5. Invalid Service Code

   RFC4340 defines the Service Code value of 0xFFFFFFFF as Invalid. This
   is provided so implementations can use a special four-byte value to
   indicate "no valid Service Code". Implementations MUST NOT accept a
   DCCP-Request with this value, and SHOULD NOT allow applications to
   bind to this Service Code value [RFC4340].

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.RTP].

2.7. A method to hash the Service Code to a Dynamic Port

   Applications that do not use out-of-band signalling still require
   both the client and server to agree the server port value to be
   used. This section describes a method at the client and server to
   hash the 32-bit Service Code to a value in the dynamic port range.


G. Fairhurst           Expires August 18, 2008                 [Page 9]

Internet-Draft            DCCP Service Codes              February 2008


   Note that more than one DCCP server may share the same server port,
   since in DCCP the Service Code mechanism is the method for unique
   identification of a service.

   The Service Code can be used to derive a default server port number
   for a service using the method below. This provides applications
   with easy identification of a default Service Code, without
   requiring IANA action to create or update a registry. The returned
   value is in the dynamic port range [RFC4340]:

     int s_port; /* server port */
     s_port = (sc[0]<<7)^(sc[1]<<5)^(sc[2]<<3)^sc[3] | 0xC000;

   Where sc[] represents the four bytes of the Service Code, and sc[3]
   is the least significant byte, for example this function associates
   SC:fdpz with the server port 64634.

   This algorithm has the following properties:

   o  The method identifies a default server port for each Service Code.

   o  The method seeks to assign different Service Codes to different
      ports, but does not guarantee an assigment is unique.

   o  The method preserves the four bits of the final bytes of the
      Service Code, allowing a series of Service Codes to be requested
      that in this method are mapped to adjacent ports, e.g. Foo1, and
      Foo2; and Fooa and Foob would be assigned adjacent ports.


   All applications and higher-layer protocols that have been assigned
   a Service Code (or use a Service Code from the unassigned private
   space) may therefore use this method, which eliminates the need for
   each registered Service Code to be allocated an IANA-assigned server
   port.


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 (server) port number that is expected to be
          associated with the specified Service Code at the destination.



G. Fairhurst           Expires August 18, 2008                [Page 10]

Internet-Draft            DCCP Service Codes              February 2008


   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.

3.1. Setting Service Codes at the Client

   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.
   Network address and port translators, known collectively as NATs
   [RFC2663], 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,
   providing that NATs do not 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
   therefore desire to use deep packet inspection, and other means, in
   an attempt to verify the content of a connection.



G. Fairhurst           Expires August 18, 2008                [Page 11]

Internet-Draft            DCCP Service Codes              February 2008


   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 Server

   A Service Code is used by a Server that receives a DCCP-Request to
   associate a new DCCP connection with the corresponding application
   service. A number of options are presented for servers using
   passively listening sockets.  Four cases can arise when two DCCP
   server applications listen on the same host:

   o  The simplest case arises when two servers are associated with
      different Service Codes and are bound to different server ports
      (section 3.3.1).

   o  Two servers may be associated with the same DCCP Service Code
      value, but be bound to different server ports (section 3.3.1).

   o  Two servers could use different DCCP Service Code values, and be
      bound to the same server port (section 3.3.2).

   o  Two servers could attempt to use the same DCCP Service Code and
      bind to the same server 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:

   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:



G. Fairhurst           Expires August 18, 2008                [Page 12]

Internet-Draft            DCCP Service Codes              February 2008


   o  "An implementation SHOULD allow more than one Service Code to be
      associated with a passive server port, enabling multiple
      applications, or multiple versions of an application, to listen on
      the same port, differentiated by Service Code.

   o  An implementation 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 requested 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 server port
      and the DCCP-Request uses one of the Service Codes previously
      associated with the server 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 server 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).

   A single application may wish to accept connections for more than one
   Service Code using the same server 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 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 server
   port. 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).

   After a connection has been accepted, the protocol control block is
   associated with a pair of ports and a pair of IP addresses and a
   single Service Code value.



G. Fairhurst           Expires August 18, 2008                [Page 13]

Internet-Draft            DCCP Service Codes              February 2008


3.3.2. Multiple Associations of a Service Code with Ports

   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 also add:

   "A specific Service Code value MAY be associated with more than one
   server port, although only a single port is registered by IANA."

3.3.3. Automatically launching a Server

   A host implementation may permit a service to be associated with a
   server 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" [inetd].

   As in the previous section, when the specified Service Code is not
   associated with the specified server port, the connection MUST be
   aborted and a DCCP Reset message sent [RFC4340].

4. DCCP Benchmarking Services

   A number of simple services are commonly supported by systems using
   TCP and UDP, this section defines corresponding services for DCCP
   [RFC4340]. These services are useful for debugging DCCP
   implementations and deployment, and for benchmarking bidirectional
   DCCP connections. The IANA section of this document allocates a
   corresponding set of code points for these services.

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.



G. Fairhurst           Expires August 18, 2008                [Page 14]

Internet-Draft            DCCP Service Codes              February 2008


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, not exceeding the current DCCP Maximum Packet Size, MPS) 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) DCCP options to signal the server to
   slow-down.

   The chargen protocol provides a 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 to 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.

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 do 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).




G. Fairhurst           Expires August 18, 2008                [Page 15]

Internet-Draft            DCCP Service Codes              February 2008


   This Service Code is for benchmarking applications that transmit data
   in one-direction only, with DCCP control traffic flowing in the
   opposite direction. A benchmarking application that expects data
   responses to the messages it sends would require 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 the UDP port used by the iperf benchmarking program [iperf].



5. Security Considerations

   This document discusses the usage of Service Codes. It does not
   describe new protocol functions. 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 4.1)

   3. Interaction with IPsec and DTLS security (section 4.2).

5.1. Association of applications with Service Codes

   Care needs to be exercised when interpreting the mapping of a Service
   Code value to the corresponding service. 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.





G. Fairhurst           Expires August 18, 2008                [Page 16]

Internet-Draft            DCCP Service Codes              February 2008


   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], so
   again this is not an issue [RFC4347].

5.3. Security Considerations for Benchmarking Services

   Services used for benchmarking and testing may also be used to
   generate traffic for other purposes. They can therefore pose an
   opportunity for a Denial of Service attack. Care needs to be
   exercised when enabling these services in an operational network.
   Appropriate rate-limits should be provided to mitigate these effects.
   In this respect the security considerations are the same as those for
   other IETF-defined transport protocols.



6. IANA Considerations

   This document updates the IANA allocation procedures for the DCCP
   Port Number and DCCP Service Codes Registries as defined in RFC 4340.






G. Fairhurst           Expires August 18, 2008                [Page 17]

Internet-Draft            DCCP Service Codes              February 2008


6.1. Service Code Registry

   Service Codes are allocated first-come-first-served (19.8.
   [RFC4340]). This document updates RFC4340 in the following way:

   o  "The IANA MAY assign new Service Codes without seeking Expert
      Review using their discretion, but SHOULD seek expert review when
      a request seeks an appreciable number of Service Codes (e.g. more
      than five)."

   However, the IANA should feel free to contact the DCCP Expert
   Reviewer with questions on any registry, regardless of the registry
   policy, for clarification or if there is a problem with a request
   [RFC4340].

6.2. Port Numbers Registry

   The DCCP ports registry is defined by RFC4340 in section 19.9.
   Allocations in this registry require prior allocation of a Service
   Code.  Not all Service Codes require IANA-registered ports. This
   document updates RFC4340 in the following way:

   o  "IANA should normally assign a value above 1024 to a DCCP server
   port. IANA allocation requests to allocate port numbers in the Well
   Known Ports range (0 through 1023), require Expert Review prior to
   allocation by IANA [RFC4340]. Requests for registered ports in the
   range 1024-49151, do not normally require Expert Review."

   RFC4340 requires each DCCP server port assignment to be associated
   with at least one Service Code value. This document updates RFC4340
   in the following way:

   o  "IANA MUST NOT allocate more than one DCCP server port with a
   single Service Code value.

   o  The set of Service Code values associated with a DCCP server port
   should be recorded in the registry.

   o  A request for additional Service Codes to be associated with an
   already allocated Port Number requires expert review. These requests
   will normally be accepted when they originate from the contact
   associated with the port registration. In other cases, these
   applications will be expected to use an unallocated port, when this
   is available."

   RFC 4340 notes that a short port name MUST be associated with each
   DCCP server port that has been registered, and that this name is


G. Fairhurst           Expires August 18, 2008                [Page 18]

Internet-Draft            DCCP Service Codes              February 2008


   expected to be unique within the registry. This document updates this
   by adding that:

   o  "A port name may be generated from the Service Code value
   represented in hexadecimal, e.g. SC:fdpz corresponds to the port name
   '0x6664707a'."

   In the case of DCCP, it is considered useful to use a value that
   shows the association with the Service Code, and since service codes
   are 32-bit numbers this requires the a hexadecimal representation.
   This differs with the tradition of naming ports in UDP and TCP.

6.3. IANA Assignments for Benchmarking Applications

   A set of new services are defined in section 4. Their corresponding
   IANA assignments are summarized in this section.

   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.SC]).  A specification is however required to allocate a Service
   Code that uses a combination of ASCII digits, uppercase letters, and
   character space, '-', '.', and '/') [RFC4340].

6.3.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. <<<

   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]





G. Fairhurst           Expires August 18, 2008                [Page 19]

Internet-Draft            DCCP Service Codes              February 2008


6.3.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 confirm these allocations. >>>

    +----------+------+----+-------------------------------+----------+
    | 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 |  - | Generic Performance Service   |    [*]   |
    |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.




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 and review of this document. Mark Handley
   provided significant input to the text on definition of Service Codes
   and their usage. He also contributed much of the material that has
   formed the historical background section.


G. Fairhurst           Expires August 18, 2008                [Page 20]

Internet-Draft            DCCP Service Codes              February 2008


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.DTLS] T.Phelan, "Datagram Transport Layer Security (DTLS) over
             the Datagram Congestion Control Protocol (DCCP)", IETF Work
             in Progress, draft-ietf-dccp-dtls-05.txt.

   [ID.RTP] C. Perkins, "RTP and the Datagram Congestion Control
             Protocol (DCCP)", IETF Work in Progress, draft-ietf-dccp-
             rtp-07.t.

   [ID.RAND] M. Larsen, F. Gont, "Port Randomization", IETF Work in
             Progress, draft-larsen-tsvwg-port-randomization-02.xt

   [inetd]   The extended intetd project, http://xinetd.org/

   [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).



G. Fairhurst           Expires August 18, 2008                [Page 21]

Internet-Draft            DCCP Service Codes              February 2008




   [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.

   [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
             Streaming Protocol (RTSP)", RFC 2326, April 1998.

   [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
             Translator (NAT) Terminology and Considerations", RFC 2663,
             August 1999.

   [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
             Values In the Internet Protocol and Related Headers", BCP
             37, RFC 2780, March 2000.

   [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
             specifying the location of services (DNS SRV)", RFC 2782,
             February 2000.

   [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.

   [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
             A., Peterson, J., Sparks, R., Handley, M., and E. Schooler,
             "SIP: Session Initiation Protocol", RFC 3261, June 2002.

   [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.


G. Fairhurst           Expires August 18, 2008                [Page 22]

Internet-Draft            DCCP Service Codes              February 2008


   [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
             Description Protocol", RFC 4566, July 2006.

   [RFC4960] Stewart, R., Ed., tream Control Transmission Protocol RFC
             4960, September 2007.

9. Author's Addresses

   Godred (Gorry) Fairhurst,
   School 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.

   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


G. Fairhurst           Expires August 18, 2008                [Page 23]

Internet-Draft            DCCP Service Codes              February 2008


   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 (2008).

   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.




































G. Fairhurst           Expires August 18, 2008                [Page 24]

Internet-Draft            DCCP Service Codes              February 2008


   >>> 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.

   +++++++++++++++++++++++++++





G. Fairhurst           Expires August 18, 2008                [Page 25]

Internet-Draft            DCCP Service Codes              February 2008


   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.

   ----

   WG 03

   Fixed NiTs and addressed issues marked in previous version.

   Added 2 para at end of port section saying how to use Well Known
   ports and that you do not need to register them.

   -----

   WG 04

   Cleaned English (removing duplication)

   Checked text that updates RFC4340 (and remove duplicates).

   Updated hash algorithm for SC->s_port

   Updated to IANA section.


G. Fairhurst           Expires August 18, 2008                [Page 26]

Internet-Draft            DCCP Service Codes              February 2008


   Edits in response to feedback from Tom Phelan, et al.



   To-do:

   The IANA procedures need to be confirmed, in particular the specific
   update that:

   "Requests for registered ports in the range 1024-49151, do not
   normally require Expert Review."

   ----




































G. Fairhurst           Expires August 18, 2008                [Page 27]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/