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)
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.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
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.
この文書では、ネットワークアドレス変換（NAT）と任意の送信元IPマルチキャストまたはソース固有IPマルチキャストをサポートするネットワークアドレスポート翻訳（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
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.
この文書は、インターネットグループ管理プロトコル（IGMP）プロキシルーティングやNATを実行するデバイスでのIPマルチキャストグループアドレスにNATを適用せずに任意のソースのマルチキャストおよびソース固有のマルチキャストの正しい操作を可能にすることを目的と要件をターゲットにしています。機能のこのプロファイルは、住宅のアクセスルータ、小規模ブランチルータ、または同様の展開に期待がベストプラクティスです。
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の「内部」インタフェース（S）上のホストは、ローカルインタフェースにIGMPメッセージを送信することによって、IPマルチキャストフローを受信することに関心を示しています。 IPマルチキャスト対応NATは、IGMPメッセージ（IGMPv1レポート[RFC1112]、IGMPv2の[RFC2236]、IGMPv3の[RFC3376]）は、おそらくそのIGMPメッセージにいくつかの機能を実行することがわかり、その上流のルータに転送します。これは、以前にそのIPマルチキャストトラフィック用IGMPメッセージを送っていたそのホスト（複数可）と、それらの「内部」セグメント（複数可）に転送NATにそのIPマルチキャストトラフィックを送信するアップストリームルータを引き起こします。
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を転送しません。 NATは、IPv6で必要と判断されていないため、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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は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.
「内側」という用語は、IPマルチキャストトラフィックをソースまたは受信を希望するホストを含むNATインターフェイス（複数可）を意味します。用語「外側」は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を使用しない場合、ホストは、このような構成では、インターネットに接続されることがあります。
+-------------+
+------+ | DSL modem | +------------+
| host +---+ or +-//-+ WAN Router |
+------+ | cable modem | +------------+
+-------------+
Figure 1: Network without NATing IGMP Proxy
図1：ネットワークのNAT変換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.
図1に示すように、代わりに単一のホストの場合、潜在的に複数のホストを有する1つまたは複数のLANがDSLまたはケーブルモデムのサービス終了の同じ種類と、接続される、図2に示すように、NATデバイスが追加されます。このデバイスは、一般的に、それはDSL /ケーブルモデムへの単一のホストのように見えないようなルーティングやNAT機能を実行します。
+----+ +-------------+
|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：NAT変換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 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は、図2のNATデバイスは、DSL /ケーブルモデムに向かってIPマルチキャストサービスのための単一のホストに見えるようにし、IPマルチキャストトラフィックを転送するために、図1に示すようなホストによって使用されるプロトコルであります画像内から、複数のホストに、それはそう「IGMPプロキシ」[RFC4605]と呼ばれる実行する必要がある - もNATを実行するのコンテキスト内。 NATは、[RFC4605]でカバーされていません。 RFC 4605で定義されたIGMPプロキシにNATを追加すると、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アドレス（およびNAPTといくつかのケースでは、ソースUDPポートは、）変更された - の動作に似これらの同じインターフェイスを横切ってユニキャストパケット。
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.
IGMPのプロキシにNATを追加すると、次の項で説明するように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マルチキャストデータトラフィックは、このようにすべての非標準のPIM-SMを排除し、それが直接WANルータに接続されたホストから発信されているように見えますようNAT処理されます[RFC4605]のセクション3.2に記載の懸念/構成。
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：その「内部」インターフェイス（S）上のホスト（複数可）に転送されている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変換マルチホームネットワークは、その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は、「内部」インタフェース（S）上のマルチキャスト受信機にその「外部」インターフェイスから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マルチキャストレシーバーへの '外' のインターフェースから「内部」インタフェース（S）。
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.
以下の要件は[RFC4787]に記載されているように、ユニキャストパケットの通常のNAT動作であり、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は、これらのパケットはNATの「外部」IPアドレスを使用するように「外部」インターフェイスに向かって「内部」インタフェースから到着するパケットの送信元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.
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の[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は、「外部」インターフェイスへの「内部」インタフェース（S）から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.
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は、帯域幅に制約のアクセスリンクに隣接して配置されている、IPマルチキャスト送信者が彼らのフローがアクセスリンク上の帯域幅を消費していないNATの背後にある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：（IGMPv1レポートが廃止されたと考えられているが）NATに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は、単に「内部」インターフェイス、NATそれらの上にIGMPメンバーシップレポートを受信して、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.
b: However, it is RECOMMENDED that such a NAT implement IGMP/MLD Proxying [RFC4605], because IGMP aggregation provides a useful optimization.
B：しかし、IGMP凝集有用な最適化を提供するので、このようなNATは、IGMP / MLDプロキシ[RFC4605]を実装することが推奨されます。
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転送テーブルを作成します。その後、IPマルチキャストグループ/チャンネルを報告し、その「外」のインターフェイス上の独立したIGMPメンバーシップレポートを作成します - しかし、インタフェースで、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が、ステータス（IS_INCLUDE、IS_EXCLUDE）と変更指示（例えば、TO_INCLUDE、TO_EXCLUDE）を区別メンバーシップレポートの種類を持っているので、NATは、NATを（参加し、同じグループを残す）2人の以上の記者からのレポートをインターリーブした場合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]を実装しなければなりません。このようなコンプライアンスは、IGMPv3メンバシップレポートを集約し、上流のみ集計情報を報告するようにNATを引き起こします。
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は、SSM [RFC4604]のためのIP [RFC4607]およびIGMPv3 / MLDv2のためにソース固有のマルチキャスト（SSM）を実装しなければなりません。
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の背後にある二つのホストを考えます。 1つのホストが別のセッションを残していると同時に、セッションに参加して、NATは単に参加し、上流のままを中継した場合、セッションは終了され、参加したままの発表は、のセクション5に準拠しています[ RFC3376]。
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）は、8分の231を介して8分の224でIPアドレスを使用し、8分の239範囲[IANA-ALLOC]スルー8分の233。
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分ごとより送信され、RTP衝突検出は、同じSSRCを共有する他のセッションメンバーによって実行される場合診断ツールを複雑にし、潜在的にジッタバッファアルゴリズムを妨害します。この状況は、通常50 KbpsのオーディオRTPストリームと約300のメンバーのIPマルチキャストグループと、例えば、発生する可能性があります。
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アドレスとUDPポートが、（特定のIPマルチキャスト受信機を識別するために使用され、識別子（むしろIPマルチキャストよりも）よりもむしろ、ユニキャストであるので、ソース固有マルチキャストは、この長いタイマーを必要とせず、例えば、[RTCPSSM]。
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.
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分（REQ-5の[RFC4787]）の最小マッピング期間に従うことが必要であることに留意されたいです。
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：その「内部」インターフェイス（S）上のホスト（複数可）に転送されている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は、「内部」インタフェース（S）上のマルチキャスト受信機にその「外部」インターフェイスから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は、 '内部' インタフェース（S）上のIPマルチキャスト受信機への '外部' インターフェイスからIPマルチキャスト非UDPプロトコル（例えば、PGM [RFC3208]、RSVP [RFC2205]）を転送すべきです。
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は、これらのパケットはNATの「外部」IPアドレスを使用するように「外部」インターフェイスに向かって「内部」インタフェースから到着するパケットの送信元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.
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の[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は、「外部」インターフェイスへの「内部」インタフェース（S）から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.
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：（IGMPv1レポートが廃止されたと考えられているが）NATに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は、単に「内部」インターフェイス、NATそれらの上にIGMPメンバーシップレポートを受信して、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.
b: However, it is RECOMMENDED that such a NAT implement IGMP/MLD Proxying [RFC4605], because IGMP aggregation provides a useful optimization.
B：しかし、IGMP凝集有用な最適化を提供するので、このようなNATは、IGMP / MLDプロキシ[RFC4605]を実装することが推奨されます。
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]を実装しなければなりません。このようなコンプライアンスは、IGMPv3メンバシップレポートを集約し、上流のみ集計情報を報告するようにNATを引き起こします。
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は、SSM [RFC4604]のためのIP [RFC4607]およびIGMPv3 / MLDv2のためにソース固有のマルチキャスト（SSM）を実装しなければなりません。
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.
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分（REQ-5の[RFC4787]）の最小マッピング期間に従うことが必要であることに留意されたいです。
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.
ヤリArkko、Yiqunカイ、スティーブンCasner、レミデニス・Courmont、ラースEggertの、Gorry Fairhurst、アルフレッド・ハインズ、のPrashant Jhingran、バーラト・ジョシ、フランソワ・ルFaucheur、アルバート・マンフレディ、マーカスマラニャン、ブライアン・マクラフリン、クリス・ニューマン、ティムポークのおかげで、この文書を書くことに彼らの支援のためのペッカSavola、マークTownsley、マグヌスウェスター、およびスティグVenaas。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236]フェナー、W.、 "インターネットグループ管理プロトコル、バージョン2"、RFC 2236、1997年11月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[RFC2365]マイヤー、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.、マイヤー、D.、およびM.シッパー、 "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]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、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.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年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]ホルブルック、H.、カイン、B.、およびB.ハーバーマン、 "ソース固有マルチキャストのためにインターネットグループ管理プロトコルバージョン3（IGMPv3の）およびマルチキャストリスナ発見プロトコルバージョン2（MLDv2の）の使用"、RFC 4604、8月2006。
[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]フェナー、B.、彼、H.、ハーバーマン、B.、およびH. Sandick、 "インターネットグループ管理プロトコル（IGMP）/マルチキャストリスナ発見（MLD）ベースマルチキャスト転送（" IGMP / MLDプロキシ」） 」、RFC 4605、2006年8月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]ホルブルック、H.、およびB.カイン、 "IPのためのソース固有のマルチキャスト"、RFC 4607、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.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、BCP 127、RFC 4787、2007年1月。
[IANA-ALLOC] Internet Assigned Numbers Authority, "Internet Multicast Addresses", <http://www.iana.org/assignments/multicast-addresses>.
[IANA-ALLOC]インターネット割り当て番号機関、 "インターネットマルチキャストアドレス"、<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]ローゼンバーグ、J.、「インタラクティブ接続確立（ICE）：オファー/回答プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための議定書」、進歩、2007年10月の作業。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]デアリング、S.、STD 5、RFC 1112 "IPマルチキャスティングのためのホスト拡大"、1989年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.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、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]ブレーデン、B.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、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]スピークマン、T.、クロウクロフト、J.、Gemmell、J.、ファリナッチ、D.、リン、S.、Leshchiner、D.、ルビー、M.、モンゴメリー、T.、リゾー、L.、Tweedly、 A.、Bhaskar、N.、Edmonstone、R.、Sumanasekera、R.、およびL. Vicisano、 "PGM信頼できるトランスポートプロトコル仕様"、RFC 3208、2001年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、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]フェナー、B.、ハンドリー、M.、ホルブルック、H.、およびI. Kouvelas、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂）"、RFC 4601、2006年8月。
[RTCPSSM] Ott, J., Chesterfield, J., and E. Schooler, "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback", Work in Progress, January 2008.
[RTCPSSM]オット、J.、チェスターフィールド、J.、およびE.学生、「ユニキャストフィードバック付きシングルソースのマルチキャストセッションのRTCP拡張機能」、進歩、2008年1月での作業。
Appendix A. Application Considerations
付録A.アプリケーションへの配慮
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は、IP送信元アドレス（S）とIPマルチキャストグループ（G）から構成されているSSMチャネル（S、G）を、知っているリスナーを必要とします。 SSM源は、そのSSMセッション確立メッセージ（例えば、そのセッション記述プロトコル（SDP）に[RFC4566]）にそのIPアドレスを通信する必要があります。 SSMの送信者がNATの背後にあるとSSMの受信機（単数または複数）がそのNATの反対側にある場合に、SSMの送信者はSSMの受信機に関連するそのIPソースアドレスを決定する必要があります。一般的に、これはNATの「外のIPアドレスになります。この「外部」アドレスは、NATの「外側」にリスナーがSSMチャネルを受信できるようにSSMセッション確立メッセージ（例えば、SDP）に含まれる必要があります。
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.
SSMリスナーが「外」とNATの「内側」の両方に存在する場合、セッション広告で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変換され、NATのパブリックインターフェイス上で送信された場合は、それらの個々のソースからのトラフィックは、もはや一意に識別されません。これは、これらのソースからのトラフィックのインターミキシングが表示されますマルチキャストレシーバに問題が発生します。この問題の解決は今後の研究のために残されています。一方で、そのソースSSMマルチキャストトラフィックアプリケーションは、そのアプリケーションがNATの背後に配置されている場合、ユーザーがこの問題を回避することができるように、ユーザは、マルチキャストSSMアドレスを変更できるようにすることをお勧めします。
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スタックは（[RFC3550]の第6.5.1項の末尾を参照してください。）適切のCNAMEを生成することが奨励されています
Authors' Addresses
著者のアドレス
Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
ダン・ウィングシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134 USA
EMail: dwing@cisco.com
メールアドレス：dwing@cisco.com
Toerless Eckert Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
Toerlessエッカートシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134 USA
EMail: eckert@cisco.com
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。