[要約] RFC 5595は、DCCPサービスコードに関する規格であり、DCCPプロトコルの拡張機能を提供します。目的は、データグラムの過負荷制御を改善し、ネットワークのパフォーマンスを向上させることです。
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
Datagram輻輳制御プロトコル（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.
このドキュメントでは、Datagramの混雑制御プロトコル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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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
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は、クライアントアプリケーションが接続を希望するアプリケーションレベルのサービス（[RFC4340]、セクション8.1.2）を記述する4バイト値（32ビット）としてサービスコードを指定します。サービスコードは、アプリケーションレイヤーで使用するプロトコル（または[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-Requestパケットのサービスコード値によって要求されたサービスを識別します。したがって、各アプリケーションは、1つ以上のサービスコードを各リスニングポート（[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].
現在のほとんどのインターネット輸送プロトコル（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-Requestパケットにのみ含まれる32ビットサービスコード[RFC4340]を使用することでした。32ビット値の使用は、各アプリケーションの一意の値を取得することを簡単に簡単にすることを目的としていました。DCCP-Requestパケットに値を配置するには、実際のデータフローに追加のオーバーヘッドは必要ありません。ただし、両方のエンドシステムに十分であり、パスに沿ったステートフルミドルボックスを提供して、使用されているアプリケーションを理解するための追加情報を提供します。
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クライアントは、リクエストにサービスコードを含め、対応するリスニングアプリケーションに到達できるようにしました。1つの欠点は、これにより、単一のマシン上の同じサービスの2つのサーバーの展開が妨げられたことです。これは、ポートに些細なことです。この設計は、既存のプロトコルと十分に異なるという欠点にも苦しんでおり、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ビット接続識別子の使用を放棄し、2つの従来の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).
多数の利用可能な一意のサービスコード値により、すべてのアプリケーションに一意のサービスコードを割り当てることができます。ただし、問題は残っています。サーバーポートはサーバーによって選択されましたが、クライアントは接続を確立するためにこのポートを知る必要がありました。サーバーポートを発見するために、バンド外の通信を義務付けることは望ましくありませんでした。選択されたソリューションは、DCCPサーバーポートを登録することでした。DCCPサーバーポートの限られた可用性は、DCCPサービスコードの利点と矛盾するように思われます。なぜなら、サービスコードを取得することは些細なことであるかもしれないが、IANAから登録されたポートを取得し、長期にわたって登録されたポートを取得することは些細なことではなかった。一意の登録DCCPポートを新しいアプリケーションに割り当てることはできない場合があります。ポート番号が不足すると、これは複数のサービスコードをリスニングポートに関連付ける必要性を動機付けます（たとえば、2つの異なるアプリケーションに同じサーバーポートを割り当てることができ、同じホストで同じホストで実行する必要があります。異なる関連サービスコード）。
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つの公開されたポート番号で識別された場合、可能な場合よりも多くの同時接続が可能になります。
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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は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では、TCPのように、接続に属するパケットが4つの値（ソースIPアドレス、ソースポート、DEST PORT、DEST PORT、DEST PORT}の組み合わせに基づいて非難されます。エンドポイントアドレスは、ポート番号（ソケットの形成など）に関連付けられており、一対の関連付けは各接続を一意に識別します。ポートは、パケットごとの基本的な反射機能を提供します。
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.
インターネットに割り当てられた番号当局は、現在、グローバルに予約されたポート番号[IANA]のセットを管理しています。「はかないポート」としてしばしば知られている接続要求に関連付けられたソースポートは、伝統的に範囲49152-65535であり、範囲1024-49151も含まれています。短命ポートに使用される値は、通常、クライアントオペレーティングシステムによって選択されます。ランダム化された選択ポート番号の値は、TCPの「ブラインド」攻撃[RAND]に対する防御に役立つことが示唆されています。この方法は、DCCPを含む他のIETF定義の輸送プロトコルに適用できます。
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（）を指すオペレーティングシステムインデックスのいずれかによって決定されます。直接マッピングを指定するアプリケーション。
The UDP and TCP port number space: 0..65535, is split into three ranges [RFC2780]:
UDPおよびTCPポート番号スペース：0..65535は、3つの範囲に分割されています[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ポートは、少なくとも1つの事前定義されたサービスコードに関連付けられている必要があります。
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ポートレジストリに登録する必要はありません）。クライアントは、さまざまな方法を使用して接続したいサービスのサーバーポート値を識別できます。一般的な方法の1つは、帯域外（SIP [RFC3261]を使用して、リアルタイムストリーミングプロトコル（RTSP）[RFC2326]を使用して、SDPレコード（セクション2.6）を交換したことです。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は、3つの形式のいずれかで表される4バイトサービスコード（[RFC4340]、セクション8.1.2）を指定します：10進数（標準的な方法）、4文字のASCII文字列[ansi.x3-4.1986]、または8桁の16進数。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]で定義されています。別の例では、Datagram Transport Layer Security（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]に関連付ける必要があります。通常、アプリケーションはこのサービスコードを提供します。単一の受動的整理ポートは、複数のサービスコード値に関連付けられている場合があります。サービスコードのセットは、1つ以上のサーバーアプリケーションに関連付けられている可能性があります。これにより、対応するソケットペア（レイヤー3アドレスとレイヤー-4ポートの4タプル）を使用して、サービスとポート番号の間のより柔軟な対応が可能になります。現在定義されているパケットタイプのセットでは、サービスコード値はDCCP-Request（[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制御の名前スペースで定義されています。IANAは、このスペースでサービスコードの新しい割り当てを管理しています[RFC4340]。プライベートサービスコードは中央に割り当てられておらず、小数範囲1056964608-1073741823（つまり、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.
インターネットでの展開を目的としたアプリケーションは、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は、10進数（0xffffffffff）の4294967295のサービスコード値を「無効」と定義しています。これが提供されるため、実装は特別な4バイト値を使用して「有効なサービスコードなし」を示すことができます。実装は、この値でDCCP-Requestを受け入れてはならず、アプリケーションがこのサービスコード値[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;}
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の範囲の文字にのみ適用されます。文字が範囲の境界を越えると、アルゴリズムは不連続性を導入し、その結果、非継続ポートにマッピングします。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-Requestを発行し、宛先の指定されたサービスコードに関連付けられると予想される宛先（サーバー）ポート番号を選択します。
A server that receives a DCCP-Request:
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-Resetパケットが返されます。
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-Requestパケットで使用されます。
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を使用していると主張するフローのリアルタイム性を特定することは、実際の接続データが関連するサービスコードに対応するという保証はありません。Middleboxの実装者は、接続のコンテンツを検証するために、ディープパケット検査などを使用する場合があります。
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-RequestまたはDCCP-Responseパケットの宛先またはソースポートに加えて、サービスコードをテストする必要があります。
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接続を対応するアプリケーションサービスに関連付けるために使用されます。2つのDCCPサーバーアプリケーションが同じホストで受動的に聞くと、4つのケースが発生する可能性があります。
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 最も単純なケースは、2つのサーバーが異なるサービスコードに関連付けられ、異なるサーバーポートにバインドされている場合に発生します（セクション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 2つのサーバーは、同じ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 2つのサーバーは、異なる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 2つのサーバーは、同じ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 指定されたサーバーポートで、各アクティブソケットを正確に1つのサービスコードで関連付ける必要があります。
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).
したがって、1つの受動的に開かれた（リスニング）ポートは複数のサービスコードに関連付けられている可能性がありますが、アクティブな（オープン）接続は単一のサービスコードにのみ関連付けられます。単一のアプリケーションは、同じサーバーポートを使用して複数のサービスコードの接続を受け入れることをお勧めします。これにより、サーバーは、ポートフィールドのサイズに応じて65,536サービスの制限以上を提供できる場合があります。上限は、2つのホスト間の一意の接続の数（つまり、4,294,967,296）のみに基づいています。
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-Requestが受信され、指定された宛先ポートがサーバーにバインドされていない場合、ホストはリセットコード「接続が拒否された」で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:
要求された宛先ポートがサーバーにバインドされている場合、ホストはサーバーポートが指定されたサービスコードに関連付けられていることを確認する必要があります（同じサーバーポートに関連付けられた複数のサービスコード値がある可能性があります）。2つのケースが発生する可能性があります。
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-Requestがポートに関連付けられているサービスコードを使用している場合、ホストは接続を受け入れます。接続すると、サーバーは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-Resetパケットを送信して要求を拒否する必要がありますが、「接続が拒否された」という理由を使用します。
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-Requestの到着には、DCCP-Requestを対応するサービスコードを処理するサーバーに関連付ける方法が必要になる場合があります。この操作は、「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:
重要なセキュリティには4つの領域があります。
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では、ミドルボックスの動作について説明します）。DCCPに関連する要件は[RFC5597]で説明されています。
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 Key Exchange Protocol（IKEV2）は現在、IPSECセキュリティ協会のセットアップに使用される情報の一部としてDCCPサービスコードを使用する方法を指定していません。
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].
完全性のために、ドキュメントは、DCCPサービスコードまたはポート番号値のアプリケーションをサポートするために承認されたドキュメント（公開されたRFCなど）を提供する必要はないことに注意してください。ただし、RFCはIANAを介してサービスコード値を要求するために使用できます考慮事項セクション。ただし、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プロジェクトによってサポートされています。この文書への重要な貢献は、ジョー・タッチとの議論から生じ、これは感謝されています。著者はまた、このトピックに関する有益なコメントをしてくれたIan McDonald、Fernando Gont、Eddie Kohler、およびDCCP WGに感謝し、DCCPの行動とこの文書のレビューを決定するのに役立ってくれたGerrit Renkerに感謝します。マーク・ハンドリーは、サービスコードの定義とその使用に関するテキストに重要な入力を提供しました。彼はまた、歴史的背景セクションを形成した資料の多くを貢献しました。
[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、「Datagramうっ血制御プロトコル（DCCP）」、RFC 4340、2006年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。、「Network Address Translation（NAT）Datagram輻輳制御プロトコルの行動要件」、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] American National Standards Institute、「コード化された文字セット-7ビットの情報交換のためのアメリカ標準コード」、ANSI X3.4、1986。
[IANA] Internet Assigned Numbers Authority, www.iana.org.
[IANA]インターネットに割り当てられた番号authority、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およびThe Datagram輻輳制御プロトコル（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。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC814] Clark, D., "Name, addresses, ports, and routes", RFC 814, July 1982.
[RFC814]クラーク、D。、「名前、住所、ポート、ルート」、RFC 814、1982年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）」、RFC 2326、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 RR（DNS SRV）」、RFC 2782、2000年2月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993] Hain、T。、「Natの建築的意味」、RFC 2993、2000年11月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B。およびS.ブリム、「ミドルボックス：分類法と問題」、RFC 3234、2002年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：SESSION INTIANIATION Protocol」、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。、「The Lightweight User Datagram Protocol（UDP-Lite）」、RFC 3828、2004年7月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、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：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R.、ed。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", RFC 5238, May 2008.
[RFC5238] Phelan、T。、「データグラムの混雑制御プロトコル（DCCP）上のデータグラム輸送層セキュリティ（DTL）」、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/Middleboxトラバーサルを促進する同時オープン手法」、RFC 5596、2009年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
ゴッドレッドフェアハースト、エンジニアリング学部、アバディーン大学、キングスカレッジ、アバディーン、AB24 3UE、英国メール：gorry@erg.abdn.ac.uk url：http：//www.erg.abdn.ac.uk/users/gorry