Network Working Group                                       G. Fairhurst
Request for Comments: 5595                        University of Aberdeen
Updates: 4340                                             September 2009
Category: Standards Track
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




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.

本文档描述了数据报拥塞控制协议RFC 4340对服务代码的使用。它促使应用程序设置服务代码。服务代码提供了一种方法,用于识别处理DCCP连接请求的预期服务/应用程序。这提高了连接多路复用端口号的使用和分配的灵活性。使用DCCP服务代码还可以使服务与中间盒(例如,网络地址转换器和防火墙)进行更明确的协调。本文件更新了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.

本文件规定了互联网社区的互联网标准跟踪协议,并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态,请参考当前版本的“互联网官方协议标准”(STD 1)。本备忘录的分发不受限制。

Copyright and License Notice


Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2009 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( 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.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本,并且提供BSD许可中所述的代码组件时不提供任何担保。

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


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
   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
1. Introduction
1. 介绍

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省略了对服务代码背后动机的描述,并且没有正确地描述已知和注册的服务器端口与服务代码的关系。本文件旨在澄清这些问题。

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.

RFC 4340规定,服务代码并非特定于DCCP。因此,服务代码或类似概念也可用于其他IETF传输协议。

1.1. History
1.1. 历史

It is simplest to understand the motivation for defining Service Codes by describing the history of the DCCP protocol.


Most current Internet transport protocols (TCP [RFC793], UDP [RFC768], SCTP (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].

大多数当前的Internet传输协议(TCP[RFC793]、UDP[RFC768]、SCTP(流控制传输协议)[RFC4960]和UDP Lite[RFC3828])使用来自已知或注册数字空间[RFC814]的“已发布”端口号。这16位值表示与连接或消息关联的应用程序服务。客户端必须知道服务器端口,才能建立连接。这可以通过使用带外信令(例如,使用SDP[RFC4566]描述)来实现,但更常见的是,将发布的端口分配给特定的协议或应用;例如,HTTP通常使用端口80,SMTP通常使用端口25。发布端口号[RFC1122]涉及向互联网分配号码管理局(IANA)注册,其中包括通过唯一关键字定义服务和从固定池[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 端口空间不够大,无法轻松分配端口(例如,以不受监管的方式)。因此,许多应用程序使用未注册的端口运行,可能与其他应用程序的使用发生冲突。

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 使用基于端口的防火墙鼓励应用程序编写者将一个应用程序伪装成另一个应用程序,试图绕过防火墙过滤规则。这促使防火墙编写者使用深度数据包检查,试图识别与端口号关联的服务。

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.

o ISP通常部署透明代理,主要是为了提高性能和降低成本。例如,发送到TCP端口80的TCP请求通常被重定向到web代理。

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.


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.

RFC 4340放弃了使用32位连接标识符,转而使用两个传统的16位端口值,一个由服务器选择,一个由客户端选择。这允许中间盒使用类似的DCCP、UDP、TCP等技术。但是,它引入了一个新问题:“服务器端口与服务代码的关系如何?”其目的是服务代码使用DCCP识别应用程序或协议,为中间盒提供有关连接预期用途的信息,这对端口有效地形成了一个32位连接标识符,它在一对终端系统之间是唯一的。

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


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
1.2. 本文件中使用的公约

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

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。

2. An Architecture for Service Codes
2. 一种服务代码体系结构

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
2.1. IANA端口号

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.

在DCCP中,属于连接的数据包根据四个值的组合{source IP address,source port,dest IP address,dest port}被解复用,如在TCP中。端点地址与端口号关联(例如,形成套接字),一对关联唯一地标识每个连接。端口提供基本的每包解复用功能。

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.

Internet Assigned Numbers Authority当前管理一组全局保留端口号[IANA]。与连接请求相关联的源端口,通常称为“临时端口”,传统上在49152-65535范围内,并且还包括1024-49151范围。用于临时端口的值通常由客户端操作系统选择。有人建议,随机选择端口号值有助于抵御TCP中的“盲”攻击[Rand]。此方法可适用于其他IETF定义的传输协议,包括DCCP。

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 0..1023“众所周知”,也称为“系统”端口,

o 1024..49151 "Registered", also called "user" ports, and

o 1024..49151“已注册”,也称为“用户”端口,以及

o 49152..65535 "Dynamic", also called "private" ports.

o 49152..65535“动态”,也称为“专用”端口。

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.

DCCP支持众所周知的和注册的端口。这些在DCCP IANA端口号注册表中分配([RFC4340],第19.9节)。每个注册的DCCP端口必须至少与一个预定义的服务代码相关联。

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

不需要使用已知或已注册范围内的服务器端口的应用程序应使用动态服务器端口(即,不需要在DCCP端口注册表中注册的端口)。客户机可以使用一系列方法识别他们希望连接到的服务的服务器端口值。一种常用方法是通过接收带外交换的SDP记录(第2.6节)(例如,使用SIP[RFC3261]或实时流协议(RTSP)[RFC2326])。DNS SRV资源记录还提供了一种基于服务的字符串名称[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
2.2. DCCP服务代码值

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.

DCCP指定以三种形式之一表示的4字节服务代码([RFC4340],第8.1.2节):十进制数(规范方法)、4字符ASCII字符串[ANSI.X3-4.1986]或8位十六进制数。所有标准分配的服务代码,包括IANA分配的所有值,都需要使用可使用ASCII字符集子集表示的值。专用服务代码不需要遵循此约定,尽管RFC 4340建议用户选择也可以用ASCII表示的服务代码。

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
2.2.1. 应用程序或协议的新版本

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
2.3. 服务代码注册表

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

IANA DCCP端口注册表(第2.1节)中还定义了服务代码与已知端口的关联。

2.4. Zero Service Code
2.4. 零服务代码

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.

零的服务代码是“永久保留的(表示没有有意义的服务代码)”[RFC4340]。这表明未提供任何应用程序信息。RFC 4340指出,应用程序可能与此服务代码以与其他服务代码值相同的方式关联。任何服务器端口都允许此使用。

This document clarifies Section 19.8 of RFC 4340 by adding the following:

本文件通过添加以下内容澄清了RFC 4340第19.8节:

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
2.5. 无效的服务代码

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

RFC 4340将十进制(0xFFFFFFFF)的4294967295服务代码值定义为“无效”。这是为了实现可以使用一个特殊的4字节值来表示“没有有效的服务代码”。实现不能接受具有此值的DCCP请求,并且不应允许应用程序绑定到此服务代码值[RFC4340]。

2.6. SDP for Describing Service Codes
2.6. 用于描述服务代码的SDP

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
2.7. 将服务代码散列到动态端口的方法

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


     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;}
     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 它标识每个服务的默认服务器端口。

o It seeks to assign different Service Codes to different ports, but does not guarantee an assignment is unique.

o 它试图将不同的服务代码分配给不同的端口,但并不保证分配是唯一的。

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 它保留服务代码最后字节的4个最低位,这允许许多常见的服务代码系列映射到一组相邻的端口号,例如Foo1和Foo2;Fooa和Foob将被分配到相邻的端口。(注意:此连续编号仅适用于0-9、A-O和P-Z范围内的字符。当字符跨越范围边界时,算法引入不连续性,导致映射到非连续端口。因此,Fooo和Foop分别映射到65015和65000的十进制值)。

o It avoids the port 0xFFFF, which is not accessible on all host platforms.

o 它避免了端口0xFFFF,这在所有主机平台上都不可访问。

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
3. DCCP服务代码的使用

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.

- 发出带有服务代码的DCCP请求,并选择预期与目标处的指定服务代码关联的目标(服务器)端口号。

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.

- 确定指定的目标服务器端口是否支持与服务代码匹配的可用服务。会话与服务代码和相应的服务器相关联。将返回DCCP响应。

- if the service is not available, the session is rejected and a DCCP-Reset packet is returned.

- 如果服务不可用,则拒绝会话并返回DCCP重置数据包。

3.1. Setting Service Codes at the Client
3.1. 在客户端设置服务代码

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
3.2. 在网络中使用服务代码

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:

DCCP服务代码的使用可能会导致与解释或修改DCCP端口号的其他协议的交互[RFC3234]。以下附加澄清更新了RFC 4340第16节中提供的说明:

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 除DCCP请求或DCCP响应数据包的目标或源端口外,用于区分应用程序的中间盒还应测试服务代码。

o A middlebox that does not modify the intended application (e.g., NATs [RFC5597] and Firewalls) MUST NOT change the Service Code.

o 未修改预期应用程序(例如NAT[RFC5597]和防火墙)的中间盒不得更改服务代码。

o A middlebox MAY send a DCCP-Reset in response to a packet with a Service Code that is considered unsuitable.

o 中间盒可以发送DCCP重置,以响应具有被认为不合适的服务代码的分组。

3.3. Using Service Codes at the Server
3.3. 在服务器上使用服务代码

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 最简单的情况是,两台服务器与不同的服务代码关联,并绑定到不同的服务器端口(第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 两台服务器可能与相同的DCCP服务代码值关联,但绑定到不同的服务器端口(第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 两台服务器可以使用不同的DCCP服务代码值,并绑定到同一服务器端口(第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.

o 两台服务器可以尝试使用相同的DCCP服务代码并绑定到相同的服务器端口。DCCP实现必须禁止这种情况,因为DCCP主机无法将新连接定向到正确的服务器应用程序。

RFC 4340 (Section 8.1.2) states that an implementation:

RFC 4340(第8.1.2节)规定实施:

o MUST associate each active socket with exactly one Service Code on a specified server port.

o 必须将每个活动套接字与指定服务器端口上的一个服务代码关联。

In addition, Section 8.1.2 of RFC 4340 also states:

此外,RFC 4340第8.1.2节还规定:

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.

o 被动插座可由实现自行决定与多个服务代码相关联;这可能会让多个应用程序或同一应用程序的多个版本在同一端口上侦听,并根据服务代码进行区分。

This document updates the above text from RFC 4340 by replacing it with the following:

本文件更新了RFC 4340中的上述文本,将其替换为以下内容:

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.

o 一个实现应该允许多个服务代码与被动服务器端口相关联,从而使多个应用程序或应用程序的多个版本能够在同一端口上侦听,并通过关联的服务代码进行区分。

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.

o 实现应该提供一种方法,将活动连接选择的服务代码值通知服务器。

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
3.3.1. 接收DCCP请求

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

当接收到DCCP请求且指定的目标端口未绑定到服务器时,主机必须通过发出带有重置代码“connection Rejected”的DCCP重置来拒绝连接。主机也可使用重置代码“太忙”([RFC4340],第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 如果接收主机正在侦听服务器端口,并且DCCP请求使用与该端口关联的服务代码,则主机接受连接。一旦连接,服务器返回DCCP响应数据包中的服务代码副本,完成初始握手[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".

o 如果服务器端口与请求的服务代码不关联,服务器应通过发送带有重置代码8“坏服务代码”([RFC4340],第8.1.2节)的DCCP重置数据包来拒绝请求,但可以使用“连接被拒绝”的原因。

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
3.3.2. 服务代码与端口的多个关联

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
3.3.3. 自动启动服务器

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
4. 安全考虑

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.

RFC 4340的安全注意事项确定了与DCCP相关的安全问题并提供了指导。本文档讨论服务代码的使用。它没有描述新的协议功能。

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

1. 服务器端口号重用(第4.1节)。

2. Interaction with NATs and firewalls (Section 3.2 describes middlebox behavior). Requirements relating to DCCP are described in [RFC5597].

2. 与NAT和防火墙的交互(第3.2节描述了中间盒行为)。[RFC5597]中描述了与DCCP相关的要求。

3. Interpretation of DCCP Service Codes overriding traditional use of reserved/Well Known port numbers (Section 4.2).

3. DCCP服务代码的解释覆盖了保留/已知端口号的传统使用(第4.2节)。

4. Interaction with IPsec and DTLS security (Section 4.3).

4. 与IPsec和DTLS安全性的交互(第4.3节)。

4.1. Server Port Number Reuse
4.1. 服务器端口号重用

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
4.2. 应用程序与服务代码的关联

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


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
5. IANA考虑

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

本文件不更新RFC 4340中定义的DCCP端口号和DCCP服务代码注册表的IANA分配程序。

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
6. 致谢

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.

这项工作得到了EC IST SatSix项目的支持。与Joe Touch的讨论对本文件做出了重大贡献,对此表示感谢。作者还感谢Ian McDonald、Fernando Gont、Eddie Kohler和DCCP工作组对此主题的有益评论,以及Gerrit Renker在确定DCCP行为和审查本文件方面的帮助。Mark Handley在服务代码的定义及其使用方面为文本提供了重要的输入。他还贡献了构成历史背景部分的许多材料。

7. References
7. 工具书类
7.1. Normative References
7.1. 规范性引用文件

[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.

[RFC1122]Braden,R.,Ed.“互联网主机的要求-通信层”,STD 3,RFC 1122,1989年10月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.

[RFC4340]Kohler,E.,Handley,M.和S.Floyd,“数据报拥塞控制协议(DCCP)”,RFC 43402006年3月。

[RFC5597] Denis-Courmont, R., "Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol", BCP 150, RFC 5597, September 2009.

[RFC5597]Denis Courmont,R.,“数据报拥塞控制协议的网络地址转换(NAT)行为要求”,BCP 150,RFC 5597,2009年9月。

7.2. Informative References
7.2. 资料性引用

[ANSI.X3-4.1986] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.

[ANSI.X3-4.1986]美国国家标准协会,“编码字符集-信息交换用7位美国标准代码”,ANSI X3.41986。

[IANA] Internet Assigned Numbers Authority,


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


[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.

[RFC768]Postel,J.,“用户数据报协议”,STD 6,RFC 768,1980年8月。

[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[RFC793]Postel,J.,“传输控制协议”,标准7,RFC 793,1981年9月。

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


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

[RFC2663]Srisuresh,P.和M.Holdrege,“IP网络地址转换器(NAT)术语和注意事项”,RFC 2663,1999年8月。

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

[RFC2780]Bradner,S.和V.Paxson,“互联网协议和相关报头中值的IANA分配指南”,BCP 37,RFC 2780,2000年3月。

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

[RFC2782]Gulbrandsen,A.,Vixie,P.和L.Esibov,“用于指定服务位置(DNS SRV)的DNS RR”,RFC 2782,2000年2月。

[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.

[RFC2993]Hain,T.,“NAT的建筑含义”,RFC 29932000年11月。

[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.

[RFC3234]Carpenter,B.和S.Brim,“中间盒:分类和问题”,RFC 32342002年2月。

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

[RFC3261]Rosenberg,J.,Schulzrinne,H.,Camarillo,G.,Johnston,A.,Peterson,J.,Sparks,R.,Handley,M.,和E.Schooler,“SIP:会话启动协议”,RFC 3261,2002年6月。

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

[RFC3828]Larzon,L-A.,Degermark,M.,Pink,S.,Jonsson,L-E.,Ed.,和G.Fairhurst,Ed.,“轻量级用户数据报协议(UDP-Lite)”,RFC 38282004年7月。

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.

[RFC4301]Kent,S.和K.Seo,“互联网协议的安全架构”,RFC 43012005年12月。

[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.

[RFC4347]Rescorla,E.和N.Modadugu,“数据报传输层安全”,RFC 4347,2006年4月。

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

[RFC4960]Stewart,R.,Ed.“流控制传输协议”,RFC 49602007年9月。

[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", RFC 5238, May 2008.

[RFC5238]Phelan,T.,“数据报拥塞控制协议(DCCP)上的数据报传输层安全性(DTLS)”,RFC 5238,2008年5月。

[RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal", RFC 5596, September 2009.

[RFC5596]Fairhurst,G.“数据报拥塞控制协议(DCCP)促进NAT/中间盒遍历的同时开放技术”,RFC 55962009年9月。

Author's Address


Godred Fairhurst, School of Engineering, University of Aberdeen, Kings College, Aberdeen, AB24 3UE, UK EMail: URL:

Godred Fairhurst,工程学院,阿伯丁大学,国王学院,阿伯丁,AB24 3UE,英国电子邮件网址: