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
数据报拥塞控制协议（DCCP）服务代码
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.
本文档描述了数据报拥塞控制协议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 (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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第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
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人可能没有授予IETF信托允许的权利
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.
在IETF标准过程之外修改此类材料。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
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
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).
DCCP将服务代码指定为4字节值（32位），用于描述客户端应用程序希望连接到的应用程序级服务（[RFC4340]，第8.1.2节）。服务代码标识应用层要使用的协议（或标准配置文件，例如[RTP-DCCP]）。它不用于指定应用程序的变体或协议的特定变体（第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).
服务代码机制允许应用程序声明与服务器端口号关联的服务集。这可能会影响应用程序与DCCP交互的方式。它还允许将端口号的角色与端口号在解复用和状态管理中的角色分离，以指示所需的服务。DCCP应用程序通过DCCP请求数据包中的服务代码值来标识请求的服务。因此，每个应用程序将一个或多个服务代码与每个侦听端口相关联（[RFC4340]，第8.1.2节）。
The use of Service Codes can assist in identifying the intended service by a firewall and may assist other middleboxes (e.g., a proxy server 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.
服务代码的使用有助于通过防火墙识别预期服务，并有助于其他中间盒（例如，代理服务器或网络地址转换器（NAT）[RFC2663]）。希望识别流声称要传输的数据类型的中间盒应为此目的使用服务代码。当一致使用时，服务代码可以提供实际服务的更具体指示（例如，指示多媒体流的类型或预期的应用程序行为），而不是从服务器端口值导出此信息。
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传输协议。
It is simplest to understand the motivation for defining Service Codes by describing the history of the DCCP protocol.
通过描述DCCP协议的历史，最容易理解定义服务代码的动机。
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:
在DCCP的最早草案中，作者希望以一种经得起未来考验的方式解决已发布端口的问题，因为这种方法存在以下几个问题：
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.
对于试图伪装成其他应用程序的应用程序，传输协议设计者几乎无能为力。对于那些不打算隐藏的端口，问题可能只是它们无法轻松获得已发布的端口。理想情况下，每个应用程序编写者都可以请求一个已知的或注册的端口，并立即接收到一个，而不必提出任何问题。传统上使用的16位端口空间不够大，无法支持如此琐碎的端口分配。
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).
因此，DCCP的设计者寻求一种替代解决方案。这个想法很简单。32位服务器端口空间应足够大，以便能够使用非常简单的分配策略。但是，由于开销的考虑，32位端口值是不可取的（DCCP需要对低速率应用程序有用）。
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.
DCCP对此问题的解决方案是使用仅包含在DCCP请求数据包中的32位服务代码[RFC4340]。使用32位值的目的是使获得每个应用程序的唯一值变得非常简单。将该值放入DCCP请求数据包不需要实际数据流的额外开销。然而，这对于两个终端系统都是足够的，并且为路径上的任何有状态的中间盒提供了额外的信息，以了解正在使用的应用程序。
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.
DCCP协议的早期讨论被认为是使用传统端口的替代方案；相反，有人建议客户机使用32位标识符来唯一标识每个连接，而服务器只监听绑定到服务代码的套接字。这个解决方案是明确的；服务代码是服务器端侦听套接字的唯一标识符。DCCP客户端在请求中包含一个服务代码，允许它到达相应的侦听应用程序。一个缺点是，这妨碍了在一台机器上为同一服务部署两台服务器，这对于端口来说是微不足道的。该设计还存在与现有协议完全不同的缺点，有人担心它会阻碍通过NAT和其他中间盒使用DCCP。
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
大量可用的唯一服务代码值允许为所有应用程序分配唯一的服务代码。但是，仍然存在一个问题：服务器端口是由服务器选择的，但是客户端需要知道这个端口才能建立连接。不希望强制进行带外通信来发现服务器端口。选择的解决方案是注册DCCP服务器端口。DCCP服务器端口的有限可用性似乎与DCCP服务代码的好处相矛盾，因为尽管可能
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).
获取服务代码很简单，传统上从IANA获取注册端口并不简单，从长远来看，可能无法将唯一的注册DCCP端口分配给新的应用程序。随着端口号变得稀少，这促使需要将多个服务代码与侦听端口相关联（例如，两个不同的应用程序可能被分配到同一服务器端口，并且需要同时在同一主机上运行，由其不同的关联服务代码区分）。
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.
服务代码提供了客户机识别其希望与之通信的服务器应用程序的方式的灵活性。该机制允许服务器将一组服务器端口与服务相关联。该集合可能与同一服务器主机上可用的其他服务共用，从而允许特定服务的并发连接数大于通过单个已发布端口号标识服务时的并发连接数。
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]中所述进行解释。
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.
DCCP定义了端口和服务代码组合的使用，以识别服务器应用程序（[RFC4340]，第8.1.2节）。以下各节将对其进行说明。
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.
传统上，与服务关联的目标（服务器）端口值由指向IANA表副本的操作系统索引（例如，Unix中的getportbyname（），它对/etc/services文件进行索引）或由指定直接映射的应用程序确定。
The UDP and TCP port number space: 0..65535, is split into three ranges [RFC2780]:
UDP和TCP端口号空间0..65535分为三个范围[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).
不使用带外信令的应用程序仍然可以通信，前提是客户端和服务器都同意要使用的端口值。这样就不需要将每个注册的服务代码分配给IANA分配的服务器端口（另请参见第2.7节）。
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.
服务代码标识客户端应用程序希望连接到的应用程序级服务。例如，已经为实时协议（RTP）[RTP-DCCP]定义了服务。在不同的示例中，数据报传输层安全性（DTLS）[RFC5238]提供传输服务（而不是应用层服务）；因此，使用DTL的应用程序由一组相应的服务代码值单独标识。
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.
端点必须将服务代码与每个主动和被动打开的DCCP套接字[RFC4340]相关联。应用程序通常会提供此服务代码。单个被动侦听端口可能与多个服务代码值相关联。服务代码集可以与一个或多个服务器应用程序相关联。这使得服务和端口号之间的对应比使用相应的套接字对（第3层地址和第4层端口的4元组）更灵活。在当前定义的数据包类型集合中，服务代码值仅存在于DCCP请求（[RFC4340]，第5.2节）和DCCP响应数据包（[RFC4340]，第5.3节）中。注意，新的DCCP数据包类型（例如，[RFC5596]）也可以携带服务代码值。
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).
在通过DCCP运行的协议中提供版本协商或指示的应用程序/协议不需要为每个新协议版本提供新的服务器端口或新的服务代码。此类应用程序/协议的新版本应继续使用相同的服务代码。如果应用程序开发人员认为新版本提供了重要的新功能（例如，这将改变中间盒的行为），他们可能会分配与相同或不同的已知端口集关联的新服务代码。如果新服务代码与已知或已注册的端口相关联，则还必须更新DCCP端口注册表以包含新服务代码值，但可能共享相同的服务器端口分配。
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 '?').
在IANA控制的名称空间中定义了指定用于通用Internet的注册服务代码集。IANA管理此空间中服务代码的新分配[RFC4340]。专用服务代码不是集中分配的，由十进制范围1056964608-1073741823表示（即，32位值，高阶字节等于63，对应于ASCII字符“？”）。
Associations of Service Code with Well Known ports are also defined in the IANA DCCP Port registry (Section 2.1).
IANA DCCP端口注册表（第2.1节）中还定义了服务代码与已知端口的关联。
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).
需要临时服务代码值的应用程序编写器应从专用范围中选择一个值（第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.
鼓励打算在Internet上部署的应用程序使用IANA定义的服务代码。如果不存在特定的服务代码，则应向IANA请求新的分配。
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]。
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].
当前发送目标端口号信号的方法，如会话描述协议（SDP）[RFC4566]，需要扩展以支持DCCP服务代码[RTP-DCCP]。
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]:
不使用带外信令或IANA分配端口的应用程序仍然需要客户端和服务器就要使用的服务器端口值达成一致。本节介绍一种可选方法，该方法允许应用程序从服务代码派生默认服务器端口号。返回值在动态端口范围[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.
其中sc[]表示服务代码的4个字节，sc[3]是最低有效字节。例如，此函数将SC:fdpz与服务器端口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.
已分配服务代码（或使用未分配的专用空间中的服务代码）的应用程序和更高层协议可以使用此方法。它不排除使用所选服务器端口的其他应用程序，因为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:
接收DCCP请求的服务器：
- 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重置数据包。
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.
客户端应用程序必须将每个DCCP连接（以及每个DCCP活动套接字）与单个服务代码值[RFC4340]相关联。该值用于相应的DCCP请求数据包中。
DCCP connections identified by the Service Code continue to use IP addresses and ports, although neither port number may be Published.
由服务代码标识的DCCP连接继续使用IP地址和端口，尽管两个端口号都不能发布。
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].
端口号和IP地址是在IP网络中识别流的传统方法。因此，Middlebox[RFC3234]实现者需要注意，除了IP地址之外，新的DCCP连接还通过服务器端口和服务代码对进行标识。这意味着IANA可以将服务器端口分配给多个DCCP应用程序[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.
网络地址和端口转换器，统称为NAT[RFC2663]，可以解释DCCP端口（[RFC2993]和[RFC5597]）。他们还可以解释DCCP服务代码。解释DCCP服务代码可以减少正确解释端口号的需要，从而为网络地址和端口转换器带来新的机会。尽管鼓励将特定交付属性与服务代码相关联，例如，识别声称使用RTP的流的实时性质，但不能保证实际连接数据对应于关联的服务代码。在尝试验证连接的内容时，中间盒实现者仍然可以使用深度数据包检查和其他方法。
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重置，以响应具有被认为不合适的服务代码的分组。
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:
服务代码和服务器端口的组合消除了服务器接收到的传入DCCP请求的歧义。服务代码用于将新的DCCP连接与相应的应用程序服务相关联。当两个DCCP服务器应用程序在同一主机上被动侦听时，可能会出现四种情况：
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).
因此，单个被动打开（侦听）端口可能与多个服务代码关联，尽管主动（打开）连接只能与单个服务代码关联。单个应用程序可能希望使用同一服务器端口接受多个服务代码的连接。根据端口字段的大小，这可能允许服务器提供超过65536个服务的限制。上限仅基于两台主机之间的唯一连接数（即4294967296）。
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.
接受连接后，协议控制块与一对端口、一对IP地址和单个服务代码值相关联。
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).
DCCP服务代码不限于特定端口，尽管它们可能与特定的已知端口相关联。这允许相同的DCCP服务代码值与多个服务器端口（处于主动或被动状态）关联。
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].
主机实现可能允许服务与服务器上未永久运行的服务器端口（或端口范围）关联。在这种情况下，DCCP请求的到达可能需要一种方法来将DCCP请求与处理相应服务代码的服务器相关联。此操作可能类似于“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].
如前一节所述，当指定的服务代码与指定的服务器端口不关联时，必须中止连接并发送DCCP重置消息[RFC4340]。
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]).
所有IPsec模式都保护DCCP头的完整性。这可以保护服务代码字段不被网络中未检测到的修改。此外，IPsec封装的安全有效载荷（ESP）模式可用于加密服务代码字段，将服务代码值隐藏在网络内，还可防止中间盒进行解释。DCCP头不受应用层安全保护（例如，使用DTLS/DCCP[RFC4347]中规定的DTLS[RFC5238]）。
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节）。
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.
在解复用传入连接时，除端口外还使用服务代码。这将更改应用程序和中间盒使用的服务模型。端口号注册表已包含TCP和UDP的单个端口号的多个应用程序注册实例。这是相对罕见的。由于DCCP服务代码允许多个应用程序安全地共享同一端口号，即使在同一主机上，DCCP中的服务器端口号重用可能比TCP和UDP中更常见。
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.
在解释服务代码值到相应服务的映射时需要小心。可以使用多个服务代码访问同一服务（应用程序）。示例包括对直接在DCCP上分层的应用程序使用单独的服务代码，以及在DCCP上使用DTLS传输的应用程序[RFC5238]。其他可能性包括使用专用服务代码映射到已分配IANA定义的服务代码值的应用程序，或映射到提供多个服务的单个应用程序的多个服务代码值。服务（应用程序）的不同版本也可以映射到相应的一组服务代码值。
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.
服务代码的处理可能意味着比当前与传入端口号关联的处理更多。实施者需要防止拒绝服务攻击的机会增加。
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.
Internet密钥交换协议（IKEv2）当前未指定使用DCCP服务代码作为用于建立IPsec安全关联的信息的一部分的方法。
IPsec uses port numbers to perform access control in transport mode [RFC4301]. Security policies can define port-specific access control (PROTECT, BYPASS, DISCARD) as well as port-specific algorithms and keys. Similarly, firewall policies allow or block traffic based on port numbers.
IPsec使用端口号在传输模式[RFC4301]下执行访问控制。安全策略可以定义特定于端口的访问控制（保护、绕过、丢弃）以及特定于端口的算法和密钥。类似地，防火墙策略允许或阻止基于端口号的通信。
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.
在IPsec选择器和防火墙中使用端口号可能会假定这些号码对应于众所周知的服务。值得注意的是，没有此类要求；根据端点主机之间的相互协议，任何服务都可以在任何端口上运行。在IPsec和其他防火墙系统中，使用服务代码可能会干扰此假设，但不会添加新的漏洞。IPsec和防火墙系统的新实现可能在实现策略规则时解释服务代码，但不应依赖端口号或服务代码来指示特定的服务。
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].
为完整起见，本文件注意到，虽然RFC可用于通过IANA注意事项部分请求服务代码值，但无需提供经批准的文件（例如，已发布的RFC）来支持DCCP服务代码或端口号值的应用。然而，分配使用ASCII数字、大写字母和字符空间“-”、“.”和“/”）[RFC4340]组合的服务代码时需要一个规范。
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在服务代码的定义及其使用方面为文本提供了重要的输入。他还贡献了构成历史背景部分的许多材料。
[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月。
[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, www.iana.org.
[IANA]互联网分配号码管理局，www.IANA.org。
[RTP-DCCP] Perkins, C., "RTP and the Datagram Congestion Control Protocol (DCCP)", Work in Progress, June 2007.
[RTP-DCCP]Perkins，C.，“RTP和数据报拥塞控制协议（DCCP）”，正在进行的工作，2007年6月。
[Rand] Larsen, M. and F. Gont, "Port Randomization", Work in Progress, March 2009.
[Rand]Larsen，M.和F.Gont，“港口随机化”，正在进行的工作，2009年3月。
[inetd] The extended inetd project, http://xinetd.org.
[inetd]扩展的inetd项目，http://xinetd.org.
[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.
[RFC814]Clark，D.，“名称、地址、港口和路线”，RFC8141982年7月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326]Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[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.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[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: gorry@erg.abdn.ac.uk URL: http://www.erg.abdn.ac.uk/users/gorry
Godred Fairhurst，工程学院，阿伯丁大学，国王学院，阿伯丁，AB24 3UE，英国电子邮件：gorry@erg.abdn.ac.uk网址：http://www.erg.abdn.ac.uk/users/gorry