Network Working Group H. Holbrook
Request for Comments: 4607 Arastra, Inc.
Category: Standards Track B. Cain
Acopia Networks
August 2006
Network Working Group H. Holbrook
Request for Comments: 4607 Arastra, Inc.
Category: Standards Track B. Cain
Acopia Networks
August 2006
Source-Specific Multicast for IP
特定于源的IP多播
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension.
232/8（232.0.0.0至232.255.255.255）范围内的IP版本4（IPv4）地址指定为源特定多播（SSM）目标地址，并保留供源特定应用程序和协议使用。对于IP版本6（IPv6），地址前缀FF3x:：/32保留供源特定的多播使用。本文档定义了适用于发送到SSM地址的数据报的Internet网络服务扩展，并定义了支持此扩展的主机和路由器要求。
Table of Contents
目录
1. Introduction ....................................................3
2. Semantics of Source-Specific Multicast Addresses ................5
3. Terminology .....................................................6
4. Host Requirements ...............................................7
4.1. Extensions to the IP Module Interface ......................7
4.2. Requirements on the Host IP Module .........................8
4.3. Allocation of Source-Specific Multicast Addresses ..........9
5. Router Requirements ............................................10
5.1. Packet Forwarding .........................................10
5.2. Protocols .................................................10
6. Link-Layer Transmission of Datagrams ...........................11
7. Security Considerations ........................................12
7.1. IPsec and SSM .............................................12
7.2. SSM and RFC 2401 IPsec Caveats ............................12
7.3. Denial of Service .........................................13
7.4. Spoofed Source Addresses ..................................13
7.5. Administrative Scoping ....................................14
8. Transition Considerations ......................................14
9. IANA Considerations ............................................15
10. Acknowledgements ..............................................15
11. Normative References ..........................................16
12. Informative References ........................................17
1. Introduction ....................................................3
2. Semantics of Source-Specific Multicast Addresses ................5
3. Terminology .....................................................6
4. Host Requirements ...............................................7
4.1. Extensions to the IP Module Interface ......................7
4.2. Requirements on the Host IP Module .........................8
4.3. Allocation of Source-Specific Multicast Addresses ..........9
5. Router Requirements ............................................10
5.1. Packet Forwarding .........................................10
5.2. Protocols .................................................10
6. Link-Layer Transmission of Datagrams ...........................11
7. Security Considerations ........................................12
7.1. IPsec and SSM .............................................12
7.2. SSM and RFC 2401 IPsec Caveats ............................12
7.3. Denial of Service .........................................13
7.4. Spoofed Source Addresses ..................................13
7.5. Administrative Scoping ....................................14
8. Transition Considerations ......................................14
9. IANA Considerations ............................................15
10. Acknowledgements ..............................................15
11. Normative References ..........................................16
12. Informative References ........................................17
The Internet Protocol (IP) multicast service model is defined in RFC 1112 [RFC1112]. RFC 1112 specifies that a datagram sent to an IP multicast address (224.0.0.0 through 239.255.255.255) G is delivered to each "upper-layer protocol module" that has requested reception of datagrams sent to address G. RFC 1112 calls the network service identified by a multicast destination address G a "host group". This model supports both one-to-many and many-to-many group communication. This document uses the term "Any-Source Multicast" (ASM) to refer to model of multicast defined in RFC 1112. RFC 3513 [RFC3513] specifies the form of IPv6 multicast addresses with ASM semantics.
互联网协议（IP）多播服务模型在RFC 1112[RFC1112]中定义。RFC 1112指定发送到IP多播地址（224.0.0.0到239.255.255.255）G的数据报被发送到每个请求接收发送到地址G的数据报的“上层协议模块”。RFC 1112将由多播目的地地址G标识的网络服务称为“主机组”。该模型支持一对多和多对多组通信。本文档使用术语“任意源多播”（ASM）来指RFC 1112中定义的多播模型。RFC 3513[RFC3513]使用ASM语义指定IPv6多播地址的形式。
IPv4 addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are currently designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols [IANA-ALLOC].
232/8（232.0.0.0至232.255.255.255）范围内的IPv4地址当前指定为源特定多播（SSM）目标地址，并保留供源特定应用程序和协议使用[IANA-ALLOC]。
For IPv6, the address prefix FF3x::/32 is reserved for source-specific multicast use, where 'x' is any valid scope identifier, by [IPv6-UBM]. Using the terminology of [IPv6-UBM], all SSM addresses must have P=1, T=1, and plen=0. [IPv6-MALLOC] mandates that the network prefix field of an SSM address also be set to zero, hence all SSM addresses fall in the FF3x::/96 range. Future documents may allow a non-zero network prefix field if, for instance, a new IP-address-to-MAC-address mapping is defined. Thus, address allocation should occur within the FF3x::/96 range, but a system should treat all of FF3x::/32 as SSM addresses, to allow for compatibility with possible future uses of the network prefix field.
对于IPv6，地址前缀FF3x:：/32由[IPv6 UBM]保留用于源特定的多播使用，其中“x”是任何有效的作用域标识符。使用[IPv6 UBM]的术语，所有SSM地址必须具有P=1、T=1和plen=0。[IPv6 MALLOC]要求SSM地址的网络前缀字段也设置为零，因此所有SSM地址都在FF3x:：/96范围内。例如，如果定义了新的IP地址到MAC地址的映射，则将来的文档可能允许非零网络前缀字段。因此，地址分配应在FF3x:：/96范围内进行，但系统应将所有FF3x:：/32视为SSM地址，以便与网络前缀字段的未来可能用途兼容。
Addresses in the range FF3x::4000:0001 through FF3x::7FFF:FFFF are reserved in [IPv6-MALLOC] for allocation by IANA. Addresses in the range FF3x::8000:0000 through FF3x::FFFF:FFFF are allowed for dynamic allocation by a host, as described in [IPv6-MALLOC]. Addresses in the range FF3x::0000:0000 through FF3x::3FFF:FFFF are invalid IPv6 SSM addresses. ([IPv6-MALLOC] indicates that FF3x::0000:0001 to FF3x::3FFF:FFFF must set P=0 and T=0, but for SSM, [IPv6-UBM] mandates that P=1 and T=1, hence their designation as invalid.) The treatment of a packet sent to such an invalid address is undefined -- a router or host MAY choose to drop such a packet.
[IPv6 MALLOC]中保留了FF3x:：4000:0001到FF3x:：7FFF:FFFF范围内的地址，供IANA分配。如[IPv6 MALLOC]中所述，允许主机动态分配范围为FF3x:：8000:0000到FF3x:：FFFF:FFFF的地址。FF3x:：0000:0000到FF3x:：3FFF:FFFF范围内的地址是无效的IPv6 SSM地址。（[IPv6 MALLOC]表示FF3x:：0000:0001到FF3x:：3FFF:FFFF必须设置P=0和T=0，但对于SSM，[IPv6 UBM]要求P=1和T=1，因此将其指定为无效。）发送到此类无效地址的数据包的处理未定义——路由器或主机可以选择丢弃此类数据包。
Source-specific multicast delivery semantics are provided for a datagram sent to an SSM address. That is, a datagram with source IP address S and SSM destination address G is delivered to each upper-layer "socket" that has specifically requested the reception of datagrams sent to address G by source S, and only to those sockets. The network service identified by (S,G), for SSM address G and source
为发送到SSM地址的数据报提供源特定的多播交付语义。也就是说，具有源IP地址S和SSM目的地地址G的数据报被传送到每个上层“套接字”，该上层“套接字”专门请求接收由源S发送到地址G的数据报，并且仅传送到那些套接字。由（S，G）标识的网络服务，用于SSM地址G和源
host address S, is referred to as a "channel". In contrast to the ASM model of RFC 1112, SSM provides network-layer support for one-to-many delivery only.
主机地址S称为“通道”。与RFC 1112的ASM模型不同，SSM仅为一对多交付提供网络层支持。
The benefits of source-specific multicast include:
源特定多播的好处包括：
Elimination of cross-delivery of traffic when two sources simultaneously use the same source-specific destination address. The simultaneous use of an SSM destination address by multiple sources and different applications is explicitly supported.
当两个信源同时使用同一信源特定的目的地址时，消除交叉传输的通信量。明确支持多个源和不同应用程序同时使用SSM目标地址。
Avoidance of the need for inter-host coordination when choosing source-specific addresses, as a consequence of the above.
由于上述原因，在选择源特定地址时避免了主机间协调的需要。
Avoidance of many of the router protocols and algorithms that are needed to provide the ASM service model. For instance, the "shared trees" and Rendezvous Points of the PIM - Sparse Mode (PIM-SM) protocol [PIM-SM] are not necessary to support the source-specific model. The router mechanisms required to support SSM are in fact largely a subset of those that are used to support ASM. For example, the shortest-path tree mechanism of the PIM-SM protocol can be adapted to provide SSM semantics.
避免提供ASM服务模型所需的许多路由器协议和算法。例如，PIM-稀疏模式（PIM-SM）协议[PIM-SM]的“共享树”和集合点对于支持特定于源的模型是不必要的。支持SSM所需的路由器机制实际上在很大程度上是用于支持ASM的路由器机制的子集。例如，PIM-SM协议的最短路径树机制可适用于提供SSM语义。
Like ASM, the set of receivers is unknown to an SSM sender. An SSM source is provided with neither the identity of receivers nor their number.
与ASM一样，SSM发送方不知道接收器集。SSM源既没有接收机的标识，也没有接收机的编号。
SSM is particularly well-suited to dissemination-style applications with one or more senders whose identities are known before the application begins. For instance, a data dissemination application that desires to provide a secondary data source in case the primary source fails over might implement this by using one channel for each source and advertising both of them to receivers. SSM can be used to build multi-source applications where all participants' identities are not known in advance, but the multi-source "rendezvous" functionality does not occur in the network layer in this case. Just like in an application that uses unicast as the underlying transport, this functionality can be implemented by the application or by an application-layer library.
SSM特别适合于具有一个或多个发送者的传播式应用程序，这些发送者的身份在应用程序开始之前就已经知道了。例如，希望在主数据源故障转移的情况下提供辅助数据源的数据分发应用程序可以通过为每个源使用一个信道并向接收机公布这两个信道来实现这一点。SSM可用于构建多源应用程序，其中所有参与者的身份事先未知，但在这种情况下，多源“会合”功能不会出现在网络层。就像在使用单播作为底层传输的应用程序中一样，此功能可以由应用程序或应用程序层库实现。
Multicast resource discovery of the form in which a client sends a multicast query directly to a "service location group" to which servers listen is not directly supported by SSM.
SSM不直接支持客户端直接向服务器侦听的“服务位置组”发送多播查询的形式的多播资源发现。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document defines the semantics of source-specific multicast addresses and specifies the policies governing their use. In particular, it defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines host extensions to support the network service. Hosts, routers, applications, and protocols that use these addresses MUST comply with the policies outlined in this document. Failure of a host to comply may prevent that host or other hosts on the same LAN from receiving traffic sent to an SSM channel. Failure of a router to comply may cause SSM traffic to be delivered to parts of the network where it is unwanted, unnecessarily burdening the network.
本文档定义了源特定多播地址的语义，并指定了管理其使用的策略。特别是，它定义了适用于发送到SSM地址的数据报的Internet网络服务扩展，并定义了支持网络服务的主机扩展。使用这些地址的主机、路由器、应用程序和协议必须符合本文档中概述的策略。主机不符合要求可能会阻止该主机或同一LAN上的其他主机接收发送到SSM通道的流量。路由器不符合要求可能会导致SSM流量传输到网络中不需要的部分，从而给网络带来不必要的负担。
The source-specific multicast service is defined as follows:
源特定的多播服务定义如下：
A datagram sent with source IP address S and destination IP address G in the SSM range is delivered to each host socket that has specifically requested delivery of datagrams sent by S to G, and only to those sockets.
使用SSM范围内的源IP地址S和目标IP地址G发送的数据报被发送到每个主机套接字，该主机套接字专门请求发送由S发送到G的数据报，并且仅发送到这些套接字。
Where, using the terminology of [IGMPv3],
其中，使用[IGMPv3]的术语，
"socket" is an implementation-specific parameter used to distinguish among different requesting entities (e.g., programs or processes or communication end-points within a program or process) within the requesting host; the socket parameter of BSD Unix system calls is a specific example.
“套接字”是一个特定于实现的参数，用于区分请求主机内的不同请求实体（例如，程序或进程或程序或进程内的通信端点）；BSD Unix系统调用的套接字参数就是一个具体的例子。
Any host may send a datagram to any SSM address, and delivery is provided according to the above semantics.
任何主机都可以向任何SSM地址发送数据报，并根据上述语义提供传递。
The IP module interface to upper-layer protocols is extended to allow a socket to "Subscribe" to or "Unsubscribe" from a particular channel identified by an SSM destination address and a source IP address. The extended interface is defined in Section 4.1. It is meaningless for an application or host to request reception of datagrams sent to an SSM destination address G, as is supported in the any-source multicast model, without also specifying a corresponding source address, and routers MUST ignore any such request.
对上层协议的IP模块接口进行了扩展，以允许套接字“订阅”或“取消订阅”由SSM目标地址和源IP地址标识的特定信道。第4.1节定义了扩展接口。应用程序或主机请求接收发送到SSM目标地址G的数据报（如任何源多播模型所支持的）而不指定相应的源地址是毫无意义的，路由器必须忽略任何此类请求。
Multiple source applications on different hosts can use the same SSM destination address G without conflict because datagrams sent by each source host Si are delivered only to those sockets that requested delivery of datagrams sent to G specifically by Si.
不同主机上的多个源应用程序可以使用相同的SSM目标地址G而不会发生冲突，因为每个源主机Si发送的数据报仅传递给那些请求传递Si专门发送给G的数据报的套接字。
The key distinguishing property of the model is that a channel is identified (addressed) by the combination of a unicast source address and a multicast destination address in the SSM range. So, for example, the channel
该模型的关键区别特性是通过SSM范围内的单播源地址和多播目的地地址的组合来识别（寻址）信道。比如说，频道
S,G = (192.0.2.1, 232.7.8.9)
S,G = (192.0.2.1, 232.7.8.9)
differs from
不同于
S,G = (192.0.2.2, 232.7.8.9),
S,G = (192.0.2.2, 232.7.8.9),
even though they have the same destination address portion. Similarly, for IPv6,
即使它们具有相同的目标地址部分。类似地，对于IPv6，
S,G = (2001:3618::1, FF33::1234)
S,G = (2001:3618::1, FF33::1234)
and
和
S,G = (2001:3618::2, FF33::1234)
S,G = (2001:3618::2, FF33::1234)
are different channels.
有不同的频道。
To reduce confusion when talking about the any-source and source-specific multicast models, we use different terminology when discussing them.
为了减少在讨论任何源和特定于源的多播模型时的混淆，我们在讨论它们时使用了不同的术语。
We use the term "channel" to refer to the service associated with an SSM address. A channel is identified by the combination of an SSM destination address and a specific source, e.g., an (S,G) pair.
我们使用术语“信道”来指代与SSM地址相关联的服务。信道由SSM目的地址和特定源（例如（S，g）对）的组合来识别。
We use the term "host group" (used in RFC 1112) to refer to the service associated with "regular" ASM multicast addresses (excluding those in the SSM range). A host group is identified by a single multicast address.
我们使用术语“主机组”（RFC 1112中使用）来指代与“常规”ASM多播地址相关联的服务（不包括SSM范围内的地址）。主机组由单个多播地址标识。
Any host can send to a host group, and similarly, any host can send to an SSM destination address. A packet sent by a host S to an ASM destination address G is delivered to the host group identified by G. A packet sent by host S to an SSM destination address G is delivered to the channel identified by (S,G). The receiver operations allowed on a host group are called "join(G)" and "leave(G)" (as per RFC 1112). The receiver operations allowed on a channel are called "Subscribe(S,G)" and "Unsubscribe(S,G)".
任何主机都可以发送到主机组，同样，任何主机都可以发送到SSM目标地址。由主机S发送到ASM目的地地址G的数据包被传送到由G标识的主机组。由主机S发送到SSM目的地地址G的数据包被传送到由（S，G）标识的信道。主机组上允许的接收器操作称为“加入（G）”和“离开（G）”（根据RFC 1112）。频道上允许的接收器操作称为“订阅（S，G）”和“取消订阅（S，G）”。
The following table summarizes the terminology:
下表总结了术语：
Service Model: any-source source-specific Network Abstraction: group channel Identifier: G S,G Receiver Operations: Join, Leave Subscribe, Unsubscribe
服务模型：任何特定于源的网络抽象：组通道标识符：G S，G接收器操作：加入、离开订阅、取消订阅
We note that, although this document specifies a new service model available to applications, the protocols and techniques necessary to support the service model are largely a subset of those used to support ASM.
我们注意到，尽管本文档指定了应用程序可用的新服务模型，但支持服务模型所需的协议和技术在很大程度上是用于支持ASM的协议和技术的子集。
This section describes requirements on hosts that support source-specific multicast, including:
本节描述了对支持源特定多播的主机的要求，包括：
- Extensions to the IP Module Interface
- IP模块接口的扩展
- Extensions to the IP Module
- IP模块的扩展
- Allocation of SSM Addresses
- SSM地址的分配
The IP module interface to upper-layer protocols is extended to allow protocols to request reception of all datagrams sent to a particular channel.
上层协议的IP模块接口被扩展，以允许协议请求接收发送到特定信道的所有数据报。
Subscribe ( socket, source-address, group-address, interface )
订阅（套接字、源地址、组地址、接口）
Unsubscribe ( socket, source-address, group-address, interface )
取消订阅（套接字、源地址、组地址、接口）
where
哪里
"socket" is as previously defined in Section 2,
“插座”如第2节所述，
and, paraphrasing [IGMPv3],
以及，解释[IGMPv3]，
"interface" is a local identifier of the network interface on which reception of the channel identified by the (source-address,group-address) pair is to be enabled or disabled. A special value may be used to indicate a "default" interface. If reception of the same channel is desired on multiple interfaces, Subscribe is invoked once for each.
“接口”是网络接口的本地标识符，在该网络接口上启用或禁用（源地址、组地址）对标识的信道接收。特殊值可用于指示“默认”接口。如果需要在多个接口上接收同一个通道，则为每个接口调用一次Subscribe。
The above are strictly abstract functional interfaces -- the functionality can be provided in an implementation-specific way. On a host that supports the multicast source filtering application programming interface of [MSFAPI], for instance, the Subscribe and Unsubscribe interfaces may be supported via that API. When a host has been configured to know the SSM address range (whether the configuration mechanism is manual or through a protocol), the host's operating system SHOULD return an error to an application that makes a non-source-specific request to receive multicast sent to an SSM destination address.
以上是严格抽象的功能接口——功能可以通过特定于实现的方式提供。例如，在支持[MSFAPI]的多播源过滤应用程序编程接口的主机上，可以通过该API支持订阅和取消订阅接口。当主机被配置为知道SSM地址范围（无论配置机制是手动的还是通过协议的）时，主机的操作系统应该向应用程序返回一个错误，该应用程序发出非源特定请求以接收发送到SSM目标地址的多播。
A host that does not support these IP module interfaces (e.g., ASM-only hosts) and their underlying protocols cannot expect to reliably receive traffic sent on an SSM channel. As specified below in Section 5.2, routers will not set up SSM forwarding state or forward datagrams in response to an ASM join request.
不支持这些IP模块接口（例如，仅限ASM的主机）及其底层协议的主机无法可靠地接收SSM通道上发送的流量。如下文第5.2节所述，路由器不会设置SSM转发状态或转发数据报以响应ASM加入请求。
Widespread implementations of the IP packet reception interface (e.g., the recvfrom() system call in BSD Unix) do not allow a receiver to determine the destination address to which a datagram was sent. On a host with such an implementation, the destination address of a datagram cannot be inferred when the socket on which the datagram is received is Subscribed to multiple channels. Host operating systems SHOULD provide a way for a host to determine both the source and the destination address to which a datagram was sent. (As one example, the Linux operating system provides the destination of a packet as part of the response to the recvmsg() system call.) Until this capability is present, applications may be forced to use higher-layer mechanisms to identify the channel to which a datagram was sent.
IP数据包接收接口的广泛实现（例如，BSD Unix中的recvfrom（）系统调用）不允许接收器确定数据报发送到的目标地址。在具有这种实现的主机上，当接收数据报的套接字订阅多个通道时，无法推断数据报的目标地址。主机操作系统应该为主机提供一种方法来确定数据报发送到的源地址和目标地址。（例如，Linux操作系统提供数据包的目的地，作为对recvmsg（）系统调用的响应的一部分。）在出现此功能之前，应用程序可能会被迫使用更高层的机制来识别数据报发送到的通道。
An incoming datagram destined to an SSM address MUST be delivered by the IP module to all sockets that have indicated (via Subscribe) a desire to receive data that matches the datagram's source address, destination address, and arriving interface. It MUST NOT be delivered to other sockets.
IP模块必须将发送到SSM地址的传入数据报发送到所有已指示（通过订阅）希望接收与数据报源地址、目标地址和到达接口匹配的数据的套接字。不得将其输送至其他插座。
When the first socket on host H subscribes to a channel (S,G) on interface I, the host IP module on H sends a request on interface I to indicate to neighboring routers that the host wishes to receive traffic sent by source S to source-specific multicast destination G. Similarly, when the last socket on a host unsubscribes from a channel on interface I, the host IP module sends an unsubscription request for that channel to interface I.
当主机H上的第一个套接字订阅接口I上的信道（S，G）时，H上的主机IP模块在接口I上发送请求，以向相邻路由器指示主机希望接收由源S发送到源特定多播目的地G的流量。类似地，当主机上的最后一个套接字从接口I上的通道取消订阅时，主机IP模块向接口I发送该通道的取消订阅请求。
These requests will typically be Internet Group Management Protocol version 3 (IGMPv3) messages for IPv4, or Multicast Listener Discovery Version 2 (MLDv2) messages for IPv6 [IGMPv3,MLDv2]. A host that supports the SSM service model MUST implement the host portion of [IGMPv3] for IPv4 and [MLDv2] for IPv6. It MUST also conform to the IGMPv3/MLDv2 behavior described in [GMP-SSM].
这些请求通常是IPv4的Internet组管理协议版本3（IGMPv3）消息，或IPv6的多播侦听器发现版本2（MLDv2）消息[IGMPv3，MLDv2]。支持SSM服务模型的主机必须为IPv4实现[IGMPv3]，为IPv6实现[MLDv2]的主机部分。它还必须符合[GMP-SSM]中描述的IGMPv3/MLDv2行为。
The SSM destination address 232.0.0.0 is reserved, and it must not be used as a destination address. Similarly, FF3x::4000:0000 is also reserved. The goal of reserving these two addresses is to preserve one invalid SSM destination for IPv4 and IPv6, which can be useful in an implementation as a null value. The address range 232.0.0.1 - 232.0.0.255 is currently reserved for allocation by IANA. SSM destination addresses in the range FF3x::4000:0001 through FF3x::7FFF:FFFF are similarly reserved for IANA allocation [IPv6-MALLOC]. The motivation to reserve these addresses is outlined below in Section 9, "IANA Considerations".
SSM目标地址232.0.0.0是保留的，不能用作目标地址。同样，也保留了FF3x:：4000:0000。保留这两个地址的目的是为IPv4和IPv6保留一个无效的SSM目标，这在实现中可以用作空值。地址范围232.0.0.1-232.0.0.255目前保留供IANA分配。FF3x:：4000:0001到FF3x:：7FFF:FFFF范围内的SSM目标地址同样保留给IANA分配[IPv6 MALLOC]。第9节“IANA注意事项”概述了保留这些地址的动机。
The policy for allocating the rest of the SSM addresses to sending applications is strictly locally determined by the sending host.
将其余SSM地址分配给发送应用程序的策略严格由发送主机在本地确定。
When allocating SSM addresses dynamically, a host or host operating system MUST NOT allocate sequentially starting at the first allowed address. It is RECOMMENDED to allocate SSM addresses to applications randomly, while ensuring that allocated addresses are not given simultaneously to multiple applications (and avoiding the reserved addresses). For IPv6, the randomization should apply to the lowest 31 bits of the address.
动态分配SSM地址时，主机或主机操作系统不得从第一个允许的地址开始顺序分配。建议将SSM地址随机分配给应用程序，同时确保分配的地址不会同时分配给多个应用程序（并避免保留地址）。对于IPv6，随机化应适用于地址的最低31位。
As described in Section 6, the mapping of an IP packet with SSM destination address onto a link-layer multicast address does not take into account the datagram's source IP address (on commonly-used link layers like Ethernet). If all hosts started at the first allowed address, then with high probability, many source-specific channels on shared-medium local area networks would use the same link-layer multicast address. As a result, traffic destined for one channel subscriber would be delivered to another's IP module, which would then have to discard the datagram.
如第6节所述，将具有SSM目标地址的IP数据包映射到链路层多播地址时，不考虑数据报的源IP地址（在以太网等常用链路层上）。如果所有主机都从第一个允许的地址启动，那么共享媒体局域网上的许多特定于源的通道很可能使用相同的链路层多播地址。因此，发送到一个信道订户的通信量将被传送到另一个的IP模块，然后该模块将不得不丢弃数据报。
A host operating system SHOULD provide an interface to allow an application to request a unique allocation of a channel destination address in advance of a session's commencement, and this allocation database SHOULD persist across host reboots. By providing persistent allocations, a host application can advertise the session in advance
主机操作系统应提供一个接口，允许应用程序在会话开始之前请求通道目标地址的唯一分配，并且此分配数据库应在主机重新启动期间保持不变。通过提供持久分配，主机应用程序可以提前播发会话
of its start time on a web page or in another directory. (We note that this issue is not specific to SSM applications -- the same problem arises for ASM.)
它在网页或其他目录中的开始时间。（我们注意到，这个问题并不特定于SSM应用程序——ASM也会出现同样的问题。）
This document neither defines the interfaces for requesting or returning addresses nor specifies the host algorithms for storing those allocations. One plausible abstract API is defined in RFC 2771 [RFC2771]. Note that RFC 2771 allows an application to request an address within a specific range of addresses. If this interface is used, the starting address of the range SHOULD be selected at random by the application.
本文档既不定义请求或返回地址的接口，也不指定存储这些分配的主机算法。RFC 2771[RFC2771]中定义了一个合理的抽象API。请注意，RFC2771允许应用程序请求特定地址范围内的地址。如果使用此接口，应用程序应随机选择范围的起始地址。
For IPv6, administratively scoped SSM channel addresses are created by choosing an appropriate scope identifier for the SSM destination address. Normal IPv6 multicast scope boundaries [SCOPINGv6] are applied to traffic sent to an SSM destination address, including any relevant boundaries applied to both the source and destination address.
对于IPv6，通过为SSM目标地址选择适当的作用域标识符来创建管理作用域SSM通道地址。正常IPv6多播作用域边界[SCOPINGv6]应用于发送到SSM目标地址的流量，包括应用于源地址和目标地址的任何相关边界。
No globally agreed-upon administratively-scoped address range [ADMIN-SCOPE] is currently defined for IPv4 source-specific multicast. For IPv4, administrative scoping of SSM addresses can be implemented within an administrative domain by filtering outgoing SSM traffic sent to a scoped address at the domain's boundary routers.
当前未为IPv4源特定多播定义全局商定的管理作用域地址范围[ADMIN-SCOPE]。对于IPv4，SSM地址的管理作用域可以通过过滤发送到域边界路由器上作用域地址的传出SSM流量在管理域内实现。
A router that receives an IP datagram with a source-specific destination address MUST silently drop it unless a neighboring host or router has communicated a desire to receive packets sent from the source and to the destination address of the received packet.
接收具有特定于源的目的地地址的IP数据报的路由器必须静默地丢弃该数据报，除非相邻主机或路由器已表示希望接收从源发送的数据包以及接收到的数据包的目的地地址。
Certain IP multicast routing protocols already have the ability to communicate source-specific joins to neighboring routers (in particular, PIM-SM [PIM-SM]), and these protocols can, with slight modifications, be used to provide source-specific semantics. A router that supports the SSM service model MUST implement the PIM-SSM subset of the PIM-SM protocol from [PIM-SM] and MUST implement the router portion of [IGMPv3] for IPv4 and [MLDv2] for IPv6. An SSM router MUST also conform to the IGMPv3/MLDv2 behavior described in [GMP-SSM].
某些IP多播路由协议已经能够与相邻路由器（特别是PIM-SM[PIM-SM]）进行源特定连接的通信，并且这些协议可以在稍作修改的情况下用于提供源特定语义。支持SSM服务模型的路由器必须实现[PIM-SM]中PIM-SM协议的PIM-SSM子集，并且必须实现IPv4的[IGMPv3]和IPv6的[MLDv2]的路由器部分。SSM路由器还必须符合[GMP-SSM]中描述的IGMPv3/MLDv2行为。
With PIM-SSM, successful establishment of an (S,G) forwarding path from the source S to any receiver depends on hop-by-hop forwarding of the explicit join request from the receiver toward the source. The protocol(s) and algorithms that are used to select the forwarding path for this explicit join must provide a loop-free path. When using PIM-SSM, the PIM-SSM implementation MUST (at least) support the ability to use the unicast topology database for this purpose.
使用PIM-SSM，成功建立从源S到任何接收器的（S，G）转发路径取决于从接收器到源的显式加入请求的逐跳转发。用于为此显式连接选择转发路径的协议和算法必须提供无循环路径。使用PIM-SSM时，PIM-SSM实现必须（至少）支持为此目的使用单播拓扑数据库的能力。
A network can concurrently support SSM in the SSM address range and any-source multicast in the rest of the multicast address space, and it is expected that this will be commonplace. In such a network, a router may receive a non-source-specific, or "(*,G)" in conventional terminology, request for delivery of traffic in the SSM range from a neighbor that does not implement source-specific multicast in a manner compliant with this document. A router that receives such a non-source-specific request for data in the SSM range MUST NOT use the request to establish forwarding state and MUST NOT propagate the request to other neighboring routers. A router MAY log an error in such a case. This applies both to any request received from a host (e.g., an IGMPv1 or IGMPv2 [IGMPv2] host report) and to any request received from a routing protocol (e.g., a PIM-SM (*,G) join). The inter-router case is further discussed in Section 8, "Transition Considerations".
网络可以同时支持SSM地址范围内的SSM和多播地址空间其余部分内的任何源多播，预计这将很常见。在这样的网络中，路由器可以从没有以符合本文档的方式实现源特定多播的邻居接收非源特定的请求，或者用传统术语来说是“（*，G）”，请求在SSM范围内传送业务。对于SSM范围内的数据，接收此类非源特定请求的路由器不得使用该请求建立转发状态，也不得将该请求传播到其他相邻路由器。在这种情况下，路由器可能会记录错误。这既适用于从主机接收的任何请求（例如，IGMPv1或IGMPv2[IGMPv2]主机报告），也适用于从路由协议接收的任何请求（例如，PIM-SM（*，g）连接）。路由器间的情况将在第8节“过渡考虑”中进一步讨论。
It is essential that all routers in the network give source-specific semantics to the same range of addresses in order to achieve the full benefit of SSM. To comply with this specification, a router MUST treat ALL IANA-allocated SSM addresses with source-specific semantics.
网络中的所有路由器必须为相同的地址范围提供源特定的语义，以实现SSM的全部好处。为了遵守此规范，路由器必须使用源特定语义处理所有IANA分配的SSM地址。
Source-specific multicast packets are transmitted on link-layer networks as specified in RFC 1112 for IPv4 and as in [ETHERv6] for IPv6. On most shared-medium link-layer networks that support multicast (e.g., Ethernet), the IP source address is not used in the selection of the link-layer destination address. Consequently, on such a network, all packets sent to destination address G will be delivered to any host that has subscribed to any channel (S,G), regardless of S. Therefore, the IP module MUST filter packets it receives from the link layer before delivering them to the socket layer.
源特定多播数据包在链路层网络上传输，如RFC 1112中针对IPv4的规定和[ETHERv6]中针对IPv6的规定。在大多数支持多播（如以太网）的共享介质链路层网络上，在选择链路层目标地址时不使用IP源地址。因此，在这样的网络上，发送到目的地地址G的所有数据包将被发送到订阅了任何信道（S，G）的任何主机，而不考虑S。因此，IP模块必须在将其从链路层接收的数据包发送到套接字层之前对其进行过滤。
This section outlines security issues pertaining to SSM. The following topics are addressed: IPsec, denial-of-service attacks, source spoofing, and security issues related to administrative scoping.
本节概述了与SSM相关的安全问题。讨论了以下主题：IPsec、拒绝服务攻击、源欺骗以及与管理范围相关的安全问题。
The IPsec Authentication Header (AH) and Encapsulating Security Payload (ESP) can be used to secure SSM traffic, if a multicast-capable implementation of IPsec (as required in [RFC4301]) is used by the receivers.
如果接收方使用支持多播的IPsec实现（如[RFC4301]中所要求），则IPsec认证报头（AH）和封装安全有效负载（ESP）可用于保护SSM通信。
For existing implementations of RFC 2401 IPsec (now superseded by [RFC4301]), there are a few caveats related to SSM. They are listed here. In RFC 2401 IPsec, the source address is not used as part of the key in the SAD lookup. As a result, two senders that happen to use the same SSM destination address and the same Security Parameter Index (SPI) will "collide" in the SAD at any host that is receiving both channels. Because the channel addresses and SPIs are both allocated autonomously by the senders, there is no reasonable means to ensure that each sender uses a unique destination address or SPI.
对于RFC 2401 IPsec（现在被[RFC4301]取代）的现有实现，有一些与SSM相关的注意事项。它们列在这里。在RFC 2401 IPsec中，源地址在SAD查找中不用作密钥的一部分。因此，两个碰巧使用相同SSM目标地址和相同安全参数索引（SPI）的发送方将在接收这两个通道的任何主机的SAD中发生“冲突”。由于信道地址和SPI都是由发送方自主分配的，因此没有合理的方法确保每个发送方使用唯一的目标地址或SPI。
A problem arises if a receiver subscribes simultaneously to two unrelated channels using IPsec whose sources happen to be using the same IP destination address (IPDA) and the same IPsec SPI. Because the channel destination addresses are allocated autonomously by the senders, any two hosts can simultaneously use the same destination address, and there is no reasonable means to ensure that this does not happen. The <IPDA,SPI> tuple, however, consists of 56 bits that are generally randomly chosen (24 bits of the IP destination and 32 bits of the SPI), and a conflict is unlikely to occur through random chance.
如果接收器使用IPsec同时订阅两个不相关的通道，而其源恰好使用相同的IP目标地址（IPDA）和相同的IPsec SPI，则会出现问题。由于信道目标地址由发送方自主分配，因此任何两台主机都可以同时使用相同的目标地址，并且没有合理的方法确保不会发生这种情况。然而，<IPDA，SPI>元组由通常随机选择的56位（IP目的地的24位和SPI的32位）组成，不太可能通过随机机会发生冲突。
If such a collision occurs, a receiver will not be able to simultaneously receive IPsec-protected traffic from the two colliding sources. A receiver can detect this condition by noticing that it is receiving traffic from two different sources with the same SPI and the same SSM destination address.
如果发生这种冲突，接收器将无法同时从两个冲突源接收受IPsec保护的通信量。接收器可以通过注意到它正在接收来自两个具有相同SPI和相同SSM目标地址的不同来源的流量来检测这种情况。
A subscription request creates (S,G) state in a router to record the subscription, invokes processing on that router, and possibly causes processing at neighboring routers. A host can mount a denial-of-service attack by requesting a large number of subscriptions. Denial of service can result if:
订阅请求在路由器中创建（S，G）状态以记录订阅，调用该路由器上的处理，并可能导致在相邻路由器上进行处理。主机可以通过请求大量订阅来发起拒绝服务攻击。如果出现以下情况，可能会导致拒绝服务：
- a large amount of traffic arrives when it was otherwise undesired, consuming network resources to deliver it and host resources to drop it;
- 大量流量在本来不需要的情况下到达，需要消耗网络资源来传递流量，并消耗主机资源来丢弃流量；
- a large amount of source-specific multicast state is created in network routers, using router memory and CPU resources to store and process the state; or
- 在网络路由器中创建大量特定于源的多播状态，使用路由器内存和CPU资源来存储和处理该状态；或
- a large amount of control traffic is generated to manage the source-specific state, using router CPU and network bandwidth.
- 使用路由器CPU和网络带宽，生成大量控制流量来管理特定于源的状态。
To reduce the damage from such an attack, a router MAY have configuration options to limit, for example, the following items:
为了减少此类攻击造成的损害，路由器可能有配置选项来限制，例如，以下项目：
- The total rate at which all hosts on any one interface are allowed to initiate subscriptions (to limit the damage caused by forged source-address attacks).
- 允许任何一个接口上的所有主机启动订阅的总速率（以限制伪造源地址攻击造成的损害）。
- The total number of subscriptions that can be initiated from any single interface or host.
- 可以从任何单个接口或主机启动的订阅总数。
Any decision by an implementor to artificially limit the rate or number of subscriptions should be taken carefully, however, as future applications may use large numbers of channels. Tight limits on the rate or number of channel subscriptions would inhibit the deployment of such applications.
但是，实现者做出的任何人为限制订阅速率或数量的决定都应该谨慎，因为未来的应用程序可能会使用大量的通道。严格限制频道订阅的速率或数量将抑制此类应用程序的部署。
A router SHOULD verify that the source of a subscription request is a valid address for the interface on which it was received. Failure to do so would exacerbate a spoofed-source address attack.
路由器应验证订阅请求的源是否为接收该请求的接口的有效地址。否则将加剧伪造源地址攻击。
We note that these attacks are not unique to SSM -- they are also present for any-source multicast.
我们注意到这些攻击不是SSM独有的——它们也存在于任何源多播中。
By forging the source address in a datagram, an attacker can potentially violate the SSM service model by transmitting datagrams on a channel belonging to another host. Thus, an application requiring strong authentication should not assume that all packets
通过伪造数据报中的源地址，攻击者可以在属于另一主机的通道上传输数据报，从而可能违反SSM服务模型。因此，需要强身份验证的应用程序不应假定所有数据包
that arrive on a channel were sent by the requested source without higher-layer authentication mechanisms. The IPSEC Authentication Header [RFC2401, RFC4301] may be used to authenticate the source of an SSM transmission, for instance.
到达通道的数据是由请求的源发送的，没有更高层的身份验证机制。例如，IPSEC认证报头[RFC2401，RFC4301]可用于认证SSM传输的源。
Some degree of protection against spoofed source addresses in multicast is already fairly widespread, because the commonly deployed IP multicast routing protocols [PIM-DM, PIM-SM, DVMRP] incorporate a "reverse-path forwarding check" that validates that a multicast packet arrived on the expected interface for its source address. Routing protocols used for SSM SHOULD incorporate such a check.
针对多播中伪造源地址的某种程度的保护已经相当普遍，因为通常部署的IP多播路由协议[PIM-DM、PIM-SM、DVMRP]包含“反向路径转发检查”，用于验证多播数据包是否到达其源地址的预期接口。用于SSM的路由协议应包含此类检查。
Source Routing [RFC791] (both Loose and Strict) in combination with source address spoofing may be used to allow an impostor of the true channel source to inject packets onto an SSM channel. An SSM router SHOULD by default disallow source routing to an SSM destination address. A router MAY have a configuration option to allow source routing. Anti-source spoofing mechanisms, such as source address filtering at the edges of the network, are also strongly encouraged.
源路由[RFC791]（松散和严格）结合源地址欺骗可用于允许真实信道源的冒名顶替者将数据包注入SSM信道。SSM路由器默认情况下不允许源路由到SSM目标地址。路由器可能具有允许源路由的配置选项。还强烈鼓励使用反源欺骗机制，如网络边缘的源地址过滤。
Administrative scoping should not be relied upon as a security measure [ADMIN-SCOPE]; however, in some cases it is part of a security solution. It should be noted that no administrative scoping exists for IPv4 source-specific multicast. An alternative approach is to manually configure traffic filters to create such scoping if necessary.
不应将管理范围界定作为安全措施[管理范围]；但是，在某些情况下，它是安全解决方案的一部分。应该注意的是，IPv4源特定多播不存在管理作用域。另一种方法是手动配置流量过滤器，以便在必要时创建此类范围。
Furthermore, for IPv6, neither source nor destination address scoping should be used as a security measure. In some currently-deployed IPv6 routers (those that do not conform to [SCOPINGv6]), scope boundaries are not always applied to all source address (for instance, an implementation may filter link-local addresses but nothing else). Such a router may incorrectly forward an SSM channel (S,G) through a scope boundary for S.
此外，对于IPv6，源地址范围和目标地址范围都不应用作安全措施。例如，对于当前部署的IPv6实例，所有这些地址都不符合[SCOPINGv6]的本地地址，但这些路由器可能不符合[SCOPINGv6]的范围。这样的路由器可能会通过S的作用域边界错误地转发SSM信道（S，G）。
A host that complies with this document will send ONLY source-specific host reports for addresses in the SSM range. As stated above, a router that receives a non-source-specific (e.g., IGMPv1 or IGMPv2 or MLDv1 [RFC2710]) host report for a source-specific multicast destination address MUST ignore these reports. Failure to do so would violate the SSM service model promised to the sender: that a packet sent to (S,G) would only be delivered to hosts that specifically requested delivery of packets sent to G by S.
符合本文档要求的主机将仅发送SSM范围内地址的源特定主机报告。如上所述，接收源特定多播目的地地址的非源特定（例如，IGMPv1或IGMPv2或MLDv1[RFC2710]）主机报告的路由器必须忽略这些报告。如果不这样做，将违反向发送方承诺的SSM服务模型：发送到（S，G）的数据包将只发送到专门请求传递由S发送到G的数据包的主机。
During a transition period, it would be possible to deliver SSM datagrams in a domain where the routers do not support SSM semantics by simply forwarding any packet destined to G to all hosts that have requested subscription of (S,G) for any S. However, this implementation risks unduly burdening the network infrastructure by delivering (S,G) datagrams to hosts that did not request them. Such an implementation for addresses in the SSM range is specifically not compliant with Section 5.2 of this document.
在过渡期内，可以在路由器不支持SSM语义的域中交付SSM数据报，只需将目的地为G的任何数据包转发给已请求订阅（S，G）任何S的所有主机。然而，这种实现存在通过交付（S，G）而不适当地加重网络基础设施负担的风险发送给未请求它们的主机的数据报。SSM范围内地址的此类实现不符合本文件第5.2节的规定。
IANA allocates IPv4 addresses in the range 232.0.0.1 through 232.0.0.255 and IPv6 addresses in the range FF3x:4000:0001 to FF3x::7FFF:FFFF. These addresses are allocated according to IETF Consensus [IANA-CONSID]. These address ranges are reserved for services with wide applicability that either require that or would strongly benefit if all hosts use a well-known SSM destination address for that service. Any proposal for allocation must consider the fact that, on an Ethernet network, all datagrams sent to any SSM destination address will be transmitted with the same link-layer destination address, regardless of the source. Furthermore, the fact that SSM destinations in 232.0.0.0/24 and 232.128.0.0/24 use the same link-layer addresses as the reserved IP multicast group range 224.0.0.0/24 must also be considered. Similar consideration should be given to the IPv6 reserved multicast addresses. 232.0.0.0 and FF3x::4000:0000 should not be allocated, as suggested above.
IANA分配的IPv4地址范围为232.0.0.1到232.0.0.255，IPv6地址范围为FF3x:4000:0001到FF3x:：7FFF:FFFF。这些地址是根据IETF共识[IANA-CONSID]分配的。这些地址范围是为具有广泛适用性的服务保留的，如果所有主机都为该服务使用众所周知的SSM目标地址，则这些服务需要该地址范围，或者将从中受益匪浅。任何分配建议都必须考虑这样一个事实，即在以太网网络上，发送到任何SSM目的地地址的所有数据报都将以相同的链路层目的地地址发送，而不管源。此外，还必须考虑232.0.0.0/24和232.128.0.0/24中的SSM目的地使用与保留IP多播组范围224.0.0/24相同的链路层地址这一事实。应该对IPv6保留多播地址进行类似的考虑。如上所述，不应分配232.0.0.0和FF3x:：4000:0000。
Except for the aforementioned addresses, IANA SHALL NOT allocate any SSM destination address to a particular entity or application. To do so would compromise one of the important benefits of the source-specific model: the ability for a host to simply and autonomously allocate a source-specific multicast address from a large flat address space.
除上述地址外，IANA不得将任何SSM目的地地址分配给特定实体或应用程序。这样做会损害源特定模型的一个重要好处：主机能够从一个大的平面地址空间简单地、自主地分配源特定的多播地址。
The SSM service model draws on a variety of prior work on alternative approaches to IP multicast, including the EXPRESS multicast model of Holbrook and Cheriton [EXPRESS], Green's [SMRP], and the Simple Multicast proposal of Perlman, et al. [SIMPLE]. We would also like to thank Jon Postel and David Cheriton for their support in reassigning the 232/8 address range to SSM. Brian Haberman contributed to the IPv6 portion of this document. Thanks to Pekka Savola for a careful review.
SSM服务模型借鉴了关于IP多播替代方法的各种先前工作，包括Holbrook和Cheriton[EXPRESS]的EXPRESS多播模型、Green的[SMRP]和Perlman等人的Simple多播方案[Simple]。我们还要感谢Jon Postel和David Cheriton在将232/8地址范围重新分配给SSM方面提供的支持。Brian Haberman参与了本文档的IPv6部分。感谢佩卡·萨沃拉的仔细审查。
[ETHERv6] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[ETHERv6]Crawford，M.，“通过以太网传输IPv6数据包”，RFC 2464，1998年12月。
[GMP-SSM] Holbrook, H. and B. Cain, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.
[GMP-SSM]Holbrook，H.和B.Cain，“为源特定多播使用Internet组管理协议版本3（IGMPv3）和多播侦听器发现协议版本2（MLDv2）”，RFC 4604，2006年8月。
[IGMPv3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[IGMPv3]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[IPv6-UBM] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[IPv6 UBM]Haberman，B.和D.Thaler，“基于单播前缀的IPv6多播地址”，RFC3306，2002年8月。
[IPv6-MALLOC] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.
[IPv6 MALLOC]Haberman，B.，“IPv6多播地址分配指南”，RFC33072002年8月。
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[MLDv2]Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC 3810，2004年6月。
[PIM-SM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas. "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[PIM-SM]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas。“协议无关多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC4601，2006年8月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513]Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[ADMIN-SCOPE] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[管理范围]Meyer，D.，“管理范围的IP多播”，BCP 23，RFC 2365，1998年7月。
[DVMRP] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[DVMRP]Waitzman，D.，Partridge，C.，和S.Deering，“距离向量多播路由协议”，RFC 1075，1988年11月。
[EXPRESS] Holbrook, H., and Cheriton, D. "Explicitly Requested Source-Specific Multicast: EXPRESS support for Large-scale Single-source Applications." Proceedings of ACM SIGCOMM '99, Cambridge, MA, September 1999.
[EXPRESS]Holbrook，H.和Cheriton，D.“明确要求特定于源的多播：对大规模单源应用的快速支持”，《ACM SIGCOMM'99会议录》，马萨诸塞州剑桥，1999年9月。
[IANA-ALLOC] Internet Assigned Numbers Authority, http://www.iana.org/assignments/multicast-addresses.
[IANA-ALOC]互联网分配号码管理局，http://www.iana.org/assignments/multicast-addresses.
[IANA-CONSID] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA-CONSID]Narten，T.和H.Alvestrand，“在RFC中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[IGMPv2]Fenner，W.，“互联网组管理协议，第2版”，RFC 2236，1997年11月。
[MSFAPI] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, January 2004.
[MSFAPI]Thaler，D.，Fenner，B.，和B.Quinn，“多播源过滤器的套接字接口扩展”，RFC 3678，2004年1月。
[PIM-DM] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
[PIM-DM]Adams，A.，Nicholas，J.，和W.Siadak，“协议独立多播-密集模式（PIM-DM）：协议规范（修订版）”，RFC 3973，2005年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]Deering，S.，Fenner，W.，和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[RFC2771] Finlayson, R., "An Abstract API for Multicast Address Allocation", RFC 2771, February 2000.
[RFC2771]Finlayson，R.，“用于多播地址分配的抽象API”，RFC 27712000年2月。
[SCOPINGv6] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005.
[SCOPINGv6]Deering，S.，Haberman，B.，Jinmei，T.，Nordmark，E.，和B.Zill，“IPv6作用域地址体系结构”，RFC 4007，2005年3月。
[SIMPLE] R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. Maufer, C. Diot, and M. Green, "Simple Multicast: A Design for Simple, Low-Overhead Multicast", Work in Progress, October 1999.
[SIMPLE]R.Perlman、C-Y.Lee、A.Ballardie、J.Crowcroft、Z.Wang、T.Maufer、C.Diot和M.Green，“简单多播：一种简单、低开销多播的设计”，正在进行的工作，1999年10月。
[SMRP] Green, M. "Method and System of Multicast Routing for Groups with a Single Transmitter." United States Patent Number 5,517,494.
[SMRP]Green，M.“具有单个发射机的组的多播路由的方法和系统”，《美国专利号5517494》。
Authors' Addresses
作者地址
Brad Cain Acopia Networks
Brad Cain Acopia网络公司
EMail: bcain99@gmail.com
EMail: bcain99@gmail.com
Hugh Holbrook Arastra, Inc. P.O. Box 10905 Palo Alto, CA 94303
休·霍尔布鲁克·阿拉斯特拉公司，邮政信箱10905，加利福尼亚州帕洛阿尔托市，邮编94303
Phone: +1 650 331-1620
EMail: holbrook@arastra.com
Phone: +1 650 331-1620
EMail: holbrook@arastra.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。