doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc5595.txt b/doc/rfc/rfc5595.txt
new file mode 100644
index 0000000..64a7e06
--- /dev/null
+++ b/doc/rfc/rfc5595.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                       G. Fairhurst
+Request for Comments: 5595                        University of Aberdeen
+Updates: 4340                                             September 2009
+Category: Standards Track
+
+
+     The Datagram Congestion Control Protocol (DCCP) Service Codes
+
+Abstract
+
+   This document describes the usage of Service Codes by the Datagram
+   Congestion Control Protocol, RFC 4340.  It motivates the setting of a
+   Service Code 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).  This document updates the specification provided in RFC
+   4340.
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright and License Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+
+
+
+Fairhurst                   Standards Track                     [Page 1]
+
+RFC 5595                   DCCP Service Codes             September 2009
+
+
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. History ....................................................3
+      1.2. Conventions Used in This Document ..........................6
+   2. An Architecture for Service Codes ...............................6
+      2.1. IANA Port Numbers ..........................................6
+      2.2. DCCP Service Code Values ...................................7
+           2.2.1. New Versions of Applications or Protocols ...........8
+      2.3. Service Code Registry ......................................8
+      2.4. Zero Service Code ..........................................9
+      2.5. Invalid Service Code .......................................9
+      2.6. SDP for Describing Service Codes ...........................9
+      2.7. A Method to Hash the Service Code to a Dynamic Port ........9
+   3. Use of the DCCP Service Code ...................................10
+      3.1. Setting Service Codes at the Client .......................11
+      3.2. Using Service Codes in the Network ........................11
+      3.3. Using Service Codes at the Server .........................12
+           3.3.1. Reception of a DCCP-Request ........................13
+           3.3.2. Multiple Associations of a Service Code
+                  with Ports .........................................14
+           3.3.3. Automatically Launching a Server ...................14
+   4. Security Considerations ........................................14
+      4.1. Server Port Number Reuse ..................................15
+      4.2. Association of Applications with Service Codes ............15
+      4.3. Interactions with IPsec ...................................15
+   5. IANA Considerations ............................................16
+   6. Acknowledgments ................................................16
+   7. References .....................................................17
+      7.1. Normative References ......................................17
+      7.2. Informative References ....................................17
+
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst                   Standards Track                     [Page 2]
+
+RFC 5595                   DCCP Service Codes             September 2009
+
+
+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 the standard profile, e.g., [RTP-DCCP])
+   to be used at the application layer.  It is not intended to be used
+   to specify a variant of an application or a specific variant of a
+   protocol (Section 2.2).
+
+   The Service Code mechanism allows an application to declare the set
+   of services that are associated with server port numbers.  This can
+   affect how an application interacts with DCCP.  It also allows
+   decoupling of the role of port numbers to indicate a desired service
+   from the role of port numbers in demultiplexing and state management.
+   A DCCP application identifies the requested service by the Service
+   Code value in a DCCP-Request packet.  Each application therefore
+   associates one or more Service Codes with each listening port
+   ([RFC4340], Section 8.1.2).
+
+   The use of Service Codes can assist in identifying the intended
+   service by a firewall and may assist other middleboxes (e.g., a proxy
+   server or network address translator (NAT) [RFC2663]).  Middleboxes
+   that desire to identify the type of data a flow claims to transport
+   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) than deriving this information from
+   the server port value.
+
+   The more flexible use of server ports can also offer benefits to
+   applications where servers need to handle very large numbers of
+   simultaneous-open ports to the same service.
+
+   RFC 4340 omits a description of the motivation behind Service Codes,
+   and it does not properly describe how Well Known and Registered
+   server ports relate to Service Codes.  The intent of this document is
+   to clarify these issues.
+
+   RFC 4340 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.1.  History
+
+   It is simplest to understand the motivation for defining Service
+   Codes by describing the history of the DCCP protocol.
+
+
+
+
+Fairhurst                   Standards Track                     [Page 3]
+
+RFC 5595                   DCCP Service Codes             September 2009
+
+
+   Most current Internet transport protocols (TCP [RFC793], UDP
+   [RFC768], SCTP (the Stream Control Transmission Protocol) [RFC4960],
+   and UDP-Lite [RFC3828]) use "Published" port numbers from the Well
+   Known or Registered number spaces [RFC814].  These 16-bit values
+   indicate the application service associated with a connection or
+   message.  The server port must be known to the client to allow a
+   connection to be established.  This may be achieved using out-of-band
+   signalling (e.g., described using SDP [RFC4566]), but more commonly a
+   Published 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 Published [RFC1122] involves registration
+   with the Internet Assigned Numbers Authority (IANA), which includes
+   defining a service by a unique keyword and reserving a port number
+   from among a fixed pool [IANA].
+
+   In the earliest draft of DCCP, the authors wanted to address the
+   issue of Published ports in a future-proof manner, since this method
+   suffers from several problems:
+
+   o  The port space is not sufficiently large for ports to be easily
+      allocated (e.g., in an unregulated manner).  Thus, many
+      applications operate using unregistered ports, possibly colliding
+      with use by other applications.
+
+   o  The use of port-based firewalls encourages application writers to
+      disguise one application as another in an attempt to bypass
+      firewall filter rules.  This motivates firewall writers to use
+      deep packet inspection in an attempt to identify the service
+      associated with a port number.
+
+   o  ISPs often deploy transparent proxies, primarily to improve
+      performance and reduce costs.  For example, TCP requests destined
+      to TCP port 80 are often redirected to a web proxy.
+
+   These issues are coupled.  When applications collide on the same
+   Published-but-unregistered port, there is no simple way for network
+   security equipment to tell them apart, and thus it is likely that
+   problems will be introduced through the interaction of features.
+
+   There is little that a transport protocol designer can do about
+   applications that attempt to masquerade as other applications.  For
+   ones that are not attempting to hide, the problem may be simply that
+   they cannot trivially obtain a Published port.  Ideally, it should be
+   sufficiently easy that every application writer can request a Well
+   Known or Registered port and receive one instantly with no questions
+   asked.  The 16-bit port space traditionally used is not large enough
+   to support such a trivial allocation of ports.
+
+
+
+
+Fairhurst                   Standards Track                     [Page 4]
+
+RFC 5595                   DCCP Service Codes             September 2009
+
+
+   Thus, the designers of DCCP sought an alternative solution.  The idea
+   was simple.  A 32-bit server port space should be sufficiently large
+   to enable use of very simple allocation policies.  However, overhead
+   considerations made a 32-bit port value undesirable (DCCP needed to
+   be useful for low-rate applications).
+
+   The solution in DCCP to this problem was to use a 32-bit Service Code
+   [RFC4340] that is included only in the DCCP-Request packet.  The use
+   of a 32-bit value was intended to make it trivially simple to obtain
+   a unique value for each application.  Placing the value in a DCCP-
+   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.
+
+   Early discussion of the DCCP protocol considered an alternative to
+   the use of traditional ports; instead, it was suggested that a client
+   use a 32-bit identifier to uniquely identify each connection and that
+   the server listen on a socket bound only to a Service Code.  This
+   solution was unambiguous; the Service Code was the only identifier
+   for a listening socket at the server side.  The DCCP client included
+   a Service Code in the request, allowing it to reach the corresponding
+   listening application.  One downside was that this prevented
+   deployment of two servers for the same service on a single machine,
+   something that is trivial with ports.  The design also suffered from
+   the downside of being sufficiently different from existing protocols
+   that there were concerns that it would hinder the use of DCCP through
+   NATs and other middleboxes.
+
+   RFC 4340 abandoned the use of a 32-bit connection identifier in favor
+   of two traditional 16-bit port values, one chosen by the server and
+   one by the client.  This allows middleboxes to utilize similar
+   techniques for DCCP, UDP, TCP, etc.  However, it introduced a new
+   problem: "How does the server port relate to the Service Code?"  The
+   intent was that the Service Code identified the application or
+   protocol using DCCP, providing middleboxes with information about the
+   intended use of a connection, and that the pair of ports effectively
+   formed a 32-bit connection identifier, which was unique between a
+   pair of end systems.
+
+   The large number of available, unique Service Code values allows all
+   applications to be assigned a unique Service Code.  However, there
+   remained a problem: the server port was chosen by the server, but the
+   client needed to know this port to establish a connection.  It was
+   undesirable to mandate out-of-band communication to discover the
+   server port.  The chosen solution was to register DCCP server ports.
+   The limited availability of DCCP server ports appears to contradict
+   the benefits of DCCP Service Codes because, although it may be
+
+
+
+Fairhurst                   Standards Track                     [Page 5]
+
+RFC 5595                   DCCP Service Codes             September 2009
+
+
+   trivial to obtain a Service Code, it has not traditionally been
+   trivial to obtain a Registered port from IANA and, in the long-run,
+   it may not be possible to allocate a unique Registered DCCP port to
+   new applications.  As port numbers become scarce, this motivates the
+   need to associate more than one Service Code with a listening port
+   (e.g., two different applications could be assigned the same server
+   port and need to run on the same host at the same time,
+   differentiated by their different associated Service Codes).
+
+   Service Codes provide flexibility in the way clients identify the
+   server application to which they wish to communicate.  The mechanism
+   allows a server to associate a set of server ports with a service.
+   The set may be common with other services available at the same
+   server host, allowing a larger number of concurrent connections for a
+   particular service than possible when the service is identified by a
+   single Published port number.
+
+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].
+
+2.  An Architecture for Service Codes
+
+   DCCP defines the use of a combination of ports and Service Codes to
+   identify the server application ([RFC4340], Section 8.1.2).  These
+   are described in the following sections.
+
+2.1.  IANA Port Numbers
+
+   In DCCP, the packets belonging to a connection are demultiplexed
+   based on a combination of four values {source IP address, source
+   port, dest IP address, dest port}, as in TCP.  An endpoint address is
+   associated with a port number (e.g., forming a socket) and a pair of
+   associations uniquely identifies each connection.  Ports provide the
+   fundamental per-packet demultiplexing 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", is
+   traditionally in the range 49152-65535 and also includes the range
+   1024-49151.  The value used for the ephemeral port is usually chosen
+   by the client operating system.  It has been suggested that a
+   randomized choice port number value can help defend against "blind"
+   attacks [Rand] in TCP.  This method may be applicable to other IETF-
+   defined transport protocols, including DCCP.
+
+
+
+
+Fairhurst                   Standards Track                     [Page 6]
+
+RFC 5595                   DCCP Service Codes             September 2009
+
+
+   Traditionally, the destination (server) port value associated with a
+   service is determined either by an operating system index that points
+   to a copy of the IANA table (e.g., getportbyname() in Unix, which
+   indexes the /etc/services file) or by the application specifying a
+   direct mapping.
+
+   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, and
+
+   o  49152..65535 "Dynamic", also called "private" ports.
+
+   DCCP supports Well Known and Registered ports.  These are allocated
+   in the DCCP IANA Port Numbers registry ([RFC4340], Section 19.9).
+   Each Registered DCCP port MUST be associated with at least one pre-
+   defined Service Code.
+
+   Applications that do not need to use a server port in the Well Known
+   or Registered range SHOULD use a Dynamic server port (i.e., one not
+   required to be registered in the DCCP Port registry).  Clients can
+   identify the server port value for the services to which they wish to
+   connect using a range of methods.  One common method is by reception
+   of an SDP record (Section 2.6) exchanged out-of-band (e.g., using SIP
+   [RFC3261] or the Real Time Streaming Protocol (RTSP) [RFC2326]).  DNS
+   SRV resource records also provide a way to identify a server port for
+   a particular service based on the service's string name [RFC2782].
+
+   Applications that do not use out-of-band signalling can still
+   communicate, provided that both client and server agree on the port
+   value to be used.  This eliminates the need for each registered
+   Service Code to be allocated to an IANA-assigned server port (see
+   also Section 2.7).
+
+2.2.  DCCP Service Code Values
+
+   DCCP specifies a 4-byte Service Code ([RFC4340], Section 8.1.2)
+   represented in one of three forms: a decimal number (the canonical
+   method), a 4-character ASCII string [ANSI.X3-4.1986], or an 8-digit
+   hexadecimal number.  All standards assigned Service Codes, including
+   all values assigned by IANA, are required to use a value that may be
+   represented using a subset of the ASCII character set.  Private
+   Service Codes do not need to follow this convention, although RFC
+   4340 suggests that users choose Service Codes that may also be
+   represented in ASCII.
+
+
+
+
+Fairhurst                   Standards Track                     [Page 7]
+
+RFC 5595                   DCCP Service Codes             September 2009
+
+
+   The Service Code identifies the application-level service to which a
+   client application wishes to connect.  For example, services have
+   been defined for the Real-Time Protocol (RTP) [RTP-DCCP].  In a
+   different example, Datagram Transport Layer Security (DTLS) [RFC5238]
+   provides a transport-service (not an application-layer service);
+   therefore, applications using DTLS are individually identified by a
+   set of corresponding Service Code values.
+
+   Endpoints MUST associate a Service Code with every DCCP socket
+   [RFC4340], both actively and passively opened.  The application will
+   generally supply this Service Code.  A single passive-listening port
+   may be associated with more than one Service Code value.  The set of
+   Service Codes could be associated with one or more server
+   applications.  This permits a 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).  In the
+   currently defined set of packet types, the Service Code value is
+   present only in DCCP-Request ([RFC4340], Section 5.2) and DCCP-
+   Response packets ([RFC4340], Section 5.3).  Note that new DCCP packet
+   types (e.g., [RFC5596]) could also carry a Service Code value.
+
+2.2.1.  New Versions of Applications or Protocols
+
+   Applications/protocols that provide version negotiation or indication
+   in the protocol operating over DCCP do not require a new server port
+   or new Service Code for each new protocol version.  New versions of
+   such applications/protocols SHOULD continue to use the same Service
+   Code.  If the application developers feel that the new version
+   provides significant new capabilities (e.g., that will change the
+   behavior of middleboxes), they MAY allocate a new Service Code
+   associated with the same or different set of Well Known ports.  If
+   the new Service Code is associated with a Well Known or Registered
+   port, the DCCP Ports registry MUST also be updated to include the new
+   Service Code value, but MAY share the same server port assignment(s).
+
+2.3.  Service Code Registry
+
+   The set of registered Service Codes specified for use within the
+   general Internet are defined in an IANA-controlled name space.  IANA
+   manages new allocations of Service Codes in this space [RFC4340].
+   Private Service Codes are not centrally allocated and are denoted by
+   the decimal range 1056964608-1073741823 (i.e., 32-bit values with the
+   high-order byte equal to a value of 63, corresponding to the ASCII
+   character '?').
+
+   Associations of Service Code with Well Known ports are also defined
+   in the IANA DCCP Port registry (Section 2.1).
+
+
+
+
+Fairhurst                   Standards Track                     [Page 8]
+
+RFC 5595                   DCCP Service Codes             September 2009
+
+
+2.4.  Zero Service Code
+
+   A Service Code of zero is "permanently reserved (it represents the
+   absence of a meaningful Service Code)" [RFC4340].  This indicates
+   that no application information was provided.  RFC 4340 states that
+   applications MAY be associated with this Service Code in the same way
+   as other Service Code values.  This use is permitted for any server
+   port.
+
+   This document clarifies Section 19.8 of RFC 4340 by adding the
+   following:
+
+      Applications SHOULD NOT use a Service Code of zero.
+
+      Application writers that need a temporary Service Code value
+      SHOULD choose a value from the private range (Section 2.3).
+
+      Applications intended for deployment in the Internet are
+      encouraged to use an IANA-defined Service Code.  If no specific
+      Service Code exists, they SHOULD request a new assignment from the
+      IANA.
+
+2.5.  Invalid Service Code
+
+   RFC 4340 defines the Service Code value of 4294967295 in decimal
+   (0xFFFFFFFF) as "invalid".  This is provided so implementations can
+   use a special 4-byte value to indicate "no valid Service Code".
+   Implementations MUST NOT accept a DCCP-Request with this value, and
+   SHOULD NOT allow applications to bind to this Service Code value
+   [RFC4340].
+
+2.6.  SDP for Describing Service Codes
+
+   Methods that currently signal destination port numbers, such as the
+   Session Description Protocol (SDP) [RFC4566], require an extension to
+   support DCCP Service Codes [RTP-DCCP].
+
+2.7.  A Method to Hash the Service Code to a Dynamic Port
+
+   Applications that do not use out-of-band signalling or an IANA-
+   assigned port still require both the client and server to agree on
+   the server port value to be used.  This section describes an optional
+   method that allows an application to derive a default server port
+   number from the Service Code.  The returned value is in the Dynamic
+   port range [RFC4340]:
+
+
+
+
+
+
+Fairhurst                   Standards Track                     [Page 9]
+
+RFC 5595                   DCCP Service Codes             September 2009
+
+
+     int s_port; /* server port */
+     s_port = ((sc[0]<<7)^(sc[1]<<5)^(sc[2]<<3)^sc[3]) | 0xC000;
+     if (s_port==0xFFFF) {s_port = 0xC000;}
+
+   where sc[] represents the 4 bytes of the Service Code, and sc[3] is
+   the least significant byte.  For example, this function associates
+   SC:fdpz with the server port 64634.
+
+   This algorithm has the following properties:
+
+   o  It identifies a default server port for each service.
+
+   o  It seeks to assign different Service Codes to different ports, but
+      does not guarantee an assignment is unique.
+
+   o  It preserves the 4 lowest bits of the final bytes of the Service
+      Code, which allows many common series of Service Codes to be
+      mapped to a set of adjacent port numbers, e.g., Foo1, and Foo2;
+      Fooa and Foob would be assigned adjacent ports.  (Note: this
+      consecutive numbering only applies to characters in the range 0-9
+      and A-O and P-Z.  When the characters cross a range boundary, the
+      algorithm introduces a discontinuity, resulting in mapping to
+      non-consecutive ports.  Hence, Fooo and Foop respectively map to
+      the decimal values of 65015 and 65000).
+
+   o  It avoids the port 0xFFFF, which is not accessible on all host
+      platforms.
+
+   Applications and higher-layer protocols that have been assigned a
+   Service Code (or use a Service Code from the unassigned private
+   space) may use this method.  It does not preclude other applications
+   using the selected server port, since DCCP servers are differentiated
+   by the Service Code value.
+
+3.  Use of the DCCP Service Code
+
+   The basic operation of Service Codes is as follows:
+
+   A client initiating a connection:
+
+      -  issues a DCCP-Request with a Service Code and chooses a
+         destination (server) port number that is expected to be
+         associated with the specified Service Code at the destination.
+
+
+
+
+
+
+
+
+Fairhurst                   Standards Track                    [Page 10]
+
+RFC 5595                   DCCP Service Codes             September 2009
+
+
+   A server that receives a DCCP-Request:
+
+      -  determines whether an available service matching the Service
+         Code is supported for the specified destination server port.
+         The session is associated with the Service Code and a
+         corresponding server.  A DCCP-Response is returned.
+
+      -  if the service is not available, the session is rejected and a
+         DCCP-Reset packet is returned.
+
+3.1.  Setting Service Codes at the Client
+
+   A client application MUST associate every DCCP connection (and hence
+   every DCCP active socket) with a single Service Code value
+   [RFC4340]).  This value is used in the corresponding DCCP-Request
+   packet.
+
+3.2.  Using Service Codes in the Network
+
+   DCCP connections identified by the Service Code continue to use IP
+   addresses and ports, although neither port number may be Published.
+
+   Port numbers and IP addresses are the traditional methods to identify
+   a flow within an IP network.  Middlebox [RFC3234] implementors
+   therefore need to note that new DCCP connections are identified by
+   the pair of server port and Service Code in addition to the IP
+   address.  This means that the IANA may allocate a server port to more
+   than one DCCP application [RFC4340].
+
+   Network address and port translators, known collectively as NATs
+   [RFC2663], may interpret DCCP ports ([RFC2993] and [RFC5597]).  They
+   may also interpret DCCP Service Codes.  Interpreting DCCP Service
+   Codes can reduce the need to correctly interpret port numbers,
+   leading to new opportunities for network address and port
+   translators.  Although it is encouraged to associate specific
+   delivery properties with the Service Code, e.g., to identify the
+   real-time nature of a flow that claims to be using RTP, there is no
+   guarantee that the actual connection data corresponds to the
+   associated Service Code.  A middlebox implementor may still use deep
+   packet inspection, and other means, in an attempt to verify the
+   content of a connection.
+
+   The use of the DCCP Service Code can potentially lead to interactions
+   with other protocols that interpret or modify DCCP port numbers
+   [RFC3234].  The following additional clarifications update the
+   description provided in Section 16 of RFC 4340:
+
+
+
+
+
+Fairhurst                   Standards Track                    [Page 11]
+
+RFC 5595                   DCCP Service Codes             September 2009
+
+
+      o  A middlebox that intends to differentiate applications SHOULD
+         test the Service Code in addition to the destination or source
+         port of a DCCP-Request or DCCP-Response packet.
+
+      o  A middlebox that does not modify the intended application
+         (e.g., NATs [RFC5597] and Firewalls) MUST NOT change the
+         Service Code.
+
+      o  A middlebox MAY send a DCCP-Reset in response to a packet with
+         a Service Code that is considered unsuitable.
+
+3.3.  Using Service Codes at the Server
+
+   The combination of the Service Code and server port disambiguates
+   incoming DCCP-Requests received by a server.  The Service Code is
+   used to associate a new DCCP connection with the corresponding
+   application service.  Four cases can arise when two DCCP server
+   applications passively listen on the same host:
+
+      o  The simplest case arises when two servers are associated with
+         different Service Codes and are bound to different server ports
+         (Section 3.3.1).
+
+      o  Two servers may be associated with the same DCCP Service Code
+         value but be bound to different server ports (Section 3.3.2).
+
+      o  Two servers could use different DCCP Service Code values and be
+         bound to the same server port (Section 3.3.1).
+
+      o  Two servers could attempt to use the same DCCP Service Code and
+         bind to the same server port.  A DCCP implementation MUST
+         disallow this, since there is no way for the DCCP host to
+         direct a new connection to the correct server application.
+
+   RFC 4340 (Section 8.1.2) states that an implementation:
+
+      o  MUST associate each active socket with exactly one Service Code
+         on a specified server port.
+
+   In addition, Section 8.1.2 of RFC 4340 also states:
+
+      o  Passive sockets MAY, at the implementation's discretion, be
+         associated with more than one Service Code; this might let
+         multiple applications, or multiple versions of the same
+         application, listen on the same port, differentiated by Service
+         Code.
+
+
+
+
+
+Fairhurst                   Standards Track                    [Page 12]
+
+RFC 5595                   DCCP Service Codes             September 2009
+
+
+   This document updates the above text from RFC 4340 by replacing it
+   with the following:
+
+      o  An implementation SHOULD allow more than one Service Code to be
+         associated with a passive server port, enabling multiple
+         applications, or multiple versions of an application, to listen
+         on the same port, differentiated by the associated Service
+         Code.
+
+   It also adds:
+
+      o  An implementation SHOULD provide a method that informs a server
+         of the Service Code value that was selected by an active
+         connection.
+
+   A single passively opened (listening) port MAY therefore 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 server port.  This may allow a server to
+   offer more than the limit of 65,536 services depending on the size of
+   the Port field.  The upper limit is based solely on the number of
+   unique connections between two hosts (i.e., 4,294,967,296).
+
+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 the Reset Code "Connection Refused".  A host MAY
+   also use the Reset Code "Too Busy" ([RFC4340], Section 8.1.3).
+
+   When the requested destination port is bound to a server, the host
+   MUST also verify that the server port is associated with the
+   specified Service Code (there could be multiple Service Code values
+   associated with the same server port).  Two cases can occur:
+
+   o  If the receiving host is listening on a server port and the DCCP-
+      Request uses a Service Code that is associated with the port, the
+      host accepts the connection.  Once connected, the server returns a
+      copy of the Service Code in the DCCP-Response packet, completing
+      the initial handshake [RFC4340].
+
+   o  If the server port is not associated with the requested Service
+      Code, the server SHOULD reject the request by sending a DCCP-Reset
+      packet with the Reset Code 8, "Bad Service Code" ([RFC4340],
+      Section 8.1.2), but MAY use the reason "Connection Refused".
+
+
+
+
+
+Fairhurst                   Standards Track                    [Page 13]
+
+RFC 5595                   DCCP Service Codes             September 2009
+
+
+   After a connection has been accepted, the protocol control block is
+   associated with a pair of ports, a pair of IP addresses, and a single
+   Service Code value.
+
+3.3.2.  Multiple Associations of a Service Code with Ports
+
+   DCCP Service Codes are not restricted to specific ports, although
+   they may be associated with a specific Well Known port.  This allows
+   the same DCCP Service Code value to be associated with more than one
+   server port (in either the active or passive state).
+
+3.3.3.  Automatically Launching a Server
+
+   A host implementation may permit a service to be associated with a
+   server port (or range of ports) that is not permanently running at
+   the server.  In this case, the arrival of a DCCP-Request may require
+   a method to associate a DCCP-Request with a server that handles the
+   corresponding Service Code.  This operation could resemble that of
+   "inetd" [inetd].
+
+   As in the previous section, when the specified Service Code is not
+   associated with the specified server port, the connection MUST be
+   aborted and a DCCP Reset message sent [RFC4340].
+
+4.  Security Considerations
+
+   The security considerations of RFC 4340 identify and offer guidance
+   on security issues relating to DCCP.  This document discusses the
+   usage of Service Codes.  It does not describe new protocol functions.
+
+   All IPsec modes protect the integrity of the DCCP header.  This
+   protects the Service Code field from undetected modification within
+   the network.  In addition, the IPsec Encapsulated Security Payload
+   (ESP) mode may be used to encrypt the Service Code field, hiding the
+   Service Code value within the network and also preventing
+   interpretation by middleboxes.  The DCCP header is not protected by
+   application-layer security (e.g., the use of DTLS [RFC5238] as
+   specified in DTLS/DCCP [RFC4347]).
+
+   There are four areas of security that are important:
+
+   1. Server Port number reuse (Section 4.1).
+
+   2. Interaction with NATs and firewalls (Section 3.2 describes
+      middlebox behavior).  Requirements relating to DCCP are described
+      in [RFC5597].
+
+
+
+
+
+Fairhurst                   Standards Track                    [Page 14]
+
+RFC 5595                   DCCP Service Codes             September 2009
+
+
+   3. Interpretation of DCCP Service Codes overriding traditional use of
+      reserved/Well Known port numbers (Section 4.2).
+
+   4. Interaction with IPsec and DTLS security (Section 4.3).
+
+4.1.  Server Port Number Reuse
+
+   Service Codes are used in addition to ports when demultiplexing
+   incoming connections.  This changes the service model to be used by
+   applications and middleboxes.  The Port Numbers registry already
+   contains instances of multiple application registrations for a single
+   port number for TCP and UDP.  These are relatively rare.  Since the
+   DCCP Service Code allows multiple applications to safely share the
+   same port number, even on the same host, server port number reuse in
+   DCCP may be more common than in TCP and UDP.
+
+4.2.  Association of Applications with Service Codes
+
+   The use of Service Codes provides more ready feedback that a concrete
+   service is associated with a given port on a server than for a
+   service that does not employ Service Codes.  By responding to an
+   inbound connection request, systems not using these codes may
+   indicate that some service is, or is not, available on a given port,
+   but systems using this mechanism immediately provide confirmation (or
+   denial) that a particular service is present.  This may have
+   implications in terms of port scanning and reconnaissance.
+
+   Care needs to be exercised when interpreting the mapping of a Service
+   Code value to the corresponding service.  The same service
+   (application) may be accessed using more than one Service Code.
+   Examples include the use of separate Service Codes for an application
+   layered directly upon DCCP and one using DTLS transport over DCCP
+   [RFC5238].  Other possibilities include the use of a private Service
+   Code to map to an application that has already been assigned an IANA-
+   defined Service Code value, or multiple Service Code values that map
+   to a single application providing more than one service.  Different
+   versions of a service (application) may also be mapped to a
+   corresponding set of Service Code values.
+
+   Processing of Service Codes may imply more processing than currently
+   associated with incoming port numbers.  Implementors need to guard
+   against increasing opportunities for Denial of Service attacks.
+
+4.3.  Interactions with IPsec
+
+   The Internet Key Exchange protocol (IKEv2) does not currently specify
+   a method to use DCCP Service Codes as a part of the information used
+   to set up an IPsec security association.
+
+
+
+Fairhurst                   Standards Track                    [Page 15]
+
+RFC 5595                   DCCP Service Codes             September 2009
+
+
+   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
+   within 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.
+
+5.  IANA Considerations
+
+   This document does not update the IANA allocation procedures for the
+   DCCP Port Number and DCCP Service Codes Registries as defined in RFC
+   4340.
+
+   For completeness, 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.  A specification is however required to
+   allocate a Service Code that uses a combination of ASCII digits,
+   uppercase letters, and character space, '-', '.', and '/') [RFC4340].
+
+6.  Acknowledgments
+
+   This work has been supported by the EC IST SatSix Project.
+   Significant contributions to this document resulted from discussion
+   with Joe Touch, and this is gratefully acknowledged.  The author also
+   thanks Ian McDonald, Fernando Gont, Eddie Kohler, and the DCCP WG for
+   helpful comments on this topic, and Gerrit Renker for his help in
+   determining DCCP behavior and review of this document.  Mark Handley
+   provided significant input to the text on the definition of Service
+   Codes and their usage.  He also contributed much of the material that
+   has formed the historical background section.
+
+
+
+
+
+
+
+
+
+Fairhurst                   Standards Track                    [Page 16]
+
+RFC 5595                   DCCP Service Codes             September 2009
+
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
+              Communication Layers", STD 3, RFC 1122, October 1989.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
+              Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
+
+   [RFC5597]  Denis-Courmont, R., "Network Address Translation (NAT)
+              Behavioral Requirements for the Datagram Congestion
+              Control Protocol", BCP 150, RFC 5597, September 2009.
+
+7.2.  Informative References
+
+   [ANSI.X3-4.1986]
+              American National Standards Institute, "Coded Character
+              Set - 7-bit American Standard Code for Information
+              Interchange", ANSI X3.4, 1986.
+
+   [IANA]     Internet Assigned Numbers Authority, www.iana.org.
+
+   [RTP-DCCP] Perkins, C., "RTP and the Datagram Congestion Control
+              Protocol (DCCP)", Work in Progress, June 2007.
+
+   [Rand]     Larsen, M. and F. Gont, "Port Randomization", Work in
+              Progress, March 2009.
+
+   [inetd]    The extended inetd project, http://xinetd.org.
+
+   [RFC768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+              August 1980.
+
+   [RFC793]   Postel, J., "Transmission Control Protocol", STD 7, RFC
+              793, September 1981.
+
+   [RFC814]   Clark, D., "Name, addresses, ports, and routes", RFC 814,
+              July 1982.
+
+   [RFC2326]  Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
+              Streaming Protocol (RTSP)", RFC 2326, April 1998.
+
+
+
+
+
+
+Fairhurst                   Standards Track                    [Page 17]
+
+RFC 5595                   DCCP Service Codes             September 2009
+
+
+   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
+              Translator (NAT) Terminology and Considerations", RFC
+              2663, August 1999.
+
+   [RFC2780]  Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
+              Values In the Internet Protocol and Related Headers", BCP
+              37, RFC 2780, March 2000.
+
+   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+              specifying the location of services (DNS SRV)", RFC 2782,
+              February 2000.
+
+   [RFC2993]  Hain, T., "Architectural Implications of NAT", RFC 2993,
+              November 2000.
+
+   [RFC3234]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
+              Issues", RFC 3234, February 2002.
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              June 2002.
+
+   [RFC3828]  Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed.,
+              and G. Fairhurst, Ed., "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]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+              Security", RFC 4347, April 2006.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, July 2006.
+
+   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
+              RFC 4960, September 2007.
+
+   [RFC5238]  Phelan, T., "Datagram Transport Layer Security (DTLS) over
+              the Datagram Congestion Control Protocol (DCCP)", RFC
+              5238, May 2008.
+
+   [RFC5596]  Fairhurst, G., "Datagram Congestion Control Protocol
+              (DCCP) Simultaneous-Open Technique to Facilitate
+              NAT/Middlebox Traversal", RFC 5596, September 2009.
+
+
+
+
+
+Fairhurst                   Standards Track                    [Page 18]
+
+RFC 5595                   DCCP Service Codes             September 2009
+
+
+Author's Address
+
+   Godred Fairhurst,
+   School of Engineering,
+   University of Aberdeen,
+   Kings College,
+   Aberdeen, AB24 3UE,
+   UK
+   EMail: gorry@erg.abdn.ac.uk
+   URL:   http://www.erg.abdn.ac.uk/users/gorry
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst                   Standards Track                    [Page 19]
+