[要約] RFC 3678は、マルチキャストソースフィルタのためのソケットインターフェース拡張に関する規格です。このRFCの目的は、マルチキャストトラフィックの送信元をフィルタリングするための機能を提供することです。
Network Working Group D. Thaler
Request for Comments: 3678 Microsoft
Category: Informational B. Fenner
AT&T Research
B. Quinn
Stardust.com
January 2004
Socket Interface Extensions for Multicast Source Filters
マルチキャストソースフィルターのソケットインターフェイス拡張機能
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
Abstract
概要
The Internet Group Management Protocol (IGMPv3) for IPv4 and the Multicast Listener Discovery (MLDv2) for IPv6 add the capability for applications to express source filters on multicast group memberships, which allows receiver applications to determine the set of senders (sources) from which to accept multicast traffic. This capability also simplifies support of one-to-many type multicast applications.
IPv4用のインターネットグループ管理プロトコル（IGMPV3）およびIPv6のマルチキャストリスナーディスカバリー（MLDV2）は、アプリケーションの機能を追加してマルチキャストグループメンバーシップでソースフィルターを表現します。これにより、レシーバーアプリケーションは、マルチキャストトラフィックを受け入れます。この機能は、1対多数のマルチキャストアプリケーションのサポートも簡素化されます。
This document specifies new socket options and functions to manage source filters for IP Multicast group memberships. It also defines the socket structures to provide input and output arguments to these new application program interfaces (APIs). These extensions are designed to provide access to the source filtering features, while introducing a minimum of change into the system and providing complete compatibility for existing multicast applications.
このドキュメントは、IPマルチキャストグループメンバーシップのソースフィルターを管理するための新しいソケットオプションと機能を指定します。また、ソケット構造を定義して、これらの新しいアプリケーションプログラムインターフェイス（API）に入力と出力の引数を提供します。これらの拡張機能は、ソースフィルタリング機能へのアクセスを提供しながら、システムに最小限の変更を導入し、既存のマルチキャストアプリケーションに完全な互換性を提供するように設計されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Design Considerations. . . . . . . . . . . . . . . . . . . . . 3
2.1 What Needs to be Added . . . . . . . . . . . . . . . . . . 4
2.2 Data Types . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Headers. . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Structures . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of APIs. . . . . . . . . . . . . . . . . . . . . . . . 5
4. IPv4 Multicast Source Filter APIs . . . . . . . . . . . . . . . 6
4.1 Basic (Delta-based) API for IPv4. . . . . . . . . . . . . . 6
4.1.1 IPv4 Any-Source Multicast API. . . . . . . . . . . . 7
4.1.2 IPv4 Source-Specific Multicast API . . . . . . . . . 7
4.1.3 Error Codes. . . . . . . . . . . . . . . . . . . . . 8
4.2 Advanced (Full-state) API for IPv4. . . . . . . . . . . . . 8
4.2.1 Set Source Filter. . . . . . . . . . . . . . . . . . 8
4.2.2 Get Source Filter. . . . . . . . . . . . . . . . . . 9
5: Protocol-Independent Multicast Source Filter APIs . . . . . . . 10
5.1 Basic (Delta-based) API . . . . . . . . . . . . . . . . . . 10
5.1.1 Any-Source Multicast API . . . . . . . . . . . . . . 11
5.1.2 Source-Specific Multicast API. . . . . . . . . . . . 11
5.2 Advanced (Full-state) API . . . . . . . . . . . . . . . . . 11
5.2.1 Set Source Filter. . . . . . . . . . . . . . . . . . 11
5.2.2 Get Source Filter. . . . . . . . . . . . . . . . . . 12
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 13
8. Appendix A: Use of ioctl() for full-state operations . . . . . 14
8.1. IPv4 Options. . . . . . . . . . . . . . . . . . . . . . . 14
8.2. Protocol-Independent Options. . . . . . . . . . . . . . . 15
9. Normative References . . . . . . . . . . . . . . . . . . . . . 16
10. Informative References . . . . . . . . . . . . . . . . . . . . 16
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
The de facto standard application program interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with applications that employ multicast source filters. Changes are required to the sockets API to support such filtering and this memo describes these changes.
TCP/IPアプリケーションの事実上の標準アプリケーションプログラムインターフェイス（API）は、「ソケット」インターフェイスです。このAPIは1980年代初頭にUNIX向けに開発されましたが、さまざまな非UNIXシステムにも実装されています。Sockets APIを使用して書かれたTCP/IPアプリケーションは、過去に高度な携帯性を享受していたため、マルチキャストソースフィルターを使用するアプリケーションと同じ移植性を希望します。このようなフィルタリングをサポートするには、Sockets APIに変更が必要であり、このメモはこれらの変更について説明しています。
This document specifies new socket options and functions to manage source filters for IP Multicast group memberships. It also defines the socket structures to provide input and output arguments to these new APIs. These extensions are designed to provide access to the source filtering features required by applications, while introducing a minimum of change into the system and providing complete compatibility for existing multicast applications.
このドキュメントは、IPマルチキャストグループメンバーシップのソースフィルターを管理するための新しいソケットオプションと機能を指定します。また、ソケット構造を定義して、これらの新しいAPIに入力と出力の引数を提供します。これらの拡張機能は、アプリケーションに必要なソースフィルタリング機能へのアクセスを提供するように設計されており、システムに最小限の変更を導入し、既存のマルチキャストアプリケーションに完全な互換性を提供します。
Furthermore, RFC 3493 [1] defines socket interface extensions for IPv6, including protocol-independent functions for most operations.
さらに、RFC 3493 [1]は、ほとんどの操作のプロトコル非依存関数を含むIPv6のソケットインターフェイス拡張機能を定義します。
However, while it defines join and leave functions for IPv6, it does not provide protocol-independent versions of these operations. Such functions will be described in this document.
ただし、IPv6のJoinおよびLeave Functionを定義しますが、これらの操作のプロトコルに依存しないバージョンを提供しません。このような機能については、このドキュメントで説明します。
The reader should note that this document is for informational purposes only, and that the official standard specification of the sockets API is [2].
読者は、このドキュメントは情報提供のみを目的としており、ソケットAPIの公式標準仕様は[2]であることに注意する必要があります。
There are a number of important considerations in designing changes to this well-worn API:
この使い古されたAPIの変更を設計する際には、多くの重要な考慮事項があります。
o The API changes should provide both source and binary compatibility for programs written to the original API. That is, existing program binaries should continue to operate when run on a system supporting the new API. In addition, existing applications that are re-compiled and run on a system supporting the new API should continue to operate. Simply put, the API changes for multicast receivers that specify source filters should not break existing programs.
o APIの変更は、元のAPIに書かれたプログラムのソースとバイナリの互換性の両方を提供する必要があります。つまり、既存のプログラムバイナリは、新しいAPIをサポートするシステムで実行すると、引き続き動作します。さらに、新しいAPIをサポートするシステムで再コンパイルされて実行される既存のアプリケーションは、引き続き動作し続ける必要があります。簡単に言えば、ソースフィルターを指定するマルチキャストレシーバーのAPI変更は、既存のプログラムを壊してはなりません。
o The changes to the API should be as small as possible in order to simplify the task of converting existing multicast receiver applications to use source filters.
o APIの変更は、既存のマルチキャストレシーバーアプリケーションを変換してソースフィルターを使用するタスクを簡素化するために、できるだけ小さくする必要があります。
o Applications should be able to detect when the new source filter APIs are unavailable (e.g., calls fail with the ENOTSUPP error) and react gracefully (e.g., revert to old non-source-filter API or display a meaningful error message to the user).
o アプリケーションは、新しいソースフィルターAPIが利用できない場合（たとえば、コールがeNotsuppエラーで失敗する）、優雅に反応する場合（たとえば、古い非ソースフィルターAPIに戻るか、ユーザーに意味のあるエラーメッセージを表示するか）を検出できる必要があります。
o Lack of type-safety in an API is a bad thing which should be avoided when possible.
o APIのタイプセーフティの欠如は、可能な場合は避けるべき悪いことです。
Several implementations exist that use ioctl() for a portion of the functionality described herein, and for historical purposes, the ioctl API is documented in Appendix A. The preferred API, however, includes new functions. The reasons for adding new functions are:
本明細書で説明した機能の一部にIOCTL（）を使用するいくつかの実装が存在し、歴史的な目的のために、IOCTL APIは付録Aに文書化されています。ただし、好ましいAPIには新しい機能が含まれています。新しい機能を追加する理由は次のとおりです。
o New functions provide type-safety, unlike ioctl, getsockopt, and setsockopt.
o 新しい機能は、ioctl、getSockopt、およびsetSockoptとは異なり、タイプセーフティを提供します。
o A new function can be written as a wrapper over an ioctl, getsockopt, or setsockopt call, if necessary. Hence, it provides more freedom as to how the functionality is implemented in an operating system. For example, a new function might be implemented as an inline function in an include file, or a function exported from a user-mode library which internally uses some mechanism to exchange information with the kernel, or be implemented directly in the kernel.
o 必要に応じて、新しい関数は、ioctl、getsockopt、またはsetsockoptの呼び出しをめぐるラッパーとして記述できます。したがって、オペレーティングシステムで機能がどのように実装されているかについて、より多くの自由を提供します。たとえば、新しい関数は、インクルードファイルのインライン関数として実装されている場合、またはいくつかのメカニズムを内部的に使用してカーネルと交換するか、カーネルに直接実装されるユーザーモードライブラリからエクスポートされる関数です。
o At least one operation defined herein needs to be able to both pass information to the TCP/IP stack, as well as retrieve information from it. In some implementations this is problematic without either changing getsockopt or using ioctl. Using new functions avoids the need to change such implementations.
o 本明細書で定義されている少なくとも1つの操作は、情報をTCP/IPスタックに渡すことと、そこから情報を取得できる必要があります。いくつかの実装では、GetSockoptまたはIOCTLを使用することなく、これは問題があります。新しい関数を使用すると、そのような実装を変更する必要性が回避されます。
The current IP Multicast APIs allow a receiver application to specify the group address (destination) and (optionally) the local interface. These existing APIs need not change (and cannot, to retain binary compatibility). Hence, what is needed are new source filter APIs that provide the same functionality and also allow receiver multicast applications to:
現在のIPマルチキャストAPIにより、受信機アプリケーションはグループアドレス（宛先）と（オプションで）ローカルインターフェイスを指定できます。これらの既存のAPIは、バイナリの互換性を保持するために変更する必要はありません。したがって、必要なのは、同じ機能を提供し、レシーバーマルチキャストアプリケーションを次のようにする新しいソースフィルターAPIです。
o Specify zero or more unicast (source) address(es) in a source filter.
o ソースフィルターでゼロ以上のユニキャスト（ソース）アドレス（es）を指定します。
o Determine whether the source filter describes an inclusive or exclusive list of sources.
o ソースフィルターが、ソースの包括的または排他的リストを記述するかどうかを判断します。
The new API design must enable this functionality for both IPv4 and IPv6.
新しいAPI設計では、IPv4とIPv6の両方でこの機能を有効にする必要があります。
The data types of the structure elements given in this memo are intended to be examples, not absolute requirements. Whenever possible, data types from POSIX 1003.1g [2] are used: uintN_t means an unsigned integer of exactly N bits (e.g., uint32_t).
このメモに記載されている構造要素のデータ型は、絶対要件ではなく、例であることを目的としています。可能な場合はいつでも、POSIX 1003.1g [2]のデータ型が使用されます。UINTN_Tとは、正確なNビット（UINT32_Tなど）の署名のない整数を意味します。
When function prototypes and structures are shown, we show the headers that must be #included to cause that item to be defined.
関数のプロトタイプと構造が表示されると、そのアイテムを定義するために#includedでなければならないヘッダーを示します。
When structures are described, the members shown are the ones that must appear in an implementation. Additional, nonstandard members may also be defined by an implementation. As an additional precaution, nonstandard members could be verified by Feature Test Macros as described in [2]. (Such Feature Test Macros are not defined by this RFC.)
構造が記載されている場合、示されているメンバーは、実装に表示されなければならないメンバーです。追加の非標準メンバーは、実装によって定義される場合もあります。追加の予防策として、[2]で説明されているように、非標準のメンバーは特徴テストマクロによって検証できます。（このような機能テストマクロは、このRFCによって定義されていません。）
The ordering shown for the members of a structure is the recommended ordering, given alignment considerations of multibyte members, but an implementation may order the members differently.
構造のメンバーに示されている順序は、マルチバイトメンバーのアラインメントに関する考慮事項を考慮して、推奨される注文ですが、実装によりメンバーが異なる方法で注文する場合があります。
There are a number of different APIs described in this document that are appropriate for a number of different application types and IP versions. Before providing detailed descriptions, this section provides a "taxonomy" with a brief description of each.
このドキュメントには、さまざまなアプリケーションタイプとIPバージョンに適したさまざまなAPIがあります。詳細な説明を提供する前に、このセクションはそれぞれの簡単な説明を含む「分類」を提供します。
There are two categories of source-filter APIs, both of which are designed to allow multicast receiver applications to designate the unicast address(es) of sender(s) along with the multicast group (destination address) to receive.
ソースフィルターAPIには2つのカテゴリがあり、どちらもマルチキャストレシーバーアプリケーションが送信者のユニキャストアドレス（es）を指定し、マルチキャストグループ（宛先アドレス）を受信できるように設計されています。
o Basic (Delta-based): Some applications desire the simplicity of a delta-based API in which 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. Such applications typically fall into either of two categories:
o BASIC（DELTAベース）：一部のアプリケーションは、各関数呼び出しが、リッスンする特定のマルチキャストグループアドレスの既存のフィルターに追加または削除する必要がある単一のソースアドレスを指定するデルタベースのAPIのシンプルさを望んでいます。このようなアプリケーションは通常、2つのカテゴリのいずれかに分類されます。
+ Any-Source Multicast: By default, all sources are accepted. Individual sources may be turned off and back on as needed over time. This is also known as "exclude" mode, since the source filter contains a list of excluded sources.
+ 任意のソースマルチキャスト：デフォルトでは、すべてのソースが受け入れられます。個々のソースは、必要に応じてオフにして、時間の経過とともにオンになる場合があります。ソースフィルターには除外されたソースのリストが含まれているため、これは「除外」モードとしても知られています。
+ Source-Specific Multicast: Only sources in a given list are allowed. The list may change over time. This is also known as "include" mode, since the source filter contains a list of included sources.
+ ソース固有のマルチキャスト：特定のリストのソースのみが許可されます。リストは時間とともに変更される場合があります。ソースフィルターには含まれるソースのリストが含まれているため、これは「含める」モードとしても知られています。
This API would be used, for example, by "single-source" applications such as audio/video broadcasting. It would also be used for logical multi-source sessions where each source independently allocates its own Source-Specific Multicast group address.
このAPIは、たとえば、オーディオ/ビデオブロードキャストなどの「シングルソース」アプリケーションによって使用されます。また、各ソースが独自のソース固有のマルチキャストグループアドレスを個別に割り当てる論理的なマルチソースセッションにも使用されます。
o Advanced (Full-state): 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.
o Advanced（Full-state）：このAPIにより、アプリケーションはゼロ以上のソースアドレスで構成される完全なソースフィルターを定義し、以前のフィルターを新しいフィルターに置き換えることができます。
Applications which require the ability to switch between filter modes without leaving a group must use a full-state API (i.e., to change the semantics of the source filter from inclusive to exclusive, or vice versa).
グループを離れることなくフィルターモードを切り替える機能を必要とするアプリケーションは、フルステートAPIを使用する必要があります（つまり、ソースフィルターのセマンティクスを包括的から排他的に変更する、またはその逆に変更する必要があります）。
Applications which use a large source list for a given group address should also use the full-state API, since filter changes can be done atomically in a single operation.
特定のグループアドレスに大きなソースリストを使用するアプリケーションは、フィルターの変更を単一の操作で原子的に実行できるため、完全な状態APIを使用する必要があります。
The above types of APIs exist in IPv4-specific variants as well as with protocol-independent variants. One might ask why the protocol-independent APIs cannot accommodate IPv4 applications as well as IPv6. Since any IPv4 application requires modification to use multicast source filters anyway, it might seem like a good opportunity to create IPv6-compatible source code.
上記のタイプのAPIは、IPv4固有のバリアントとプロトコル非依存性バリアントに存在します。プロトコルに依存しないAPIがIPv4アプリケーションとIPv6に対応できない理由を尋ねるかもしれません。とにかくIPv4アプリケーションでは、マルチキャストソースフィルターを使用するために変更が必要なため、IPv6互換のソースコードを作成する良い機会のように思えるかもしれません。
The primary reasons for extending an IPv4-specific API are:
IPv4固有のAPIを拡張する主な理由は、次のとおりです。
o To minimize changes needed in existing IPv4 multicast application source code to add source filter support.
o 既存のIPv4マルチキャストアプリケーションソースコードで必要な変更を最小限に抑えるには、ソースフィルターサポートを追加します。
o To avoid overloading APIs to accommodate the differences between IPv4 interface addresses (e.g., in the ip_mreq structure) and interface indices.
o APIの過負荷を回避して、IPv4インターフェイスアドレス（例：IP_MREQ構造）とインターフェイスインデックスの違いに対応します。
Version 3 of the Internet Group Management Protocol (IGMPv3) [3] and version 2 of the Multicast Listener Discovery (MLDv2) protocol [4] provide the ability to communicate source filter information to the router and hence avoid pulling down data from unwanted sources onto the local link. However, source filters may be implemented by the operating system regardless of whether the routers support IGMPv3 or MLDv2, so when the source-filter API is available, applications can always benefit from using it.
インターネットグループ管理プロトコル（IGMPV3）[3]のバージョン3およびマルチキャストリスナーディスカバリー（MLDV2）プロトコル[4]のバージョン2は、ソースフィルター情報をルーターに通信する機能を提供し、したがって、不要なソースからデータを引き下げないようにします。ローカルリンク。ただし、ソースフィルターは、ルーターがIGMPv3またはMLDV2をサポートするかどうかに関係なく、オペレーティングシステムによって実装される場合があるため、ソースフィルターAPIが利用可能な場合、アプリケーションは常にそれを使用することで利益を得ることができます。
The reception of multicast packets is controlled by the setsockopt() options summarized below. An error of EOPNOTSUPP is returned if these options are used with getsockopt().
マルチキャストパケットの受信は、以下にまとめたSetSockopt（）オプションによって制御されます。これらのオプションがgetSockopt（）で使用される場合、eopnotsuppのエラーが返されます。
The following structures are used by both the Any-Source Multicast and the Source-Specific Multicast API:
次の構造は、任意のソースマルチキャストとソース固有のマルチキャストAPIの両方で使用されます。
#include <netinet/in.h>
struct ip_mreq {
struct in_addr imr_multiaddr; /* IP address of group */
struct in_addr imr_interface; /* IP address of interface */
};
struct ip_mreq_source {
struct in_addr imr_multiaddr; /* IP address of group */
struct in_addr imr_sourceaddr; /* IP address of source */
struct in_addr imr_interface; /* IP address of interface */
};
The following socket options are defined in <netinet/in.h> for applications in the Any-Source Multicast category:
次のソケットオプションは、任意のソースマルチキャストカテゴリのアプリケーションの<netinet/in.h>で定義されています。
Socket option Argument type
IP_ADD_MEMBERSHIP struct ip_mreq
IP_BLOCK_SOURCE struct ip_mreq_source
IP_UNBLOCK_SOURCE struct ip_mreq_source
IP_DROP_MEMBERSHIP struct ip_mreq
IP_ADD_MEMBERSHIP and IP_DROP_MEMBERSHIP are already implemented on most operating systems, and are used to join and leave an any-source group.
IP_ADD_MEMBERSHIPとIP_DROP_MEMBERSHIPは、ほとんどのオペレーティングシステムですでに実装されており、任意のソースグループに参加して出発するために使用されます。
IP_BLOCK_SOURCE can be used to block data from a given source to a given group (e.g., if the user "mutes" that source), and IP_UNBLOCK_SOURCE can be used to undo this (e.g., if the user then "unmutes" the source).
IP_BLOCK_SOURCEを使用して、特定のソースから特定のグループ（ユーザーがそのソースを「ミュート」する場合）にデータをブロックし、IP_Unblock_Sourceを使用してこれを元に戻すことができます（たとえば、ユーザーがソースを「解消する」場合）。
The following socket options are available for applications in the Source-Specific category:
ソース固有のカテゴリのアプリケーションでは、次のソケットオプションを使用できます。
Socket option Argument type IP_ADD_SOURCE_MEMBERSHIP struct ip_mreq_source IP_DROP_SOURCE_MEMBERSHIP struct ip_mreq_source IP_DROP_MEMBERSHIP struct ip_mreq
ソケットオプション引数タイプip_add_source_membership struct ip_mreq_source ip_drop_source_membership struct ip_mreq_source ip_drop_membership struct ip_mreq
IP_ADD_SOURCE_MEMBERSHIP and IP_DROP_SOURCE_MEMBERSHIP are used to join and leave a source-specific group.
ip_add_source_membershipとip_drop_source_membershipは、ソース固有のグループに参加して去るために使用されます。
IP_DROP_MEMBERSHIP is supported, as a convenience, to drop all sources which have been joined for a particular group and interface. The operations are the same as if the socket had been closed.
IP_DROP_MEMBERSHIPは、特定のグループとインターフェイスのために結合されたすべてのソースをドロップするために、利便性としてサポートされています。操作は、ソケットが閉じられていた場合と同じです。
When the option would be legal on the group, but an address is invalid (e.g., when trying to block a source that is already blocked by the socket, or when trying to drop an unjoined group) the error generated is EADDRNOTAVAIL.
オプションがグループで合法であるが、アドレスが無効である場合（たとえば、ソケットによってすでにブロックされているソースをブロックしようとする場合、または接続されていないグループをドロップしようとする場合）、生成されたエラーはEaddrnotavailです。
When the option itself is not legal on the group (i.e., when trying a Source-Specific option on a group after doing IP_ADD_MEMBERSHIP, or when trying an Any-Source option without doing IP_ADD_MEMBERSHIP) the error generated is EINVAL.
オプション自体がグループで合法でない場合（つまり、IP_ADD_MEMBERSHIPを実行した後、またはIP_ADD_MEMBERSHIPを実行せずに任意のソースオプションを試すときにグループでソース固有のオプションを試す場合）エラーはEINVALです。
When any of these options are used with getsockopt(), the error generated is EOPNOTSUPP.
これらのオプションのいずれかがgetSockopt（）で使用される場合、生成されるエラーはeopnotsuppです。
Finally, if the implementation imposes a limit on the maximum number of sources in a source filter, ENOBUFS is generated when an operation would exceed the maximum.
最後に、実装がソースフィルター内のソースの最大数に制限を課す場合、操作が最大を超えるとENOBUFSが生成されます。
Several implementations exist that use ioctl() for this API, and for historical purposes, the ioctl() API is documented in Appendix A. The preferred API uses the new functions described below.
このAPIにIOCTL（）を使用するいくつかの実装が存在し、歴史的な目的のために、IOCTL（）APIは付録Aに文書化されています。
#include <netinet/in.h>
int setipv4sourcefilter(int s, struct in_addr interface, struct in_addr group, uint32_t fmode, uint32_t numsrc, struct in_addr *slist);
int setipv4sourcefilter（int s、struct in_addrインターフェイス、struct in_addrグループ、uint32_t fmode、uint32_t numsrc、struct in_addr *slist）;
On success the value 0 is returned, and on failure, the value -1 is returned and errno is set accordingly.
成功すると、値0が返され、障害時に値-1が返され、それに応じてerrnoが設定されます。
The s argument identifies the socket.
S引数はソケットを識別します。
The interface argument holds the local IP address of the interface.
インターフェイス引数は、インターフェイスのローカルIPアドレスを保持します。
The group argument holds the IP multicast address of the group.
グループの引数は、グループのIPマルチキャストアドレスを保持しています。
The fmode argument identifies the filter mode. The value of this field must be either MCAST_INCLUDE or MCAST_EXCLUDE, which are likewise defined in <netinet/in.h>.
FMODE引数は、フィルターモードを識別します。このフィールドの値は、<netinet/in.h>で同様に定義されているmcast_includeまたはmcast_excludeのいずれかでなければなりません。
The numsrc argument holds the number of source addresses in the slist array.
NumSRC引数は、Slist配列内のソースアドレスの数を保持します。
The slist argument points to an array of IP addresses of sources to include or exclude depending on the filter mode.
Slist引数は、フィルターモードに応じて含める、または除外するソースのIPアドレスの配列を指します。
If the implementation imposes a limit on the maximum number of sources in a source filter, ENOBUFS is generated when the operation would exceed the maximum.
実装がソースフィルター内のソースの最大数に制限を課す場合、操作が最大を超えるとENOBUFSが生成されます。
#include <netinet/in.h>
int getipv4sourcefilter(int s, struct in_addr interface,
struct in_addr group, uint32_t *fmode,
uint32_t *numsrc, struct in_addr *slist);
On success the value 0 is returned, and on failure, the value -1 is returned and errno is set accordingly.
成功すると、値0が返され、障害時に値-1が返され、それに応じてerrnoが設定されます。
The s argument identifies the socket.
S引数はソケットを識別します。
The interface argument holds the local IP address of the interface.
インターフェイス引数は、インターフェイスのローカルIPアドレスを保持します。
The group argument holds the IP multicast address of the group.
グループの引数は、グループのIPマルチキャストアドレスを保持しています。
The fmode argument points to an integer that will contain the filter mode on a successful return. The value of this field will be either MCAST_INCLUDE or MCAST_EXCLUDE, which are likewise defined in <netinet/in.h>.
FMODE引数は、成功したリターンでフィルターモードを含む整数を指します。このフィールドの値は、<netinet/in.h>で同様に定義されているmcast_includeまたはmcast_excludeのいずれかです。
On input, the numsrc argument holds the number of source addresses that will fit in the slist array. On output, the numsrc argument will hold the total number of sources in the filter.
入力では、numSRC引数は、スリスト配列に適合するソースアドレスの数を保持します。出力では、NUMSRC引数はフィルター内のソースの総数を保持します。
The slist argument points to buffer into which an array of IP addresses of included or excluded (depending on the filter mode) sources will be written. If numsrc was 0 on input, a NULL pointer may be supplied.
Slist引数は、含まれるまたは除外された（フィルターモードに応じて）ソースのソースの配列が記述されるバッファーを指します。入力時にnumsrcが0の場合、ヌルポインターが提供される場合があります。
If the application does not know the size of the source list beforehand, it can make a reasonable guess (e.g., 0), and if upon completion, numsrc holds a larger value, the operation can be repeated with a large enough buffer.
アプリケーションが事前にソースリストのサイズを知らない場合、合理的な推測（例：0）を作成できます。完了時に、numSRCがより大きな値を保持する場合、操作は十分な大きさのバッファーで繰り返すことができます。
That is, on return, numsrc is always updated to be the total number of sources in the filter, while slist will hold as many source addresses as fit, up to the minimum of the array size passed in as the original numsrc value and the total number of sources in the filter.
つまり、返品時に、numSRCは常にフィルター内のソースの総数に更新されますが、slistは元のnumsrc値と合計と同じように渡されたアレイサイズの最小値まで、適合しているように多くのソースアドレスを保持します。フィルター内のソースの数。
Protocol-independent functions are provided for join and leave operations so that an application may pass a sockaddr_storage structure obtained from calls such as getaddrinfo() [1] as the group to join. For example, an application can resolve a DNS name (e.g., NTP.MCAST.NET) to a multicast address which may be either IPv4 or IPv6, and may easily join and leave the group.
プロトコルに依存しない関数は、結合操作と休暇操作に提供されるため、アプリケーションは、getaddrinfo（）[1]などのコールから得られるsockaddr_storage構造をグループとして渡すことができます。たとえば、アプリケーションは、IPv4またはIPv6のいずれかである可能性のあるマルチキャストアドレスにDNS名（ntp.mcast.netなど）を解決でき、グループを簡単に結合して去ることができます。
The reception of multicast packets is controlled by the setsockopt() options summarized below. An error of EOPNOTSUPP is returned if these options are used with getsockopt().
マルチキャストパケットの受信は、以下にまとめたSetSockopt（）オプションによって制御されます。これらのオプションがgetSockopt（）で使用される場合、eopnotsuppのエラーが返されます。
The following structures are used by both the Any-Source Multicast
and the Source-Specific Multicast API: #include <netinet/in.h>
struct group_req {
uint32_t gr_interface; /* interface index */
struct sockaddr_storage gr_group; /* group address */
};
struct group_source_req {
uint32_t gsr_interface; /* interface index */
struct sockaddr_storage gsr_group; /* group address */
struct sockaddr_storage gsr_source; /* source address */
};
The sockaddr_storage structure is defined in RFC 3493 [1] to be large enough to hold either IPv4 or IPv6 address information.
Sockaddr_storage構造は、RFC 3493 [1]で定義されており、IPv4またはIPv6アドレス情報のいずれかを保持するのに十分な大きさです。
The rules for generating errors are the same as those given in Section 5.1.3.
エラーを生成するためのルールは、セクション5.1.3に記載されているルールと同じです。
Socket option Argument type
MCAST_JOIN_GROUP struct group_req
MCAST_BLOCK_SOURCE struct group_source_req
MCAST_UNBLOCK_SOURCE struct group_source_req
MCAST_LEAVE_GROUP struct group_req
MCAST_JOIN_GROUP and MCAST_LEAVE_GROUP are used to join and leave an any-source group.
mcast_join_groupとmcast_leave_groupは、任意のソースグループに参加して去るために使用されます。
MCAST_BLOCK_SOURCE can be used to block data from a given source to a given group (e.g., if the user "mutes" that source), and MCAST_UNBLOCK_SOURCE can be used to undo this (e.g., if the user then "unmutes" the source).
mcast_block_sourceを使用して、特定のソースから特定のグループ（ユーザーがそのソースを「ミュート」する場合）にデータをブロックし、mcast_unblock_sourceを使用してこれを元に戻すことができます（たとえば、ユーザーがソースを「解消する」場合）。
Socket option Argument type
MCAST_JOIN_SOURCE_GROUP struct group_source_req
MCAST_LEAVE_SOURCE_GROUP struct group_source_req
MCAST_LEAVE_GROUP struct group_req
MCAST_JOIN_SOURCE_GROUP and MCAST_LEAVE_SOURCE_GROUP are used to join and leave a source-specific group.
mcast_join_source_groupおよびmcast_leave_source_groupは、ソース固有のグループに参加して去るために使用されます。
MCAST_LEAVE_GROUP is supported, as a convenience, to drop all sources which have been joined for a particular group and interface. The operations are the same as if the socket had been closed.
mcast_leave_groupは、特定のグループとインターフェイスのために結合されたすべてのソースをドロップするために、利便性としてサポートされています。操作は、ソケットが閉じられていた場合と同じです。
Implementations may exist that use ioctl() for this API, and for historical purposes, the ioctl() API is documented in Appendix A. The preferred API uses the new functions described below.
このAPIにIOCTL（）を使用する実装が存在する場合があり、歴史的な目的のために、IOCTL（）APIは付録Aに文書化されています。
#include <netinet/in.h>
int setsourcefilter(int s, uint32_t interface, struct sockaddr *group, socklen_t grouplen, uint32_t fmode, uint_t numsrc, struct sockaddr_storage *slist);
int SetSourceFilter（int S、UINT32_Tインターフェイス、struct sockaddr *グループ、socklen_t grouplen、uint32_t fmode、uint_t numsrc、struct sockaddr_storage *slist）;
On success the value 0 is returned, and on failure, the value -1 is returned and errno is set accordingly.
成功すると、値0が返され、障害時に値-1が返され、それに応じてerrnoが設定されます。
The s argument identifies the socket.
S引数はソケットを識別します。
The interface argument holds the interface index of the interface.
インターフェイス引数は、インターフェイスのインターフェイスインデックスを保持します。
The group argument points to either a sockaddr_in structure (for IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP multicast address of the group.
グループの引数は、グループのIPマルチキャストアドレスを保持するSockaddr_in構造（IPv4の場合）またはSockaddr_in6構造（IPv6の場合）を指しています。
The grouplen argument gives the length of the sockaddr_in or sockaddr_in6 structure.
グラップレンの引数は、sockaddr_inまたはsockaddr_in6構造の長さを示します。
The fmode argument identifies the filter mode. The value of this field must be either MCAST_INCLUDE or MCAST_EXCLUDE, which are likewise defined in <netinet/in.h>.
FMODE引数は、フィルターモードを識別します。このフィールドの値は、<netinet/in.h>で同様に定義されているmcast_includeまたはmcast_excludeのいずれかでなければなりません。
The numsrc argument holds the number of source addresses in the slist array.
NumSRC引数は、Slist配列内のソースアドレスの数を保持します。
The slist argument points to an array of IP addresses of sources to include or exclude depending on the filter mode.
Slist引数は、フィルターモードに応じて含める、または除外するソースのIPアドレスの配列を指します。
If the implementation imposes a limit on the maximum number of sources in a source filter, ENOBUFS is generated when the operation would exceed the maximum.
実装がソースフィルター内のソースの最大数に制限を課す場合、操作が最大を超えるとENOBUFSが生成されます。
#include <netinet/in.h>
int getsourcefilter(int s, uint32_t interface, struct sockaddr *group, socklen_t grouplen, uint32_t fmode, uint_t *numsrc, struct sockaddr_storage *slist);
int getSourceFilter（int s、uint32_tインターフェイス、struct sockaddr *group、socklen_t grouplen、uint32_t fmode、uint_t *numsrc、struct sockaddr_storage *slist）;
On success the value 0 is returned, and on failure, the value -1 is returned and errno is set accordingly.
成功すると、値0が返され、障害時に値-1が返され、それに応じてerrnoが設定されます。
The s argument identifies the socket.
S引数はソケットを識別します。
The interface argument holds the local IP address of the interface.
インターフェイス引数は、インターフェイスのローカルIPアドレスを保持します。
The group argument points to either a sockaddr_in structure (for IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP multicast address of the group.
グループの引数は、グループのIPマルチキャストアドレスを保持するSockaddr_in構造（IPv4の場合）またはSockaddr_in6構造（IPv6の場合）を指しています。
The fmode argument points to an integer that will contain the filter mode on a successful return. The value of this field will be either MCAST_INCLUDE or MCAST_EXCLUDE, which are likewise defined in <netinet/in.h>.
FMODE引数は、成功したリターンでフィルターモードを含む整数を指します。このフィールドの値は、<netinet/in.h>で同様に定義されているmcast_includeまたはmcast_excludeのいずれかです。
On input, the numsrc argument holds the number of source addresses that will fit in the slist array. On output, the numsrc argument will hold the total number of sources in the filter.
入力では、numSRC引数は、スリスト配列に適合するソースアドレスの数を保持します。出力では、NUMSRC引数はフィルター内のソースの総数を保持します。
The slist argument points to buffer into which an array of IP addresses of included or excluded (depending on the filter mode) sources will be written. If numsrc was 0 on input, a NULL pointer may be supplied.
Slist引数は、含まれるまたは除外された（フィルターモードに応じて）ソースのソースの配列が記述されるバッファーを指します。入力時にnumsrcが0の場合、ヌルポインターが提供される場合があります。
If the application does not know the size of the source list beforehand, it can make a reasonable guess (e.g., 0), and if upon completion, numsrc holds a larger value, the operation can be repeated with a large enough buffer.
アプリケーションが事前にソースリストのサイズを知らない場合、合理的な推測（例：0）を作成できます。完了時に、numSRCがより大きな値を保持する場合、操作は十分な大きさのバッファーで繰り返すことができます。
That is, on return, numsrc is always updated to be the total number of sources in the filter, while slist will hold as many source addresses as fit, up to the minimum of the array size passed in as the original numsrc value and the total number of sources in the filter.
つまり、返品時に、numSRCは常にフィルター内のソースの総数に更新されますが、slistは元のnumsrc値と合計と同じように渡されたアレイサイズの最小値まで、適合しているように多くのソースアドレスを保持します。フィルター内のソースの数。
Although source filtering can help to combat denial-of-service attacks, source filtering alone is not a complete solution, since it does not provide protection against spoofing the source address to be an allowed source. Multicast routing protocols which use reverse-path forwarding based on the source address, however, do provide some natural protection against spoofing the source address, since if a router receives a packet on an interface other than the one toward the "real" source, it will drop the packet. However, this still does not provide any guarantee of protection.
ソースフィルタリングは、サービス拒否攻撃と戦うのに役立ちますが、ソースアドレスを許可されたソースであるようにスプーフィングすることに対する保護を提供しないため、ソースフィルタリングのみは完全な解決策ではありません。ただし、ソースアドレスに基づいてリバースパス転送を使用するマルチキャストルーティングプロトコルは、ルーターが「実際の」ソースに向かってインターフェイス以外のパケットを受け取る場合、ソースアドレスのスプーフィングに対する自然な保護を提供します。パケットをドロップします。ただし、これはまだ保護の保証を提供しません。
This document was updated based on feedback from the IETF's IDMR and MAGMA Working Groups, and the Austin Group. Wilbert de Graaf also provided many helpful comments.
このドキュメントは、IETFのIDMRおよびMagmaワーキンググループ、およびオースティングループからのフィードバックに基づいて更新されました。Wilbert de Graafは、多くの有用なコメントも提供しました。
The API defined here is historic, but is documented here for informational purposes since it is implemented by multiple platforms. The new functions defined earlier in this document should now be used instead.
ここで定義されているAPIは歴史的ですが、複数のプラットフォームによって実装されているため、情報目的のためにここに文書化されています。このドキュメントの前半で定義された新しい機能は、代わりに使用する必要があります。
Retrieving the source filter for a given group cannot be done with getsockopt() on some existing platforms, since the group and interface must be passed down in order to retrieve the correct filter, and getsockopt only supports an output buffer. This can, however, be done with an ioctl(), and hence for symmetry, both gets and sets are done with an ioctl.
特定のグループのソースフィルターの取得いくつかの既存のプラットフォームでGetSockopt（）では実行できません。これは、正しいフィルターを取得するためにグループとインターフェイスを渡す必要があり、GetSockoptは出力バッファーのみをサポートするためです。ただし、これはiOCTL（）で行うことができ、したがって対称性の場合、両方の取得とセットがiOCTLで行われます。
The following are defined in <sys/sockio.h>:
以下は<sys/sockio.h>で定義されています。
o ioctl() SIOCGIPMSFILTER: to retrieve the list of source addresses that comprise the source filter along with the current filter mode.
o IOCTL（）SIOCGIPMSFILTER：ソースフィルターを現在のフィルターモードとともに構成するソースアドレスのリストを取得するには。
o ioctl() SIOCSIPMSFILTER: to set or modify the source filter content (e.g., unicast source address list) or mode (exclude or include).
o IOCTL（）SIOCSIPMSFILTER：ソースフィルターコンテンツ（ユニキャストソースアドレスリストなど）またはモード（除外または含める）を設定または変更する。
Ioctl option Argument type
SIOCGIPMSFILTER struct ip_msfilter
SIOCSIPMSFILTER struct ip_msfilter
struct ip_msfilter {
struct in_addr imsf_multiaddr; /* IP multicast address of group */
struct in_addr imsf_interface; /* local IP address of interface */
uint32_t imsf_fmode; /* filter mode */
uint32_t imsf_numsrc; /* number of sources in src_list */
struct in_addr imsf_slist[1]; /* start of source list */
};
#define IP_MSFILTER_SIZE(numsrc) \
(sizeof(struct ip_msfilter) - sizeof(struct in_addr) \
+ (numsrc) * sizeof(struct in_addr))
The imsf_fmode mode is a 32-bit integer that identifies the filter mode. The value of this field must be either MCAST_INCLUDE or MCAST_EXCLUDE, which are likewise defined in <netinet/in.h>.
IMSF_FMODEモードは、フィルターモードを識別する32ビット整数です。このフィールドの値は、<netinet/in.h>で同様に定義されているmcast_includeまたはmcast_excludeのいずれかでなければなりません。
The structure length pointed to must be at least IP_MSFILTER_SIZE(0) bytes long, and the imsf_numsrc parameter should be set so that IP_MSFILTER_SIZE(imsf_numsrc) indicates the buffer length.
指し示された構造の長さは、少なくともIP_MSFILTER_SIZE（0）の長さでなければならず、IMSF_NUMSRCパラメーターを設定して、IP_MSFILTER_SIZE（IMSF_NUMSRC）がバッファーの長さを示します。
If the implementation imposes a limit on the maximum number of sources in a source filter, ENOBUFS is generated when a set operation would exceed the maximum.
実装がソースフィルター内のソースの最大数に制限を課す場合、設定操作が最大を超えるとENOBUFSが生成されます。
The result of a get operation (SIOCGIPMSFILTER) will be that the imsf_multiaddr and imsf_interface fields will be unchanged, while imsf_fmode, imsf_numsrc, and as many source addresses as fit will be filled into the application's buffer.
GET操作の結果（SIOCGIPMSFILTER）は、IMSF_MULTIADDRおよびIMSF_INTERFACEフィールドが変更されず、IMSF_FMODE、IMSF_NUMSRC、およびFITとしての多くのソースアドレスがアプリケーションのバッファーに入力されることです。
If the application does not know the size of the source list beforehand, it can make a reasonable guess (e.g., 0), and if upon completion, the imsf_numsrc field holds a larger value, the operation can be repeated with a large enough buffer.
アプリケーションが事前にソースリストのサイズを知らない場合、合理的な推測（例：0）を作成することができ、完了時にIMSF_NUMSRCフィールドがより大きな値を保持する場合、操作は十分な大きさのバッファーで繰り返すことができます。
That is, on return from SIOCGIPMSFILTER, imsf_numsrc is always updated to be the total number of sources in the filter, while imsf_slist will hold as many source addresses as fit, up to the minimum of the array size passed in as the original imsf_numsrc value and the total number of sources in the filter.
つまり、SIOCGIPMSFILTERからの返品時に、IMSF_NUMSRCは常にフィルターのソースの総数に更新されますが、IMSF_SLISTは、元のIMSF_NUMSRC値と同様に最小限のアレイサイズまで、適合していると同じくらい多くのソースアドレスを適合させます。フィルター内のソースの総数。
The following are defined in <sys/sockio.h>:
以下は<sys/sockio.h>で定義されています。
o ioctl() SIOCGMSFILTER: to retrieve the list of source addresses that comprise the source filter along with the current filter mode.
o IOCTL（）SIOCGMSFILTER：電源フィルターを現在のフィルターモードとともに構成するソースアドレスのリストを取得するには。
o ioctl() SIOCSMSFILTER: to set or modify the source filter content (e.g., unicast source address list) or mode (exclude or include).
o IOCTL（）SIOCSMSFILTER：ソースフィルターコンテンツ（ユニキャストソースアドレスリストなど）またはモード（除外または含める）を設定または変更する。
Ioctl option Argument type
SIOCGMSFILTER struct group_filter
SIOCSMSFILTER struct group_filter
struct group_filter {
uint32_t gf_interface; /* interface index */
struct sockaddr_storage gf_group; /* multicast address */
uint32_t gf_fmode; /* filter mode */
uint32_t gf_numsrc; /* number of sources */
struct sockaddr_storage gf_slist[1]; /* source address */
};
#define GROUP_FILTER_SIZE(numsrc) \
(sizeof(struct group_filter) - sizeof(struct sockaddr_storage) \
+ (numsrc) * sizeof(struct sockaddr_storage))
The imf_numsrc field is used in the same way as described for imsf_numsrc above.
IMF_NUMSRCフィールドは、上記のIMSF_NUMSRCについて説明されているのと同じ方法で使用されます。
[1] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[1] Gilligan、R.、Thomson、S.、Bound、J.、McCann、J。、およびW. Stevens、「IPv6用の基本ソケットインターフェイス拡張」、RFC 3493、2003年2月。
[2] IEEE Std. 1003.1-2001 Standard for Information Technology -- Portable Operating System Interface (POSIX). Open Group Technical Standard: Base Specifications, Issue 6, December 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin
[2] IEEE STD。1003.1-2001情報技術の標準 - ポータブルオペレーティングシステムインターフェイス（POSIX）。オープングループの技術標準：基本仕様、2001年12月、第6号。ISO/IEC 9945：2002。http://www.opengroup.org/austin
[3] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[3] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。and A. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[4] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", Work in Progress, December 2003.
[4] Vida、R。およびL. Costa、「IPv6用のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、2003年12月の作業。
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Dave Thaler Microsoft Corporation One Microsoft Way Redmond、WA 98052-6399
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Bill Fenner 75 Willow Road Menlo Park, CA 94025
ビルフェナー75ウィローロードメンロパーク、カリフォルニア94025
Phone: +1 650 867 6073
EMail: fenner@research.att.com
Bob Quinn IP Multicast Initiative (IPMI) Stardust.com 1901 S. Bascom Ave. #333 Campbell, CA 95008
Bob Quinn IP Multicast Initiative（IPMI）Stardust.com 1901 S. Bascom Ave.＃333 Campbell、CA 95008
Phone: +1 408 879 8080
EMail: rcq@ipmulticast.com
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。