[要約] RFC 5135は、NATおよびNAPTに対するIPマルチキャストの要件を定義しています。このRFCの目的は、NATおよびNAPTがIPマルチキャストトラフィックを適切に処理できるようにすることです。
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
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.
このドキュメントで概説されている原則のほとんどは、Protocol Independent Multicast -Sparse Mode（PIM -SM）などのIGMP以外のプロトコルを使用する場合、またはこれらのケースの明示的な考慮事項など、複数の「内部」インターフェイスの間で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に送信します。これにより、以前に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は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：Nating 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デバイスが追加されます。一般に、このデバイスはルーティングとNAT機能を実行して、DSL/ケーブルモデムに向けて単一のホストのように見えるようにします。
+----+ +-------------+
|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 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は、図1に示すように、ホストが使用するプロトコルです。図2のNATデバイスについては、DSL/ケーブルモデムに向けてIPマルチキャストサービスの単一ホストのように見え、IPマルチキャストトラフィックを転送する写真の複数のホストから、そして複数のホストに、いわゆる「IGMPプロキシ」[RFC4605]を実行する必要がありますが、NATを実行するコンテキスト内でも。NATは[RFC4605]でカバーされていません。IGMPプロキシにNATを追加すると、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アドレスを備えたパケットには、NATによって宛先IPアドレスや宛先ポートが変更されていません。ただし、パケットがNATの「内部」インターフェイスからNATの「外側」インターフェイスに移行すると、ソースIPアドレス（およびSource 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マルチキャストデータトラフィックがネートになり、WANルーターに直接接続されたホストから調達されているように見えるため、すべての非標準のPIM-SMが排除されます。[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：「内部」インターフェイスでホストに転送される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））メッセージ。このようなアプリケーションメッセージの変更は、ベストプラクティスとは見なされません。さらに、NATED Multi-Homedネットワークは、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マルチキャスト非DONPプロトコルを転送する必要があります（例えば、実用的な一般マルチキャスト（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は、「内側」インターフェイスから「外部」インターフェイスに向かって到着するパケットのソースIPアドレスを変更する必要があり、それらのパケットがNATの「外側」IPアドレス（ES）を使用するようにする必要があります。
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.
A：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には「エンドポイント非依存マッピング」動作（[RFC4787]のReq-1）を持つ必要があります。マルチキャストアドレス。
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.
A：上記の要件をサポートする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アドレスを使用してアプリケーションによって達成されます。同様に、Link-Local Multicastトラフィックはローカルネットワークから外れているとは思われません。
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]（「Link-Local Multicast」とも呼ばれる）トラフィックを「内部」インターフェイスから「外側」インターフェースに転送してはなりません。。
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メンバーシップレポートを受け取ることができます。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.
A：NATがこの方法でIgMPv1またはIgmpv2メッセージをリレーする場合、IgMPメッセージのTTLを既にTTL = 1で送信しているため、IGMPメッセージのTTLを減少させてはなりません。
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: 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.
IGMPV3メンバーシップレポートでNATを実行することにより、メンバーシップレポートは、異なる記者ではなく単一のIGMPV3レポーターに由来するように見えます。IGMPV3には、ステータス（is_include、is_exclude）と変更表示（例えば、to_include、to_exclude）を区別するさまざまなタイプのメンバーシップレポートがあるため、NATが2人以上の記者（同じグループに参加して出て行く）からのレポートを繰り返した場合、NATはIGMPV3レポーター[RFC3376]に準拠していないパケットのシーケンスを作成します。このため、次の要件が指定されています。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の背後にある2つのホストを検討してください。あるホストがセッションに同時に参加している場合、別のホストがセッションを去り、NATは単に結合を中継して上流を離れることになった場合、セッションは終了し、結合と離れるアナウンスは[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）は、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分間の不活動とRTCP受信レポートが2分ごとに送信される頻度が低い後にUDPセッションのタイミングを出した場合、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マルチキャストではなく）であり、IPアドレスやUDPポートではなく識別子が特定の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.
A：この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マルチキャスト受信機へのIPマルチキャストNONUDPプロトコル（例：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は、「内側」インターフェイスから「外部」インターフェイスに向かって到着するパケットのソースIPアドレスを変更する必要があり、それらのパケットがNATの「外側」IPアドレス（ES）を使用するようにする必要があります。
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.
A：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には「エンドポイント非依存マッピング」動作（[RFC4787]のReq-1）を持つ必要があります。マルチキャストアドレス。
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.
A：上記の要件をサポートする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]（「Link-Local Multicast」とも呼ばれる）トラフィックを「内部」インターフェイスから「外側」インターフェースに転送してはなりません。。
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メンバーシップレポートを受け取ることができます。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.
A：NATがこの方法でIgMPv1またはIgmpv2メッセージをリレーする場合、IgMPメッセージのTTLを既にTTL = 1で送信しているため、IGMPメッセージのTTLを減少させてはなりません。
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]を実装する必要があります。このようなコンプライアンスにより、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.
A：この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の推奨により、マルチキャストホストのサイズやホストのRTCP送信の周期性に関係なく、ホストがそのIPマルチキャストセッションに参加する期間、NATマッピングを開いたままにします。
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.
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、Bryan Mclaughlin、Chris frymanPekka Savola、Mark Townsley、Magnus Westerlund、および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 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] Holbrook、H.、Cain、B。、およびB. Haberman、「インターネットグループ管理プロトコルバージョン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] Fenner、B.、He、H.、Haberman、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] Holbrook、H。およびB. Cain、「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. Jennings、「Unicast 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-Alloc]インターネットは、「Internet Multicastアドレス」、<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。、「Interactive Connectivity Indecivity Indecivity（ICE）：ネットワークアドレス翻訳者のプロトコル（NAT）オファー/回答プロトコルのトラバーサル」、2007年10月、進行中の作業。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、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.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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 2205、1997年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.、Farinacci、D.、Lin、S.、Leshchiner、D.、Luby、M.、Montgomery、T.、Rizzo、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] Handley、M.、Jacobson、V。、およびC. Perkins、「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] Fenner、B.、Handley、M.、Holbrook、H.、およびI. Kouvelas、 "Protocol Independent Multicast -Sparse Mode（PIM -SM）：Protocol Specification（改訂）、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] 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は、リスナーがIPソースアドレスとIPマルチキャストグループ（G）で構成されるSSMチャネル（S、G）を知ることを要求します。SSMソースは、SSMセッションの確立メッセージでIPアドレスを通信する必要があります（たとえば、セッション説明プロトコル（SDP）[RFC4566]）。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.
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の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 West Tasman Drive San Jose、CA 95134 USA
EMail: dwing@cisco.com
Toerless Eckert Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
Toerless Eckert Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134 USA
EMail: eckert@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。