Network Working Group                                       G. Fairhurst
Request for Comments: 5595                        University of Aberdeen
Updates: 4340                                             September 2009
Category: Standards Track
     The Datagram Congestion Control Protocol (DCCP) Service Codes



This document describes the usage of Service Codes by the Datagram Congestion Control Protocol, RFC 4340. It motivates the setting of a Service Code by applications. Service Codes provide a method to identify the intended service/application to process a DCCP connection request. This provides improved flexibility in the use and assignment of port numbers for connection multiplexing. The use of a DCCP Service Code can also enable more explicit coordination of services with middleboxes (e.g., network address translators and firewalls). This document updates the specification provided in RFC 4340.

この文書では、それはアプリケーションによるサービスコードの設定を動機付けるデータグラム輻輳制御プロトコル、RFC 4340でサービスコードの使用方法について説明します。サービスコードは、DCCP接続要求を処理することを意図したサービス/アプリケーションを識別するための方法を提供します。これは、接続多重化のために使用し、ポート番号の割り当てに改善された柔軟性を提供します。 DCCPサービスコードの使用はまた、ミドルボックス(例えば、ネットワークアドレス変換およびファイアウォール)とのサービスのより明示的な連携を可能にすることができます。この文書は、RFC 4340で提供さ仕様を更新します。

Status of This Memo


This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD 1)の最新版を参照してください。このメモの配布は無制限です。

Copyright and License Notice


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

著作権(C)2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント(に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション4.eに記載されており、BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.


Table of Contents


   1. Introduction ....................................................3
      1.1. History ....................................................3
      1.2. Conventions Used in This Document ..........................6
   2. An Architecture for Service Codes ...............................6
      2.1. IANA Port Numbers ..........................................6
      2.2. DCCP Service Code Values ...................................7
           2.2.1. New Versions of Applications or Protocols ...........8
      2.3. Service Code Registry ......................................8
      2.4. Zero Service Code ..........................................9
      2.5. Invalid Service Code .......................................9
      2.6. SDP for Describing Service Codes ...........................9
      2.7. A Method to Hash the Service Code to a Dynamic Port ........9
   3. Use of the DCCP Service Code ...................................10
      3.1. Setting Service Codes at the Client .......................11
      3.2. Using Service Codes in the Network ........................11
      3.3. Using Service Codes at the Server .........................12
           3.3.1. Reception of a DCCP-Request ........................13
           3.3.2. Multiple Associations of a Service Code
                  with Ports .........................................14
           3.3.3. Automatically Launching a Server ...................14
   4. Security Considerations ........................................14
      4.1. Server Port Number Reuse ..................................15
      4.2. Association of Applications with Service Codes ............15
      4.3. Interactions with IPsec ...................................15
   5. IANA Considerations ............................................16
   6. Acknowledgments ................................................16
   7. References .....................................................17
      7.1. Normative References ......................................17
      7.2. Informative References ....................................17
1. Introduction
1. はじめに

DCCP specifies a Service Code as a 4-byte value (32 bits) that describes the application-level service to which a client application wishes to connect ([RFC4340], Section 8.1.2). A Service Code identifies the protocol (or the standard profile, e.g., [RTP-DCCP]) to be used at the application layer. It is not intended to be used to specify a variant of an application or a specific variant of a protocol (Section 2.2).


The Service Code mechanism allows an application to declare the set of services that are associated with server port numbers. This can affect how an application interacts with DCCP. It also allows decoupling of the role of port numbers to indicate a desired service from the role of port numbers in demultiplexing and state management. A DCCP application identifies the requested service by the Service Code value in a DCCP-Request packet. Each application therefore associates one or more Service Codes with each listening port ([RFC4340], Section 8.1.2).

サービスコードメカニズムは、アプリケーションがサーバーのポート番号に関連付けられているサービスのセットを宣言することができます。これは、アプリケーションがDCCPと対話する方法に影響することができます。また、ポート番号の役割のデカップリングが分離し、状態管理のポート番号の役割から所望のサービスを示すことができます。 DCCPアプリケーションがDCCP-Requestパケットにおけるサービスコード値によって要求されたサービスを識別します。各アプリケーションは、従って、各リスニングポート([RFC4340]、セクション8.1.2)を有する1つまたは複数のサービスコードを関連付けます。

The use of Service Codes can assist in identifying the intended service by a firewall and may assist other middleboxes (e.g., a proxy server or network address translator (NAT) [RFC2663]). Middleboxes that desire to identify the type of data a flow claims to transport should utilize the Service Code for this purpose. When consistently used, the Service Code can provide a more specific indication of the actual service (e.g., indicating the type of multimedia flow or intended application behaviour) than deriving this information from the server port value.


The more flexible use of server ports can also offer benefits to applications where servers need to handle very large numbers of simultaneous-open ports to the same service.


RFC 4340 omits a description of the motivation behind Service Codes, and it does not properly describe how Well Known and Registered server ports relate to Service Codes. The intent of this document is to clarify these issues.

RFC 4340は、サービスコードの背後にある動機の説明を省略し、それが適切に知られており、登録サーバポートは、サービス・コードにどのように関係するかをよく説明していません。このドキュメントの目的は、これらの問題を明らかにすることです。

RFC 4340 states that Service Codes are not intended to be DCCP-specific. Service Codes, or similar concepts, may therefore also be useful to other IETF transport protocols.

RFC 4340は、サービスコードがDCCP特有であることを意図していないと述べています。サービスコード、または同様の概念は、したがって、他のIETFトランスポートプロトコルに有用であり得ます。

1.1. History
1.1. 歴史

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


Most current Internet transport protocols (TCP [RFC793], UDP [RFC768], SCTP (the Stream Control Transmission Protocol) [RFC4960], and UDP-Lite [RFC3828]) use "Published" port numbers from the Well Known or Registered number spaces [RFC814]. These 16-bit values indicate the application service associated with a connection or message. The server port must be known to the client to allow a connection to be established. This may be achieved using out-of-band signalling (e.g., described using SDP [RFC4566]), but more commonly a Published port is allocated to a particular protocol or application; for example, HTTP commonly uses port 80 and SMTP commonly uses port 25. Making a port number Published [RFC1122] involves registration with the Internet Assigned Numbers Authority (IANA), which includes defining a service by a unique keyword and reserving a port number from among a fixed pool [IANA].

現在のほとんどのインターネット・トランスポート・プロトコル(TCP [RFC793]、UDP [RFC768]、SCTP(ストリーム制御伝送プロトコル)[RFC4960]、およびUDP-Liteの[RFC3828])は、周知または登録数のスペースから "公開" のポート番号を使用します[RFC814]。これらの16ビット値は、接続またはメッセージに関連付けられたアプリケーションサービスを示しています。サーバポートは、接続を確立することができるように、クライアントに知らなければなりません。これは、シグナリング帯域外(例えば、SDP [RFC4566]を使用して説明した)を使用して達成することができるが、より一般的に公開されたポートは、特定のプロトコルまたはアプリケーションに割り当てられています。例えば、HTTPは一般にポート80を使用し、SMTPは、一般に公開されたポート番号[RFC1122]は固有のキーワードでサービスを定義してからポート番号を予約することを含む、インターネット割り当て番号機関(IANA)で登録することを含む作るポート25を使用し固定されたプールのうち、[IANA]。

In the earliest draft of DCCP, the authors wanted to address the issue of Published ports in a future-proof manner, since this method suffers from several problems:


o The port space is not sufficiently large for ports to be easily allocated (e.g., in an unregulated manner). Thus, many applications operate using unregistered ports, possibly colliding with use by other applications.


o The use of port-based firewalls encourages application writers to disguise one application as another in an attempt to bypass firewall filter rules. This motivates firewall writers to use deep packet inspection in an attempt to identify the service associated with a port number.


o ISPs often deploy transparent proxies, primarily to improve performance and reduce costs. For example, TCP requests destined to TCP port 80 are often redirected to a web proxy.

O ISPは、多くの場合、パフォーマンスを向上させ、コストを削減するために、主に、透明のプロキシを展開します。たとえば、TCPポート80宛てのTCP要求は、多くの場合、Webプロキシにリダイレクトされます。

These issues are coupled. When applications collide on the same Published-but-unregistered port, there is no simple way for network security equipment to tell them apart, and thus it is likely that problems will be introduced through the interaction of features.

これらの問題は結合されています。アプリケーションが同じ公開 - しかし、未登録のポートに衝突すると、そこにそれらを区別するために、ネットワークセキュリティ機器のための簡単な方法はありませんので、問題は機能の相互作用を介して導入される可能性があります。

There is little that a transport protocol designer can do about applications that attempt to masquerade as other applications. For ones that are not attempting to hide, the problem may be simply that they cannot trivially obtain a Published port. Ideally, it should be sufficiently easy that every application writer can request a Well Known or Registered port and receive one instantly with no questions asked. The 16-bit port space traditionally used is not large enough to support such a trivial allocation of ports.


Thus, the designers of DCCP sought an alternative solution. The idea was simple. A 32-bit server port space should be sufficiently large to enable use of very simple allocation policies. However, overhead considerations made a 32-bit port value undesirable (DCCP needed to be useful for low-rate applications).

このように、DCCPの設計者は、代替ソリューションを求めていました。アイデアは簡単でした。 32ビットサーバーのポート空間は非常に単純な割り当てポリシーの使用を可能にするために十分に大きくなければなりません。しかしながら、オーバーヘッドの考察は(DCCP低レートのアプリケーションに有用であることが必要)望ましくない32ビットポートの値を作りました。

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クライアントは、それが対応するリスニングアプリケーションに到達することを可能にする、要求にサービスコードが含まれています。一つの欠点は、これは、単一のマシン上で同じサービス、ポートを備えた些細な何かのための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は、サーバによって選択された一方とクライアントずつ2つの伝統的な16ビットのポート値の有利な32ビットの接続識別子の使用を断念しました。しかし、それは新たな問題を導入しましたこれは、ミドルボックスは、などDCCP、UDP、TCP、のために同様の技術を利用することができます:「どのようにサーバーのポートがサービスコードに関連していますか?」意図は、サービスコードは、接続の使用目的に関する情報を中間装置を提供し、DCCPを使用して、アプリケーションまたはプロトコルを識別していることであり、ポートのペアが有効端の対の間にユニークであった32ビットの接続識別子を形成していますシステム。

The large number of available, unique Service Code values allows all applications to be assigned a unique Service Code. However, there remained a problem: the server port was chosen by the server, but the client needed to know this port to establish a connection. It was undesirable to mandate out-of-band communication to discover the server port. The chosen solution was to register DCCP server ports. The limited availability of DCCP server ports appears to contradict the benefits of DCCP Service Codes because, although it may be trivial to obtain a Service Code, it has not traditionally been trivial to obtain a Registered port from IANA and, in the long-run, it may not be possible to allocate a unique Registered DCCP port to new applications. As port numbers become scarce, this motivates the need to associate more than one Service Code with a listening port (e.g., two different applications could be assigned the same server port and need to run on the same host at the same time, differentiated by their different associated Service Codes).


Service Codes provide flexibility in the way clients identify the server application to which they wish to communicate. The mechanism allows a server to associate a set of server ports with a service. The set may be common with other services available at the same server host, allowing a larger number of concurrent connections for a particular service than possible when the service is identified by a single Published port number.


1.2. Conventions Used in This Document
1.2. このドキュメントの表記規則

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。

2. An Architecture for Service Codes

DCCP defines the use of a combination of ports and Service Codes to identify the server application ([RFC4340], Section 8.1.2). These are described in the following sections.


2.1. IANA Port Numbers
2.1. IANAポート番号

In DCCP, the packets belonging to a connection are demultiplexed based on a combination of four values {source IP address, source port, dest IP address, dest port}, as in TCP. An endpoint address is associated with a port number (e.g., forming a socket) and a pair of associations uniquely identifies each connection. Ports provide the fundamental per-packet demultiplexing function.

DCCPでは、接続に属するパケットは、TCPのように四つの値{送信元IPアドレス、送信元ポート、DEST IPアドレス、DESTポート}、の組み合わせに基づいて分離されます。エンドポイントアドレスは、ポート番号(例えば、ソケット形成する)との関連の対は一意の接続を識別する関連付けられています。ポートは、基本的なパケットごとの分波機能を提供します。

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.


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テーブルのコピーをポイントするオペレーティングシステムインデックスによって(例えば、getportbyname()のUnix、インデックス/ etc / servicesファイル内)またはいずれかによって決定されます直接マッピングを指定するアプリケーション。

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 1024..49151 "Registered", also called "user" ports, and

O 1024..49151「登録」とも呼ばれる「ユーザー」ポート、および

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


DCCP supports Well Known and Registered ports. These are allocated in the DCCP IANA Port Numbers registry ([RFC4340], Section 19.9). Each Registered DCCP port MUST be associated with at least one pre-defined Service Code.

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

よく知られまたは登録範囲内のサーバポートを使用する必要はありませんアプリケーションは、(すなわち、1 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).


2.2. DCCP Service Code Values
2.2. DCCPサービスコード値

DCCP specifies a 4-byte Service Code ([RFC4340], Section 8.1.2) represented in one of three forms: a decimal number (the canonical method), a 4-character ASCII string [ANSI.X3-4.1986], or an 8-digit hexadecimal number. All standards assigned Service Codes, including all values assigned by IANA, are required to use a value that may be represented using a subset of the ASCII character set. Private Service Codes do not need to follow this convention, although RFC 4340 suggests that users choose Service Codes that may also be represented in ASCII.

DCCPは、4バイトのサービスコードの3つの形式のいずれかで表される([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.


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リクエスト([RFC4340]、セクション5.2)とDCCP - 応答パケット([RFC4340]、セクション5.3)中に存在します。新しいDCCPパケットタイプ(例えば、[RFC5596])はまた、サービスコード値を運ぶことができることに留意されたいです。

2.2.1. New Versions of Applications or Protocols
2.2.1. アプリケーションやプロトコルの新バージョン

Applications/protocols that provide version negotiation or indication in the protocol operating over DCCP do not require a new server port or new Service Code for each new protocol version. New versions of such applications/protocols SHOULD continue to use the same Service Code. If the application developers feel that the new version provides significant new capabilities (e.g., that will change the behavior of middleboxes), they MAY allocate a new Service Code associated with the same or different set of Well Known ports. If the new Service Code is associated with a Well Known or Registered port, the DCCP Ports registry MUST also be updated to include the new Service Code value, but MAY share the same server port assignment(s).


2.3. Service Code Registry
2.3. サービスコードレジストリ

The set of registered Service Codes specified for use within the general Internet are defined in an IANA-controlled name space. IANA manages new allocations of Service Codes in this space [RFC4340]. Private Service Codes are not centrally allocated and are denoted by the decimal range 1056964608-1073741823 (i.e., 32-bit values with the high-order byte equal to a value of 63, corresponding to the ASCII character '?').

一般的なインターネット内で使用するために指定された登録済みのサービスコードのセットは、IANA制御名前空間で定義されています。 IANAは、このスペース[RFC4340]でサービスコードの新しい割り当てを管理します。プライベートサービスコードは、中央割り当てられていないと小数範囲によって1056964608から1073741823まで示されている(ASCII文字に対応し、63の値に等しい上位バイトで、すなわち、32ビット値を「?」)。

Associations of Service Code with Well Known ports are also defined in the IANA DCCP Port registry (Section 2.1).

ウェルノウンポートを備えたサービスコードの関連付けは、IANA DCCP Portレジストリ(セクション2.1)で定義されています。

2.4. Zero Service Code
2.4. ゼロサービスコード

A Service Code of zero is "permanently reserved (it represents the absence of a meaningful Service Code)" [RFC4340]. This indicates that no application information was provided. RFC 4340 states that applications MAY be associated with this Service Code in the same way as other Service Code values. This use is permitted for any server port.

ゼロのサービスコードは「永久(これは意味のあるサービスコードが存在しないことを表す)予約」されている[RFC4340]。これは何のアプリケーション情報が提供されなかったことを示しています。 RFC 4340は、アプリケーションが他のサービスコードの値と同じように、このサービスコードを関連付けることができると述べています。この使用は、任意のサーバポートに許可されています。

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

このドキュメントでは、次を追加することにより、RFC 4340のセクション19.8を明確に:

Applications SHOULD NOT use a Service Code of zero.


Application writers that need a temporary Service Code value SHOULD choose a value from the private range (Section 2.3).


Applications intended for deployment in the Internet are encouraged to use an IANA-defined Service Code. If no specific Service Code exists, they SHOULD request a new assignment from the IANA.


2.5. Invalid Service Code
2.5. 無効なサービスコード

RFC 4340 defines the Service Code value of 4294967295 in decimal (0xFFFFFFFF) as "invalid". This is provided so implementations can use a special 4-byte value to indicate "no valid Service Code". Implementations MUST NOT accept a DCCP-Request with this value, and SHOULD NOT allow applications to bind to this Service Code value [RFC4340].

RFC 4340には、「無効」として、小数(0xFFFFFFFFの)に4294967295のサービスコード値を定義します。実装は、「有効なサービスコード」を示していないために、特別な4バイトの値を使用することができますので、これが設けられています。実装は、この値を持つDCCP-Requestを受け入れてはいけません、そしてアプリケーションは、このサービスコード値[RFC4340]にバインドするために許してはなりません。

2.6. SDP for Describing Service Codes
2.6. SDPサービスコードの記述について

Methods that currently signal destination port numbers, such as the Session Description Protocol (SDP) [RFC4566], require an extension to support DCCP Service Codes [RTP-DCCP].


2.7. A Method to Hash the Service Code to a Dynamic Port
2.7. ダイナミックポートにサービスコードをハッシュする方法

Applications that do not use out-of-band signalling or an IANA-assigned port still require both the client and server to agree on the server port value to be used. This section describes an optional method that allows an application to derive a default server port number from the Service Code. The returned value is in the Dynamic port range [RFC4340]:


     int s_port; /* server port */
     s_port = ((sc[0]<<7)^(sc[1]<<5)^(sc[2]<<3)^sc[3]) | 0xC000;
     if (s_port==0xFFFF) {s_port = 0xC000;}

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]は最下位バイトです。サーバのポート64634とfdpz:たとえば、この機能は、SCを関連付けます。

This algorithm has the following properties:


o It identifies a default server port for each service.


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


o It preserves the 4 lowest bits of the final bytes of the Service Code, which allows many common series of Service Codes to be mapped to a set of adjacent port numbers, e.g., Foo1, and Foo2; Fooa and Foob would be assigned adjacent ports. (Note: this consecutive numbering only applies to characters in the range 0-9 and A-O and P-Z. When the characters cross a range boundary, the algorithm introduces a discontinuity, resulting in mapping to non-consecutive ports. Hence, Fooo and Foop respectively map to the decimal values of 65015 and 65000).

Oそれは、例えば、FOO1、およびfoo2は、隣接するポート番号のセットにマッピングされるサービスコードの多くの一般的な一連のできるサービスコードの最終バイトの最下位4ビットを保持し、 Fooaとfoob型は、隣接するポートを割り当てられます。 (注:この連続番号は文字だけが範囲境界を越えるとき、アルゴリズムは非連続的なポートへのマッピングをもたらす、不連続性を導入する範囲0-9とAO及びPZの文字に適用されるため、ザ・フー・コンスピラシー及びFoopそれぞれ。 65015および65000)の小数点以下の値にマッピングします。

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


Applications and higher-layer protocols that have been assigned a Service Code (or use a Service Code from the unassigned private space) may use this method. It does not preclude other applications using the selected server port, since DCCP servers are differentiated by the Service Code value.

アプリケーションとサービスコードを割り当て(または割り当てられていないプライベートな空間からサービスコードを使用して)このメソッドを使用することができますされている上位層プロトコル。 DCCPサーバがサービスコード値によって区別されているので、それは、選択したサーバーのポートを使用して、他のアプリケーションを排除するものではありません。

3. Use of the DCCP Service Code

The basic operation of Service Codes is as follows:


A client initiating a connection:


- issues a DCCP-Request with a Service Code and chooses a destination (server) port number that is expected to be associated with the specified Service Code at the destination.

- サービスコードとDCCP-Requestを発行し、先に指定されたサービスコードに関連することが期待されている宛先(サーバ)のポート番号を選択します。

A server that receives a DCCP-Request:


- determines whether an available service matching the Service Code is supported for the specified destination server port. The session is associated with the Service Code and a corresponding server. A DCCP-Response is returned.

- サービスコードに一致する利用可能なサービスは、指定した宛先サーバポートでサポートされているかどうかを決定します。セッションは、サービスコードとそれに対応するサーバーに関連付けられています。 DCCP-応答が返されます。

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

- サービスが利用できない場合、セッションは拒否され、DCCP-リセットパケットが返されます。

3.1. Setting Service Codes at the Client
3.1. クライアントにサービスコードを設定します

A client application MUST associate every DCCP connection (and hence every DCCP active socket) with a single Service Code value [RFC4340]). This value is used in the corresponding DCCP-Request packet.


3.2. Using Service Codes in the Network
3.2. ネットワークでのサービスコードを使用しました

DCCP connections identified by the Service Code continue to use IP addresses and ports, although neither port number may be Published.


Port numbers and IP addresses are the traditional methods to identify a flow within an IP network. Middlebox [RFC3234] implementors therefore need to note that new DCCP connections are identified by the pair of server port and Service Code in addition to the IP address. This means that the IANA may allocate a server port to more than one DCCP application [RFC4340].


Network address and port translators, known collectively as NATs [RFC2663], may interpret DCCP ports ([RFC2993] and [RFC5597]). They may also interpret DCCP Service Codes. Interpreting DCCP Service Codes can reduce the need to correctly interpret port numbers, leading to new opportunities for network address and port translators. Although it is encouraged to associate specific delivery properties with the Service Code, e.g., to identify the real-time nature of a flow that claims to be using RTP, there is no guarantee that the actual connection data corresponds to the associated Service Code. A middlebox implementor may still use deep packet inspection, and other means, in an attempt to verify the content of a connection.

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 A middlebox that does not modify the intended application (e.g., NATs [RFC5597] and Firewalls) MUST NOT change the Service Code.


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


3.3. Using Service Codes at the Server
3.3. サーバーでサービスコードを使用しました

The combination of the Service Code and server port disambiguates incoming DCCP-Requests received by a server. The Service Code is used to associate a new DCCP connection with the corresponding application service. Four cases can arise when two DCCP server applications passively listen on the same host:

サービスコードとサーバポートの組み合わせは、サーバーが受信した着信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 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.


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.


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.


It also adds:


o An implementation SHOULD provide a method that informs a server of the Service Code value that was selected by an active connection.


A single passively opened (listening) port MAY therefore be associated with multiple Service Codes, although an active (open) connection can only be associated with a single Service Code. A single application may wish to accept connections for more than one Service Code using the same server port. This may allow a server to offer more than the limit of 65,536 services depending on the size of the Port field. The upper limit is based solely on the number of unique connections between two hosts (i.e., 4,294,967,296).


3.3.1. Reception of a DCCP-Request
3.3.1. DCCP-要求の受信

When a DCCP-Request is received and the specified destination port is not bound to a server, the host MUST reject the connection by issuing a DCCP-Reset with the Reset Code "Connection Refused". A host MAY also use the Reset Code "Too Busy" ([RFC4340], Section 8.1.3).


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 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とDCCP-リセットパケットを送信することにより、要求を拒否すべきである、「悪いサービスコード」([RFC4340]、セクション8.1.2)が、 「接続が拒否」の理由を使用するかもしれません。

After a connection has been accepted, the protocol control block is associated with a pair of ports, a pair of IP addresses, and a single Service Code value.


3.3.2. Multiple Associations of a Service Code with Ports
3.3.2. ポートとサービスコードの複数のアソシエーション

DCCP Service Codes are not restricted to specific ports, although they may be associated with a specific Well Known port. This allows the same DCCP Service Code value to be associated with more than one server port (in either the active or passive state).


3.3.3. Automatically Launching a Server
3.3.3. 自動的にサーバを起動します

A host implementation may permit a service to be associated with a server port (or range of ports) that is not permanently running at the server. In this case, the arrival of a DCCP-Request may require a method to associate a DCCP-Request with a server that handles the corresponding Service Code. This operation could resemble that of "inetd" [inetd].


As in the previous section, when the specified Service Code is not associated with the specified server port, the connection MUST be aborted and a DCCP Reset message sent [RFC4340].


4. Security Considerations

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で指定されるようにDTLS [RFC5238]を使用する[RFC4347])。

There are four areas of security that are important:


1. Server Port number reuse (Section 4.1).

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

NATのファイアウォール(3.2節は、ミドルの動作を説明)2.相互作用。 DCCPに関する要件は、[RFC5597]に記載されています。

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


4. Interaction with IPsec and DTLS security (Section 4.3).
4.1. Server Port Number Reuse
4.1. サーバーのポート番号の再利用

Service Codes are used in addition to ports when demultiplexing incoming connections. This changes the service model to be used by applications and middleboxes. The Port Numbers registry already contains instances of multiple application registrations for a single port number for TCP and UDP. These are relatively rare. Since the DCCP Service Code allows multiple applications to safely share the same port number, even on the same host, server port number reuse in DCCP may be more common than in TCP and UDP.

着信接続を逆多重化する際に、サービスコードは、ポートに加えて使用されています。これは、アプリケーションやミドルボックスが使用するサービスモデルを変更します。ポート番号のレジストリは、すでにTCPとUDPのための単一のポート番号に複数のアプリケーション登録のインスタンスが含まれています。これらは比較的まれです。 DCCPサービスコードは、複数のアプリケーションを安全にしても、同じホスト上で、同じポート番号を共有することができますので、DCCPにおけるサーバーのポート番号の再利用は、TCPやUDPにおけるよりも一般的かもしれません。

4.2. Association of Applications with Service Codes
4.2. サービスコードを使用したアプリケーションの協会

The use of Service Codes provides more ready feedback that a concrete service is associated with a given port on a server than for a service that does not employ Service Codes. By responding to an inbound connection request, systems not using these codes may indicate that some service is, or is not, available on a given port, but systems using this mechanism immediately provide confirmation (or denial) that a particular service is present. This may have implications in terms of port scanning and reconnaissance.


Care needs to be exercised when interpreting the mapping of a Service Code value to the corresponding service. The same service (application) may be accessed using more than one Service Code. Examples include the use of separate Service Codes for an application layered directly upon DCCP and one using DTLS transport over DCCP [RFC5238]. Other possibilities include the use of a private Service Code to map to an application that has already been assigned an IANA-defined Service Code value, or multiple Service Code values that map to a single application providing more than one service. Different versions of a service (application) may also be mapped to a corresponding set of Service Code values.

ケアは、対応するサービスにサービスコード値のマッピングを解釈する際に行使する必要があります。同一のサービス(アプリケーション)は、複数のサービスコードを使用してアクセスすることができます。例としては、DCCP [RFC5238]上DCCP、1つはDTLSトランスポートを使用して上に直接積層アプリケーションのための別個のサービスコードの使用を含みます。他の可能性は、すでに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.


4.3. Interactions with IPsec
4.3. IPsecのとの相互作用

The Internet Key Exchange protocol (IKEv2) does not currently specify a method to use DCCP Service Codes as a part of the information used to set up an IPsec security association.


IPsec uses port numbers to perform access control in transport mode [RFC4301]. Security policies can define port-specific access control (PROTECT, BYPASS, DISCARD) as well as port-specific algorithms and keys. Similarly, firewall policies allow or block traffic based on port numbers.


Use of port numbers in IPsec selectors and firewalls may assume that the numbers correspond to Well Known services. It is useful to note that there is no such requirement; any service may run on any port, subject to mutual agreement between the endpoint hosts. Use of the Service Code may interfere with this assumption both within IPsec and within other firewall systems, but it does not add a new vulnerability. New implementations of IPsec and firewall systems may interpret the Service Code when implementing policy rules, but should not rely on either port numbers or Service Codes to indicate a specific service.

IPsecのセレクタやファイアウォールのポート番号を使用すると、数字はよく知られたサービスに対応することを仮定してもよいです。そのような要件が存在しないことに注意することは有益です。任意のサービスは、エンドポイントのホスト間の合意に従う、任意のポート上で実行することができます。サービスコードの使用は、IPsec内およびその他のファイアウォールシステム内の両方この仮定に干渉するかもしれないが、それは、新たな脆弱性を追加しません。 IPsecとファイアウォールシステムの新しい実装は、ポリシールールを実装する際にサービスコードを解釈するかもしれないが、特定のサービスを示すために、ポート番号またはサービス・コードのいずれかに依存しないでください。

5. IANA Considerations
5. IANAの考慮事項

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

RFC 4340で定義されたこの文書は、DCCPポート番号とDCCPサービスコードのレジストリのためのIANA配分手続きを更新しません。

For completeness, the document notes that it is not required to supply an approved document (e.g., a published RFC) to support an application for a DCCP Service Code or port number value, although RFCs may be used to request Service Code values via the IANA Considerations section. A specification is however required to allocate a Service Code that uses a combination of ASCII digits, uppercase letters, and character space, '-', '.', and '/') [RFC4340].

完全を期すため、文書は、RFCはIANAを経由してサービスコード値を要求するために使用することができるが、DCCPサービスコードまたはポート番号値のためのアプリケーションをサポートするために承認された文書(例えば、公表RFC)を供給するために必要とされていないことを指摘します留意事項セクション。 [RFC4340])、および 『/』「」 - 「」仕様はしかし、ASCII数字、大文字、および文字スペースの組み合わせを使用してサービスコードを割り当てることが必要です。

6. Acknowledgments

This work has been supported by the EC IST SatSix Project. Significant contributions to this document resulted from discussion with Joe Touch, and this is gratefully acknowledged. The author also thanks Ian McDonald, Fernando Gont, Eddie Kohler, and the DCCP WG for helpful comments on this topic, and Gerrit Renker for his help in determining DCCP behavior and review of this document. Mark Handley provided significant input to the text on the definition of Service Codes and their usage. He also contributed much of the material that has formed the historical background section.

この作品は、EC IST SatSixプロジェクトによって支えられてきました。このドキュメントへの重要な貢献は、ジョー・タッチとの議論の結果であり、これは深く感謝しています。 DCCPの挙動と、この文書の見直しを決定する上で彼の助けのための著者も感謝イアン・マクドナルド、フェルナンドGont、エディコーラー、このトピックに関する有益なコメントについてDCCP WG、およびゲリットRenker。マーク・ハンドリーは、サービスコードとその使用法の定義上のテキストに重要な入力を提供します。彼はまた、歴史的背景部分を形成している材料の多くを貢献しました。

7. References
7.1. Normative References
7.1. 引用規格

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

[RFC1122]ブレーデン、R.、エド、 "インターネットホストのための要件 - 通信層"。、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

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

[RFC4340]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル(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]デニス・Courmont、R.、 "ネットワークアドレス変換(NAT)データグラム輻輳制御プロトコルのための行動の要件"、BCP 150、RFC 5597、2009年9月。

7.2. Informative References
7.2. 参考文献

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

「 - 情報交換のための7ビットの米国標準コードコード化文字セット」、ANSI X3.4、1986 [ANSI.X3-4.1986]米国規格協会、。

[IANA] Internet Assigned Numbers Authority,


[RTP-DCCP] Perkins, C., "RTP and the Datagram Congestion Control Protocol (DCCP)", Work in Progress, June 2007.

[RTP-DCCP]パーキンス、C.、 "RTPおよびデータグラム輻輳制御プロトコル(DCCP)"、進歩、2007年6月に作業。

[Rand] Larsen, M. and F. Gont, "Port Randomization", Work in Progress, March 2009.

[ランド]ラーセン、M.とF. Gont、 "ポートランダム化"、進歩、2009年3月での作業。

[inetd] The extended inetd project,


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

[RFC768]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。

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

[RFC793]ポステル、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.とラオと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.ホールドレッジ、 "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]ブラドナー、S.とV.パクソン、 "インターネットプロトコルと関連ヘッダーの値のための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]ハイン、T.、 "NATの建築的意味"、RFC 2993、2000年11月。

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

[RFC3234]大工、B.とS.つば、 "のMiddleboxes:分類と課題"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "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、LA。、Degermark、M.、ピンク、S.、ジョンソン、LE。、編、及びG. Fairhurst、編、 "軽量ユーザーデータグラムプロトコル(UDP-Liteの)"、RFC 3828、 2004年7月。

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

[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。

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

[RFC4347]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティ"、RFC 4347、2006年4月。

[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.

[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP:セッション記述プロトコル"、RFC 4566、2006年7月。

[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.

[RFC4960]スチュワート、R.、エド。、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。

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

[RFC5238]フェラン、T.、RFC 5238、2008年5月、 "データグラム輻輳制御プロトコル(DCCP)を超えるデータグラムトランスポート層セキュリティ(DTLS)"。

[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 5596、2009年9月。

Author's Address


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

Godred Fairhurst、工学部、アバディーン大学、キングズカレッジ、アバディーン、AB24 3UE、英国の電子メールのURL: