RFC 3678 - Socket Interface Extensions for Multicast Source Filters 日本語訳

URL : https://tools.ietf.org/html/rfc3678
タイトル : RFC 3678 - マルチキャストソースフィルタのためのソケットインタフェース拡張
翻訳編集 : 自動生成

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.

このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（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

1. Introduction

1. はじめに

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システムの多種多様に実装されています。ソケットAPIを使って書かれたTCP / IPアプリケーションは、過去に移植性の高い学位を享受してきたし、我々は、マルチキャストソースフィルタを採用したアプリケーションと同じポータビリティをしたいと思います。変更は、このようなフィルタリングをサポートするために、ソケット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の参加及び残す機能を定義しながら、しかし、それはこれらの動作のプロトコルに依存しないバージョンを提供しません。このような機能は、この文書で説明します。

The reader should note that this document is for informational purposes only, and that the official standard specification of the sockets API is [2].

読者は、この文書は情報提供のみを目的としており、及び[2]ソケットAPIの正式な標準仕様があることことに注意してください。

2. Design Considerations

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.

APIの変更Oソースフィルタを使用する既存のマルチキャスト受信アプリケーションに変換する作業を簡単にするためにできるだけ小さくすべきです。

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を使用してのいずれかせずに問題があります。新しい機能を使用すると、このような実装を変更する必要がありません。

2.1. What Needs to be Added

2.1. 追加する必要がありますどのような

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ソースフィルタでゼロ以上のユニキャスト（送信元）アドレスを指定します。

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の両方のために、この機能を有効にする必要があります。

2.2. Data Types

2.2. データの種類

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.1グラム[2]からのデータ・タイプが使用される：uintN_tは正確にNビット（例えば、のuint32_t）の符号なし整数を意味します。

2.3. Headers

2.3. ヘッダ

When function prototypes and structures are shown, we show the headers that must be #included to cause that item to be defined.

関数のプロトタイプと構造が示されている場合、我々はその項目が定義させるようにインクルードされなければならないヘッダを示しています。

2.4. Structures

2.4. 構造

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.

構造体のメンバーのために示す順序が推奨順序、マルチバイトメンバーの所定のアライメントの考慮であるが、実装が異なるメンバーを命ずることができます。

3. Overview of APIs

APIの概要3。

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.

マルチキャスト受信側アプリケーションは、受信するマルチキャストグループ（宛先アドレス）とともに、送信者（S）のユニキャストアドレスを指定できるように設計されているどちらのソースフィルタのAPIの2つのカテゴリが存在します。

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ベーシック（デルタベース）：一部のアプリケーションでは、各関数呼び出しが待ち受ける与えられたマルチキャストグループアドレスのために既存のフィルタに追加または削除する必要があり、単一の送信元アドレスを指定したデルタベースの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アドバンスト（フル状態）：この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.

ソースフィルタのサポートを追加するために、既存のIPv4マルチキャストアプリケーションのソースコードに必要な変更を最小限にするために、O。

o To avoid overloading APIs to accommodate the differences between IPv4 interface addresses (e.g., in the ip_mreq structure) and interface indices.

IPv4インタフェースアドレス（例えば、ip_mreq構造における）とインターフェースインデックスとの間の違いに対応するためのAPIの過負荷を防ぐために、O。

4. IPv4 Multicast Source Filter APIs

4. IPv4マルチキャストソースフィルタのAPI

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の）プロトコルのバージョン2 [4]ルータにソースフィルタ情報を通信する能力を提供し、したがって、上の不要なソースからのデータをプルダウン避けますローカルリンク。しかし、ソースフィルタは関係なく、ルータにIGMPv3またはMLDv2のをサポートするかどうかのオペレーティング・システムによって実施することができるので、ソース・フィルタAPIが利用可能な場合、アプリケーションは、常にそれを使用することから利益を得ることができます。

4.1. Basic (Delta-based) API for IPv4

4.1. IPv4の基本（デルタベース）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>

書式#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 */
   };

4.1.1. IPv4 Any-Source Multicast API

4.1.1. IPv4のエニーソースマルチキャストAPI

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構造体ip_mreq IP_BLOCK_SOURCE構造体ip_mreq_source IP_UNBLOCK_SOURCE構造体ip_mreq_source IP_DROP_MEMBERSHIP構造体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はこれを元に戻すために使用することができる（例えば、ユーザー場合、「ミュート解除」ソース）。

4.1.2. IPv4 Source-Specific Multicast API

4.1.2. IPv4のソース固有のマルチキャストAPI

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構造体ip_mreq_source IP_DROP_SOURCE_MEMBERSHIP構造体ip_mreq_source IP_DROP_MEMBERSHIP構造体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は、特定のグループとのインタフェースのために接合されたすべてのソースを削除するために、便宜的に、支持されています。操作は、ソケットがクローズされていた場合と同じです。

4.1.3. Error Codes

4.1.3. エラーコード

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を行うことなく、任意の-sourceオプションをしようとしたときに）生成されたエラーは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が生成されます。

4.2. Advanced (Full-state) API for IPv4

4.2. IPv4のための高度な（フル状態）API

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は、好ましいAPIは、後述する新しい機能を使用する付録Aに記載されています。

4.2.1. Set Source Filter

4.2.1. セットソースフィルタ

#include <netinet/in.h>

書式#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、構造体in_addr形式のインタフェース、構造体in_addr形式基のuint32_t FMODE、のuint32_t numsrc、構造体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.

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.

フィルタモードに応じて含めるか除外するかをソースのIPアドレスのアレイにSLIST引数ポイント。

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が生成されます。

4.2.2. Get Source Filter

4.2.2. ソースフィルタを取得します。

#include <netinet/in.h>

書式#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);

INT getipv4sourcefilter（INT S、構造体in_addr形式のインタフェース、構造体in_addr形式基のuint32_t * FMODE、のuint32_t * numsrc、構造体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.

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引数はSLIST配列に収まるソースアドレスの数を保持しています。出力に、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.

（フィルタモードに応じて）または除外のIPアドレスのアレイはソースが書き込まれるバッファへのSLIST引数ポイント。 numsrc入力に0であった場合は、NULLポインタが供給されてもよいです。

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.

完了時に、numsrcは大きな値を保持している場合、アプリケーションは、予めソースリストのサイズを知らない場合、それは合理的な推測を行うことができる（例えば、0）、及び、操作が十分な大きさのバッファを用いて繰り返すことができます。

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.

SLISTが元numsrc値として渡された配列のサイズとの合計の最小値まで、フィット限り多くのソースアドレスを保持しながら、すなわち、リターンに、numsrcは常に、フィルタにおける光源の総数に更新されますフィルタ内のソースの数。

5. Protocol-Independent Multicast Source Filter APIs

5.プロトコル独立マルチキャストソースフィルタのAPI

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（ASコールから得られたSOCKADDR_STORAGE構造）[1]基が参加するように通過できるように参加して操作を残すためのプロトコル非依存の機能が提供されます。例えば、アプリケーションは、IPv4またはIPv6のいずれであってもよく、かつ容易にグループに参加し、残すことができるマルチキャストアドレスにDNS名（例えば、NTP.MCAST.NET）を解決することができます。

5.1. Basic (Delta-based) API

5.1. ベーシック（デルタベース）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().

The following structures are used by both the Any-Source Multicast and the Source-Specific Multicast API: #include <netinet/in.h>

以下の構造はいずれも、ソースのマルチキャストおよびソース固有のマルチキャスト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構造[1]のIPv4またはIPv6アドレス情報を保持するのに十分な大きさであることがRFC 3493で定義されています。

The rules for generating errors are the same as those given in Section 5.1.3.

エラーを生成するための規則は、セクション5.1.3で与えられたものと同じです。

5.1.1. Any-Source Multicast API

5.1.1. どれ-ソースマルチキャストAPI

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構造体group_req MCAST_BLOCK_SOURCE構造体group_source_req MCAST_UNBLOCK_SOURCE構造体group_source_req MCAST_LEAVE_GROUP構造体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これを元に戻すために使用することができる（例えば、もしユーザ次いで「ミュート解除」ソース）。

5.1.2. Source-Specific Multicast API

5.1.2. ソース固有のマルチキャストAPI

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構造体group_source_req MCAST_LEAVE_SOURCE_GROUP構造体group_source_req MCAST_LEAVE_GROUP構造体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は、特定のグループとのインタフェースのために接合されたすべてのソースを削除するために、便宜的に、支持されています。操作は、ソケットがクローズされていた場合と同じです。

5.2. Advanced (Full-state) API

5.2. アドバンスト（フル状態）API

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は、好ましいAPIは、後述する新しい機能を使用する付録Aに記載されています。

5.2.1. Set Source Filter

5.2.1. セットソースフィルタ

#include <netinet/in.h>

書式#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インタフェースいるsockaddr *基、のsocklen_t grouplen、のuint32_t FMODE、uint_t numsrc、構造体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.

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マルチキャストアドレスを保持する（IPv4の場合）sockaddr_in構造体または（IPv6の場合）sockaddr_in6構造体のいずれかのグループの引数ポイント。

The grouplen argument gives the length of the sockaddr_in or sockaddr_in6 structure.

grouplen引数は、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>.

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.

フィルタモードに応じて含めるか除外するかをソースのIPアドレスのアレイにSLIST引数ポイント。

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が生成されます。

5.2.2. Get Source Filter

5.2.2. ソースフィルタを取得します。

#include <netinet/in.h>

書式#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インタフェースいるsockaddr *基、のsocklen_t grouplen、のuint32_t FMODE、uint_t * numsrc、構造体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.

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.

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引数はSLIST配列に収まるソースアドレスの数を保持しています。出力に、numsrc引数はフィルタに光源の総数を保持します。

6. Security Considerations

6.セキュリティの考慮事項

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.

ソースフィルタリングは、サービス拒否攻撃に対抗するために助けることができますが、それは許さ源であると送信元アドレスを偽装に対する保護を提供していないため、単独のソースフィルタリングは、完全なソリューションではありません。ルータは「本物」のソースに向けて1以外のインターフェイス上のパケットを受信した場合ので、送信元アドレスに基づいて、リバースパス転送を使用するマルチキャストルーティングプロトコルは、しかし、送信元アドレスを偽装に対して、いくつかの自然保護を提供しない、それをパケットをドロップします。しかし、これはまだ保護のいずれかの保証を提供していません。

7. Acknowledgments

7.謝辞

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ワーキンググループ、およびオースティングループからのフィードバックに基づいて更新されました。ウィルバート・デ・グラーフは、多くの有益なコメントを提供しました。

8. : Use of ioctl() for full-state operations

8：フル状態動作のためのioctl（）の使用

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を用いて行われます。

8.1. IPv4 Options

8.1. IPv4のオプション

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

ioctlのオプションの引数のタイプSIOCGIPMSFILTER構造体ip_msfilter SIOCSIPMSFILTER構造体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))

#define IP_MSFILTER_SIZE（numsrc）\（はsizeof（構造体ip_msfilter） - はsizeof（構造体in_addr形式）\ +（numsrc）*はsizeof（構造体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）バイト長、及びIP_MSFILTER_SIZE（imsf_numsrc）はバッファ長を示すよう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_fmode、imsf_numsrcなどの多くのソース・アドレスは、アプリケーションのバッファ内に充填されながらimsf_multiaddrとimsf_interfaceフィールドは、変更されませんということになります。

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.

完了時に、imsf_numsrcフィールドは、大きな値を保持している場合、アプリケーションは、予めソースリストのサイズを知らない場合、それは合理的な推測を行うことができる（例えば、0）、及び、操作が十分な大きさのバッファを用いて繰り返すことができます。

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.

imsf_slistが元imsf_numsrc値として渡された配列のサイズの最小値まで、フィット限り多くのソースアドレスを保持しながら、すなわち、SIOCGIPMSFILTERからの復帰に、imsf_numsrcは常に、フィルタにおける光源の総数に更新され、フィルタ内のソースの総数。

8.2. Protocol-Independent Options

8.2. プロトコル独立オプション

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

ioctlのオプションの引数のタイプSIOCGMSFILTER構造体group_filter SIOCSMSFILTER構造体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))

#define GROUP_FILTER_SIZE（numsrc）\（はsizeof（構造体group_filter） - はsizeof（構造体SOCKADDR_STORAGE）\ +（numsrc）*はsizeof（構造体SOCKADDR_STORAGE））

The imf_numsrc field is used in the same way as described for imsf_numsrc above.

imf_numsrcフィールドは、上記imsf_numsrcについて記載したのと同じように使用されます。

9. Normative References

9.引用規格

[1] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.

[1]ギリガン、R.、トムソン、S.、バウンド、J.、マッキャン、J.とW.スティーブンス、 "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）。 Open Groupの技術標準：基本仕様、6号、2001年12月ISO / IEC 9945：2002。 http://www.opengroup.org/austin

10. Informative References

10.参考文献

[3] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.

[3]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.と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]ヴィーダ、R.とL.コスタ、 "マルチキャストリスナ発見バージョン2（MLDv2の）IPv6のため"、進歩、2003年12月に作業。

11. Authors' Addresses

11.著者のアドレス

Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399

デーブターラーマイクロソフト社1つのマイクロソフト道、レドモンド、WA 98052-6399

Phone: +1 425 703 8835 EMail: dthaler@microsoft.com

電話：+1 425 703 8835 Eメール：dthaler@microsoft.com

Bill Fenner 75 Willow Road Menlo Park, CA 94025

ビルフェナー75ウィローロードメンロパーク、CA 94025

Phone: +1 650 867 6073 EMail: fenner@research.att.com

電話：+1 650 867 6073 Eメール：fenner@research.att.com

Bob Quinn IP Multicast Initiative (IPMI) Stardust.com 1901 S. Bascom Ave. #333 Campbell, CA 95008

ボブ・クインIPマルチキャストイニシアティブ（IPMI）Stardust.com 1901 S. BASCOMアベニュー。＃333キャンベル、CA 95008

Phone: +1 408 879 8080 EMail: rcq@ipmulticast.com

電話：+1 408 879 8080 Eメール：rcq@ipmulticast.com

12. Full Copyright Statement

12.完全な著作権声明

著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。