DCCP WG                                                     G.Fairhurst 
Internet Draft                                   University of Aberdeen 
Expires: September 2007                                 October 2, 2007 
                                    
 
                                      
                           The DCCP Service Code 
                     draft-ietf-dccp-serv-codes-01.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 2, . 

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 2, 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..............................7 
      2.1. IANA Port Numbers.........................................7 
      2.2. DCCP Service Code Values..................................8 
      2.3. Service Code Registry.....................................8 
      2.4. Zero Service Code.........................................9 
      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....12 
         3.3.3. Automatically launching a Server....................13 
   4. Benchmarking Services Described in this document..............13 
      4.1. Echo.....................................................13 
      4.2. Daytime..................................................13 
      4.3. Character generator......................................14 
      4.4. Time service.............................................14 
      4.5. PerfTest service.........................................14 
   5. Security Considerations.......................................15 
      5.1. Interactions of Service Codes and port numbers...........15 
      5.2. Interactions with IPsec..................................16 
   6. IANA Considerations...........................................16 
      6.1. Port number values allocated by this document............17 
      6.2. Service Code values allocated by this document...........17 
   7. Acknowledgments...............................................18 
   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...................................21 
      9.3. Copyright Statement......................................22 
   APPENDIX A: API support for Service Codes........................23 








 
 
Fairhurst               Expires April 2, 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.  

   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. Only one application may listen on a specific port 
   at any time, however when accepting a new connection, a port may be 
   associated with more than one Service Code (the requested Service 
   Code may then select the application).  

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

   Use of a Service Code value, instead of binding a service to a 
   particular publicly-known port number, permits a larger number of 
   concurrent connections for a particular service. For example, this 
   may be useful for 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. In the earliest 
   draft of DCCP the authors wanted to address the issue of well-known 
   ports in a future-proof manner.   


 
 
Fairhurst               Expires April 2, 2008                  [Page 3] 

Internet-Draft            DCCP Service Codes               October 2007 
    

   Most current Internet transport protocols used "well-known" port 
   numbers [RFC814]. These 16-bit values indicate the application 
   service associated with a connection or message; this includes TCP 
   [RFC793], UDP [RFC768], SCTP [RFC2960], UDP-Lite [RFC3828], and DCCP 
   [RFC4340]. The server port must be known to the client to allow a 
   connection to be established.  This could be achieved using out-of-
   band signaling, 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 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 method of using well-known ports 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. This encourages firewall writers to use 
      deep packet inspection in an attempt to validate that the 
      application actually is that 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 feature interaction problems. 

   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 2, 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 bitrate 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 
   middleboxes 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 at all; instead the client allocated a 32-bit connection 
   identifier that 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, and the DCCP client would have had to 
   include a Service Code in the request to allow it to reach the 
   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 43404 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 maintained its original role of 
   being the globally-unique identifier for the application or protocol 
   being used over DCCP, and that the pair of ports would effectively be 
   a 32-bit connection identifier, unique at both end-systems, even 
   though the two parts were allocated by the two different ends of a 
   connection. 

   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.  


 
 
Fairhurst               Expires April 2, 2008                  [Page 5] 

Internet-Draft            DCCP Service Codes               October 2007 
    

   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 
   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). The co-existence that arise 
   when one port is associated with two Service Codes that are each 
   bound to different applications does not raise any protocol issues. 
   An incoming DCCP-Request is directed to the correct application. 

   This has led to 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. 

   Service Codes provide flexibility in the way clients identify the 
   server application to which they wish to communicate. Traditionally 
   IANA has allocated a single well-known port value for global use by 
   all hosts [RFC1122] on the public Internet, even though the 
   association between a port and a service is of interest only to the 
   hosts participating in a connection. This has resulted in the fixed 
   space of port numbers being globally reserved unnecessarily  
   [ID.Portnames]. Service Codes offer a flexible alternative where this 
   name space is allocated per-host.  This allows clients to choose 
   which destination port is used for a service, permitting servers to 
   associate more than one port with a service and enabling a larger 
   number of concurrent connections for a particular service than 
   possible using well-known port numbers. 

   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. 


 
 
Fairhurst               Expires April 2, 2008                  [Page 6] 

Internet-Draft            DCCP Service Codes               October 2007 
    

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, forming a socket; and a pair of 
   sockets 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. Such methods may be 
   applicable to other IETF-defined transport protocols, including DCCP. 

   Traditionally, the destination 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 registry [RFC4340].  

   This section updates section 19.9 of [RFC4340] in the following way: 

   "Each DCCP port entered in this registry MUST be associated with at 
   least one pre-defined Service Code (see section 2.2)." 

 
 
Fairhurst               Expires April 2, 2008                  [Page 7] 

Internet-Draft            DCCP Service Codes               October 2007 
    

2.2. DCCP Service Code Values 

   DCCP specifies a 4 byte Service Code [RFC4340], 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. 

   A single destination port may be associated with more than one 
   Service Code value. These may be associated with one or different 
   server applications. Appendix A provides some examples of ways that 
   may be used to configure this support.  

   Endpoints MUST associate a Service Code with every DCCP socket, both 
   actively and passively opened. The application will generally supply 
   this Service Code. This Service Code value is present only in DCCP-
   Request and DCCP-Response packets. It permits a more flexible 
   correspondence between services and port numbers than is 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. 

   Applications/protocols that provide version negotiation or indication 
   in the protocol operating over DCCP do not require a new port for a 
   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 (which MAY be associated with 
   the same set of DCCP well-known ports). 

2.3. Service Code Registry 

   The set of registered Service Codes currently 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]. 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. 
 
 
Fairhurst               Expires April 2, 2008                  [Page 8] 

Internet-Draft            DCCP Service Codes               October 2007 
    

2.4. Zero Service Code  

   RFC 4340 assigns a Service Code of zero to represent the absence of a 
   meaningful Service Code. Applications SHOULD NOT associate themselves 
   with this Service Code. Application writers that need a new Service 
   Code value should either choose a value from the private range 
   (Section 2.3), or request a new service code from the IANA. 

   >>> Author Note: The following alternative has also been proposed. 

   A DCCP Service Code with a value of zero has no special meaning and 
   should not be used as a wildcard service code. This section updates 
   Section 19.8 of RFC 4340: 

   "Implementations MUST allow applications to listen with a Service 
   Code of zero, by being explicity associating a port with this Service 
   Code." 

   >>> End Author Note 

2.5. SDP for describing Service Codes 

   Methods that currently signal destination port numbers, such as the 
   Session Description Protocol (SDP) require extension to also support 
   DCCP Service Codes [ID.DCCP.RTP].  

    

3. Use of the DCCP Service Code 

   The basic operation of the Service Codes is as follows: 

   o  A sending host: 

       .  issues a DCCP-Request with a Service Code and choose 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 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 2, 2008                  [Page 9] 

Internet-Draft            DCCP Service Codes               October 2007 
    

   This section explicitly updates RFC 4340 as follows: 

   "A DCCP implementation MUST 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. Valid 
   Service Codes may be selected from the set of values assigned in the 
   DCCP Service Code Registry maintained by IANA [IANA-SC], or from the 
   uncoordinated private space ([RFC4340], 8.1.2.). 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 instead use the Service Code 
   to identify the application-service (even when running on a non-
   standard port). Middlebox devices are therefore expected to check 
   Service Code values before 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.  

   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: 



 
 
Fairhurst               Expires April 2, 2008                 [Page 10] 

Internet-Draft            DCCP Service Codes               October 2007 
    

   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 the 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 destination port at the server. 

   Each active socket MUST be associated with exactly one Service Code. 
   Passive sockets MAY, at the discretion of an implementation (section 
   3.2), be associated with more than one Service Code; this may let 
   multiple applications, or multiple versions of the same application, 
   listen on the same port, differentiated by Service Code.  

   An implementation: 

   o  MUST allow a server to be associated with a Service Code on a 
      specified port [RFC4340]. 

   o  MAY also allow a server to set a Service Code that applies to a 
      set of acceptable destination ports [RFC4340]. 

   o  SHOULD provide a method that informs a server of the Service Code 
      value that was selected by an active connection. 

   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 
      (see section 3.3.1). 

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


 
 
Fairhurst               Expires April 2, 2008                 [Page 11] 

Internet-Draft            DCCP Service Codes               October 2007 
    

   o  The two servers could use different DCCP Service Code values, and 
      be bound to the same port.  This is discussed in detail in 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 and reset the connection, since there is no way for the DCCP 
      host to direct a new connection to the correct server application. 

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 port has been associated with the specified Service 
   Code. A Service Code of zero MUST only be accepted for servers that 
   have no associated Service Code or are explicitly associated with the 
   Service Code value of zero. 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.  

3.3.2. Multiple Associations of Service Codes and Ports at the Server 

   RFC 4340 states that a Service Code MAY be associated with more than 
   one destination port (corresponding to a set of port values). Also a 
   single destination port MAY be associated with multiple Service 
   Codes, although an active (open) connection can only be associated 
   with a single Service Code.  

   A single application may wish to accept connections for more than one 
   Service Code using the same port.  This approach can simplify 
 
 
Fairhurst               Expires April 2, 2008                 [Page 12] 

Internet-Draft            DCCP Service Codes               October 2007 
    

   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. 

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.  
 
 
Fairhurst               Expires April 2, 2008                 [Page 13] 

Internet-Draft            DCCP Service Codes               October 2007 
    

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. 

4.5. PerfTest service 

   The PerfTest concept 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.  

   This document defines a generic PerfTest service. The payload of DCCP 
   packets associated with the DCCP PerfTest service are silently 
   discarded by the receiver, and used only for gathering numerical 
   performance data. 

   The PerfTest server is identified by a combination of the port number 
   and DCCP Service Code. It does not recommend a specific benchmarking 
   software to use, but does allocate a port number specified that 
   currently coincides with that of the open-source iperf benchmarking 
   program [iperf].  
 
 
Fairhurst               Expires April 2, 2008                 [Page 14] 

Internet-Draft            DCCP Service Codes               October 2007 
    

    

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 (see section 3.2, on middlebox 
      behaviour). 

   2. Interpretation of DCCP Service Codes over-riding traditional use 
      of reserved/well-known port numbers (see section 8.1) 

   3. Interaction with IPsec and DTLS security (see section 8.2, on use 
      of IPsec). 

   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 Service Code value may be used to over-ride the traditional way 
   operating systems consider low-numbered ports as privileged. This 
   represents a change in the way operating systems respect this range 
   of DCCP 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. 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. 



 
 
Fairhurst               Expires April 2, 2008                 [Page 15] 

Internet-Draft            DCCP Service Codes               October 2007 
    

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

    

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 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.  
 
 
Fairhurst               Expires April 2, 2008                 [Page 16] 

Internet-Draft            DCCP Service Codes               October 2007 
    

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

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












 
 
Fairhurst               Expires April 2, 2008                 [Page 17] 

Internet-Draft            DCCP Service Codes               October 2007 
    

    +----------+------+----+-------------------------------+----------+ 
    | 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| Performance tests (e.g.       | *        | 
    |0x50455246|      |    | iperf, ttcp, ...)             |          | 
    +----------+------+----+-------------------------------+----------+ 
     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. 
      

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






 
 
Fairhurst               Expires April 2, 2008                 [Page 18] 

Internet-Draft            DCCP Service Codes               October 2007 
    

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. 

   [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). 
 
 
Fairhurst               Expires April 2, 2008                 [Page 19] 

Internet-Draft            DCCP Service Codes               October 2007 
    

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

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

    
 
 
Fairhurst               Expires April 2, 2008                 [Page 20] 

Internet-Draft            DCCP Service Codes               October 2007 
    

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. 

   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. 
 
 
Fairhurst               Expires April 2, 2008                 [Page 21] 

Internet-Draft            DCCP Service Codes               October 2007 
    

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 2, 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 2, 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 2, 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 -                              - no longer required. 

   Draft was reorganized to improve clarity and simplify concepts. 

   ---- 

 























 
 
Fairhurst               Expires April 2, 2008                 [Page 25]