Network Working Group D. Thaler
Request for Comments: 3678 Microsoft
Category: Informational B. Fenner
AT&T Research
B. Quinn
Stardust.com
January 2004
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）互联网协会（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的Internet组管理协议（IGMPv3）和IPv6的多播侦听器发现（MLDv2）为应用程序添加了在多播组成员身份上表示源筛选器的功能，这允许接收方应用程序确定从中接受多播通信的发送方（源）集。此功能还简化了对一对多类型多播应用程序的支持。
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
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
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是在20世纪80年代早期为Unix开发的，但它也已在各种非Unix系统上实现。使用socketsapi编写的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].
读者应注意，本文档仅供参考，sockets 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
o 如有必要，可以将新函数编写为ioctl、getsockopt或setsockopt调用上的包装器。因此，它提供了在操作系统中如何实现功能的更多自由。例如，一个新函数可以在
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.
include文件，或从用户模式库导出的函数，该库在内部使用某种机制与内核交换信息，或直接在内核中实现。
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 这里定义的至少一个操作需要能够向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 在源筛选器中指定零个或多个单播（源）地址。
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.
当显示函数原型和结构时，我们将显示必须包含的标题，以便定义该项。
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，这两种API都设计为允许多播接收器应用程序指定发送方的单播地址以及要接收的多播组（目标地址）。
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的简单性，其中每个函数调用指定一个源地址，该地址应添加到要侦听的给定多播组地址的现有筛选器中或从中删除。此类应用通常分为两类：
+ 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.
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.
Internet组管理协议（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>
#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 {
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 */
};
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\u添加\u成员结构IP\u mreq IP\u块\u源结构IP\u mreq\u源IP\u取消阻止\u源结构IP\u mreq\u源IP\u删除\u成员结构IP\u 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_添加_成员身份和IP_删除_成员身份已经在大多数操作系统上实现，并用于加入和离开任意源组。
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\u添加\u源\u成员结构IP\u mreq\u源IP\u删除\u源\u成员结构IP\u mreq\u源IP\u删除\u成员结构IP\u mreq
IP_ADD_SOURCE_MEMBERSHIP and IP_DROP_SOURCE_MEMBERSHIP are used to join and leave a source-specific group.
IP_添加_源_成员身份和IP_删除_源_成员身份用于加入和离开特定于源的组。
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_成员身份，以删除已加入特定组和接口的所有源。操作与套接字已关闭时的操作相同。
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_添加_成员资格后在组上尝试源特定选项时，或在不执行IP_添加_成员资格的情况下尝试任何源选项时），生成的错误为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.
存在几种将ioctl（）用于此API的实现，出于历史目的，ioctl（）API记录在附录A中。首选API使用下面描述的新函数。
#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、地址接口中的结构、地址组中的结构、uint32格式、uint32 numsrc、地址*列表中的结构）；
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.
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参数标识过滤器模式。此字段的值必须是MCAST_INCLUDE或MCAST_EXCLUDE，这在<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.
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>
#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, 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.
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参数指向一个整数，该整数将在成功返回时包含筛选模式。此字段的值将是MCAST_INCLUDE或MCAST_EXCLUDE，它们在<netinet/in.h>中也有类似的定义。
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.
slist参数指向缓冲区，其中将写入包含或排除（取决于过滤模式）源的IP地址数组。如果输入时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_存储结构作为要加入的组传递。例如，应用程序可以将DNS名称（例如，NTP.MCAST.NET）解析为多播地址，该地址可以是IPv4或IPv6，并且可以轻松加入和离开组。
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>
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_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 */
};
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.
RFC 3493[1]中定义的sockaddr_存储结构足够大，可以容纳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\u JOIN\u GROUP struct GROUP\u req MCAST\u BLOCK\u SOURCE\u req MCAST\u UNBLOCK\u SOURCE struct GROUP\u SOURCE\u req MCAST\u LEAVE\u GROUP struct GROUP\u req
MCAST_JOIN_GROUP and MCAST_LEAVE_GROUP are used to join and leave an any-source group.
MCAST_加入_组和MCAST_离开_组用于加入和离开任意源组。
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\u JOIN\u SOURCE\u GROUP struct GROUP\u SOURCE\u req MCAST\u LEAVE\u SOURCE\u GROUP struct GROUP\u SOURCE\u req MCAST\u LEAVE\u GROUP struct GROUP\u req
MCAST_JOIN_SOURCE_GROUP and MCAST_LEAVE_SOURCE_GROUP are used to join and leave a source-specific group.
MCAST_加入_源_组和MCAST_离开_源_组用于加入和离开特定于源的组。
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_组删除为特定组和接口加入的所有源。操作与套接字已关闭时的操作相同。
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.
可能存在将ioctl（）用于此API的实现，出于历史目的，ioctl（）API记录在附录A中。首选API使用下面描述的新函数。
#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_存储*列表）；
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.
group参数指向保存组的IP多播地址的sockaddr_in结构（对于IPv4）或sockaddr_in 6结构（对于IPv6）。
The grouplen argument gives the length of the sockaddr_in or sockaddr_in6 structure.
grouplen参数给出了sockaddr_in或sockaddr_in 6结构的长度。
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参数标识过滤器模式。此字段的值必须是MCAST_INCLUDE或MCAST_EXCLUDE，这在<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.
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>
#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组，uint32_t fmode，uint_t*numsrc，结构sockaddr\u存储*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.
group参数指向保存组的IP多播地址的sockaddr_in结构（对于IPv4）或sockaddr_in 6结构（对于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参数指向一个整数，该整数将在成功返回时包含筛选模式。此字段的值将是MCAST_INCLUDE或MCAST_EXCLUDE，它们在<netinet/in.h>中也有类似的定义。
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.
slist参数指向缓冲区，其中将写入包含或排除（取决于过滤模式）源的IP地址数组。如果输入时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工作组以及奥斯汀小组的反馈进行了更新。威尔伯特·德格拉夫也提出了许多有益的意见。
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（）完成，因此对于对称性，get和set都是通过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（）SIOCGIMPSFILTER：检索包含源筛选器的源地址列表以及当前筛选器模式。
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选项参数类型SIOCGIMPSFILTER结构ip\U msfilter SIOCSIPMSFILTER结构ip\U 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 */
};
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(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位整数，用于标识过滤器模式。此字段的值必须是MCAST_INCLUDE或MCAST_EXCLUDE，这在<netinet/in.h>中也有类似的定义。
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.
如果实现对源过滤器中的最大源数量施加限制，则当set操作超过最大值时，将生成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操作（SIOCGIMPSFILTER）的结果是imsf_multiaddr和imsf_接口字段将保持不变，而imsf_fmode、imsf_numsrc和尽可能多的源地址将填充到应用程序的缓冲区中。
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.
也就是说，从SIOCGIMPSFILTER返回时，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
Ioctl选项参数类型SIOCGMSFILTER结构组\过滤器SIOCSMSFILTER结构组\过滤器
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 */
};
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(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 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
[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.和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微软公司华盛顿州雷德蒙微软大道一号98052-6399
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
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
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多播计划（IPMI）Stardust.com 1901 S.Bascom Ave.#333 Campbell，CA 95008
Phone: +1 408 879 8080
EMail: rcq@ipmulticast.com
Phone: +1 408 879 8080
EMail: rcq@ipmulticast.com
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（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编辑功能的资金目前由互联网协会提供。