Internet DRAFT - draft-fairhurst-dccp-serv-codes

draft-fairhurst-dccp-serv-codes



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

Abstract 

   This document describes the usage of Service Codes by the Datagram 
   Congestion Control Protocol, RFC 4340. 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 DCCP 
   Service Code can also enable more explicit coordination of services 
   behind NATs and firewalls. This document motivates the setting of 
   Service Codes by applications, rather than assigning a default 
   Service Code value of zero. 

 
 
 
G. Fairhurst          Expires September 2, 2007                [Page 1] 

Internet-Draft            DCCP Service Codes                 March 2007 
    

Table of Contents 

   1. Introduction...................................................3 
      1.1. Conventions used in this document.........................4 
   2. An Architecture for supporting Service Codes...................5 
      2.1. IANA Port Numbers.........................................5 
      2.2. DCCP Service Code Values..................................6 
      2.3. Zero Service Code.........................................6 
      2.4. Reception of a DCCP-Request with a bound Service Code.....6 
      2.5. Reception of a DCCP-Request with an unbound Service Code..7 
      2.6. SDP for describing Service Codes..........................7 
      2.7. Service Code Registry.....................................7 
   3. Use of the DCCP Service Code...................................7 
      3.1. Setting Service Codes at the Sender.......................8 
      3.2. Using Service Codes in the Network........................8 
      3.3. Using Service Codes at the Receiver.......................8 
      3.4. Multiple Associations of Service Codes and Ports at the 
      Sender.........................................................9 
      3.5. Summary of Service Code and Port Handling................10 
   4. Implementation Support for Service Codes......................11 
      4.1. Minimal Support..........................................11 
      4.2. Standard Support.........................................11 
      4.3. Enhanced Support.........................................11 
   5. Changes required to the API to support Service Codes..........12 
      5.1. Interactions with IPsec..................................12 
   6. Service Code Registry.........................................13 
   7. Benchmarking Services Described in this document..............13 
      7.1. Echo.....................................................13 
      7.2. Daytime..................................................13 
      7.3. Character generator......................................13 
      7.4. Time service.............................................14 
      7.5. PerfTest service.........................................14 
   8. Security Considerations.......................................15 
      8.1. Interactions of Service Codes and port numbers...........15 
   9. IANA Considerations...........................................16 
      9.1. Port number values allocated by this document............16 
      9.2. Service Code values allocated by this document...........16 
   10. Conclusions..................................................17 
   11. Acknowledgments..............................................17 
   12. References...................................................18 
      12.1. Normative References....................................18 
      12.2. Informative References..................................18 
   Author's Addresses...............................................19 
   Intellectual Property Statement..................................20 
   Disclaimer of Validity...........................................20 
   Copyright Statement....................Error! Bookmark not defined. 
   Acknowledgment...................................................21 
 
 
Fairhurst             Expires September 2, 2007                [Page 2] 

Internet-Draft            DCCP Service Codes                 March 2007 

1. Introduction 

   Most Internet transport protocols use "well-known" port numbers 
   [RFC814] to indicate which application service is associated with a 
   connection or message; this includes TCP [RFC793], UDP [RFC768], SCTP 
   [RFC2960], UDP-Lite [RFC3828], and DCCP [RFC4340]. 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]. 

   DCCP specifies a Service Code as a 4-byte value (32 bits). This 
   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. 

   The use of Service Codes can assist in identifying the correct 
   intended service when the server is located behind a NAT that 
   modifies the port numbers associated with a flow. 

   Middle-boxes (e.g. NATs, Firewalls) that desire to identify the type 
   of data being transported by a flow, can 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, also 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. 

   If an application does not set a Service Code, the connection is 
   associated with a Service Code of zero, with the intended server 
   identified only by the destination port number. 

 
 
Fairhurst             Expires September 2, 2007                [Page 3] 

Internet-Draft            DCCP Service Codes                 March 2007 
    

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










































 
 
Fairhurst             Expires September 2, 2007                [Page 4] 

Internet-Draft            DCCP Service Codes                 March 2007 
    

2. An Architecture for supporting 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. Section 3 describes the use of 
   Service Codes by end hosts and network middleboxes. 

2.1. IANA Port Numbers 

   In DCCP, 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 de-multiplexing function.  

   Like DCCP, most Internet Transport Protocols (e.g. TCP [RFC793], UDP 
   [RFC768]) also define publicly-known ports for most services, whether 
   intended for public access (e.g., telnet, DNS) or for services 
   typically used between pre-arranged pairs (e.g., X11, SSL). In TCP 
   and UDP these are the primary means of identifying the required 
   service when a connection request is received. 

   The Internet Assigned Numbers Authority currently manages the set of 
   globally reserved port numbers [IANA]. 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 

   One challenge with the use of IANA-managed ports is that this 
   allocates ports globally, for all hosts on the public Internet, even 
   though the association between a port and a service is of interest 
   only to the end hosts participating in a connection. As a result, the 
   fixed space of port numbers is being globally reserved unnecessarily. 
   It is more useful to allocate this name space on a per-host basis 
   [ID.Portnames].  

   Well-known/Reserved DCCP ports are described in a separate IANA 
   registry [RFC4340]. This registry may also associate ports with a 
   pre-defined set of Service Codes (see section 2.2). 
 
 
Fairhurst             Expires September 2, 2007                [Page 5] 
 
Internet-Draft            DCCP Service Codes                 March 2007 
    

   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]. Such methods 
   may also be applicable to IETF-defined transport protocols, including 
   DCCP. 

2.2. DCCP Service Code Values 

   DCCP specifies a 4 byte Service Code [RFC4340]. Service codes may be 
   represented in one of three forms: as a decimal number (the canonical 
   method), as a 4 character ASCII string, or as a hexadecimal number.  

   The Service Code identifies the application-level service to which a 
   client application wishes to connect. It is present only in DCCP-
   Request and DCCP-Response packets and 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. 

   One method of operation is to assign one Service Code per Port, 
   although multiple applications may be permitted on the same port (if 
   a Server implementation permits this).  

   Service Codes allow a larger number of concurrent connections for a 
   particular service than possible using well-known port numbers, by 
   allowing endpoints to allocate their own port numbers separately, 
   based on services they deploy (c.f. section 2.1). 

2.3. Zero Service Code  

   A Service Code value of zero indicates that the Service Code function 
   is not used by a client. A server uses only the destination port 
   number to identify the required application (as in section 2.1). 

2.4. Reception of a DCCP-Request with a bound Service Code 

   A Service Code value may be associated by the client (initiator of 
   the DCCP-Request), and is used by the server (recipient of the DCCP-
   Request) to associate the connection with the corresponding 
   application. This association MUST be explicit (i.e. the requested 
   Service Code MUST have been previously bound to the destination port 
   at the server). Once connected, the server returns a copy of the 
 
 
Fairhurst             Expires September 2, 2007                [Page 6] 

Internet-Draft            DCCP Service Codes                 March 2007 
    

   Service Code in the DCCP-Response packet completing the initial 
   handshake [RFC4340]. 

2.5. Reception of a DCCP-Request with an unbound Service Code 

   DCCP defines a number of possible error conditions that may arise in 
   processing of a Connection Request: 

   o  Connection Refused (Invalid port) 

   o  Too Busy (Service Code/Port may be valid) 

   o  Bad Service Code (Invalid Service Code for specified port) 

   Reception of a DCCP-Request with an invalid destination port MUST 
   result in the DCCP-Request being rejected, and sending a DCCP-Reset 
   with Reset Code "Connection Refused". A server MAY also use the Reset 
   Code "Too Busy" ([RFC4340], 8.1.3). 

   Reception of a DCCP-Request for a port number where the Service Code 
   that is not bound MUST result in the DCCP-Request being rejected, and 
   returning a DCCP-Reset with Reset Code "Bad Service Code" ([RFC4340], 
   8.1.2). 

2.6. SDP for describing Service Codes 

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

2.7. Service Code Registry 

   The set of 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]. 
   Service Code bindings to Ports may also be defined in the IANA DCCP 
   Port Registry. 

    

    

3. Use of the DCCP Service Code 

   Like UDP, DCCP uses port numbers to demultiplex connections. Upon 
   receipt of a DCCP-Request including the Service Code, the Code is 
   matched against a list of available services.  
 
 
Fairhurst             Expires September 2, 2007                [Page 7] 

Internet-Draft            DCCP Service Codes                 March 2007 
    

3.1. Setting Service Codes at the Sender 

   Applications SHOULD specify an appropriate Service Code when sending 
   a DCCP-Request packet. Valid Service Codes should 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.). An application that does not set a Service Code, 
   SHOULD be associated with a Service Code value of zero. 

3.2. Using Service Codes in the Network 

   Port numbers and IP addresses are the accepted methods to identify a 
   flow within an IP network. When the DCCP header has not been 
   encrypted, Middleboxes [RFC3234], such as firewalls, can instead use 
   the Service Code to identify the application (even when running on a 
   non-standard port). Middlebox devices are therefore expected to check 
   Service Code values before port numbers for DCCP. The Service Code 
   values on DCCP-Requests should be used for supplementary checks 
   [RFC4340]. Section 4.1 describes some issues that may arise in this 
   case. 

   The use of the DCCP Service Code can potentially lead to interactions 
   with other protocols that interpret or modify DCCP port numbers. This 
   includes IPsec and other firewall systems, other security mechanisms, 
   other in-band exchange of port numbers, and network address 
   translators (NATs).  

   Network address and port translators, known collectively as NATs, not 
   only interpret DCCP ports, but may also translate/modify them 
   [RFC2993]. This interferes with the use of ports for service 
   identification [RFC3234]. The DCCP Service Code may allow services to 
   be identified behind NATs if NATs are not further extended to 
   translate Service Codes. Middleboxes should not modify the Service 
   Code unless they change the service that a connection is accessing.  

   DCCP connections identified by the Service Code continue to use IP 
   addresses and ports, although neither port number may be well-
   known/reserved. Translation of these ports need to be considered in 
   the operation of NATs. In addition, DCCP Service Codes can reduce the 
   need to correctly interpret port numbers, leading to new 
   opportunities for network address and port translators.  

3.3. Using Service Codes at the Receiver 

   An implementation MUST allow a server application to bind to a 
   Service Code on a fixed port. The Service Code of zero may be the 
   default, indicating that no specific Service Code is in use. 
 
 
Fairhurst             Expires September 2, 2007                [Page 8] 

Internet-Draft            DCCP Service Codes                 March 2007 
    

   An implementation MAY allow server applications to bind to a Service 
   Code specifying a set of acceptable ports. 

   The DCCP Service Codes associates a DCCP Connection with the service 
   that the client expects to be running at the server.  This value MUST 
   take precedence over any service bound to the port number. Two cases 
   can occur: 

   o  When a DCCP-Request packet is received with a Service Code value 
      of zero, the connection is associated with an application using 
      the destination port number specified in the DCCP-Request. If 
      there is no specific application associated with the destination 
      port, then the connection MUST be aborted and a DCCP-RESET packet 
      is returned. If the port is not associated with a zero Service 
      Code, then the connection is aborted. 

   o  A DCCP-Request that is received with a non-zero Service Code MUST 
      be checked to validate that the server has associated the Service 
      Code with the specified destination port. If the Service Code is 
      associated with the port, the corresponding server application is 
      used. If there is no associated application, the server MUST abort 
      the connection by issuing a DCCP-Reset with the reset code "Bad 
      Service Code". 

3.4. Multiple Associations of Service Codes and Ports at the Sender 

   A single Service Code MAY be bound to more than one destination port 
   (wildcarding a set of port values). Also a single destination port 
   MAY be bound to multiple Service Codes (wildcarding a set of Service 
   Codes), although an active connection may only be associated with a 
   single Service Code [RFC4340].   

   o  An end host implementation may provide a method that only allows a 
      single Service Code to be associated with each listening port. 
      This means that a single port may be used only for a pre-specified 
      service; however this service does not need to be permanently 
      running at the Server. The arrival of a DCCP-Request may therefore 
      require launching an application to accept messages from the DCCP 
      connection. This operation could resemble that of "portmapper" or 
      "inetd". 







 
 
Fairhurst             Expires September 2, 2007                [Page 9] 

Internet-Draft            DCCP Service Codes                 March 2007 
    

   o  When a Connection Request is received with a port number that is 
      associated with multiple Service Codes, the listening server needs 
      to provide a method to ensure that the DCCP-Request is associated 
      with an application server that handles the corresponding Service 
      Code. This may require launching an application to accept messages 
      from the DCCP connection. This use 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 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 server MUST abort the 
   connection and send a DCCP Reset message. 

3.5. Summary of Service Code and Port Handling 

   The basic operation of the Service Codes is as follows: 

   o  A source host may issue a DCCP-Request with a Service Code of zero 
      and chooses either a well-known/reserved destination port or a 
      port number announced by some other means. 

   o  A source host may issue a DCCP-Request with a non-zero Service 
      Code and chooses a destination port number that is associated with 
      the specified Service Code at the destination. 

   o  The destination host, upon receiving a DCCP-Request with a zero 
      Service Code, validates that the port supports a Service Code of 
      zero and then uses the destination port to identify the associated 
      server. 

   o  The destination host, upon receiving a DCCP-Request with a non-
      zero Service Code, determines whether an available service 
      matching the Service Code is supported for the specified 
      destination port.  

   o  If the service is available, the session is associated with a 
      corresponding server, and a DCCP-Response is returned. 

   o  If the service is not available, the session is aborted and a 
      DCCP-Reset packet is returned. 

    



 
 
Fairhurst             Expires September 2, 2007               [Page 10] 

Internet-Draft            DCCP Service Codes                 March 2007 
    

4. Implementation Support for Service Codes 

   This document does not define how to implement Service Codes on a 
   particular platform or using a specific operating system. It does 
   define three levels of support that may be offered. 

   >>> This section needs further work, ideas are welcome! <<< 

4.1. Minimal Support 

   All Servers MUST be capable of accepting a DCCP-Request that contains 
   a zero Service Code. These may be handled in the same way as other 
   transport connections (e.g. UDP, TCP). In this level, a DCCP-Request 
   with a non-zero Service Code MUST result in the connection being 
   aborted. This limits interoperability with other levels. This model 
   is suitable for platforms with limited capability, but is NOT 
   RECOMMENDED for general use.  

4.2. Standard Support 

   In this level of support, a server MAY accept a DCCP-Request that 
   contains a zero Service Code. Each Service Code specified in a DCCP-
   Request message is checked against an internal database to determine 
   the permitted port range that may be associated with the Service 
   Code. This model is RECOMMENDED for general use. 

   The design could be simplified if one Default Service code were to be 
   associated with a set of specific well-known ports, allowing a port 
   to be mapped via a library or operating system function to their 
   default Service Code (simplifying the binding). Such a system needs 
   however also MUST provide a way to allow a sending and/or receiving 
   application to bind to a none-default Service Code (specified by the 
   application). It should also be noted that some higher layer 
   protocols are not associated with a single well-known port and that 
   they must therefore use this latter method. 

4.3. Enhanced Support 

   A server operating at the enhanced level provides finer and more 
   flexible control of the use of Service Codes and Port numbers. This 
   permits a receiver to accept DCCP-Requests with arbitrary mappings 
   between Service Codes and port ranges, associating each connection 
   with the appropriate application server. This level of support may 
   require operating systems to use a modified process to handle in-
   coming DCCP requests and may allow policies to be defined. 

    
 
 
Fairhurst             Expires September 2, 2007               [Page 11] 
 
Internet-Draft            DCCP Service Codes                 March 2007 
    

5. Changes required to the API to support Service Codes 

   The use of Service Codes requires an API that allows a service to 
   bind to a Service Code as well as 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 select a specific port number where 
      desired. 

   o  Extend the existing socket parameterization command (e.g., Unix 
      setsockopt()) to set a service-code option. 

   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. 

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

   XXX End Author Note. 

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

 
 
Fairhurst             Expires September 2, 2007               [Page 12] 
   
Internet-Draft            DCCP Service Codes                 March 2007 
    

   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. Service Code Registry 

   The set of 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]. 
   Service Code bindings to Ports may also be defined in the IANA DCCP 
   Port Registry. 

    

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

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

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

7.3. Character generator 

   The operation of the DCCP chargen service corresponds to the 
   connection-based TCP chargen protocol [RFC864]: A server listens for 
 
 
Fairhurst             Expires September 2, 2007               [Page 13] 
 
Internet-Draft            DCCP Service Codes                 March 2007 
    

   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.  

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

7.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 September 2, 2007               [Page 14] 

Internet-Draft            DCCP Service Codes                 March 2007 
    

8. 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. Interaction with IPsec and DTLS security (see section 4.1, on use 
      of IPsec). 

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

   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. 

 

8.1. Interactions of Service Codes and port numbers 

   The Service Code value may be used to over-ride the traditional way 
   that 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 potentially 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 point 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 the 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 September 2, 2007               [Page 15] 

Internet-Draft            DCCP Service Codes                 March 2007 
    

9. IANA Considerations 

   A set of new services are defined in section 6 and are summarized in 
   this section. 

9.1. Port number values allocated by this document 

   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] 
    

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

    +----------+------+----+-------------------------------+----------+ 
    | Service  | ASCII|Port|          Description          |   Ref    | 
    | Code (SC)| Code |    |                               |          | 
    +----------+------+----+-------------------------------+----------+ 
    |0x4543484f| ECHO |   7| Echo service                  | [RFC862] | 
    |0x4454494d| DTIM |  13| Daytime server                | [RFC867] | 
    |0x43484152| CHAR |  19| Character generator (chargen) | [RFC864] | 
    |0x54494d45| TIME |  37| Timeserver                    | [RFC868] | 
    |0x50455246| PERF |5001| Performance tests (e.g.       | *        | 
    |          |      |    | iperf, ttcp, ...)             |          | 
    +----------+------+----+-------------------------------+----------+ 
     Table 1: Allocation of Service Codes by this document. 


 
 
Fairhurst             Expires September 2, 2007               [Page 16] 
 
Internet-Draft            DCCP Service Codes                 March 2007 
    

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

    
10. Conclusions 

   This document discusses the operation of service codes by the DCCP 
   transport protocol [RFC4340] and motivates their use. The document 
   augments and clarifies the way in which DCCP applications should use 
   the Service Code Feature. It does not update or obsolete the protocol 
   defined in RFC4340. 

   Service Codes, or similar concepts may also be useful to other IETF 
   Transport Protocols [ID.Portnames]). 

    

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













 
 
Fairhurst             Expires September 2, 2007               [Page 17] 
    
Internet-Draft            DCCP Service Codes                 March 2007 
    

12. References 

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

12.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-01.txt.  

   [ID.DCCP.RTP] C. Perkins, "RTP and the Datagram Congestion Control 
             Protocol (DCCP)", IETF Work in Progress, draft-ietf-dccp-
             rtp-01.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 September 2, 2007               [Page 18] 
 
Internet-Draft            DCCP Service Codes                 March 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. 

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

   [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 September 2, 2007               [Page 19] 

Internet-Draft            DCCP Service Codes                 March 2007 
    

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

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. 

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 September 2, 2007               [Page 20] 

Internet-Draft            DCCP Service Codes                 March 2007 
    

    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 September 2, 2007               [Page 21] 

Internet-Draft            DCCP Service Codes                 March 2007 
    

   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 
























 
 
Fairhurst             Expires September 2, 2007               [Page 22]