RFC 8304 - Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8304
タイトル : RFC 8304 - ユーザーデータグラムプロトコル（UDP）および軽量UDP（UDP-Lite）のトランスポート機能
翻訳編集 : 自動生成

[要約] RFC 8304は、UDPとUDP-Liteのトランスポート機能に関する情報を提供する。目的は、これらのプロトコルの特徴と利点を理解し、ネットワーク通信の効率性と信頼性を向上させることである。

Internet Engineering Task Force (IETF)                      G. Fairhurst
Request for Comments: 8304                                      T. Jones
Category: Informational                           University of Aberdeen
ISSN: 2070-1721                                            February 2018

Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite)

ユーザーデータグラムプロトコル（UDP）および軽量UDP（UDP-Lite）のトランスポート機能

Abstract

概要

This is an informational document that describes the transport protocol interface primitives provided by the User Datagram Protocol (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport protocols. It identifies the datagram services exposed to applications and how an application can configure and use the features offered by the Internet datagram transport service. RFC 8303 documents the usage of transport features provided by IETF transport protocols, describing the way UDP, UDP-Lite, and other transport protocols expose their services to applications and how an application can configure and use the features that make up these services. This document provides input to and context for that document, as well as offers a road map to documentation that may help users of the UDP and UDP-Lite protocols.

これは、ユーザーデータグラムプロトコル（UDP）およびライトウェイトユーザーデータグラムプロトコル（UDP-Lite）トランスポートプロトコルによって提供されるトランスポートプロトコルインターフェイスプリミティブについて説明する情報ドキュメントです。これは、アプリケーションに公開されているデータグラムサービスと、アプリケーションがインターネットデータグラムトランスポートサービスによって提供される機能を構成および使用する方法を識別します。 RFC 8303は、IETFトランスポートプロトコルによって提供されるトランスポート機能の使用法を文書化し、UDP、UDP-Lite、および他のトランスポートプロトコルがアプリケーションにサービスを公開する方法と、アプリケーションがこれらのサービスを構成する機能を構成および使用する方法を説明します。このドキュメントは、そのドキュメントへの入力とコンテキストを提供するだけでなく、UDPおよびUDP-Liteプロトコルのユーザーに役立つドキュメントへのロードマップを提供します。

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 a candidate for any level of Internet Standard; see Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション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/rfc8304.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8304で入手できます。

著作権表示

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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  UDP and UDP-Lite Primitives . . . . . . . . . . . . . . . . .   4
     3.1.  Primitives Provided by UDP  . . . . . . . . . . . . . . .   4
       3.1.1.  Excluded Primitives . . . . . . . . . . . . . . . . .  11
     3.2.  Primitives Provided by UDP-Lite . . . . . . . . . . . . .  12
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Appendix A.  Multicast Primitives . . . . . . . . . . . . . . . .  17
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1. Introduction

1. はじめに

This document presents defined interactions between transport protocols and applications in the form of 'primitives' (function calls) for the User Datagram Protocol (UDP) [RFC0768] and the Lightweight User Datagram Protocol (UDP-Lite) [RFC3828]. In this usage, the word application refers to any program built on the datagram interface, including tunnels and other upper-layer protocols that use UDP and UDP-Lite.

このドキュメントでは、ユーザーデータグラムプロトコル（UDP）[RFC0768]およびライトウェイトユーザーデータグラムプロトコル（UDP-Lite）[RFC3828]の「プリミティブ」（関数呼び出し）の形式で、トランスポートプロトコルとアプリケーション間の定義された相互作用について説明します。この使用法では、アプリケーションという用語は、UDPおよびUDP-Liteを使用するトンネルおよびその他の上位層プロトコルを含む、データグラムインターフェイス上に構築されたすべてのプログラムを指します。

UDP is widely implemented and deployed. It is used for a wide range of applications. A special class of applications can derive benefit from having partially damaged payloads delivered, rather than discarded, when using paths that include error-prone links. Applications that can tolerate payload corruption can choose to use UDP-Lite instead of UDP and use the application programming interface (API) to control checksum protection. Conversely, UDP applications could choose to use UDP-Lite, but this is currently less widely deployed, and users could encounter paths that do not support UDP-Lite. These topics are discussed more in Section 3.4 of "UDP Usage Guidelines" [RFC8085].

UDPは広く実装および展開されています。幅広い用途に使用されています。エラーが発生しやすいリンクを含むパスを使用する場合、特別なクラスのアプリケーションは、ペイロードが破棄されるのではなく、部分的に破損していることからメリットを引き出すことができます。ペイロードの破損を許容できるアプリケーションは、UDPの代わりにUDP-Liteを使用することを選択し、アプリケーションプログラミングインターフェイス（API）を使用してチェックサム保護を制御できます。逆に、UDPアプリケーションはUDP-Liteの使用を選択できますが、これは現在それほど広く展開されておらず、UDP-Liteをサポートしないパスに遭遇する可能性があります。これらのトピックについては、「UDP使用ガイドライン」[RFC8085]のセクション3.4で詳しく説明しています。

The IEEE standard API for TCP/IP applications is the "socket" interface [POSIX]. An application can use the recv() and send() POSIX functions as well as the recvfrom(), sendto(), recvmsg(), and sendmsg() functions. The UDP and UDP-Lite sockets API differs from that for TCP in several key ways. (Examples of usage of this API are provided in [STEVENS].) In UDP and UDP-Lite, each datagram is a self-contained message of a specified length, and options at the transport layer can be used to set properties for all subsequent datagrams sent using a socket or changed for each datagram. For datagrams, this can require the application to use the API to set IP-level information (IP Time To Live (TTL), Differentiated Services Code Point (DSCP), IP fragmentation, etc.) for the datagrams it sends and receives. In contrast, when using TCP and other connection-oriented transports, the IP-level information normally either remains the same for the duration of a connection or is controlled by the transport protocol rather than the application.

TCP / IPアプリケーションのIEEE標準APIは、「ソケット」インターフェース[POSIX]です。アプリケーションは、recv()およびsend()POSIX関数、ならびにrecvfrom()、sendto()、recvmsg()、およびsendmsg()関数を使用できます。 UDPおよびUDP-LiteソケットAPIは、いくつかの重要な点でTCPのAPIと異なります。（このAPIの使用例は[STEVENS]で提供されています。）UDPおよびUDP-Liteでは、各データグラムは指定された長さの自己完結型メッセージであり、トランスポート層のオプションを使用して以降のすべてのプロパティを設定できます。ソケットを使用して送信された、またはデータグラムごとに変更されたデータグラム。データグラムの場合、これにより、アプリケーションはAPIを使用して、送受信するデータグラムのIPレベル情報（IP存続時間（TTL）、DiffServコードポイント（DSCP）、IPフラグメンテーションなど）を設定する必要があります。対照的に、TCPおよびその他の接続指向のトランスポートを使用する場合、IPレベルの情報は通常、接続の間同じままであるか、アプリケーションではなくトランスポートプロトコルによって制御されます。

Socket options are used in the sockets API to provide additional functions. For example, the IP_RECVTTL socket option is used by some UDP multicast applications to return the IP TTL field from the IP header of a received datagram.

ソケットオプションは、追加機能を提供するためにソケットAPIで使用されます。たとえば、一部のUDPマルチキャストアプリケーションでは、IP_RECVTTLソケットオプションを使用して、受信したデータグラムのIPヘッダーからIP TTLフィールドを返します。

Some platforms also offer applications the ability to directly assemble and transmit IP packets through "raw sockets" or similar facilities. The raw sockets API is a second, more cumbersome, method to send UDP datagrams. The use of this API is discussed in the RFC series in the UDP Guidelines [RFC8085].

一部のプラットフォームでは、「生のソケット」または同様の機能を介してIPパケットを直接組み立てて送信する機能もアプリケーションに提供します。 rawソケットAPIは、UDPデータグラムを送信するための2番目の、より面倒な方法です。このAPIの使用については、UDPガイドライン[RFC8085]のRFCシリーズで説明されています。

The list of transport service features and primitives in this document is strictly based on the parts of protocol specifications in the RFC series that relate to what the transport protocol provides to an application that uses it and how the application interacts with the transport protocol. Primitives can be invoked by an application or a transport protocol; the latter type is called an "event".

このドキュメントのトランスポートサービスの機能とプリミティブのリストは、RFCシリーズのプロトコル仕様のうち、トランスポートプロトコルがそれを使用するアプリケーションに提供するものと、アプリケーションがトランスポートプロトコルと対話する方法に関連する部分に厳密に基づいています。プリミティブは、アプリケーションまたはトランスポートプロトコルによって呼び出すことができます。後者のタイプは「イベント」と呼ばれます。

The description in Section 3 follows the methodology defined by the IETF TAPS Working Group in [RFC8303]. Specifically, this document provides the first pass of this process, which discusses the relevant RFC text describing primitives for each protocol. [RFC8303] uses this input to document the usage of transport features provided by IETF transport protocols, describing the way UDP, UDP-Lite, and other transport protocols expose their services to applications and how an application can configure and use the features that make up these services.

セクション3の説明は、[RFC8303]のIETF TAPSワーキンググループによって定義された方法論に従います。具体的には、このドキュメントはこのプロセスの最初のパスを提供し、各プロトコルのプリミティブを説明する関連RFCテキストについて説明します。 [RFC8303]は、この入力を使用して、IETFトランスポートプロトコルによって提供されるトランスポート機能の使用法を文書化し、UDP、UDP-Lite、および他のトランスポートプロトコルがアプリケーションにサービスを公開する方法と、アプリケーションが構成する機能を構成および使用する方法を説明しますこれらのサービス。

The presented road map to documentation of the transport interface may also help developers working with UDP and UDP-Lite.

提示されたトランスポートインターフェイスのドキュメントへのロードマップは、UDPおよびUDP-Liteを使用する開発者にも役立ちます。

2. Terminology

2. 用語

This document provides details for the pass 1 analysis of UDP and UDP-Lite that is used in "On the Usage of Transport Features Provided by IETF Transport Protocols" [RFC8303]. It uses common terminology defined in that document and also quotes RFCs that use the terminology of RFC 2119 [RFC2119].

このドキュメントは、「IETFトランスポートプロトコルによって提供されるトランスポート機能の使用について」[RFC8303]で使用されるUDPおよびUDP-Liteのパス1分析の詳細を提供します。そのドキュメントで定義されている一般的な用語を使用し、RFC 2119 [RFC2119]の用語を使用するRFCも引用しています。

3. UDP and UDP-Lite Primitives

3. UDPおよびUDP-Liteプリミティブ

UDP [RFC0768] [RFC8200] and UDP-Lite [RFC3828] are IETF Standards Track transport protocols. These protocols provide unidirectional, datagram services, supporting transmit and receive operations that preserve message boundaries.

UDP [RFC0768] [RFC8200]およびUDP-Lite [RFC3828]は、IETF Standards Trackトランスポートプロトコルです。これらのプロトコルは、単一方向のデータグラムサービスを提供し、メッセージの境界を保持する送受信操作をサポートします。

This section summarizes the relevant text parts of the RFCs describing the UDP and UDP-Lite protocols, focusing on what the transport protocols provide to the application and how the transport is used (based on abstract API descriptions, where they are available). It describes how UDP is used with IPv4 or IPv6 to send unicast or anycast datagrams and is used to send broadcast datagrams for IPv4. A set of network-layer primitives required to use UDP or UDP-Lite with IP multicast (for IPv4 and IPv6) have been specified in the RFC series. Appendix A describes where to find documentation for network-layer primitives required to use UDP or UDP-Lite with IP multicast (for IPv4 and IPv6).

このセクションでは、UDPおよびUDP-Liteプロトコルを説明するRFCの関連テキスト部分を要約し、トランスポートプロトコルがアプリケーションに提供するものとトランスポートがどのように使用されるかに焦点を当てています（利用可能な場合、抽象的なAPIの説明に基づく）。 UDPをIPv4またはIPv6で使用してユニキャストまたはエニーキャストデータグラムを送信する方法と、IPv4のブロードキャストデータグラムを送信する方法について説明します。 RFCシリーズでは、IPマルチキャスト（IPv4およびIPv6用）でUDPまたはUDP-Liteを使用するために必要な一連のネットワーク層プリミティブが指定されています。付録Aでは、IPマルチキャスト（IPv4およびIPv6の場合）でUDPまたはUDP-Liteを使用するために必要なネットワーク層プリミティブのドキュメントの場所について説明します。

3.1. Primitives Provided by UDP

3.1. UDPが提供するプリミティブ

"User Datagram Protocol" [RFC0768] states:

「ユーザーデータグラムプロトコル」[RFC0768]は次のように述べています。

This User Datagram Protocol (UDP) is defined to make available a datagram mode of packet-switched computer communication in the environment of an interconnected set of computer networks...This protocol provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism.

このユーザーデータグラムプロトコル（UDP）は、相互接続されたコンピューターネットワークのセットの環境でパケット交換コンピューター通信のデータグラムモードを利用できるように定義されています...このプロトコルは、アプリケーションプログラムが他のプログラムにメッセージを送信する手順を提供します。プロトコルメカニズムの最小値。

The User Interface section of RFC 768 states that the user interface to an application should allow

RFC 768のユーザーインターフェイスセクションには、アプリケーションへのユーザーインターフェイスで許可する必要があると記載されています

the creation of new receive ports, receive operations on the receive ports that return the data octets and an indication of source port and source address, and an operation that allows a datagram to be sent, specifying the data, source and destination ports and addresses to be sent.

新しい受信ポートの作成、データオクテットと送信元ポートと送信元アドレスの表示を返す受信ポートでの受信操作、およびデータグラムの送信を許可する操作。データ、送信元と宛先のポートとアドレスを指定します。送信されます。

UDP has been defined for IPv6 [RFC8200], together with API extensions for "Basic Socket Interface Extensions for IPv6" [RFC3493].

UDPは、「IPv6の基本ソケットインターフェイス拡張」[RFC3493]のAPI拡張とともに、IPv6 [RFC8200]に対して定義されています。

[RFC6935] and [RFC6936] define an update to the UDP transport originally specified in [RFC2460] (note that RFC 2460 has been obsoleted by RFC 8200). This enables use of a zero UDP checksum mode with a tunnel protocol, providing that the method satisfies the requirements in the corresponding applicability statement [RFC6936].

[RFC6935]と[RFC6936]は、[RFC2460]で最初に指定されたUDPトランスポートの更新を定義します（RFC 2460はRFC 8200で廃止されていることに注意してください）。これにより、対応する適用性ステートメント[RFC6936]の要件をメソッドが満たす場合、トンネルプロトコルでゼロUDPチェックサムモードを使用できます。

UDP offers only a basic transport interface. UDP datagrams may be directly sent and received, without exchanging messages between the endpoints to set up a connection (i.e., no handshake is performed by the transport protocol prior to communication). Using the sockets API, applications can receive packets from more than one IP source address on a single UDP socket. Common support allows specification of the local IP address, destination IP address, local port, and destination port values. Any or all of these can be indicated, with defaults supplied by the local system when these are not specified. The local endpoint address is set using the BIND call. At the remote end, the remote endpoint address is set using the CONNECT call. The CLOSE function has local significance only. It does not impact the status of the remote endpoint.

UDPは基本的なトランスポートインターフェイスのみを提供します。接続を設定するためにエンドポイント間でメッセージを交換せずに、UDPデータグラムを直接送受信できます（つまり、通信の前にトランスポートプロトコルによってハンドシェイクが実行されません）。ソケットAPIを使用すると、アプリケーションは単一のUDPソケットで複数のIP送信元アドレスからパケットを受信できます。共通サポートにより、ローカルIPアドレス、宛先IPアドレス、ローカルポート、および宛先ポートの値を指定できます。これらのいずれかまたはすべてを指定できます。デフォルトが指定されていない場合は、ローカルシステムによってデフォルトが提供されます。ローカルエンドポイントアドレスは、BIND呼び出しを使用して設定されます。リモートエンドでは、リモートエンドポイントアドレスはCONNECT呼び出しを使用して設定されます。 CLOSE関数はローカルでのみ意味があります。リモートエンドポイントのステータスには影響しません。

Neither UDP nor UDP-Lite provide congestion control, retransmission, or mechanisms for application-level packetization that would avoid IP fragmentation and other transport functions. This means that applications using UDP need to provide additional functions on top of the UDP transport API [RFC8085]. Some transport functions require parameters to be passed through the API to control the network layer (IPv4 or IPv6). These additional primitives could be considered a part of the network layer (e.g., control of the setting of the Don't Fragment (DF) flag on a transmitted IPv4 datagram) but are nonetheless essential to allow a user of the UDP API to implement functions that are normally associated with the transport layer (such as probing for the path maximum transmission size). This document includes such primitives.

UDPもUDP-Liteも、IPの断片化やその他のトランスポート機能を回避するアプリケーションレベルのパケット化のための輻輳制御、再送信、またはメカニズムを提供していません。つまり、UDPを使用するアプリケーションは、UDPトランスポートAPI [RFC8085]に加えて追加の機能を提供する必要があります。一部のトランスポート関数では、ネットワーク層（IPv4またはIPv6）を制御するために、APIを介してパラメーターを渡す必要があります。これらの追加のプリミティブは、ネットワーク層の一部（たとえば、送信されたIPv4データグラムのフラグメントしない（DF）フラグの設定の制御）と見なすことができますが、UDP APIのユーザーが機能を実装できるようにするために不可欠ですこれらは通常、トランスポート層に関連付けられています（パスの最大伝送サイズのプローブなど）。このドキュメントには、そのようなプリミティブが含まれています。

Guidance on the use of the services provided by UDP is provided in the UDP Guidelines [RFC8085]. This also states that

UDPによって提供されるサービスの使用に関するガイダンスは、UDPガイドライン[RFC8085]で提供されています。これはまた

many operating systems also allow a UDP socket to be connected, i.e., to bind a UDP socket to a specific pair of addresses and ports. This is similar to the corresponding TCP sockets API functionality. However, for UDP, this is only a local operation that serves to simplify the local send/receive functions and to filter the traffic for the specified addresses and ports. Binding a UDP socket does not establish a connection -- UDP does not notify the remote end when a local UDP socket is bound. Binding a socket also allows configuring options that affect the UDP or IP layers, for example, use of the UDP checksum or the IP Timestamp option. On some stacks, a bound socket also allows an application to be notified when ICMP error messages are received for its transmissions [RFC1122].

多くのオペレーティングシステムでは、UDPソケットを接続することもできます。つまり、UDPソケットを特定のアドレスとポートのペアにバインドします。これは、対応するTCPソケットAPI機能に似ています。ただし、UDPの場合、これはローカルの送受信機能を簡素化し、指定されたアドレスとポートのトラフィックをフィルタリングするためのローカル操作にすぎません。 UDPソケットをバインドしても接続は確立されません-UDPは、ローカルUDPソケットがバインドされたときにリモートエンドに通知しません。ソケットをバインドすると、UDPまたはIPレイヤーに影響を与えるオプション（UDPチェックサムやIPタイムスタンプオプションの使用など）も構成できます。一部のスタックでは、バインドされたソケットを使用して、ICMPエラーメッセージが送信されたときにアプリケーションに通知することもできます[RFC1122]。

The POSIX Base Specifications [POSIX] define an API that offers mechanisms for an application to receive asynchronous data events at the socket layer. Calls such as "poll", "select", or "queue" allow an application to be notified when data has arrived at a socket or when a socket has flushed its buffers.

POSIX基本仕様[POSIX]は、アプリケーションがソケットレイヤーで非同期データイベントを受信するためのメカニズムを提供するAPIを定義します。「poll」、「select」、または「queue」などの呼び出しにより、データがソケットに到着したとき、またはソケットがバッファーをフラッシュしたときに、アプリケーションに通知することができます。

A callback-driven API to the network interface can be structured on top of these calls. Implicit connection setup allows an application to delegate connection life management to the transport API. The transport API uses protocol primitives to offer the automated service to the application via the sockets API. By combining UDP primitives (CONNECT.UDP and SEND.UDP), a higher-level API could offer a similar service.

ネットワークインターフェースへのコールバック駆動型APIは、これらの呼び出しの上に構築できます。暗黙的な接続セットアップにより、アプリケーションは接続寿命の管理をトランスポートAPIに委任できます。トランスポートAPIは、プロトコルプリミティブを使用して、ソケットAPI経由でアプリケーションに自動化サービスを提供します。 UDPプリミティブ（CONNECT.UDPとSEND.UDP）を組み合わせることにより、より高レベルのAPIが同様のサービスを提供できます。

The following datagram primitives are specified:

次のデータグラムプリミティブが指定されています。

CONNECT: The CONNECT primitive allows the association of source and destination port sets to a socket to enable creation of a 'connection' for UDP traffic. This UDP connection allows an application to be notified of errors received from the network stack and provides a shorthand access to the SEND and RECEIVE primitives. Since UDP is itself connectionless, no datagrams are sent because this primitive is executed. A further connect call can be used to change the association.

CONNECT：CONNECTプリミティブにより、送信元ポートセットと宛先ポートセットをソケットに関連付けて、UDPトラフィックの「接続」を作成できます。このUDP接続により、アプリケーションはネットワークスタックから受信したエラーを通知され、SENDおよびRECEIVEプリミティブへの簡単なアクセスを提供します。 UDP自体はコネクションレスであるため、このプリミティブが実行されるため、データグラムは送信されません。さらに接続呼び出しを使用して、関連付けを変更できます。

The roles of a client and a server are often not appropriate for UDP, where connections can be peer-to-peer. The listening functions are performed using one of the forms of the CONNECT primitive:

クライアントとサーバーの役割は、接続がピアツーピアになる可能性のあるUDPには適していないことがよくあります。リスニング機能は、CONNECTプリミティブのいずれかの形式を使用して実行されます。

1. bind(): A bind operation sets the local port either implicitly, triggered by a "sendto" operation on an unbound unconnected socket using an ephemeral port, or by an explicit "bind" to use a configured or well-known port.

1. bind()：バインド操作は、一時ポートを使用してバインドされていない未接続ソケットに対する「sendto」操作、または構成済みポートまたは既知のポートを使用する明示的な「バインド」によってトリガーされて、暗黙的にローカルポートを設定します。

2. bind(); connect(): A bind operation that is followed by a CONNECT primitive. The bind operation establishes the use of a known local port for datagrams rather than using an ephemeral port. The connect operation specifies a known address port combination to be used by default for future datagrams. This form either is used after receiving a datagram from an endpoint that causes the creation of a connection or can be triggered by a third-party configuration or a protocol trigger (such as reception of a UDP Service Description Protocol (SDP) [RFC4566] record).

2. 練る(); connect()：CONNECTプリミティブが後に続くバインド操作。バインド操作は、エフェメラルポートを使用するのではなく、データグラム用の既知のローカルポートの使用を確立します。接続操作は、将来のデータグラムにデフォルトで使用される既知のアドレスポートの組み合わせを指定します。このフォームは、接続の作成を引き起こすエンドポイントからデータグラムを受信した後に使用されるか、サードパーティの構成またはプロトコルトリガー（UDPサービス記述プロトコル（SDP）[RFC4566]レコードの受信など）によってトリガーされます。）。

SEND: The SEND primitive hands over a provided number of bytes that UDP should send to the other side of a UDP connection in a UDP datagram. The primitive can be used by an application to directly send datagrams to an endpoint defined by an address/port pair. If a connection has been created, then the address/port pair is inferred from the current connection for the socket. Connecting a socket allows network errors to be returned to the application as a notification on the SEND primitive. Messages passed to the SEND primitive that cannot be sent atomically in an IP packet will not be sent by the network layer, generating an error.

SEND：SENDプリミティブは、UDPがUDPデータグラム内のUDP接続の反対側に送信する必要があるバイト数を渡します。アプリケーションはプリミティブを使用して、アドレス/ポートのペアで定義されたエンドポイントにデータグラムを直接送信できます。接続が作成されている場合、アドレス/ポートのペアは、ソケットの現在の接続から推測されます。ソケットを接続すると、ネットワークエラーをSENDプリミティブの通知としてアプリケーションに返すことができます。 IPパケットでアトミックに送信できないSENDプリミティブに渡されたメッセージは、ネットワーク層によって送信されず、エラーが生成されます。

RECEIVE: The RECEIVE primitive allocates a receiving buffer to accommodate a received datagram. The primitive returns the number of bytes provided from a received UDP datagram. Section 4.1.3.5 of the requirements of Internet hosts [RFC1122] states "When a UDP datagram is received, its specific-destination address MUST be passed up to the application layer."

RECEIVE：RECEIVEプリミティブは、受信したデータグラムを収容するために受信バッファーを割り当てます。プリミティブは、受信したUDPデータグラムから提供されたバイト数を返します。インターネットホスト[RFC1122]の要件のセクション4.1.3.5には、「UDPデータグラムを受信したとき、その特定の宛先アドレスをアプリケーションレイヤーに渡す必要がある」と記載されています。

CHECKSUM_ENABLED: The optional CHECKSUM_ENABLED primitive controls whether a sender enables the UDP checksum when sending datagrams [RFC0768] [RFC6935] [RFC6936] [RFC8085]. When unset, this overrides the default UDP behavior, disabling the checksum on sending. Section 4.1.3.4 of the requirements for Internet hosts [RFC1122] states that "An application MAY optionally be able to control whether a UDP checksum will be generated, but it MUST default to checksumming on."

CHECKSUM_ENABLED：オプションのCHECKSUM_ENABLEDプリミティブは、送信者がデータグラムを送信するときにUDPチェックサムを有効にするかどうかを制御します[RFC0768] [RFC6935] [RFC6936] [RFC8085]。設定を解除すると、デフォルトのUDP動作が上書きされ、送信時のチェックサムが無効になります。インターネットホスト[RFC1122]の要件のセクション4.1.3.4には、「アプリケーションは、UDPチェックサムを生成するかどうかをオプションで制御できますが、デフォルトでチェックサムをオンにする必要がある」と述べています。

REQUIRE_CHECKSUM: The optional REQUIRE_CHECKSUM primitive determines whether UDP datagrams received with a zero checksum are permitted or discarded; UDP defaults to requiring checksums. Section 4.1.3.4 of the requirements for Internet hosts [RFC1122] states that "An application MAY optionally be able to control whether UDP datagrams without checksums should be discarded or passed to the application." Section 3.1 of the specification for UDP-Lite [RFC3828] requires that the checksum field be non-zero; hence, the UDP-Lite API must discard all datagrams received with a zero checksum.

REQUIRE_CHECKSUM：オプションのREQUIRE_CHECKSUMプリミティブは、ゼロのチェックサムで受信したUDPデータグラムを許可するか破棄するかを決定します。 UDPはデフォルトでチェックサムを要求します。インターネットホストの要件のセクション4.1.3.4 [RFC1122]には、「アプリケーションは、チェックサムなしのUDPデータグラムを破棄するか、アプリケーションに渡すかをオプションで制御できる場合があります」と記載されています。 UDP-Lite [RFC3828]の仕様のセクション3.1では、チェックサムフィールドをゼロ以外にする必要があります。したがって、UDP-Lite APIは、ゼロのチェックサムで受信したすべてのデータグラムを破棄する必要があります。

SET_IP_OPTIONS: The SET_IP_OPTIONS primitive requests the network layer to send a datagram with the specified IP options. Section 4.1.3.2 of the requirements for Internet hosts [RFC1122] states that an "application MUST be able to specify IP options to be sent in its UDP datagrams, and UDP MUST pass these options to the IP layer."

SET_IP_OPTIONS：SET_IP_OPTIONSプリミティブは、指定されたIPオプションでデータグラムを送信するようネットワーク層に要求します。インターネットホストの要件のセクション4.1.3.2 [RFC1122]は、「アプリケーションは、UDPデータグラムで送信されるIPオプションを指定できなければならず、UDPはこれらのオプションをIP層に渡さなければならない」と述べています。

GET_IP_OPTIONS: The GET_IP_OPTIONS primitive retrieves the IP options of a datagram received at the network layer. Section 4.1.3.2 of the requirements for Internet hosts [RFC1122] states that a UDP receiver "MUST pass any IP option that it receives from the IP layer transparently to the application layer."

GET_IP_OPTIONS：GET_IP_OPTIONSプリミティブは、ネットワーク層で受信されたデータグラムのIPオプションを取得します。インターネットホストの要件のセクション4.1.3.2 [RFC1122]は、UDPレシーバーが「IPレイヤーから受信したすべてのIPオプションを透過的にアプリケーションレイヤーに渡す必要がある」と述べています。

SET_DF: The SET_DF primitive allows the network layer to fragment packets using the Fragment Offset in IPv4 [RFC6864] and a host to use Fragment Headers in IPv6 [RFC8200]. The SET_DF primitive sets the Don't Fragment (DF) flag in the IPv4 packet header that carries a UDP datagram, which allows routers to fragment IPv4 packets. Although some specific applications rely on fragmentation support, in general, a UDP application should implement a method that avoids IP fragmentation (Section 4 of [RFC8085]). NOTE: In many other IETF transports (e.g., TCP and the Stream Control Transmission Protocol (SCTP)), the transport provides the support needed to use DF. However, when using UDP, the application is responsible for the techniques needed to discover the effective Path MTU (PMTU) allowed on the network path, coordinating with the network layer. Classical Path MTU Discovery (PMTUD) [RFC1191] relies upon the network path returning ICMP Fragmentation Needed or ICMPv6 Packet Too Big messages to the sender. When these ICMP messages are not delivered (or filtered), a sender is unable to learn the actual PMTU, and UDP datagrams larger than the PMTU will be "black holed". To avoid this, an application can instead implement Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] that does not rely upon network support for ICMPv6 messages and is therefore considered more robust than standard PMTUD, as recommended in [RFC8085] and [RFC8201].

SET_DF：SET_DFプリミティブにより、ネットワークレイヤーはIPv4 [RFC6864]のフラグメントオフセットを使用してパケットをフラグメント化し、ホストはIPv6 [RFC8200]のフラグメントヘッダーを使用できます。 SET_DFプリミティブは、ルーターがIPv4パケットをフラグメント化できるようにする、UDPデータグラムを運ぶIPv4パケットヘッダーにDo n't Fragment（DF）フラグを設定します。一部の特定のアプリケーションはフラグメンテーションサポートに依存していますが、一般に、UDPアプリケーションはIPフラグメンテーションを回避するメソッドを実装する必要があります（[RFC8085]のセクション4）。注：他の多くのIETFトランスポート（TCPやストリーム制御伝送プロトコル（SCTP）など）では、トランスポートはDFを使用するために必要なサポートを提供します。ただし、UDPを使用する場合、アプリケーションは、ネットワーク層と連携して、ネットワークパスで許可されている有効なパスMTU（PMTU）を検出するために必要な手法を担当します。クラシックパスMTUディスカバリー（PMTUD）[RFC1191]は、ネットワークパスがICMPフラグメンテーションが必要か、ICMPv6パケットが大きすぎるというメッセージを送信者に返すことに依存しています。これらのICMPメッセージが配信（またはフィルタリング）されない場合、送信者は実際のPMTUを学習できず、PMTUより大きいUDPデータグラムは「ブラックホール」になります。これを回避するために、アプリケーションは代わりにパケット化レイヤーパスMTU検出（PLPMTUD）[RFC4821]を実装できます。これは、ICMPv6メッセージのネットワークサポートに依存しないため、[RFC8085]および[RFC8201]で推奨されているように、標準のPMTUDよりも堅牢であると見なされます。。

GET_MMS_S: The GET_MMS_S primitive retrieves a network-layer value that indicates the maximum message size (MMS) that may be sent at the transport layer using a non-fragmented IP packet from the configured interface. This value is specified in Section 6.1 of [RFC1191] and Section 5.1 of [RFC8201]. It is calculated from Effective MTU for Sending (EMTU_S) and the link MTU for the given source IP address. This takes into account the size of the IP header plus space reserved by the IP layer for additional headers (if any). UDP applications should use this value as part of a method to avoid sending UDP datagrams that would result in IP packets that exceed the effective PMTU allowed across the network path. The effective PMTU (specified in Section 1 of [RFC1191]) is equivalent to the EMTU_S (specified in [RFC1122]). The specification of PLPMTUD [RFC4821] states:

GET_MMS_S：GET_MMS_Sプリミティブは、構成されたインターフェースからフラグメント化されていないIPパケットを使用してトランスポート層で送信できる最大メッセージサイズ（MMS）を示すネットワーク層値を取得します。この値は、[RFC1191]のセクション6.1および[RFC8201]のセクション5.1で指定されています。これは、送信に有効なMTU（EMTU_S）と指定されたソースIPアドレスのリンクMTUから計算されます。これは、IPヘッダーのサイズに加えて、IPレイヤーによって追加ヘッダー（ある場合）のために予約されたスペースを考慮に入れます。 UDPアプリケーションは、この値をメソッドの一部として使用して、ネットワークパス全体で許可される有効なPMTUを超えるIPパケットが発生する可能性があるUDPデータグラムを送信しないようにする必要があります。実効PMTU（[RFC1191]のセクション1で指定）は、EMTU_S（[RFC1122]で指定）と同等です。 PLPMTUD [RFC4821]の仕様は次のように述べています。

If PLPMTUD updates the MTU for a particular path, all Packetization Layer sessions that share the path representation (as described in Section 5.2) SHOULD be notified to make use of the new MTU and make the required congestion control adjustments.

PLPMTUDが特定のパスのMTUを更新する場合、（5.2節で説明されているように）パス表現を共有するすべてのパケット化レイヤーセッションに、新しいMTUを利用して必要な輻輳制御調整を行うよう通知する必要があります（SHOULD）。

GET_MMS_R: The GET_MMS_R primitive retrieves a network-layer value that indicates the MMS that may be received at the transport layer from the configured interface. This value is specified in Section 3.1 of [RFC1191]. It is calculated from Effective MTU for Receiving (EMTU_R) and the link MTU for the given source IP address, and it takes into account the size of the IP header plus space reserved by the IP layer for additional headers (if any).

GET_MMS_R：GET_MMS_Rプリミティブは、構成されたインターフェースからトランスポート層で受信できるMMSを示すネットワーク層値を取得します。この値は、[RFC1191]のセクション3.1で指定されています。これは、受信の有効MTU（EMTU_R）と特定の送信元IPアドレスのリンクMTUから計算され、IPヘッダーのサイズに加えて、IPレイヤーによって追加ヘッダー用に予約されたスペース（存在する場合）を考慮に入れます。

SET_TTL: The SET_TTL primitive sets the Hop Limit (TTL field) in the network layer that is used in the IPv4 header of a packet that carries a UDP datagram. This is used to limit the scope of unicast datagrams. Section 3.2.2.4 of the requirements for Internet hosts [RFC1122] states that "An incoming Time Exceeded message MUST be passed to the transport layer."

SET_TTL：SET_TTLプリミティブは、UDPデータグラムを運ぶパケットのIPv4ヘッダーで使用されるネットワーク層のホップ制限（TTLフィールド）を設定します。これは、ユニキャストデータグラムのスコープを制限するために使用されます。インターネットホスト[RFC1122]の要件のセクション3.2.2.4には、「着信時間超過メッセージをトランスポート層に渡す必要がある」と記載されています。

GET_TTL: The GET_TTL primitive retrieves the value of the TTL field in an IP packet received at the network layer. An application using the Generalized TTL Security Mechanism (GTSM) [RFC5082] can use this information to trust datagrams with a TTL value within the expected range, as described in Section 3 of RFC 5082.

GET_TTL：GET_TTLプリミティブは、ネットワーク層で受信されたIPパケットのTTLフィールドの値を取得します。一般化されたTTLセキュリティメカニズム（GTSM）[RFC5082]を使用するアプリケーションは、RFC 5082のセクション3で説明されているように、この情報を使用して、予期される範囲内のTTL値を持つデータグラムを信頼できます。

SET_MIN_TTL: The SET_MIN_TTL primitive restricts datagrams delivered to the application to those received with an IP TTL value greater than or equal to the passed parameter. This primitive can be used to implement applications such as GTSM [RFC5082] too, as described in Section 3 of RFC 5082, but this RFC does not specify this method.

SET_MIN_TTL：SET_MIN_TTLプリミティブは、アプリケーションに配信されるデータグラムを、渡されたパラメーター以上のIP TTL値で受信されたものに制限します。 RFC 5082のセクション3で説明されているように、このプリミティブを使用してGTSM [RFC5082]などのアプリケーションを実装することもできますが、このRFCではこの方法を指定していません。

SET_IPV6_UNICAST_HOPS: The SET_IPV6_UNICAST_HOPS primitive sets the network-layer Hop Limit field in an IPv6 packet header [RFC8200] carrying a UDP datagram. For IPv6 unicast datagrams, this is functionally equivalent to the SET_TTL IPv4 function.

SET_IPV6_UNICAST_HOPS：SET_IPV6_UNICAST_HOPSプリミティブは、UDPデータグラムを運ぶIPv6パケットヘッダー[RFC8200]のネットワーク層ホップ制限フィールドを設定します。 IPv6ユニキャストデータグラムの場合、これは機能的にSET_TTL IPv4関数と同等です。

GET_IPV6_UNICAST_HOPS: The GET_IPV6_UNICAST_HOPS primitive is a network-layer function that reads the hop count in the IPv6 header [RFC8200] information of a received UDP datagram. This is specified in Section 6.3 of RFC 3542. For IPv6 unicast datagrams, this is functionally equivalent to the GET_TTL IPv4 function.

GET_IPV6_UNICAST_HOPS：GET_IPV6_UNICAST_HOPSプリミティブは、受信したUDPデータグラムのIPv6ヘッダー[RFC8200]情報のホップカウントを読み取るネットワーク層関数です。これはRFC 3542のセクション6.3で指定されています。IPv6ユニキャストデータグラムの場合、これは機能的にGET_TTL IPv4関数と同等です。

   SET_DSCP:  The SET_DSCP primitive is a network-layer function that
      sets the DSCP (or the legacy Type of Service (ToS)) value
      [RFC2474] to be used in the field of an IP header of a packet that
      carries a UDP datagram.  Section 2.4 of the requirements for
      Internet hosts [RFC1123] states that "Applications MUST select
      appropriate ToS values when they invoke transport layer services,
      and these values MUST be configurable."  The application should be
      able to change the ToS during the connection lifetime, and the ToS
      value should be passed to the IP layer unchanged.  Section 4.1.4
      of [RFC1122] also states that on reception the "UDP MAY pass the
      received ToS up to the application layer."  The Diffserv model
      [RFC2475] [RFC3260] replaces this field in the IP header assigning
      the six most significant bits to carry the DSCP field [RFC2474].
      Preserving the intention of the host requirements [RFC1122] to
      allow the application to specify the "Type of Service" should be
      interpreted to mean that an API should allow the application to
      set the DSCP.  Section 3.1.8 of the UDP Guidelines [RFC8085]
      describes the way UDP applications should use this field.
      Normally, a UDP socket will assign a single DSCP value to all
      datagrams in a flow, but a sender is allowed to use different DSCP
      values for datagrams within the same flow in certain cases
      [RFC8085].  There are guidelines for WebRTC that illustrate this
      use [RFC7657].

SET_ECN: The SET_ECN primitive is a network-layer function that sets the Explicit Congestion Notification (ECN) field in the IP header of a UDP datagram. The ECN field defaults to a value of 00. When the use of the ToS field was redefined by Diffserv [RFC3260], 2 bits of the field were assigned to support ECN [RFC3168]. Section 3.1.5 of the UDP Guidelines [RFC8085] describes the way

SET_ECN：SET_ECNプリミティブは、UDPデータグラムのIPヘッダーに明示的輻輳通知（ECN）フィールドを設定するネットワーク層機能です。 ECNフィールドのデフォルト値は00です。ToSフィールドの使用がDiffserv [RFC3260]によって再定義されたとき、フィールドの2ビットがECN [RFC3168]をサポートするために割り当てられました。 UDPガイドライン[RFC8085]のセクション3.1.5は方法を説明しています

UDP applications should use this field. NOTE: In many other IETF transports (e.g., TCP), the transport provides the support needed to use ECN; when using UDP, the application or higher-layer protocol is itself responsible for the techniques needed to use ECN.

UDPアプリケーションはこのフィールドを使用する必要があります。注：他の多くのIETFトランスポート（TCPなど）では、トランスポートはECNの使用に必要なサポートを提供します。 UDPを使用する場合、アプリケーションまたは上位層プロトコル自体が、ECNを使用するために必要な技術を担当します。

GET_ECN: The GET_ECN primitive is a network-layer function that returns the value of the ECN field in the IP header of a received UDP datagram. Section 3.1.5 of [RFC8085] states that a UDP receiver "MUST check the ECN field at the receiver for each UDP datagram that it receives on this port", requiring the UDP receiver API to pass the received ECN field up to the application layer to enable appropriate congestion feedback.

GET_ECN：GET_ECNプリミティブは、受信したUDPデータグラムのIPヘッダーのECNフィールドの値を返すネットワーク層関数です。 [RFC8085]のセクション3.1.5は、UDPレシーバーが「このポートで受信する各UDPデータグラムのレシーバーでECNフィールドをチェックする必要がある」と述べており、UDPレシーバーAPIが受信したECNフィールドをアプリケーションレイヤーに渡す必要があります。適切な輻輳フィードバックを有効にします。

ERROR_REPORT: The ERROR_REPORT event informs an application of "soft errors", including the arrival of an ICMP or ICMPv6 error message. Section 4.1.4 of the requirements for Internet hosts [RFC1122] states that "UDP MUST pass to the application layer all ICMP error messages that it receives from the IP layer." For example, this event is required to implement ICMP-based Path MTU Discovery [RFC1191] [RFC8201]. UDP applications must perform a CONNECT to receive ICMP errors.

ERROR_REPORT：ERROR_REPORTイベントは、ICMPまたはICMPv6エラーメッセージの到着を含む「ソフトエラー」をアプリケーションに通知します。インターネットホストの要件[RFC1122]のセクション4.1.4には、「UDPは、IP層から受信するすべてのICMPエラーメッセージをアプリケーション層に渡す必要がある」と述べています。たとえば、このイベントは、ICMPベースのパスMTU発見[RFC1191] [RFC8201]を実装するために必要です。 UDPアプリケーションは、ICMPエラーを受信するためにCONNECTを実行する必要があります。

CLOSE: The CLOSE primitive closes a connection. No further datagrams can be sent or received. Since UDP is itself connectionless, no datagrams are sent when this primitive is executed.

CLOSE：CLOSEプリミティブは接続を閉じます。これ以上データグラムを送受信することはできません。 UDP自体はコネクションレスであるため、このプリミティブが実行されるときにデータグラムは送信されません。

3.1.1. Excluded Primitives

3.1.1. 除外されたプリミティブ

In the requirements for Internet hosts [RFC1122], Section 3.4 describes GET_MAXSIZES and ADVISE_DELIVPROB, and Section 3.3.4.4 describes GET_SRCADDR. These mechanisms are no longer used. It also specifies use of the Source Quench ICMP message, which has since been deprecated [RFC6633].

インターネットホストの要件[RFC1122]では、3.4項でGET_MAXSIZESとADVISE_DELIVPROBについて説明し、3.3.4.4項でGET_SRCADDRについて説明しています。これらのメカニズムは使用されなくなりました。また、ソースクエンチICMPメッセージの使用も指定しています。これは、非推奨となった[RFC6633]です。

The IPV6_V6ONLY function is a network-layer primitive that applies to all transport services, as defined in Section 5.3 of the basic socket interface for IPv6 [RFC3493]. This restricts the use of information from the name resolver to only allow communication of AF_INET6 sockets to use IPv6 only. This is not considered part of the transport service.

IPV6_V6ONLY関数は、IPv6の基本ソケットインターフェイス[RFC3493]のセクション5.3で定義されているように、すべてのトランスポートサービスに適用されるネットワーク層プリミティブです。これにより、名前リゾルバーからの情報の使用が制限され、IPv_6のみを使用するAF_INET6ソケットの通信のみが許可されます。これはトランスポートサービスの一部とは見なされません。

3.2. Primitives Provided by UDP-Lite

3.2. UDP-Liteが提供するプリミティブ

UDP-Lite [RFC3828] provides similar services to UDP. It changed the semantics of the UDP "payload length" field to that of a "checksum coverage length" field. UDP-Lite requires the pseudo-header checksum to be computed at the sender and checked at a receiver. Apart from the length and coverage changes, UDP-Lite is semantically identical to UDP.

UDP-Lite [RFC3828]はUDPと同様のサービスを提供します。これは、UDPの「ペイロード長」フィールドのセマンティクスを「チェックサムカバレッジ長」フィールドのセマンティクスに変更しました。 UDP-Liteでは、疑似ヘッダーチェックサムを送信側で計算し、受信側でチェックする必要があります。長さとカバレッジの変更は別として、UDP-Liteは意味的にUDPと同じです。

The sending interface of UDP-Lite differs from that of UDP by the addition of a single (socket) option that communicates the checksum coverage length. This specifies the intended checksum coverage, with the remaining unprotected part of the payload called the "error-insensitive part".

UDP-Liteの送信インターフェイスは、チェックサムカバレッジ長を伝達する単一（ソケット）オプションが追加されている点がUDPの送信インターフェイスとは異なります。これは、意図されたチェックサムカバレッジを指定し、ペイロードの残りの保護されていない部分は「エラーに影響されない部分」と呼ばれます。

The receiving interface of UDP-Lite differs from that of UDP by the addition of a single (socket) option that specifies the minimum acceptable checksum coverage. The UDP-Lite Management Information Base (MIB) [RFC5097] further defines the checksum coverage method. Guidance on the use of services provided by UDP-Lite is provided in the UDP Guidelines [RFC8085].

UDP-Liteの受信インターフェイスは、最小の許容可能なチェックサムカバレッジを指定する単一（ソケット）オプションが追加されている点で、UDPのインターフェイスとは異なります。 UDP-Lite管理情報ベース（MIB）[RFC5097]は、チェックサムカバレッジ方式をさらに定義しています。 UDP-Liteによって提供されるサービスの使用に関するガイダンスは、UDPガイドライン[RFC8085]で提供されています。

UDP-Lite requires use of the UDP or UDP-Lite checksum; hence, it is not permitted to use the DISABLE_CHECKSUM function to disable use of a checksum, nor is it possible to disable receiver checksum processing using the REQUIRE_CHECKSUM function. All other primitives and functions for UDP are permitted.

UDP-Liteでは、UDPまたはUDP-Liteチェックサムを使用する必要があります。したがって、DISABLE_CHECKSUM関数を使用してチェックサムの使用を無効にすることも、REQUIRE_CHECKSUM関数を使用してレシーバーのチェックサム処理を無効にすることもできません。 UDPの他のすべてのプリミティブと関数は許可されます。

In addition, the following are defined:

さらに、以下が定義されています。

SET_CHECKSUM_COVERAGE: The SET_CHECKSUM_COVERAGE primitive sets the coverage area for a sent datagram. UDP-Lite traffic uses this primitive to set the coverage length provided by the UDP checksum. Section 3.3 of the UDP-Lite specification [RFC3828] states that "Applications that wish to define the payload as partially insensitive to bit errors...should do this by an explicit system call on the sender side." The default is to provide the same coverage as for UDP.

SET_CHECKSUM_COVERAGE：SET_CHECKSUM_COVERAGEプリミティブは、送信されたデータグラムのカバレッジエリアを設定します。 UDP-Liteトラフィックは、このプリミティブを使用して、UDPチェックサムによって提供されるカバレッジの長さを設定します。 UDP-Lite仕様[RFC3828]のセクション3.3には、「ペイロードをビットエラーの影響を部分的に受けないように定義するアプリケーションは、送信側の明示的なシステムコールによってこれを行う必要があります」と記載されています。デフォルトでは、UDPと同じカバレッジを提供します。

SET_MIN_COVERAGE: The SET_MIN_COVERAGE primitive sets the minimum acceptable coverage protection for received datagrams. UDP-Lite traffic uses this primitive to set the coverage length that is checked on receive. (Section 1.1 of [RFC5097] describes the corresponding MIB entry as udpliteEndpointMinCoverage.) Section 3.3 of the UDP-Lite specification [RFC3828] states that "Applications that wish to receive payloads that were only partially covered by a checksum should inform the receiving system by an explicit system call." The default is to require only minimal coverage of the datagram payload.

SET_MIN_COVERAGE：SET_MIN_COVERAGEプリミティブは、受信したデータグラムの最小許容カバレッジ保護を設定します。 UDP-Liteトラフィックは、このプリミティブを使用して、受信時にチェックされるカバレッジ長を設定します。（[RFC5097]のセクション1.1は、対応するMIBエントリをudpliteEndpointMinCoverageとして説明しています。）UDP-Lite仕様[RFC3828]のセクション3.3は、「チェックサムによって部分的にのみカバーされたペイロードを受信したいアプリケーションは、明示的なシステムコール。」デフォルトでは、データグラムペイロードのカバレッジは最小限で済みます。

4. IANA Considerations

4. IANAに関する考慮事項

This document does not require any IANA actions.

このドキュメントでは、IANAアクションは必要ありません。

5. Security Considerations

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

Security considerations for the use of UDP and UDP-Lite are provided in the referenced RFCs. Security guidance for application usage is provided in the UDP Guidelines [RFC8085].

UDPおよびUDP-Liteの使用に関するセキュリティの考慮事項は、参照されているRFCで提供されています。アプリケーション使用のセキュリティガイダンスは、UDPガイドライン[RFC8085]で提供されています。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.

[RFC0768] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<https://www.rfc-editor.org/info/rfc768>。

[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, <https://www.rfc-editor.org/info/rfc1112>.

[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、DOI 10.17487 / RFC1112、1989年8月、<https://www.rfc-editor.org/info/rfc1112>。

[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.

[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<https://www.rfc-editor.org/info/ rfc1122>。

[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <https://www.rfc-editor.org/info/rfc1123>.

[RFC1123] Braden、R。、編、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、DOI 10.17487 / RFC1123、1989年10月、<https://www.rfc-editor.org/info / rfc1123>。

[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.

[RFC1191] Mogul、J。およびS. Deering、「Path MTU discovery」、RFC 1191、DOI 10.17487 / RFC1191、1990年11月、<https://www.rfc-editor.org/info/rfc1191>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。

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

[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<https：// www。 rfc-editor.org/info/rfc3168>。

[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, DOI 10.17487/RFC3493, February 2003, <https://www.rfc-editor.org/info/rfc3493>.

[RFC3493] Gilligan、R.、Thomson、S.、Bound、J.、McCann、J.、and W. Stevens、 "Basic Socket Interface Extensions for IPv6"、RFC 3493、DOI 10.17487 / RFC3493、February 2003、<https ：//www.rfc-editor.org/info/rfc3493>。

[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, DOI 10.17487/RFC3828, July 2004, <https://www.rfc-editor.org/info/rfc3828>.

[RFC3828] Larzon、LA。、Degermark、M.、Pink、S.、Jonsson、LE。、Ed。、and G. Fairhurst、Ed。、 "The Lightweight User Datagram Protocol（UDP-Lite）"、RFC 3828、 DOI 10.17487 / RFC3828、2004年7月、<https://www.rfc-editor.org/info/rfc3828>。

[RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", RFC 6864, DOI 10.17487/RFC6864, February 2013, <https://www.rfc-editor.org/info/rfc6864>.

[RFC6864] Touch、J。、「IPv4 IDフィールドの更新された仕様」、RFC 6864、DOI 10.17487 / RFC6864、2013年2月、<https://www.rfc-editor.org/info/rfc6864>。

[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013, <https://www.rfc-editor.org/info/rfc6935>.

[RFC6935] Eubanks、M.、Chimento、P。、およびM. Westerlund、「トンネルパケットのIPv6およびUDPチェックサム」、RFC 6935、DOI 10.17487 / RFC6935、2013年4月、<https：//www.rfc-editor。 org / info / rfc6935>。

[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, <https://www.rfc-editor.org/info/rfc6936>.

[RFC6936] Fairhurst、G。およびM. Westerlund、「ゼロチェックサムを使用したIPv6 UDPデータグラムの使用に関する適用性声明」、RFC 6936、DOI 10.17487 / RFC6936、2013年4月、<https://www.rfc-editor.org / info / rfc6936>。

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.

[RFC8085] Eggert、L.、Fairhurst、G。、およびG. Shepherd、「UDP使用ガイドライン」、BCP 145、RFC 8085、DOI 10.17487 / RFC8085、2017年3月、<https://www.rfc-editor.org / info / rfc8085>。

[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[RFC8200] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https://www.rfc-editor.org / info / rfc8200>。

[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.

[RFC8201] McCann、J.、Deering、S.、Mogul、J。、およびR. Hinden、編、「Path MTU Discovery for IP version 6」、STD 87、RFC 8201、DOI 10.17487 / RFC8201、2017年7月<https://www.rfc-editor.org/info/rfc8201>。

[RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of Transport Features Provided by IETF Transport Protocols", RFC 8303, DOI 10.17487/RFC8303, February 2018, <https://www.rfc-editor.org/info/rfc8303>.

[RFC8303] Welzl、M.、Tuexen、M。、およびN. Khademi、「IETFトランスポートプロトコルによって提供されるトランスポート機能の使用について」、RFC 8303、DOI 10.17487 / RFC8303、2018年2月、<https：// www。 rfc-editor.org/info/rfc8303>。

6.2. Informative References

6.2. 参考引用

[POSIX] IEEE, "Standard for Information Technology - Portable Operating System Interface (POSIX(R)) Base Specifications", Issue 7, IEEE 1003.1, <http://ieeexplore.ieee.org/document/7582338/>.

[POSIX] IEEE、「Standard for Information Technology-Portable Operating System Interface（POSIX（R））Base Specifications」、Issue 7、IEEE 1003.1、<http://ieeexplore.ieee.org/document/7582338/>。

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <https://www.rfc-editor.org/info/rfc2460>.

[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<https://www.rfc-editor.org/info/ rfc2460>。

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

[RFC2474]ニコルズ、K。、ブレイク、S。、ベイカー、F。、およびD.ブラック、「IPv4およびIPv6ヘッダーのDiffServフィールド（DSフィールド）の定義」、RFC 2474、DOI 10.17487 / RFC2474、 1998年12月、<https://www.rfc-editor.org/info/rfc2474>。

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.

[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、and W. Weiss、 "An Architecture for Differentiated Services"、RFC 2475、DOI 10.17487 / RFC2475、December 1998、<https://www.rfc-editor.org/info/rfc2475>。

[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, <https://www.rfc-editor.org/info/rfc3260>.

[RFC3260] Grossman、D。、「Diffservの新しい用語と説明」、RFC 3260、DOI 10.17487 / RFC3260、2002年4月、<https://www.rfc-editor.org/info/rfc3260>。

[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, <https://www.rfc-editor.org/info/rfc3376>.

[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、DOI 10.17487 / RFC3376、2002年10月、< https://www.rfc-editor.org/info/rfc3376>。

[RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, DOI 10.17487/RFC3678, January 2004, <https://www.rfc-editor.org/info/rfc3678>.

[RFC3678] Thaler、D.、Fenner、B。、およびB. Quinn、「マルチキャストソースフィルターのソケットインターフェイス拡張」、RFC 3678、DOI 10.17487 / RFC3678、2004年1月、<https：//www.rfc-editor。 org / info / rfc3678>。

[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <https://www.rfc-editor.org/info/rfc3810>.

[RFC3810] Vida、R.、Ed。 L.コスタ編、「IPv6のマルチキャストリスナーディスカバリバージョン2（MLDv2）」、RFC 3810、DOI 10.17487 / RFC3810、2004年6月、<https://www.rfc-editor.org/info/rfc3810>。

[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.

[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<https://www.rfc-editor.org/ info / rfc4566>。

[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, August 2006, <https://www.rfc-editor.org/info/rfc4604>.

[RFC4604] Holbrook、H.、Cain、B。、およびB. Haberman、「Source-Specific MulticastでのInternet Group Management Protocolバージョン3（IGMPv3）およびMulticast Listener Discovery Protocolバージョン2（MLDv2）の使用」、RFC 4604、DOI 10.17487 / RFC4604、2006年8月、<https://www.rfc-editor.org/info/rfc4604>。

[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.

[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、DOI 10.17487 / RFC4821、2007年3月、<https://www.rfc-editor.org/info/rfc4821>。

[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, <https://www.rfc-editor.org/info/rfc5082>.

[RFC5082] Gill、V.、Heasley、J.、Meyer、D.、Savola、P.、Ed。、およびC. Pignataro、「一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 5082、DOI 10.17487 / RFC5082、 2007年10月、<https://www.rfc-editor.org/info/rfc5082>。

[RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite protocol", RFC 5097, DOI 10.17487/RFC5097, January 2008, <https://www.rfc-editor.org/info/rfc5097>.

[RFC5097] Renker、G。およびG. Fairhurst、「MIB for the UDP-Lite protocol」、RFC 5097、DOI 10.17487 / RFC5097、2008年1月、<https://www.rfc-editor.org/info/rfc5097> 。

[RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, DOI 10.17487/RFC5790, February 2010, <https://www.rfc-editor.org/info/rfc5790>.

[RFC5790] Liu、H.、Cao、W。、およびH. Asaeda、「Lightweight Internet Group Management Protocol Version 3（IGMPv3）and Multicast Listener Discovery Version 2（MLDv2）Protocols」、RFC 5790、DOI 10.17487 / RFC5790、February 2010、<https://www.rfc-editor.org/info/rfc5790>。

[RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages", RFC 6633, DOI 10.17487/RFC6633, May 2012, <https://www.rfc-editor.org/info/rfc6633>.

[RFC6633] Gont、F。、「Deprecation of ICMP Source Quench Messages」、RFC 6633、DOI 10.17487 / RFC6633、2012年5月、<https://www.rfc-editor.org/info/rfc6633>。

[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, <https://www.rfc-editor.org/info/rfc7657>.

[RFC7657]ブラック、D。、エド。およびP.ジョーンズ、「Differentiated Services（Diffserv）and Real-Time Communication」、RFC 7657、DOI 10.17487 / RFC7657、2015年11月、<https://www.rfc-editor.org/info/rfc7657>。

[STEVENS] Stevens, W., Fenner, B., and A. Rudoff, "UNIX Network Programming, The sockets Networking API", Volume 1, ISBN-13: 9780131411555, October 2003.

[STEVENS] Stevens、W.、Fenner、B.、and A. Rudoff、 "UNIX Network Programming、The sockets Networking API"、Volume 1、ISBN-13：9780131411555、October 2003。

Appendix A. Multicast Primitives

付録A.マルチキャストプリミティブ

This appendix describes primitives that are used when UDP and UDP-Lite support IPv4/IPv6 multicast. Multicast services are not considered by the IETF TAPS WG, but the currently specified primitives are included for completeness in this appendix. Guidance on the use of UDP and UDP-Lite for multicast services is provided in the UDP Guidelines [RFC8085].

この付録では、UDPおよびUDP-LiteがIPv4 / IPv6マルチキャストをサポートする場合に使用されるプリミティブについて説明します。マルチキャストサービスはIETF TAPS WGでは考慮されていませんが、現在指定されているプリミティブは、この付録に完全を期すために含まれています。マルチキャストサービスでのUDPおよびUDP-Liteの使用に関するガイダンスは、UDPガイドライン[RFC8085]で提供されています。

IP multicast may be supported by using the Any Source Multicast (ASM) model or the Source-Specific Multicast (SSM) model. The latter requires use of a Multicast Source Filter (MSF) when specifying an IP multicast group destination address.

IPマルチキャストは、Any Source Multicast（ASM）モデルまたはSource-Specific Multicast（SSM）モデルを使用してサポートできます。後者では、IPマルチキャストグループの宛先アドレスを指定するときに、マルチキャストソースフィルター（MSF）を使用する必要があります。

Use of multicast requires additional primitives at the transport API that need to be called to coordinate operation of the IPv4 and IPv6 network-layer protocols. For example, to receive datagrams sent to a group, an endpoint must first become a member of a multicast group at the network layer. Local multicast reception is signaled for IPv4 by the Internet Group Management Protocol (IGMP) [RFC3376] [RFC4604]. IPv6 uses the equivalent Multicast Listener Discovery (MLD) protocol [RFC3810] [RFC5790], carried over ICMPv6. A lightweight version of these protocols has also been specified [RFC5790].

マルチキャストを使用するには、トランスポートAPIで追加のプリミティブが必要です。これらのプリミティブは、IPv4およびIPv6ネットワーク層プロトコルの操作を調整するために呼び出す必要があります。たとえば、グループに送信されたデータグラムを受信するには、エンドポイントはまずネットワーク層でマルチキャストグループのメンバーになる必要があります。ローカルマルチキャスト受信は、インターネットグループ管理プロトコル（IGMP）[RFC3376] [RFC4604]によってIPv4用に通知されます。 IPv6は、ICMPv6で伝送される同等のマルチキャストリスナーディスカバリ（MLD）プロトコル[RFC3810] [RFC5790]を使用します。これらのプロトコルの軽量バージョンも指定されています[RFC5790]。

The following are defined:

以下が定義されています：

JoinHostGroup: Section 7.1 of "Host Extensions for IP Multicasting" [RFC1112] provides a function that allows receiving traffic from an IP multicast group.

JoinHostGroup：「IPマルチキャストのホスト拡張」のセクション7.1 [RFC1112]は、IPマルチキャストグループからトラフィックを受信できるようにする機能を提供します。

JoinLocalGroup: Section 7.3 of "Host Extensions for IP Multicasting" [RFC1112] provides a function that allows receiving traffic from a local IP multicast group.

JoinLocalGroup：「IPマルチキャストのホスト拡張機能」のセクション7.3 [RFC1112]は、ローカルIPマルチキャストグループからトラフィックを受信できるようにする機能を提供します。

LeaveHostGroup: Section 7.1 of "Host Extensions for IP Multicasting" [RFC1112] provides a function that allows leaving an IP multicast group.

LeaveHostGroup：「IPマルチキャストのホスト拡張」[RFC1112]のセクション7.1は、IPマルチキャストグループからの脱退を可能にする機能を提供します。

LeaveLocalGroup: Section 7.3 of "Host Extensions for IP Multicasting" [RFC1112] provides a function that allows leaving a local IP multicast group.

LeaveLocalGroup：「IPマルチキャストのホスト拡張」[RFC1112]のセクション7.3は、ローカルIPマルチキャストグループからの脱退を可能にする機能を提供します。

IPV6_MULTICAST_IF: Section 5.2 of the basic socket extensions for IPv6 [RFC3493] states that this sets the interface that will be used for outgoing multicast packets.

IPV6_MULTICAST_IF：IPv6の基本的なソケット拡張のセクション5.2 [RFC3493]には、これが発信マルチキャストパケットに使用されるインターフェースを設定することが記載されています。

IP_MULTICAST_TTL: This sets the time-to-live field t to use for outgoing IPv4 multicast packets. This is used to limit the scope of multicast datagrams. Methods such as "The Generalized TTL Security Mechanism (GTSM)" [RFC5082] set this value to ensure link-local transmission. GTSM also requires the UDP receiver API to pass the received value of this field to the application.

IP_MULTICAST_TTL：これは、発信IPv4マルチキャストパケットに使用する存続時間フィールドtを設定します。これは、マルチキャストデータグラムのスコープを制限するために使用されます。「一般化されたTTLセキュリティメカニズム（GTSM）」[RFC5082]などの方法は、リンクローカル転送を確実にするためにこの値を設定します。 GTSMでは、このフィールドの受信値をアプリケーションに渡すために、UDPレシーバーAPIも必要です。

IPV6_MULTICAST_HOPS: Section 5.2 of the basic socket extensions for IPv6 [RFC3493] states that this sets the hop count to use for outgoing multicast IPv6 packets. (This is equivalent to IP_MULTICAST_TTL used for IPv4 multicast.)

IPV6_MULTICAST_HOPS：IPv6の基本的なソケット拡張のセクション5.2 [RFC3493]には、これが発信マルチキャストIPv6パケットに使用するホップカウントを設定することが記載されています。（これは、IPv4マルチキャストに使用されるIP_MULTICAST_TTLに相当します。）

IPV6_MULTICAST_LOOP: Section 5.2 of the basic socket extensions for IPv6 [RFC3493] states that this sets whether a copy of a datagram is looped back by the IP layer for local delivery when the datagram is sent to a group to which the sending host itself belongs).

IPV6_MULTICAST_LOOP：IPv6の基本的なソケット拡張のセクション5.2 [RFC3493]には、送信側ホスト自体が属するグループにデータグラムが送信されたときに、ローカル配信用にデータグラムのコピーがIPレイヤーによってループバックされるかどうかが設定されていることが示されています）。

IPV6_JOIN_GROUP: Section 5.2 of the basic socket extensions for IPv6 [RFC3493] provides a function that allows an endpoint to join an IPv6 multicast group.

IPV6_JOIN_GROUP：IPv6の基本的なソケット拡張のセクション5.2 [RFC3493]は、エンドポイントがIPv6マルチキャストグループに参加できるようにする機能を提供します。

SIOCGIPMSFILTER: Section 8.1 of the socket interface for MSF [RFC3678] provides a function that allows reading the multicast source filters.

SIOCGIPMSFILTER：MSFのソケットインターフェイスのセクション8.1 [RFC3678]は、マルチキャストソースフィルターを読み取ることができる機能を提供します。

SIOCSIPMSFILTER: Section 8.1 of the socket interface for MSF [RFC3678] provides a function that allows setting/modifying the multicast source filters.

SIOCSIPMSFILTER：MSFのソケットインターフェイスのセクション8.1 [RFC3678]は、マルチキャストソースフィルターの設定/変更を可能にする機能を提供します。

IPV6_LEAVE_GROUP: Section 5.2 of the basic socket extensions for IPv6 [RFC3493] provides a function that allows leaving an IPv6 multicast group.

IPV6_LEAVE_GROUP：IPv6の基本的なソケット拡張のセクション5.2 [RFC3493]は、IPv6マルチキャストグループからの脱退を可能にする機能を提供します。

The socket interface extensions for MSF [RFC3678] updates the multicast interface to add support for MSF for IPv4 and IPv6 required by IGMPv3. Section 3 defines both basic and advanced APIs, and Section 5 describes protocol-independent versions of these APIs. Four sets of API functionality are therefore defined:

MSFのソケットインターフェイス拡張[RFC3678]はマルチキャストインターフェイスを更新して、IGMPv3で必要なIPv4およびIPv6のMSFのサポートを追加します。セクション3では、基本APIと高度なAPIの両方を定義し、セクション5では、これらのAPIのプロトコルに依存しないバージョンについて説明します。したがって、4組のAPI機能が定義されています。

1. IPv4 Basic (Delta-based) API. "Each function call specifies a single source address which should be added to or removed from the existing filter for a given multicast group address on which to listen."

1. IPv4 Basic（Delta-based）API。「各関数呼び出しは、リッスンする特定のマルチキャストグループアドレスの既存のフィルターに追加または削除する必要がある単一の送信元アドレスを指定します。」

2. IPv4 Advanced (Full-state) API. "This API allows an application to define a complete source-filter comprised of zero or more source addresses, and replace the previous filter with a new one."

2. IPv4 Advanced（Full-state）API。「このAPIを使用すると、アプリケーションは0個以上の送信元アドレスで構成される完全な送信元フィルターを定義し、以前のフィルターを新しいフィルターに置き換えることができます。」

3. Protocol-Independent Basic MSF (Delta-based) API.

3. プロトコルに依存しない基本的なMSF（Deltaベース）API。

4. Protocol-Independent Advanced MSF (Full-state) API.

4. プロトコルに依存しない高度なMSF（フルステート）API。

It specifies the following primitives:

次のプリミティブを指定します。

IP_ADD_MEMBERSHIP: This is used to join an ASM group.

IP_ADD_MEMBERSHIP：これは、ASMグループに参加するために使用されます。

IP_BLOCK_SOURCE: This MSF can block data from a given multicast source to a given ASM or SSM group.

IP_BLOCK_SOURCE：このMSFは、特定のマルチキャストソースから特定のASMまたはSSMグループへのデータをブロックできます。

IP_UNBLOCK_SOURCE: This updates an MSF to undo a previous call to IP_UNBLOCK_SOURCE for an ASM or SSM group.

IP_UNBLOCK_SOURCE：これは、ASMまたはSSMグループのIP_UNBLOCK_SOURCEへの以前の呼び出しを取り消すためにMSFを更新します。

IP_DROP_MEMBERSHIP: This is used to leave an ASM or SSM group. (In SSM, this drops all sources that have been joined for a particular group and interface. The operations are the same as if the socket had been closed.)

IP_DROP_MEMBERSHIP：これは、ASMまたはSSMグループを離れるために使用されます。（SSMでは、これにより、特定のグループおよびインターフェースに参加しているすべてのソースがドロップされます。操作は、ソケットが閉じられた場合と同じです。）

Section 4.1.2 of the socket interface for MSF [RFC3678] updates the interface to add IPv4 MSF support to IGMPv3 using ASM:

MSFのソケットインターフェイス[RFC3678]のセクション4.1.2は、インターフェイスを更新して、ASMを使用してIPv4 MSFサポートをIGMPv3に追加します。

IP_ADD_SOURCE_MEMBERSHIP: This is used to join an SSM group.

IP_ADD_SOURCE_MEMBERSHIP：これは、SSMグループに参加するために使用されます。

IP_DROP_SOURCE_MEMBERSHIP: This is used to leave an SSM group.

IP_DROP_SOURCE_MEMBERSHIP：これは、SSMグループを離脱するために使用されます。

Section 4.2 of the socket interface for MSF [RFC3678] defines the Advanced (Full-state) API:

MSFのソケットインターフェイスのセクション4.2 [RFC3678]は、高度な（フルステート）APIを定義しています。

setipv4sourcefilter: This is used to join an IPv4 multicast group or to enable multicast from a specified source.

setipv4sourcefilter：これは、IPv4マルチキャストグループに参加するか、指定されたソースからのマルチキャストを有効にするために使用されます。

getipv4sourcefilter: This is used to leave an IPv4 multicast group or to filter multicast from a specified source.

getipv4sourcefilter：これは、IPv4マルチキャストグループを脱退するか、指定されたソースからのマルチキャストをフィルタリングするために使用されます。

Section 5.1 of the socket interface for MSF [RFC3678] specifies Protocol-Independent Multicast API functions:

MSFのソケットインターフェイスのセクション5.1 [RFC3678]は、プロトコルに依存しないマルチキャストAPI関数を指定しています。

MCAST_JOIN_GROUP: This is used to join an ASM group.

MCAST_JOIN_GROUP：これは、ASMグループに参加するために使用されます。

MCAST_JOIN_SOURCE_GROUP: This is used to join an SSM group.

MCAST_JOIN_SOURCE_GROUP：これは、SSMグループに参加するために使用されます。

MCAST_BLOCK_SOURCE: This is used to block a source in an ASM group.

MCAST_BLOCK_SOURCE：これは、ASMグループのソースをブロックするために使用されます。

MCAST_UNBLOCK_SOURCE: This removes a previous MSF set by MCAST_BLOCK_SOURCE.

MCAST_UNBLOCK_SOURCE：これにより、MCAST_BLOCK_SOURCEによって設定された以前のMSFが削除されます。

MCAST_LEAVE_GROUP: This leaves an ASM or SSM group.

MCAST_LEAVE_GROUP：ASMまたはSSMグループを残します。

MCAST_LEAVE_SOURCE_GROUP: This leaves an SSM group.

MCAST_LEAVE_SOURCE_GROUP：SSMグループを離れます。

Section 5.2 of the socket interface for MSF [RFC3678] specifies the Protocol-Independent Advanced MSF (Full-state) API applicable for both IPv4 and IPv6:

MSFのソケットインターフェイスのセクション5.2 [RFC3678]は、IPv4とIPv6の両方に適用可能なプロトコルに依存しない高度なMSF（フルステート）APIを指定しています。

setsourcefilter: This is used to join an IPv4 or IPv6 multicast group or to enable multicast from a specified source.

setsourcefilter：これは、IPv4またはIPv6マルチキャストグループに参加するか、指定されたソースからのマルチキャストを有効にするために使用されます。

getsourcefilter: This is used to leave an IPv4 or IPv6 multicast group or to filter multicast from a specified source.

getsourcefilter：これは、IPv4またはIPv6マルチキャストグループを離れるか、指定されたソースからのマルチキャストをフィルタリングするために使用されます。

The Lightweight IGMPv3 (LW_IGMPv3) and MLDv2 protocol [RFC5790] updates this interface (in Section 7.2 of RFC 5790).

Lightweight IGMPv3（LW_IGMPv3）およびMLDv2プロトコル[RFC5790]は、このインターフェイスを更新します（RFC 5790のセクション7.2）。

Acknowledgements

謝辞

This work was partially funded by the European Union's Horizon 2020 research and innovation programme under grant agreement No. 644334 (NEAT). Thanks to all who have commented or contributed, including Joe Touch, Ted Hardie, Aaron Falk, Tommy Pauly, and Francis Dupont.

この研究は、助成金契約番号644334（NEAT）に基づくEUのHorizon 2020研究および革新プログラムによって部分的に資金提供されました。 Joe Touch、Ted Hardie、Aaron Falk、Tommy Pauly、Francis Dupontなど、コメントまたは寄稿してくれたすべての人に感謝します。

Authors' Addresses

著者のアドレス

Godred Fairhurst University of Aberdeen School of Engineering Fraser Noble Building Fraser Noble Building Aberdeen AB24 3UE United Kingdom

Godred Fairhurst University of Aberdeen School of EngineeringフレーザーノーブルビルディングフレーザーノーブルビルディングアバディーンAB24 3UEイギリス

   Email: gorry@erg.abdn.ac.uk

Tom Jones University of Aberdeen School of Engineering Fraser Noble Building Aberdeen AB24 3UE United Kingdom

トムジョーンズアバディーン大学工学部フレーザーノーブルビルディングアバディーンAB24 3UEイギリス

   Email: tom@erg.abdn.ac.uk