Network Working Group D. Wing
Request for Comments: 5135 T. Eckert
BCP: 135 Cisco Systems, Inc.
Category: Best Current Practice February 2008
Network Working Group D. Wing
Request for Comments: 5135 T. Eckert
BCP: 135 Cisco Systems, Inc.
Category: Best Current Practice February 2008
IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT)
网络地址转换器（NAT）和网络地址端口转换器（NAPT）的IP多播要求
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Abstract
摘要
This document specifies requirements for a for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) that support Any Source IP Multicast or Source-Specific IP Multicast. An IP multicast-capable NAT device that adheres to the requirements of this document can optimize the operation of IP multicast applications that are generally unaware of IP multicast NAT devices.
本文件规定了对支持任何源IP多播或源特定IP多播的网络地址转换器（NAT）和网络地址端口转换器（NAPT）的要求。符合本文档要求的支持IP多播的NAT设备可以优化通常不知道IP多播NAT设备的IP多播应用程序的操作。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology Used in This Document . . . . . . . . . . . . . . 2
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. NATing IP Multicast Data Packets . . . . . . . . . . . . . 5
4.1.1. Receiving Multicast Data Packets . . . . . . . . . . . 5
4.1.2. Sending Multicast Data Packets . . . . . . . . . . . . 5
4.2. IGMP Version Support . . . . . . . . . . . . . . . . . . . 6
4.2.1. IGMPv1 or IGMPv2 . . . . . . . . . . . . . . . . . . . 7
4.2.2. IGMPv3 . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Any Source Multicast Transmitters . . . . . . . . . . . . 8
5. Requirements Summary . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Application Considerations . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology Used in This Document . . . . . . . . . . . . . . 2
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. NATing IP Multicast Data Packets . . . . . . . . . . . . . 5
4.1.1. Receiving Multicast Data Packets . . . . . . . . . . . 5
4.1.2. Sending Multicast Data Packets . . . . . . . . . . . . 5
4.2. IGMP Version Support . . . . . . . . . . . . . . . . . . . 6
4.2.1. IGMPv1 or IGMPv2 . . . . . . . . . . . . . . . . . . . 7
4.2.2. IGMPv3 . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Any Source Multicast Transmitters . . . . . . . . . . . . 8
5. Requirements Summary . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Application Considerations . . . . . . . . . . . . . 14
In order for IP multicast applications to function well over NATs, multicast UDP must work as seamlessly as unicast UDP. However, NATs have little consistency in IP multicast operation, which results in inconsistent user experiences and failed IP multicast operation.
为了使IP多播应用程序能够在NAT上正常运行，多播UDP必须像单播UDP一样无缝工作。然而，NAT在IP组播操作中的一致性较差，导致用户体验不一致，导致IP组播操作失败。
This document targets requirements intended to enable correct operations of Any Source Multicast and Source-Specific Multicast in devices running Internet Group Management Protocol (IGMP) proxy routing and NAT and without applying NAT to IP multicast group addresses. This profile of functionality is the expected best practice for residential access routers, small branch routers, or similar deployments.
本文档针对的要求旨在使运行Internet组管理协议（IGMP）代理路由和NAT的设备中的任何源多播和源特定多播能够正确运行，并且不将NAT应用于IP多播组地址。此功能配置文件是住宅接入路由器、小型分支路由器或类似部署的预期最佳实践。
Most of the principles outlined in this document do also apply when using protocols other than IGMP, such as Protocol Independent Multicast - Sparse Mode (PIM-SM), or when performing NAT between multiple "inside" interfaces, but explicit consideration for these cases is outside the scope of this document.
当使用IGMP以外的协议时，如协议独立多播稀疏模式（PIM-SM），或在多个“内部”接口之间执行NAT时，本文档中概述的大多数原则也适用，但对这些情况的明确考虑超出了本文档的范围。
This document describes the behavior of a device that functions as a NAT for unicast flows and also forwards IP multicast traffic in either direction ('inside' to 'outside', or 'outside' to 'inside'). This allows a host 'inside' the NAT to both receive multicast traffic and to source multicast traffic. Hosts on the 'inside' interface(s) of a NAT indicate their interest in receiving an IP multicast flow by sending an IGMP message to their local interface. An IP multicast-capable NAT will see that IGMP message (IGMPv1 [RFC1112], IGMPv2 [RFC2236], IGMPv3 [RFC3376]), possibly perform some functions on that IGMP message, and forward it to its upstream router. This causes the upstream router to send that IP multicast traffic to the NAT, which forwards it to those 'inside' segment(s) with host(s) that had previously sent IGMP messages for that IP multicast traffic.
本文档描述了设备的行为，该设备作为单播流的NAT，并在任一方向上转发IP多播流量（“内部”到“外部”，或“外部”到“内部”）。这允许NAT“内部”的主机接收多播流量和源多播流量。NAT“内部”接口上的主机通过向其本地接口发送IGMP消息来表示其对接收IP多播流的兴趣。支持IP多播的NAT将看到IGMP消息（IGMPv1[RFC1112]、IGMPv2[RFC2236]、IGMPv3[RFC3376]）可能对该IGMP消息执行一些功能，并将其转发到其上游路由器。这会导致上游路由器将该IP多播流量发送到NAT，NAT将其转发到具有主机的那些“内部”段，这些主机先前已为该IP多播流量发送IGMP消息。
Out of scope of this document are PIM-SM [RFC4601] and IPv6 [RFC2460]. The IGMP Proxy devices that are scoped in this document do not forward PIM-SM. IPv6 is out of scope because NAT is not considered necessary with IPv6.
不在本文件范围内的是PIM-SM[RFC4601]和IPv6[RFC2460]。本文件范围内的IGMP代理设备不转发PIM-SM。IPv6不在范围内，因为NAT被认为是IPv6所必需的。
This document is a companion document to "NAT Behavioral Requirements for Unicast UDP" [RFC4787].
本文件是“单播UDP的NAT行为要求”[RFC4787]的配套文件。
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]中所述进行解释。
In this document, the term "NAT" applies to both Network Address and Port Translator (NAPT) as well as a NAT that does not translate ports.
在本文档中，术语“NAT”既适用于网络地址和端口转换器（NAPT），也适用于不转换端口的NAT。
The term 'inside' refers to the interface(s) on a NAT that contain hosts that wish to source or receive IP multicast traffic. The term 'outside' refers to the interface(s) that the NAT forwards IGMP membership messages to, and where the NAT routes IP multicast traffic that originates from hosts on its 'inside' interface.
术语“内部”是指NAT上的接口，其中包含希望提供或接收IP多播流量的主机。术语“外部”是指NAT将IGMP成员资格消息转发到的接口，以及NAT在其中路由源自其“内部”接口上主机的IP多播流量。
When a NAT isn't used, a host might be connected to the Internet in a configuration such as this:
未使用NAT时，主机可能会以如下配置连接到Internet：
+-------------+
+------+ | DSL modem | +------------+
| host +---+ or +-//-+ WAN Router |
+------+ | cable modem | +------------+
+-------------+
+-------------+
+------+ | DSL modem | +------------+
| host +---+ or +-//-+ WAN Router |
+------+ | cable modem | +------------+
+-------------+
Figure 1: Network without NATing IGMP Proxy
图1：没有本地IGMP代理的网络
If instead of a single host as shown in Figure 1, one or more LANs with potentially multiple hosts are to be connected, with the same type of service termination on the DSL or cable modem, a NAT device is added as shown in Figure 2. This device, in general, perform routing and NAT functions such that it does look like a single host towards the DSL/cable modem.
如果要使用DSL或电缆调制解调器上相同类型的服务终端连接一个或多个可能有多个主机的LAN，而不是图1所示的单个主机，则会添加NAT设备，如图2所示。通常，该设备执行路由和NAT功能，使其看起来像DSL/电缆调制解调器的单个主机。
+----+ +-------------+
|host+---+ +---------+ | +-----------+
+----+ | |Multicast| | | DSL modem | +------------+
| | Proxy | +--+ or +-//-+ WAN Router |
'inside' | +---------+ | |cable modem| +------------+
interfaces | | +-----------+
| +------+ |
+----+ | | NAT | | 'outside'
|host+---+ +------+ | interfaces
+----+ +-------------+
IGMP Proxy NAT Device
+----+ +-------------+
|host+---+ +---------+ | +-----------+
+----+ | |Multicast| | | DSL modem | +------------+
| | Proxy | +--+ or +-//-+ WAN Router |
'inside' | +---------+ | |cable modem| +------------+
interfaces | | +-----------+
| +------+ |
+----+ | | NAT | | 'outside'
|host+---+ +------+ | interfaces
+----+ +-------------+
IGMP Proxy NAT Device
Figure 2: Network with NATing IGMP Proxy
图2：带有本机IGMP代理的网络
In IP multicast, IGMP is the protocol used by hosts, such as the one shown in Figure 1. For the NAT device in Figure 2 to look like the single host for IP multicast services towards the DSL/cable modem and
在IP多播中，IGMP是主机使用的协议，如图1所示。使图2中的NAT设备看起来像面向DSL/电缆调制解调器的IP多播服务的单一主机
to forward IP multicast traffic from and to the multiple hosts in the picture, it needs to perform so called "IGMP Proxying" [RFC4605] -- but within the context of also performing NAT. NAT is not covered by [RFC4605]. Adding NAT to IGMP proxying does not need to change the processing of the IGMP messages as defined in RFC 4605:
要将IP多播通信从图片中的多个主机转发到多个主机，它需要执行所谓的“IGMP代理”[RFC4605]——但也要在执行NAT的上下文中执行。[RFC4605]未涵盖NAT。将NAT添加到IGMP代理不需要更改RFC 4605中定义的IGMP消息的处理：
IGMP messages are never logically forwarded by the IGMP proxying device, but rather sourced or received by it. In general, receipt of IGMP messages by the device updates the device's IGMP state. The updated state changes the device's forwarding of multicast messages or triggers the sending of IGMP messages. "Forwarding" of IGMP protocol messages may thus only happen implicitly by implementation optimizations that create shortcuts in this machinery.
IGMP消息从不在逻辑上由IGMP代理设备转发，而是由其来源或接收。通常，设备接收IGMP消息会更新设备的IGMP状态。更新状态会更改设备对多播消息的转发或触发IGMP消息的发送。因此，IGMP协议消息的“转发”只能通过在该机器中创建快捷方式的实现优化隐式发生。
This specifically means that IGMP protocol packets sent by the NAT device will always use the IP address of the interface ('inside' or 'outside') from which they are sent, but because those packets are logically "sourced" and not "forwarded", NAT does not have any impact on this.
这具体意味着NAT设备发送的IGMP协议数据包将始终使用发送它们的接口（“内部”或“外部”）的IP地址，但由于这些数据包在逻辑上是“源”的，而不是“转发的”，NAT对此没有任何影响。
Unlike unicast flows, packets with a multicast destination IP address do not have their destination IP address or destination port changed by a NAT. However, their source IP address (and source UDP port, in some cases with a NAPT) is changed if the packet goes from an 'inside' interface of a NAT to the 'outside' interface of a NAT -- similar to the behavior of a unicast packet across those same interfaces.
与单播流不同，具有多播目标IP地址的数据包的目标IP地址或目标端口不会被NAT更改。但是，如果数据包从NAT的“内部”接口转到NAT的“外部”接口，则它们的源IP地址（以及源UDP端口，在某些情况下是NAPT）会发生更改，这类似于跨这些接口的单播数据包的行为。
Adding NAT to IGMP proxying changes the processing of IP multicast data packets forwarded across the IGMP proxying device as described in the following sections. These changes actually simplify the ability to deploy IGMP proxying over a device that does *not* perform NAT.
将NAT添加到IGMP代理会更改对通过IGMP代理设备转发的IP多播数据包的处理，如下节所述。这些更改实际上简化了在不执行NAT的设备上部署IGMP代理的能力。
With an IGMP Proxy NAT Device, IP multicast data traffic sourced from hosts on the 'inside' is NATed such that it will look like it is being sourced from a host directly connected to the WAN router, thus eliminating all non-standard PIM-SM concerns/configurations described in Section 3.2 of [RFC4605].
使用IGMP代理NAT设备，来自“内部”主机的IP多播数据流量被隔离，使其看起来像是来自直接连接到WAN路由器的主机，从而消除了[RFC4605]第3.2节中描述的所有非标准PIM-SM问题/配置。
REQ-1: For IP multicast packets that are forwarded to a host(s) on its 'inside' interface(s), a NAT MUST NOT modify the destination IP address or destination port of the packets.
REQ-1：对于转发到主机“内部”接口上的IP多播数据包，NAT不得修改数据包的目标IP地址或目标端口。
If a NAT were to modify the destination IP or port addresses, the NAT would also need to modify session announcements (e.g., electronic program guides, Session Announcement Protocol (SAP)) and session establishment and control (e.g., SIP, Real Time Streaming Protocol (RTSP)) messages. Such modifications of application messages are not considered a best practice. Furthermore, a NATed multi-homed network would need to coordinate such rewriting between its NATs.
如果NAT要修改目标IP或端口地址，NAT还需要修改会话公告（例如，电子节目指南、会话公告协议（SAP））和会话建立和控制（例如，SIP、实时流协议（RTSP））消息。对应用程序消息的此类修改不被视为最佳实践。此外，多宿网络需要协调NAT之间的这种重写。
REQ-2: A NAT MUST forward IP multicast UDP datagrams from its 'outside' interface to multicast receivers on its 'inside' interface(s).
REQ-2:NAT必须将IP多播UDP数据报从其“外部”接口转发到其“内部”接口上的多播接收器。
REQ-3: A NAT SHOULD forward IP multicast non-UDP protocols (e.g., Pragmatic General Multicast (PGM) [RFC3208], Resource Reservation Protocol (RSVP) [RFC2205]) from its 'outside' interface to IP multicast receivers on its 'inside' interface(s).
REQ-3:NAT应将IP多播非UDP协议（例如，实用通用多播（PGM）[RFC3208]，资源预留协议（RSVP）[RFC2205]）从其“外部”接口转发到其“内部”接口上的IP多播接收器。
The following requirement is normal NAT behavior for unicast packets, as described in [RFC4787], and is extended here to provide support for IP multicast senders behind the NAT.
以下要求是单播数据包的正常NAT行为，如[RFC4787]中所述，并在此处扩展以支持NAT后面的IP多播发送者。
REQ-4: A NAT MUST modify the source IP address of packets that arrive from an 'inside' interface towards the 'outside' interface so that those packets use the NAT's 'outside' IP address(es).
REQ-4:NAT必须修改从“内部”接口到达“外部”接口的数据包的源IP地址，以便这些数据包使用NAT的“外部”IP地址。
a: If the NAT also performs port translation (that is, it is a NAPT), the NAT MUST also create a mapping to allow responses to that IP multicast packet to be received by the appropriate host. For Any Source Multicast, also see Section 4.3.
答：如果NAT还执行端口转换（即，它是NAPT），则NAT还必须创建映射，以允许相应主机接收对该IP多播数据包的响应。对于任何源多播，也请参见第4.3节。
b: To allow hosts to learn the NAT's 'outside' interface address, the NAT MUST have "Endpoint-Independent Mapping" behavior (REQ-1 of [RFC4787]), no matter if the destination IP address is a unicast address or an IP multicast address.
b：为了允许主机了解NAT的“外部”接口地址，NAT必须具有“端点独立映射”行为（REQ-1 of[RFC4787]），无论目标IP地址是单播地址还是IP多播地址。
c: If the NAT has multiple public IP addresses, the NAT SHOULD have an address pooling behavior of "Paired" (as described in Section 4.1 of [RFC4787]) for its IP multicast mappings as well as for its unicast UDP mappings. This allows a multicast source to discover the NAT's public IP address using a unicast address discovery mechanism (e.g., [ICE]) and communicate that discovered IP address to a multicast receiver.
c：如果NAT有多个公共IP地址，NAT的IP多播映射和单播UDP映射的地址池行为应为“成对”（如[RFC4787]第4.1节所述）。这允许多播源使用单播地址发现机制（例如，[ICE]）发现NAT的公共IP地址，并将发现的IP地址与多播接收器通信。
REQ-5: A NAT MUST forward IP multicast UDP datagrams from its 'inside' interface(s) to its 'outside' interface.
REQ-5:NAT必须将IP多播UDP数据报从其“内部”接口转发到其“外部”接口。
a: NATs that support the above requirement MUST also provide a configuration option to disable this feature. Otherwise, a multihomed network would cause duplicate instances of the multicast data traffic on the public network.
答：支持上述要求的NAT还必须提供一个配置选项来禁用此功能。否则，多址网络将导致公共网络上的多播数据通信的重复实例。
As many NATs are located adjacent to bandwidth-constrained access links, it is important that IP multicast senders communicating with IP multicast receivers behind the NAT not have their flows consume bandwidth on the access link. This is accomplished by applications using administratively scoped IP addresses. Similarly, link-local multicast traffic isn't supposed to be routed off the local network.
由于许多NAT位于带宽受限的接入链路附近，因此，与NAT后面的IP多播接收器通信的IP多播发送者不应让其流消耗接入链路上的带宽，这一点很重要。这是由使用管理作用域IP地址的应用程序实现的。类似地，链路本地多播流量不应该路由到本地网络之外。
REQ-6: The NAT's default configuration MUST NOT forward administratively scoped IP multicast traffic (239.0.0.0/8) [RFC2365] from its 'inside' interface(s) to its 'outside' interface.
REQ-6:NAT的默认配置不得将管理范围的IP多播流量（239.0.0.0/8）[RFC2365]从其“内部”接口转发到其“外部”接口。
REQ-7: The NAT MUST NOT forward Local Network Control Block (224.0.0/24) [RFC3171] (also known as "link-local multicast") traffic from its 'inside' interface(s) to its 'outside' interface.
REQ-7:NAT不得将本地网络控制块（224.0.0/24）[RFC3171]（也称为“链路本地多播”）流量从其“内部”接口转发到其“外部”接口。
REQ-8: A NAT MAY support IGMPv1 (although IGMPv1 is considered obsolete).
REQ-8:NAT可能支持IGMPv1（尽管IGMPv1被认为已经过时）。
REQ-9: A NAT MUST support IGMPv2.
REQ-9:NAT必须支持IGMPv2。
REQ-10: A NAT SHOULD support IGMPv3.
REQ-10:NAT应支持IGMPv3。
For IGMPv1 and IGMPv2, a NAT can successfully operate by merely forwarding IGMP membership reports and queries between the interested hosts (on its internal interface) towards its external interface.
对于IGMPv1和IGMPv2，NAT只需在感兴趣的主机之间（在其内部接口上）向其外部接口转发IGMP成员资格报告和查询，即可成功运行。
REQ-11: If a NAT supports IGMPv1 and/or IGMPv2 (but not IGMPv3), the NAT MAY simply receive IGMP membership reports on the 'inside' interface, NAT them, and relay the IGMP membership report, and do the same function in the opposite direction to the IGMP listeners. That is, the NAT does not need to do any aggregation of IGMP messages.
REQ-11：如果NAT支持IGMPv1和/或IGMPv2（但不支持IGMPv3），则NAT可以简单地在“内部”接口上接收IGMP成员报告，对其进行NAT，并中继IGMP成员报告，并以与IGMP侦听器相反的方向执行相同的功能。也就是说，NAT不需要对IGMP消息进行任何聚合。
a: If a NAT relays IGMPv1 or IGMPv2 messages in this manner, it MUST NOT decrement the TTL of the IGMP messages, as they are already sent with TTL=1.
答：如果NAT以这种方式中继IGMPv1或IGMPv2消息，则它不得减少IGMP消息的TTL，因为它们已以TTL=1的方式发送。
b: However, it is RECOMMENDED that such a NAT implement IGMP/MLD Proxying [RFC4605], because IGMP aggregation provides a useful optimization.
b：但是，建议这样的NAT实现IGMP/MLD代理[RFC4605]，因为IGMP聚合提供了有用的优化。
When an IGMPv3 proxying device receives an IGMP membership on an 'inside' interface, it creates its own IGMP proxying membership state and its own IGMP forwarding table. It then creates an independent IGMP membership report on its 'outside' interface reporting the IP multicast groups/channels -- but there is no direct relationship or "forwarding" of IGMP membership reports or queries across the interfaces. The NAT device will subsequently receive an IP multicast data packet on the 'outside' interface and forward the IP multicast packet to the 'inside' interface(s) based on its IGMP forwarding table.
当IGMPv3代理设备在“内部”接口上接收到IGMP成员身份时，它将创建自己的IGMP代理成员身份状态和自己的IGMP转发表。然后，它在其“外部”接口上创建一个独立的IGMP成员资格报告，报告IP多播组/通道——但接口之间没有IGMP成员资格报告或查询的直接关系或“转发”。NAT设备随后将在“外部”接口上接收IP多播数据包，并基于其IGMP转发表将IP多播数据包转发到“内部”接口。
By performing NAT on IGMPv3 membership reports, the membership reports appear to originate from a single IGMPv3 reporter instead of different reporters. Because IGMPv3 has different types of membership reports differentiating between status (IS_INCLUDE, IS_EXCLUDE) and change indication (e.g., TO_INCLUDE, TO_EXCLUDE), if a NAT were to interleave reports from two or more reporters (joining and leaving the same groups), the NAT would create a sequence of packets that are not compliant with an IGMPv3 reporter [RFC3376]. For this reason, the following requirements are specified:
通过对IGMPv3成员报告执行NAT，成员报告似乎来自单个IGMPv3报告程序，而不是不同的报告程序。由于IGMPv3具有不同类型的成员报告，区分状态（包括、排除）和更改指示（例如，包括、排除），如果NAT要交错来自两个或多个报告者的报告（加入和离开相同的组），NAT将创建不符合IGMPv3报告器[RFC3376]的数据包序列。为此，规定了以下要求：
REQ-12: If a NAT supports IGMPv3, the NAT MUST implement IGMP/MLD Proxying [RFC4605]. Such compliance causes the NAT to aggregate the IGMPv3 membership reports and report only the aggregated information upstream.
REQ-12：如果NAT支持IGMPv3，则NAT必须实现IGMP/MLD代理[RFC4605]。这种合规性导致NAT聚合IGMPv3成员报告，并仅报告聚合的上游信息。
REQ-13: If a NAT supports IGMPv3, the NAT MUST implement Source-Specific Multicast (SSM) for IP [RFC4607] and IGMPv3/MLDv2 for SSM [RFC4604].
REQ-13：如果NAT支持IGMPv3，则NAT必须为IP[RFC4607]实现源特定多播（SSM），为SSM[RFC4604]实现IGMPv3/MLDv2。
Failure to implement IGMP aggregation [RFC4605] will cause undesired temporary black holing of IP multicast traffic. For example, consider two hosts behind the same NAT. If one host is joining a session at the same time another is leaving the session, and the NAT were to merely relay the join and leave upstream, the session will be terminated, and the join and leave announcements would not comply with Section 5 of [RFC3376].
未能实现IGMP聚合[RFC4605]将导致IP多播流量出现不希望出现的临时黑洞。例如，在同一NAT后面考虑两个主机。如果一台主机在另一台主机离开会话的同时加入会话，且NAT仅在上游中继加入和离开，则会话将终止，且加入和离开公告将不符合[RFC3376]第5节的规定。
Any Source Multicast (ASM) uses the IP addresses in the 224/8 through 231/8, and 233/8 through 239/8 range [IANA-ALLOC].
任何源多播（ASM）都使用224/8到231/8以及233/8到239/8范围[IANA-ALLOC]中的IP地址。
When a host both receives an ASM stream and sends traffic into it, using RTP [RFC3550], there is a potential problem if a NAT merely followed the requirements of [RFC4787]. The problem is that RTP uses the source transport address (source IP address and source UDP port) and the Real-time Transport Protocol / RTP Control Protocol (RTP/ RTCP) SSRC value to identify session members. If a session member sees the same SSRC arrive from a different transport address, that session member will perform RTP collision detection (Section 8.2 of [RFC3550]). If a NAT merely followed the requirements of [RFC4787] and timed out a UDP session after 2 minutes of inactivity and RTCP receiver reports are sent less often than every 2 minutes, RTP collision detection would be performed by other session members sharing the same SSRC, complicating diagnostic tools and potentially interfering with jitter buffer algorithms. This situation can occur, for example, with an IP multicast group of approximately 300 members with a normal 50 Kbps audio RTP stream.
当主机同时接收ASM流并使用RTP[RFC3550]向其中发送流量时，如果NAT仅遵循[RFC4787]的要求，则存在潜在问题。问题在于RTP使用源传输地址（源IP地址和源UDP端口）和实时传输协议/RTP控制协议（RTP/RTCP）SSRC值来标识会话成员。如果会话成员看到相同的SSRC从不同的传输地址到达，则该会话成员将执行RTP冲突检测（RFC3550的第8.2节）。如果NAT仅遵循[RFC4787]的要求，并在2分钟不活动后超时UDP会话，并且RTCP接收器报告的发送频率低于每2分钟一次，则共享相同SSRC的其他会话成员将执行RTP冲突检测，使诊断工具复杂化，并可能干扰抖动缓冲算法。这种情况可能发生，例如，当IP多播组大约有300个成员，并且具有正常的50 Kbps音频RTP流时。
Source-Specific Multicast does not need this long timer because application feedback reports are unicast (rather than IP multicast) and identifiers, rather than IP addresses and UDP ports, are used to identify a specific IP multicast receiver (e.g., [RTCPSSM].
源特定多播不需要这个长计时器，因为应用程序反馈报告是单播（而不是IP多播）的，标识符（而不是IP地址和UDP端口）用于标识特定IP多播接收器（例如，[RTCPSM]）。
REQ-14: If a host on the 'inside' interface of a NAT belongs to an Any Source Multicast host group and the host sends a UDP packet to the same group, the NAT SHOULD have a UDP mapping timer of 60 minutes for that mapping.
REQ-14：如果NAT“内部”接口上的主机属于任何源多播主机组，并且该主机向同一组发送UDP数据包，则NAT应具有60分钟的UDP映射计时器，用于该映射。
a: This UDP mapping SHOULD be destroyed when the host leaves that host group. The NAT is aware of this through receipt of an IGMP message from the host.
答：当主机离开该主机组时，应该销毁此UDP映射。NAT通过从主机接收IGMP消息来意识到这一点。
b: If a NAT has exhausted its resources, the NAT MAY time out that mapping before 60 minutes have elapsed, but this is discouraged. Note that even in a situation with resource exhaustion, a NAT is still required to follow the minimum mapping duration of 2 minutes (REQ-5 of [RFC4787]).
b：如果NAT耗尽了它的资源，NAT可能会在60分钟之前超时映射，但这是不鼓励的。注意，即使在资源耗尽的情况下，NAT仍然需要遵循2分钟的最小映射持续时间（RFC4787的REQ-5）。
This section summarizes the requirements.
本节总结了这些要求。
REQ-1: For IP multicast packets that are forwarded to a host(s) on its 'inside' interface(s), a NAT MUST NOT modify the destination IP address or destination port of the packets.
REQ-1：对于转发到主机“内部”接口上的IP多播数据包，NAT不得修改数据包的目标IP地址或目标端口。
REQ-2: A NAT MUST forward IP multicast UDP datagrams from its 'outside' interface to multicast receivers on its 'inside' interface(s).
REQ-2:NAT必须将IP多播UDP数据报从其“外部”接口转发到其“内部”接口上的多播接收器。
REQ-3: A NAT SHOULD forward IP multicast non-UDP protocols (e.g., PGM [RFC3208], RSVP [RFC2205]) from its 'outside' interface to IP multicast receivers on its 'inside' interface(s).
REQ-3:NAT应将IP多播非UDP协议（例如PGM[RFC3208]，RSVP[RFC2205]）从其“外部”接口转发到其“内部”接口上的IP多播接收器。
REQ-4: A NAT MUST modify the source IP address of packets that arrive from an 'inside' interface towards the 'outside' interface so that those packets use the NAT's 'outside' IP address(es).
REQ-4:NAT必须修改从“内部”接口到达“外部”接口的数据包的源IP地址，以便这些数据包使用NAT的“外部”IP地址。
a: If the NAT also performs port translation (that is, it is a NAPT), the NAT MUST also create a mapping to allow responses to that IP multicast packet to be received by the appropriate host. For Any Source Multicast, also see Section 4.3.
答：如果NAT还执行端口转换（即，它是NAPT），则NAT还必须创建映射，以允许相应主机接收对该IP多播数据包的响应。对于任何源多播，也请参见第4.3节。
b: To allow hosts to learn the NAT's 'outside' interface address, the NAT MUST have "Endpoint-Independent Mapping" behavior (REQ-1 of [RFC4787]), no matter if the destination IP address is a unicast address or an IP multicast address.
b：为了允许主机了解NAT的“外部”接口地址，NAT必须具有“端点独立映射”行为（REQ-1 of[RFC4787]），无论目标IP地址是单播地址还是IP多播地址。
c: If the NAT has multiple public IP addresses, the NAT SHOULD have an address pooling behavior of "Paired" (as described in Section 4.1 of [RFC4787]) for its IP multicast mappings as well as for its unicast UDP mappings. This allows a multicast source to discover the NAT's public IP address using a unicast address discovery mechanism (e.g., [ICE]) and communicate that discovered IP address to a multicast receiver.
c：如果NAT有多个公共IP地址，NAT的IP多播映射和单播UDP映射的地址池行为应为“成对”（如[RFC4787]第4.1节所述）。这允许多播源使用单播地址发现机制（例如，[ICE]）发现NAT的公共IP地址，并将发现的IP地址与多播接收器通信。
REQ-5: A NAT MUST forward IP multicast UDP datagrams from its 'inside' interface(s) to its 'outside' interface.
REQ-5:NAT必须将IP多播UDP数据报从其“内部”接口转发到其“外部”接口。
a: NATs that support the above requirement MUST also provide a configuration option to disable this feature. Otherwise, a multihomed network would cause duplicate instances of the multicast data traffic on the public network.
答：支持上述要求的NAT还必须提供一个配置选项来禁用此功能。否则，多址网络将导致公共网络上的多播数据通信的重复实例。
REQ-6: The NAT's default configuration MUST NOT forward administratively scoped IP multicast traffic (239.0.0.0/8) [RFC2365] from its 'inside' interface(s) to its 'outside' interface.
REQ-6:NAT的默认配置不得将管理范围的IP多播流量（239.0.0.0/8）[RFC2365]从其“内部”接口转发到其“外部”接口。
REQ-7: The NAT MUST NOT forward Local Network Control Block (224.0.0/24) [RFC3171] (also known as "link-local multicast") traffic from its 'inside' interface(s) to its 'outside' interface.
REQ-7:NAT不得将本地网络控制块（224.0.0/24）[RFC3171]（也称为“链路本地多播”）流量从其“内部”接口转发到其“外部”接口。
REQ-8: A NAT MAY support IGMPv1 (although IGMPv1 is considered obsolete).
REQ-8:NAT可能支持IGMPv1（尽管IGMPv1被认为已经过时）。
REQ-9: A NAT MUST support IGMPv2.
REQ-9:NAT必须支持IGMPv2。
REQ-10: A NAT SHOULD support IGMPv3.
REQ-10:NAT应支持IGMPv3。
REQ-11: If a NAT supports IGMPv1 and/or IGMPv2 (but not IGMPv3), the NAT MAY simply receive IGMP membership reports on the 'inside' interface, NAT them, and relay the IGMP membership report, and do the same function in the opposite direction to the IGMP listeners. That is, the NAT does not need to do any aggregation of IGMP messages.
REQ-11：如果NAT支持IGMPv1和/或IGMPv2（但不支持IGMPv3），则NAT可以简单地在“内部”接口上接收IGMP成员报告，对其进行NAT，并中继IGMP成员报告，并以与IGMP侦听器相反的方向执行相同的功能。也就是说，NAT不需要对IGMP消息进行任何聚合。
a: If a NAT relays IGMPv1 or IGMPv2 messages in this manner, it MUST NOT decrement the TTL of the IGMP messages, as they are already sent with TTL=1.
答：如果NAT以这种方式中继IGMPv1或IGMPv2消息，则它不得减少IGMP消息的TTL，因为它们已以TTL=1的方式发送。
b: However, it is RECOMMENDED that such a NAT implement IGMP/MLD Proxying [RFC4605], because IGMP aggregation provides a useful optimization.
b：但是，建议这样的NAT实现IGMP/MLD代理[RFC4605]，因为IGMP聚合提供了有用的优化。
REQ-12: If a NAT supports IGMPv3, the NAT MUST implement IGMP/MLD Proxying [RFC4605]. Such compliance causes the NAT to aggregate the IGMPv3 membership reports and report only the aggregated information upstream.
REQ-12：如果NAT支持IGMPv3，则NAT必须实现IGMP/MLD代理[RFC4605]。这种合规性导致NAT聚合IGMPv3成员报告，并仅报告聚合的上游信息。
REQ-13: If a NAT supports IGMPv3, the NAT MUST implement Source-Specific Multicast (SSM) for IP [RFC4607] and IGMPv3/MLDv2 for SSM [RFC4604].
REQ-13：如果NAT支持IGMPv3，则NAT必须为IP[RFC4607]实现源特定多播（SSM），为SSM[RFC4604]实现IGMPv3/MLDv2。
REQ-14: If a host on the 'inside' interface of a NAT belongs to an Any Source Multicast host group and the host sends a UDP packet to the same group, the NAT SHOULD have a UDP mapping timer of 60 minutes for that mapping.
REQ-14：如果NAT“内部”接口上的主机属于任何源多播主机组，并且该主机向同一组发送UDP数据包，则NAT应具有60分钟的UDP映射计时器，用于该映射。
a: This UDP mapping SHOULD be destroyed when the host leaves that host group. The NAT is aware of this through receipt of an IGMP message from the host.
答：当主机离开该主机组时，应该销毁此UDP映射。NAT通过从主机接收IGMP消息来意识到这一点。
b: If a NAT has exhausted its resources, the NAT MAY time out that mapping before 60 minutes have elapsed, but this is discouraged. Note that even in a situation with resource exhaustion, a NAT is still required to follow the minimum mapping duration of 2 minutes (REQ-5 of [RFC4787]).
b：如果NAT耗尽了它的资源，NAT可能会在60分钟之前超时映射，但这是不鼓励的。注意，即使在资源耗尽的情况下，NAT仍然需要遵循2分钟的最小映射持续时间（RFC4787的REQ-5）。
The Security Considerations sections of IGMPv3 [RFC3376] and IGMP Proxying [RFC4605] apply to a device complying with this document.
IGMPv3[RFC3376]和IGMP代理[RFC4605]的安全注意事项部分适用于符合本文件要求的设备。
When a host is using RTP and participating in an Any Source Multicast session, the host's periodic RTCP receiver reports cause the NAT to create a mapping. When the group size is less than approximately 300, the RTCP reports are sent frequently enough that a NAT's mapping will always be kept open. When the group size is larger than approximately 300, the RTCP reports are sent less frequently. The recommendation in Section 4.3 causes the NAT mapping to be kept open for the duration of the host's participation in that IP multicast session no matter the size of the multicast host or periodicity of the host's RTCP transmissions.
当主机使用RTP并参与任意源多播会话时，主机的定期RTCP接收器报告会导致NAT创建映射。当组大小小于大约300时，RTCP报告的发送频率足以使NAT的映射始终保持打开状态。当组大小大于约300时，发送RTCP报告的频率会降低。第4.3节中的建议使NAT映射在主机参与该IP多播会话期间保持打开状态，无论多播主机的大小或主机RTCP传输的周期如何。
Thanks to Jari Arkko, Yiqun Cai, Stephen Casner, Remi Denis-Courmont, Lars Eggert, Gorry Fairhurst, Alfred Hines, Prashant Jhingran, Bharat Joshi, Francois Le Faucheur, Albert Manfredi, Marcus Maranhao, Bryan McLaughlin, Chris Newman, Tim Polk, Pekka Savola, Mark Townsley, Magnus Westerlund, and Stig Venaas for their assistance in writing this document.
感谢贾里·阿尔科、蔡依群、斯蒂芬·卡斯纳、雷米·丹尼斯·库尔蒙、拉尔斯·艾格特、戈里·费尔赫斯特、阿尔弗雷德·海因斯、普拉尚特·金格伦、巴拉特·乔希、弗朗索瓦·勒·福彻、阿尔伯特·曼弗雷迪、马库斯·马兰豪、布莱恩·麦克劳林、克里斯·纽曼、蒂姆·波尔克、佩卡·萨沃拉、马克·汤斯利、马格纳斯·韦斯特隆德、，以及Stig Venaas，感谢他们协助撰写本文件。
[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月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236]Fenner，W.，“互联网组管理协议，第2版”，RFC 2236，1997年11月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[RFC2365]Meyer，D.，“管理范围的IP多播”，BCP 23，RFC 2365，1998年7月。
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 3171, August 2001.
[RFC3171]Albanna，Z.，Almeroth，K.，Meyer，D.，和M.Schipper，“IPv4多播地址分配的IANA指南”，BCP 51，RFC 3171，2001年8月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.
[RFC4604]Holbrook，H.，Cain，B.，和B.Haberman，“为源特定多播使用Internet组管理协议版本3（IGMPv3）和多播侦听器发现协议版本2（MLDv2）”，RFC 4604，2006年8月。
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC4605]Fenner，B.，He，H.，Haberman，B.，和H.Sandick，“基于Internet组管理协议（IGMP）/多播侦听器发现（MLD）的多播转发（“IGMP/MLD代理”）”，RFC 4605，2006年8月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC4607，2006年8月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]Audet，F.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[IANA-ALLOC] Internet Assigned Numbers Authority, "Internet Multicast Addresses", <http://www.iana.org/assignments/multicast-addresses>.
[IANA-ALOC]互联网分配号码管理局，“互联网多播地址”<http://www.iana.org/assignments/multicast-addresses>.
[ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, October 2007.
[ICE]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，正在进行的工作，2007年10月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，B.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, L., Tweedly, A., Bhaskar, N., Edmonstone, R., Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport Protocol Specification", RFC 3208, December 2001.
[RFC3208]Speakman，T.，Crowcroft，J.，Gemmell，J.，Farinaci，D.，Lin，S.，Leshchiner，D.，Luby，M.，Montgomery，T.，Rizzo，L.，Tweedy，A.，Bhaskar，N.，Edmonstone，R.，Sumanasekera，R.，和L.Vicisano，“PGM可靠传输协议规范”，RFC 32082001年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月。
[RTCPSSM] Ott, J., Chesterfield, J., and E. Schooler, "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback", Work in Progress, January 2008.
[RTCPSM]Ott，J.，Chesterfield，J.，和E.Schooler，“具有单播反馈的单源多播会话的RTCP扩展”，正在进行的工作，2008年1月。
SSM requires listeners to know the SSM channel (S,G), which is comprised of the IP source address (S) and the IP multicast group (G). An SSM source needs to communicate its IP address in its SSM session establishment message (e.g., in its Session Description Protocol (SDP) [RFC4566]). When the SSM sender is behind a NAT and the SSM receiver(s) are on the other side of that NAT, the SSM sender will need to determine its IP source address relevant to the SSM receivers; generally, this will be the 'outside' IP address of the NAT. This 'outside' address needs to be included in the SSM session establishment message (e.g., SDP) so that listeners on the 'outside' of the NAT can receive the SSM channel.
SSM要求侦听器知道SSM通道（S，G），该通道由IP源地址和IP多播组（G）组成。SSM源需要在其SSM会话建立消息（例如，在其会话描述协议（SDP）[RFC4566]中）中传输其IP地址。当SSM发送方位于NAT后面且SSM接收方位于该NAT的另一侧时，SSM发送方将需要确定其与SSM接收方相关的IP源地址；通常，这将是NAT的“外部”IP地址。此“外部”地址需要包含在SSM会话建立消息（例如SDP）中，以便NAT“外部”的侦听器可以接收SSM信道。
If there are SSM listeners on both the 'outside' and 'inside' of the NAT, it may be valuable to consider using ICE [ICE] in the session advertisement; the full scope of the interaction between SSM and ICE is beyond the scope of this document.
如果在NAT的“外部”和“内部”上都有SSM侦听器，那么在会话广告中考虑使用ICE[ICE ]可能是有价值的；SSM和ICE之间的整个交互范围超出了本文件的范围。
If multiple SSM sources on the 'inside' of a NAT choose the same multicast group address, those sources are uniquely identifiable because their IP addresses are unique. However, if their multicast traffic is NATed and sent on the NAT's public interface, the traffic from those individual sources is no longer uniquely identifiable. This will cause problems for multicast receivers, which will see an intermixing of traffic from those sources. Resolution of this issue is left for future study. In the meantime, applications that source SSM multicast traffic are encouraged to allow the user to modify the multicast SSM address so that users can avoid this problem if that application is placed behind a NAT.
如果NAT“内部”的多个SSM源选择相同的多播组地址，则这些源是唯一可识别的，因为它们的IP地址是唯一的。但是，如果它们的多播通信量是NAT的公共接口上发送的，则来自这些单独来源的通信量不再是唯一可识别的。这将给多播接收器带来问题，多播接收器将看到来自这些源的流量混合。这个问题的解决留待将来研究。同时，鼓励源SSM多播流量的应用程序允许用户修改多播SSM地址，以便如果该应用程序位于NAT后面，用户可以避免此问题。
A multicast source that wants its traffic to not traverse a router (e.g., leave a home network) may find it useful to send traffic with IP TTL=1. Both ASM and SSM sources may find this useful.
如果多播源希望其流量不穿过路由器（例如，离开家庭网络），则可能会发现使用IP TTL=1发送流量是有用的。ASM和SSM源都会发现这很有用。
As many NATs use the same private address space (e.g., 192.168.0.0/16, [RFC1918]), RTP stacks are encouraged to generate CNAMEs properly (see end of Section 6.5.1 of [RFC3550].)
由于许多NAT使用相同的专用地址空间（例如192.168.0.0/16，[RFC1918]），因此鼓励RTP堆栈正确生成CNAME（见[RFC3550]第6.5.1节末尾）
Authors' Addresses
作者地址
Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
Dan Wing Cisco Systems，Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
EMail: dwing@cisco.com
EMail: dwing@cisco.com
Toerless Eckert Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市西塔斯曼大道170号无托勒埃克特思科系统有限公司，邮编95134
EMail: eckert@cisco.com
EMail: eckert@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.