RFC 10055 - Configuring UDP Sockets for Explicit Congestion Notification (ECN) for Common Platforms 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc10055.html
タイトル : RFC 10055 - 一般的なプラットフォームにおける明示的輻輳通知 (ECN) のためのUDPソケットの設定
翻訳編集 : 自動生成

[要約] Apple、Linux、Windows などの一般的なプラットフォームで、UDPソケットから明示的輻輳通知（ECN）を扱うためのAPIと設定方法を、Chromiumでの実験結果に基づいて記録した情報提供文書です。受信時にECNコードポイントを報告させるソケットの設定と、パケットごとの取得方法、送信時にソケット単位またはパケット単位でコードポイントを設定する方法を、プラットフォーム別に説明します。特定のAPIを規定するものではなく、執筆時点の状況の記録であり、QUICなどUDP上でECNを使う実装の支援を目的としています。

Internet Engineering Task Force (IETF)                           M. Duke
Request for Comments: 10055                                       Google
Category: Informational                                     October 2026
ISSN: 2070-1721

Configuring UDP Sockets for Explicit Congestion Notification (ECN) for Common Platforms

一般的なプラットフォームにおける明示的輻輳通知 (ECN) のためのUDPソケットの設定

Abstract

概要

Explicit Congestion Notification (ECN) applies to all transport protocols in principle. However, it had limited deployment for UDP until QUIC became widely adopted. As a result, documentation of UDP socket APIs for ECN on various platforms is sparse. This document records the results of experimenting with these APIs in order to get ECN working on UDP for Chromium on Apple, Linux, and Windows platforms.

明示的輻輳通知 (ECN) は、原理的にはすべてのトランスポートプロトコルに適用されます。しかし、QUICが広く採用されるまで、UDPでの展開は限定的でした。その結果、さまざまなプラットフォームにおけるECN向けUDPソケットAPIの文書化は乏しい状況です。本文書は、Apple、Linux、Windowsの各プラットフォーム上のChromiumでUDPのECNを動作させるために、これらのAPIを試行した結果を記録するものです。

This document provides a snapshot of the ECN state of affairs as supported by these platforms at the time of writing. Readers should refer to the documentation of the various platforms for more up-to-date information.

本文書は、執筆時点でこれらのプラットフォームがサポートしているECNの状況のスナップショットを提供します。より新しい情報については、読者は各プラットフォームの文書を参照してください。

Status of This Memo

本メモのステータス

This document is not an Internet Standards Track specification; it is published for informational purposes.

本文書はInternet Standards Trackの仕様ではなく、情報提供を目的として公開されるものです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.

本文書はInternet Engineering Task Force (IETF) の成果物です。IETFコミュニティの合意を表しています。公開レビューを受け、Internet Engineering Steering Group (IESG) により公開が承認されました。IESGが承認したすべての文書がいずれかのレベルのInternet Standardの候補となるわけではありません。RFC 7841のSection 2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc10055.

本文書の現在のステータス、正誤表、およびフィードバックの方法に関する情報は、https://www.rfc-editor.org/info/rfc10055 で入手できます。

Copyright Notice

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

本文書は、本文書の公開日に有効なBCP 78およびIETF Trustの IETF文書に関する法的規定 (https://trustee.ietf.org/license-info) の適用を受けます。これらの文書は本文書に関する権利と制限を記述しているため、注意深く確認してください。本文書から抽出されるコードコンポーネントには、Trust Legal ProvisionsのSection 4.eに記載されているRevised BSD Licenseの条文を含めなければならず、Revised BSD Licenseに記載されているとおり無保証で提供されます。

   1.  Introduction
   2.  Conventions and Definitions
   3.  Receiving ECN Codepoints
     3.1.  Setting the Socket to Report Incoming ECN Codepoints
       3.1.1.  Linux, Apple, and FreeBSD
       3.1.2.  Windows
     3.2.  Retrieving ECN Codepoints on Incoming Packets
       3.2.1.  Linux
       3.2.2.  Apple and FreeBSD
       3.2.3.  Windows
   4.  Sending ECN Codepoints
     4.1.  On a Per-Socket Basis
       4.1.1.  Apple, FreeBSD, and Linux
       4.1.2.  Windows
     4.2.  On a Per-Packet Basis
       4.2.1.  Apple, FreeBSD, and Linux
       4.2.2.  Windows
   5.  Security Considerations
   6.  IANA Considerations
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Acknowledgments
   Author's Address

1. Introduction

1. はじめに

[RFC3168] defines a 2-bit field in the IP header for Explicit Congestion Notification (ECN), which provides network feedback to endpoint congestion controllers. Historically, this has mostly been relevant to TCP [RFC9293], where any incoming ECN codepoints are internally consumed by the kernel and, therefore, imply no application interface except for enabling and disabling the capability.

[RFC3168] は、エンドポイントの輻輳制御器にネットワークからのフィードバックを提供する明示的輻輳通知 (ECN) のために、IPヘッダ内に2ビットのフィールドを定義しています。歴史的には、これは主にTCP [RFC9293] に関連するものでした。TCPでは、受信したECNコードポイントはカーネル内部で消費されるため、この機能の有効化と無効化を除いて、アプリケーションインタフェースは必要ありません。

The Stream Control Transmission Protocol (SCTP) [RFC9260] has long supported ECN in its design. SCTP is sometimes carried over DTLS and UDP [RFC8261]. In principle, user-space implementers might have leveraged UDP ECN APIs to deliver ECN codepoints between SCTP and the UDP socket. At the time of publication, the IETF is not aware of any such efforts.

Stream Control Transmission Protocol (SCTP) [RFC9260] は、設計当初からECNをサポートしてきました。SCTPは、DTLSおよびUDP上で運ばれることもあります [RFC8261]。原理的には、ユーザ空間の実装者がUDPのECN APIを活用して、SCTPとUDPソケットの間でECNコードポイントを受け渡すことも可能だったかもしれません。公開時点で、IETFはそのような取り組みを把握していません。

[RFC6679] defines ECN over RTP over UDP. The IETF is aware of a research implementation but cannot confirm any commercial deployments. [RFC8888] proposes a different feedback format to work with [RFC6679], and there are a few implementations of this.

[RFC6679] は、UDP上のRTPにおけるECNを定義しています。IETFは研究用の実装を把握していますが、商用での展開は確認できていません。[RFC8888] は、[RFC6679] と組み合わせて動作する別のフィードバック形式を提案しており、これについてはいくつかの実装があります。

QUIC [RFC9000] runs over UDP and has seen wider deployment than SCTP. The Low Latency, Low Loss, Scalable Throughput (L4S) architecture [RFC9330] and QUIC have combined to increase interest in ECN over UDP.

QUIC [RFC9000] はUDP上で動作し、SCTPよりも広く展開されています。Low Latency, Low Loss, Scalable Throughput (L4S) アーキテクチャ [RFC9330] とQUICが相まって、UDP上のECNへの関心が高まっています。

The Chromium Projects [CHROMIUM] provide a widely deployed protocol library that includes QUIC. An effort to provide ECN support for QUIC on the many platforms on which Chromium is deployed revealed that many ECN-related UDP socket interfaces are poorly documented.

Chromium Projects [CHROMIUM] は、QUICを含む広く展開されたプロトコルライブラリを提供しています。Chromiumが展開されている多くのプラットフォームでQUIC向けにECNサポートを提供する取り組みを通じて、ECNに関連するUDPソケットインタフェースの多くが十分に文書化されていないことが明らかになりました。

This Informational document provides a record of that experience to encourage further support for ECN in other QUIC implementations and any consumer of ECN codepoints that operates over UDP. It is not a Standards Track document and does not bind platforms to any API nor suggest any such API.

この情報提供文書 (Informational) は、他のQUIC実装や、UDP上で動作するECNコードポイントのあらゆる利用者におけるECNのさらなるサポートを促すため、その経験を記録するものです。本文書はStandards Trackの文書ではなく、プラットフォームに特定のAPIを課すものでも、そのようなAPIを提案するものでもありません。

Many socket APIs continue to reference the "ToS (Type of Service) byte", including the IP_TOS label, even though [RFC2474] obsoleted that in 1998. That 8-bit field now contains a 6-bit Differentiated Services Code Point (DSCP) and the 2-bit ECN field.

多くのソケットAPIは、[RFC2474] が1998年にこれを廃止したにもかかわらず、IP_TOSというラベルを含め、依然として「ToS (Type of Service) バイト」を参照しています。この8ビットのフィールドは現在、6ビットのDifferentiated Services Code Point (DSCP) と2ビットのECNフィールドを含んでいます。

This document focuses on the APIs for the C and C++ languages. Other languages are likely to have different syntax and capabilities.

本文書は、CおよびC++言語向けのAPIに焦点を当てています。他の言語では、構文や機能が異なる可能性があります。

The "ecn-examples" code repository [EXAMPLES] is extremely compact code that can verify the information in this document.

「ecn-examples」コードリポジトリ [EXAMPLES] は、本文書の情報を検証できる、極めて簡潔なコードです。

This document addresses access to the ECN field in the IP header via socket APIs. It does not address UDP transport-layer options [RFC9868], which are a separate extension mechanism operating at a different layer.

本文書は、ソケットAPIを介したIPヘッダ内のECNフィールドへのアクセスを扱います。UDPトランスポート層オプション [RFC9868] は扱いません。これは別の層で動作する、別個の拡張メカニズムです。

2. Conventions and Definitions

2. 表記と定義

This document is not a general tutorial on UDP socket programming and does assume familiarity with basic socket concepts like binding, socket options, and common system error codes.

本文書はUDPソケットプログラミングの一般的なチュートリアルではなく、バインド、ソケットオプション、一般的なシステムエラーコードといった基本的なソケットの概念に精通していることを前提としています。

Throughout this document, "Apple" refers to both macOS and iOS. "Linux" guidance also applies to Android.

本文書全体を通じて、「Apple」はmacOSとiOSの両方を指します。「Linux」に関する指針はAndroidにも当てはまります。

3. Receiving ECN Codepoints

3. ECNコードポイントの受信

Network devices can change the ECN codepoint in the IP header. Since this feedback is required at the packet sender, the packet receiver needs to extract this codepoint from the UDP socket in order to report to the sender.

ネットワーク機器は、IPヘッダ内のECNコードポイントを変更することがあります。このフィードバックはパケットの送信側で必要とされるため、パケットの受信側は、送信側に報告するために、UDPソケットからこのコードポイントを取り出す必要があります。

There are two components to this: 1) setting the socket to report incoming ECN marks and 2) retrieving the ECN codepoint for each incoming packet.

これには2つの要素があります。1) 受信したECNマークを報告するようにソケットを設定すること、2) 受信した各パケットのECNコードポイントを取得することです。

Note that Apple platforms additionally provide a framework for network connections that allows receiving ECN flags when using UDP without traditional socket option semantics. When sending or receiving UDP datagrams, IP protocol metadata carries ECN information in both directions. See [APPLE-NETWORK-FRAMEWORK].

Appleのプラットフォームは、従来のソケットオプションの意味論を用いずに、UDP使用時にECNフラグを受信できる、ネットワーク接続用のフレームワークも追加で提供している点に注意してください。UDPデータグラムの送信または受信時には、IPプロトコルのメタデータが双方向でECN情報を運びます。[APPLE-NETWORK-FRAMEWORK] を参照してください。

3.1. Setting the Socket to Report Incoming ECN Codepoints

3.1. 受信したECNコードポイントを報告するためのソケットの設定

3.1.1. Linux, Apple, and FreeBSD

3.1.1. Linux、Apple、FreeBSD

To receive ECN codepoints, applications set a socket option to "true" using a setsockopt() call.

ECNコードポイントを受信するために、アプリケーションはsetsockopt()呼び出しを使用してソケットオプションを「true」に設定します。

On all platforms, IPv4 sockets require the IPPROTO_IP-level socket option with the name IP_RECVTOS to be set.

すべてのプラットフォームで、IPv4ソケットには、名前がIP_RECVTOSであるIPPROTO_IPレベルのソケットオプションを設定する必要があります。

On all platforms, IPv6 sockets require the IPPROTO_IPV6-level socket option with the name IPV6_RECVTCLASS to be set.

すべてのプラットフォームで、IPv6ソケットには、名前がIPV6_RECVTCLASSであるIPPROTO_IPV6レベルのソケットオプションを設定する必要があります。

If the IPv6 socket is not IPv6 only, on Linux hosts it is required to also set the IPPROTO_IP-level socket option IP_RECVTOS to receive ECN codepoints for UDP/IPv4 packets. This step is not necessary for Apple or FreeBSD.

IPv6ソケットがIPv6 onlyでない場合、LinuxホストではUDP/IPv4パケットのECNコードポイントを受信するために、IPPROTO_IPレベルのソケットオプションIP_RECVTOSも設定する必要があります。この手順はAppleやFreeBSDでは不要です。

At the time of writing, an example implementation can be found at [CHROMIUM-POSIX].

執筆時点での実装例は、[CHROMIUM-POSIX] で参照できます。

3.1.2. Windows

Windows documentation recommends using the function WSASetRecvIPEcn() to enable ECN codepoint reporting regardless of the IP version. This function dates to Windows 10 Build 20348, according to [WINDOWS-DOC].

Windowsの文書では、IPバージョンにかかわらずECNコードポイントの報告を有効にするために、関数WSASetRecvIPEcn()の使用を推奨しています。[WINDOWS-DOC] によれば、この関数はWindows 10 Build 20348以降で提供されています。

However, this can also be accomplished by calling setsockopt() and using options of level IPPROTO_IP and name IP_RECVECN for IPv4 and level IPPROTO_IPV6 and name IPV6_RECVECN for IPv6. These options are documented at [WINDOWS-SOCKOPT].

ただし、setsockopt()を呼び出し、IPv4にはレベルIPPROTO_IPと名前IP_RECVECN、IPv6にはレベルIPPROTO_IPV6と名前IPV6_RECVECNのオプションを使用することでも、同じことを実現できます。これらのオプションは [WINDOWS-SOCKOPT] に記載されています。

For IPv6 sockets that are not IPv6 only, WSASetRecvIPEcn() will not enable ECN reporting for IPv4. This requires a separate setsockopt() call using the IP_RECVECN option.

IPv6 専用ではない IPv6 ソケットでは、WSASetRecvIPEcn() を呼び出しても IPv4 に対する ECN 報告は有効になりません。IPv4 に対して有効にするには、IP_RECVECN オプションを使った別の setsockopt() 呼び出しが必要です。

If a socket is bound to an IPv4-mapped IPv6 address (i.e., it is of the format ::ffff:<IPv4 address>; see Section 2.5.5.2 of [RFC4291]), then calls to WSASetRecvIpEcn() return the error EINVAL. These sockets should instead use an explicit setsockopt() call to set IP_RECVECN.

ソケットが IPv4 射影 IPv6 アドレス（すなわち ::ffff:<IPv4 address> の形式のアドレス。[RFC4291] のセクション 2.5.5.2 を参照）にバインドされている場合、WSASetRecvIpEcn() の呼び出しはエラー EINVAL を返します。このようなソケットでは、代わりに明示的な setsockopt() 呼び出しで IP_RECVECN を設定すべきです。

At the time of writing, an example implementation can be found at [CHROMIUM-WINDOWS].

本書の執筆時点では、実装例を [CHROMIUM-WINDOWS] で確認できます。

3.2. Retrieving ECN Codepoints on Incoming Packets

3.2. 受信パケットの ECN コードポイントの取得

All platforms described in this document require the use of a recvmsg() call to read data from the socket and to retrieve the ECN codepoint, because that information is provided as ancillary data. Those platforms all return zero or more "cmsg"s that contain requested information about the arriving packet.

本書で説明するすべてのプラットフォームでは、ソケットからデータを読み取り ECN コードポイントを取得するために recvmsg() の呼び出しが必要です。これは、その情報が補助データとして提供されるためです。これらのプラットフォームはいずれも、到着したパケットに関する要求された情報を含む "cmsg" を 0 個以上返します。

Examples of the technique described below can be found at [CHROMIUM-POSIX] and [CHROMIUM-WINDOWS].

以下に説明する手法の例は、[CHROMIUM-POSIX] と [CHROMIUM-WINDOWS] で確認できます。

3.2.1. Linux

If a UDP/IPv4 message is received, Linux will include a cmsg of level IPPROTO_IP and type IP_TOS. The cmsg data contains an unsigned char. This applies to IPv4 sockets and to IPv6 sockets that are not IPv6 only.

UDP/IPv4 メッセージを受信すると、Linux はレベル IPPROTO_IP、タイプ IP_TOS の cmsg を含めます。cmsg データには unsigned char が入っています。これは IPv4 ソケットと、IPv6 専用ではない IPv6 ソケットに適用されます。

If a UDP/IPv6 message is received, Linux will include a cmsg of level IPPROTO_IPV6 and type IPV6_TCLASS. The cmsg data contains an int. This applies to IPv6 sockets.

UDP/IPv6 メッセージを受信すると、Linux はレベル IPPROTO_IPV6、タイプ IPV6_TCLASS の cmsg を含めます。cmsg データには int が入っています。これは IPv6 ソケットに適用されます。

The cmsg data contains the entire IP header byte, which includes the DSCP and the ECN codepoint. The ECN codepoint constitutes the two least significant bits of this byte.

cmsg データには、DSCP と ECN コードポイントを含む IP ヘッダーのバイト全体が入っています。ECN コードポイントは、このバイトの下位 2 ビットです。

The same applies to the Linux-specific recvmmsg() call.

Linux 固有の recvmmsg() 呼び出しにも同じことが当てはまります。

3.2.2. Apple and FreeBSD

3.2.2. Apple と FreeBSD

If a UDP/IPv4 message is received on an IPv4 socket, the ancillary data will contain a cmsg of level IPPROTO_IP and type IP_RECVTOS. The cmsg data contains an unsigned char.

IPv4 ソケットで UDP/IPv4 メッセージを受信すると、補助データにはレベル IPPROTO_IP、タイプ IP_RECVTOS の cmsg が含まれます。cmsg データには unsigned char が入っています。

If a UDP/IPv6 or UDP/IPv4 message is received on an IPv6 socket, the ancillary data will contain a cmsg of level IPPROTO_IPV6 and type IPV6_TCLASS. The cmsg data contains an int.

IPv6 ソケットで UDP/IPv6 または UDP/IPv4 メッセージを受信すると、補助データにはレベル IPPROTO_IPV6、タイプ IPV6_TCLASS の cmsg が含まれます。cmsg データには int が入っています。

The cmsg data contains the entire IP header byte, which includes the DSCP and the ECN codepoint. The ECN codepoint constitutes the two least significant bits of this byte.

cmsg データには、DSCP と ECN コードポイントを含む IP ヘッダーのバイト全体が入っています。ECN コードポイントは、このバイトの下位 2 ビットです。

3.2.3. Windows

If the incoming packet is UDP/IPv4, the socket will include a cmsg of level IPPROTO_IP and type IP_ECN. The cmsg data contains an int.

受信パケットが UDP/IPv4 の場合、ソケットはレベル IPPROTO_IP、タイプ IP_ECN の cmsg を含めます。cmsg データには int が入っています。

If the incoming packet is UDP/IPv6, the socket will include a cmsg of level IPPROTO_IPV6 and type IPV6_ECN. The cmsg data contains an int.

受信パケットが UDP/IPv6 の場合、ソケットはレベル IPPROTO_IPV6、タイプ IPV6_ECN の cmsg を含めます。cmsg データには int が入っています。

The cmsg data solely consists of the ECN codepoint and requires no further bitwise operations.

cmsg データは ECN コードポイントのみで構成されており、それ以上のビット演算は不要です。

4. Sending ECN Codepoints

4. ECN コードポイントの送信

Existing ECN specifications ([RFC3168] and [RFC9330]) envision a particular connection that is consistently sending the same ECN codepoint. It might transition that marking after successfully completing a handshake, recognizing that the path or the peer does not support ECN or transitioning to a new path. Therefore, using a socket option to configure a consistent marking is generally more resource efficient.

既存の ECN 仕様（[RFC3168] と [RFC9330]）は、特定のコネクションが一貫して同じ ECN コードポイントを送信し続けることを想定しています。ハンドシェイクが正常に完了した後や、経路またはピアが ECN をサポートしていないと認識した場合、あるいは新しい経路へ移行する場合には、そのマーキングを切り替えることもあります。したがって、ソケットオプションを使って一貫したマーキングを設定する方が、一般にリソース効率が高くなります。

However, some server designs receive all incoming packets on a single socket. As the many connections that constitute this packet stream may have different support for ECN, it is suitable to provide the ECN codepoint on a per-packet basis.

しかし、サーバーの設計によっては、すべての受信パケットを単一のソケットで受信するものがあります。このパケットストリームを構成する多数のコネクションでは ECN のサポート状況が異なる可能性があるため、ECN コードポイントをパケット単位で指定できるようにするのが適切です。

Note that Apple platforms additionally provide a framework for network connections that allows sending ECN flags when using UDP without traditional socket option semantics. When sending or receiving UDP datagrams, IP protocol metadata carries ECN information in both directions. See [APPLE-NETWORK-FRAMEWORK].

Apple プラットフォームは、従来のソケットオプションの意味論を用いずに UDP 使用時に ECN フラグを送信できる、ネットワーク接続用のフレームワークも追加で提供していることに注意してください。UDP データグラムの送信時と受信時には、IP プロトコルのメタデータが双方向で ECN 情報を運びます。[APPLE-NETWORK-FRAMEWORK] を参照してください。

4.1. On a Per-Socket Basis

4.1. ソケット単位

4.1.1. Apple, FreeBSD, and Linux

4.1.1. Apple、FreeBSD、Linux

For sending UDP/IPv4 packets on an IPv4 socket, Apple, FreeBSD, and Linux platforms allow the outgoing ECN codepoint to be configured by using the IPPROTO_IP-level socket option with the name IP_TOS. The value has the type int.

IPv4 ソケットで UDP/IPv4 パケットを送信する場合、Apple、FreeBSD、Linux の各プラットフォームでは、IPPROTO_IP レベルの IP_TOS という名前のソケットオプションを使って、送信する ECN コードポイントを設定できます。値の型は int です。

For sending UDP/IPv6 packets on an IPv6 socket, Apple, FreeBSD, and Linux platforms allow the outgoing ECN codepoint to be configured by using the IPPROTO_IPV6-level socket option with the name IPV6_TCLASS. The value has the type int.

IPv6 ソケットで UDP/IPv6 パケットを送信する場合、Apple、FreeBSD、Linux の各プラットフォームでは、IPPROTO_IPV6 レベルの IPV6_TCLASS という名前のソケットオプションを使って、送信する ECN コードポイントを設定できます。値の型は int です。

For sending UDP/IPv4 packets on an IPv6 socket, Linux platforms allow the outgoing ECN codepoint to be configured by using the IPPROTO_IP-level socket option with the name IP_TOS.

IPv6 ソケットで UDP/IPv4 パケットを送信する場合、Linux プラットフォームでは、IPPROTO_IP レベルの IP_TOS という名前のソケットオプションを使って、送信する ECN コードポイントを設定できます。

For sending UDP/IPv4 packets on an IPv6 socket, Apple and FreeBSD platforms allow the outgoing ECN codepoint to be configured by using the IPPROTO_IPV6-level socket option with the name IPV6_TCLASS.

IPv6 ソケットで UDP/IPv4 パケットを送信する場合、Apple および FreeBSD プラットフォームでは、IPPROTO_IPV6 レベルの IPV6_TCLASS という名前のソケットオプションを使って、送信する ECN コードポイントを設定できます。

Except for Apple platforms, this setsockopt() call also sets the DSCP that comprises the rest of the header byte. Applications making this call ought to preserve any existing DSCP setting, which might require an additional getsockopt() call, to avoid overriding commands set by other code in the stack. If there are multiple threads making changes to this byte, further safeguards will be necessary.

Apple プラットフォームを除き、この setsockopt() 呼び出しは、ヘッダーバイトの残りの部分を構成する DSCP も設定します。この呼び出しを行うアプリケーションは、スタック内の他のコードが設定した指示を上書きしないよう、既存の DSCP 設定を保持すべきであり、そのためには追加の getsockopt() 呼び出しが必要になる場合があります。複数のスレッドがこのバイトを変更する場合は、さらなる保護策が必要になります。

An example of the technique described above can be found at [CHROMIUM-POSIX].

上記の手法の例は [CHROMIUM-POSIX] で確認できます。

4.1.2. Windows

At the time of this writing, Windows does not provide a way to configure marking on a per-socket basis.

本書の執筆時点では、Windows にはソケット単位でマーキングを設定する方法がありません。

4.2. On a Per-Packet Basis

4.2. パケット単位

Packets can be individually marked with ECN codepoints using the ancillary data that accompanies a sendmsg() call.

sendmsg() 呼び出しに付随する補助データを使って、個々のパケットに ECN コードポイントでマーキングできます。

4.2.1. Apple, FreeBSD, and Linux

4.2.1. Apple、FreeBSD、Linux

For sending UDP/IPv4 packets on an IPv4 socket, Apple, FreeBSD, and Linux use a cmsg with level IPPROTO_IP and type IP_TOS. On Apple and Linux, the type of data is int; and for FreeBSD, it is unsigned char.

IPv4 ソケットで UDP/IPv4 パケットを送信する場合、Apple、FreeBSD、Linux はレベル IPPROTO_IP、タイプ IP_TOS の cmsg を使います。データの型は、Apple と Linux では int、FreeBSD では unsigned char です。

For sending UDP/IPv6 packets on an IPv6 socket, Apple, FreeBSD, and Linux use a cmsg with level IPPROTO_IPV6 and type IPV6_TCLASS. The type of the data is int.

IPv6 ソケットで UDP/IPv6 パケットを送信する場合、Apple、FreeBSD、Linux はレベル IPPROTO_IPV6、タイプ IPV6_TCLASS の cmsg を使います。データの型は int です。

For sending UDP/IPv4 packets on an IPv6 socket, Linux requires a cmsg with level IPPROTO_IP and type IP_TOS. Apple and FreeBSD accept a cmsg with level IPPROTO_IPV6 and type IPV6_TCLASS.

IPv6 ソケットで UDP/IPv4 パケットを送信する場合、Linux ではレベル IPPROTO_IP、タイプ IP_TOS の cmsg が必要です。Apple と FreeBSD は、レベル IPPROTO_IPV6、タイプ IPV6_TCLASS の cmsg を受け付けます。

The same applies to the Linux-specific sendmmsg() call.

Linux 固有の sendmmsg() 呼び出しにも同じことが当てはまります。

4.2.2. Windows

For IPv4 packets, Windows uses a cmsg with level IPPROTO_IP and type IP_ECN.

IPv4パケットの場合、Windowsはレベルが IPPROTO_IP、タイプが IP_ECN の cmsg を使用します。

For IPv6 packets, Windows uses a cmsg with level IPPROTO_IPV6 and type IPV6_ECN.

IPv6パケットの場合、Windowsはレベルが IPPROTO_IPV6、タイプが IPV6_ECN の cmsg を使用します。

An example of the technique described above can be found at [CHROMIUM-WINDOWS].

上記の手法の例は [CHROMIUM-WINDOWS] にあります。

5. Security Considerations

5. セキュリティに関する考慮事項

The security implications of ECN are documented in [RFC3168] and [RFC9330]. This document is a guide to enabling these capabilities, which incurs no additional security considerations.

ECNのセキュリティ上の影響は [RFC3168] と [RFC9330] に記載されています。本文書はこれらの機能を有効にするためのガイドであり、追加のセキュリティ上の考慮事項は生じません。

Note that implementing ECN capabilities on some platforms, but not others, can help peers identify the operating system in use by a host, which can have privacy implications. This document aims to mitigate that possibility.

一部のプラットフォームでECN機能を実装し、他では実装しない場合、ピアがホストの使用しているオペレーティングシステムを識別しやすくなる可能性があり、プライバシー上の影響が生じうることに注意してください。本文書は、その可能性を軽減することを目的としています。

6. IANA Considerations

6. IANAに関する考慮事項

This document has no IANA actions.

本文書にはIANAへの要請事項はありません。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              DOI 10.17487/RFC2474, December 1998,
              <https://www.rfc-editor.org/info/rfc2474>.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, DOI 10.17487/RFC3168, September 2001,
              <https://www.rfc-editor.org/info/rfc3168>.

   [RFC9330]  Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G.
              White, "Low Latency, Low Loss, and Scalable Throughput
              (L4S) Internet Service: Architecture", RFC 9330,
              DOI 10.17487/RFC9330, January 2023,
              <https://www.rfc-editor.org/info/rfc9330>.

7.2. Informative References

7.2. 参考引用

   [APPLE-NETWORK-FRAMEWORK]
              "NWProtocolIP.Metadata",
              <https://developer.apple.com/documentation/network/
              nwprotocolip/metadata>.

   [CHROMIUM] "The Chromium Projects",
              <https://www.chromium.org/chromium-projects/>.

   [CHROMIUM-POSIX]
              "udp_socket_posix.cc", commit 6bdc14d, 19 June 2026,
              <https://source.chromium.org/chromium/chromium/
              src/+/main:net/socket/udp_socket_posix.cc>.

   [CHROMIUM-WINDOWS]
              "udp_socket_win.cc", commit 85a1d1c, 10 June 2026,
              <https://source.chromium.org/chromium/chromium/
              src/+/main:net/socket/udp_socket_win.cc>.

   [EXAMPLES] "ecn-examples", commit 39e39bf, 1 December 2025,
              <https://github.com/nplab/ecn-examples>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC6679]  Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
              and K. Carlberg, "Explicit Congestion Notification (ECN)
              for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
              2012, <https://www.rfc-editor.org/info/rfc6679>.

   [RFC8261]  Tuexen, M., Stewart, R., Jesup, R., and S. Loreto,
              "Datagram Transport Layer Security (DTLS) Encapsulation of
              SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November
              2017, <https://www.rfc-editor.org/info/rfc8261>.

   [RFC8888]  Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP
              Control Protocol (RTCP) Feedback for Congestion Control",
              RFC 8888, DOI 10.17487/RFC8888, January 2021,
              <https://www.rfc-editor.org/info/rfc8888>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/info/rfc9000>.

   [RFC9260]  Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control
              Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260,
              June 2022, <https://www.rfc-editor.org/info/rfc9260>.

   [RFC9293]  Eddy, W., Ed., "Transmission Control Protocol (TCP)",
              STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
              <https://www.rfc-editor.org/info/rfc9293>.

   [RFC9868]  Touch, J. and C. Heard, Ed., "Transport Options for UDP",
              RFC 9868, DOI 10.17487/RFC9868, October 2025,
              <https://www.rfc-editor.org/info/rfc9868>.

   [WINDOWS-DOC]
              "WSASetRecvIPEcn function (ws2tcpip.h)", 22 February 2024,
              <https://learn.microsoft.com/en-
              us/windows/win32/api/ws2tcpip/nf-ws2tcpip-
              wsasetrecvipecn>.

   [WINDOWS-SOCKOPT]
              "MSDN - IPPROTO_IP socket options", 7 May 2026,
              <https://learn.microsoft.com/en-us/windows/win32/winsock/
              ipproto-ip-socket-options>.

Acknowledgments

謝辞

The author would like to thank Ryan Hamilton, who provided constant advice through this effort. Randall Meyer from Apple and Nick Grifka from Microsoft provided useful hints about the behavior of their respective operating systems. However, the author takes full responsibility for any errors above.

著者は、この取り組みを通じて常に助言をくださった Ryan Hamilton に感謝します。Apple の Randall Meyer と Microsoft の Nick Grifka は、それぞれのオペレーティングシステムの挙動について有益なヒントを提供してくれました。ただし、上記の誤りについては、著者がすべての責任を負います。

Michael Tüxen wrote the "ecn-examples" code that was very helpful in verifying the conclusions in this document. He also made multiple editorial contributions.

Michael Tüxen は、本文書の結論を検証する上で非常に役立った "ecn-examples" のコードを書きました。また、複数の編集上の貢献もしてくれました。

Neal Cardwell, Gorry Fairhurst, Max Franke, Rodney Grimes, Will Hawkins, Guillaume Hétier, Max Inden, Jonathan Lennox, Colin Perkins, Marten Seemann, and Greg White made improvements to this document.

Neal Cardwell、Gorry Fairhurst、Max Franke、Rodney Grimes、Will Hawkins、Guillaume Hétier、Max Inden、Jonathan Lennox、Colin Perkins、Marten Seemann、Greg White は、本文書の改善に貢献しました。

Author's Address

著者の連絡先

   Martin Duke
   Google
   Email: martin.h.duke@gmail.com

RFC 10055 - Configuring UDP Sockets for Explicit Congestion Notification (ECN) for Common Platforms 日本語訳

Configuring UDP Sockets for Explicit Congestion Notification (ECN) for Common Platforms

一般的なプラットフォームにおける明示的輻輳通知 (ECN) のためのUDPソケットの設定

Abstract

概要

Status of This Memo

本メモのステータス

Copyright Notice

著作権表示

Table of Contents

目次

1. Introduction

1. はじめに

2. Conventions and Definitions

2. 表記と定義

3. Receiving ECN Codepoints

3. ECNコードポイントの受信

3.1. Setting the Socket to Report Incoming ECN Codepoints

3.1. 受信したECNコードポイントを報告するためのソケットの設定

3.1.1. Linux, Apple, and FreeBSD

3.1.1. Linux、Apple、FreeBSD

3.1.2. Windows

3.1.2. Windows

3.2. Retrieving ECN Codepoints on Incoming Packets

3.2. 受信パケットの ECN コードポイントの取得

3.2.1. Linux

3.2.1. Linux

3.2.2. Apple and FreeBSD

3.2.2. Apple と FreeBSD

3.2.3. Windows

3.2.3. Windows

4. Sending ECN Codepoints

4. ECN コードポイントの送信

4.1. On a Per-Socket Basis

4.1. ソケット単位

4.1.1. Apple, FreeBSD, and Linux

4.1.1. Apple、FreeBSD、Linux

4.1.2. Windows

4.1.2. Windows

4.2. On a Per-Packet Basis

4.2. パケット単位

4.2.1. Apple, FreeBSD, and Linux

4.2.1. Apple、FreeBSD、Linux

4.2.2. Windows

4.2.2. Windows

5. Security Considerations

5. セキュリティに関する考慮事項

6. IANA Considerations

6. IANAに関する考慮事項

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

7.2. Informative References

7.2. 参考引用

Acknowledgments

謝辞

Author's Address

著者の連絡先