RFC5135 日本語訳
5135 IP Multicast Requirements for a Network Address Translator (NAT)and a Network Address Port Translator (NAPT). D. Wing, T. Eckert. February 2008. (Format: TXT=36528 bytes) (Also BCP0135) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Wing Request for Comments: 5135 T. Eckert BCP: 135 Cisco Systems, Inc. Category: Best Current Practice February 2008
コメントを求めるワーキンググループD.翼の要求をネットワークでつないでください: 5135T.エッケルトBCP: 135シスコシステムズInc.カテゴリ: 最も良い現在の練習2008年2月
IP Multicast Requirements for a Network Address Translator (NAT)
and a Network Address Port Translator (NAPT)
ネットワークアドレス変換機構(NAT)とネットワーク・アドレスポート翻訳者のためのIPマルチキャスト要件(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.
このドキュメントはAny SourceがIP MulticastかSource特有のIP MulticastであるとサポートするNetwork Address Translator(NAT)とNetwork Address Port Translator(NAPT)のためのaのための要件を指定します。 このドキュメントの要件を固く守る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. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語は本書では.2 3を使用しました。 バックグラウンド. . . . . . . . . . . . . . . . . . . . . . . . . . 3 4。 要件. . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1。 NATing IPマルチキャストデータ・パケット. . . . . . . . . . . . . 5 4.1.1。 マルチキャストデータ・パケット. . . . . . . . . . . 5 4.1.2を受け取ります。 マルチキャストデータ・パケット. . . . . . . . . . . . 5 4.2を送ります。 IGMPバージョンサポート. . . . . . . . . . . . . . . . . . . 6 4.2.1。 IGMPv1かIGMPv2. . . . . . . . . . . . . . . . . . . 7 4.2.2。 IGMPv3. . . . . . . . . . . . . . . . . . . . . . . . 7 4.3。 どんなソースマルチキャスト送信機. . . . . . . . . . . . 8 5。 要件概要. . . . . . . . . . . . . . . . . . . . . 9 6 セキュリティ問題. . . . . . . . . . . . . . . . . . . 11 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 12 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1。 引用規格. . . . . . . . . . . . . . . . . . . 12 8.2。 有益な参照. . . . . . . . . . . . . . . . . . 13付録A.アプリケーション問題. . . . . . . . . . . . . 14
Wing & Eckert Best Current Practice [Page 1] RFC 5135 NAT IP Multicast Requirements February 2008
翼とエッケルト最も良い現在の習慣[1ページ]RFC5135NAT IPマルチキャスト要件2008年2月
1. Introduction
1. 序論
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マルチキャストアプリケーションがNATsの上でよく機能するように、マルチキャストUDPはユニキャストUDPと同じくらいシームレスに働かなければなりません。 しかしながら、NATsには、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.
このドキュメントはデバイス実行しているインターネットGroup Managementプロトコル(IGMP)プロキシルーティングとNATとIPマルチキャストグループアドレスにNATを適用しないでAny Source MulticastとSource特有のMulticastの正しい操作を可能にすることを意図する要件を狙います。 機能性のこのプロフィールは住宅のアクセスルータ、小枝ルータ、または同様の展開のための予想された最も良い習慣です。
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.
また、このドキュメントの範囲の外に複数の“inside"インタフェースの間でNATを実行しますが、まばらなMode(PIM-SM)、またはいつがこれらのケースのために明白な考慮を実行して、プロトコル無党派MulticastなどのIGMP以外のプロトコルを使用するのがあるとき、本書では概説された原則の大部分は適用されます。
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が流れるとき機能するデバイスの働きについて説明して、また、どちらの方向('外部'への'inside'、または'inside'への'外部')にもIPマルチキャストトラフィックを送ります。 これは、ともにマルチキャストトラフィックとソースマルチキャストトラフィックに受信するためにホスト'inside'にNATを許容します。 NATの'inside'インタフェースのホストはIGMPメッセージを彼らの局所界面に送ることによってIPマルチキャスト流動を受けることへの彼らの関心を示します。 できるIPマルチキャストNATは、そのIGMPメッセージ(IGMPv1[RFC1112]、IGMPv2[RFC2236]、IGMPv3[RFC3376])を見て、ことによるとそのIGMPメッセージにいくつかの機能を実行して、上流のルータにそれを送るでしょう。 これで、上流のルータはそのIPマルチキャストトラフィックをNATに送ります。(それは、以前にそのIPマルチキャストトラフィックへのメッセージをIGMPに送ったホストがいるそれらの'inside'セグメントにそれを送ります)。
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 Proxyデバイスは本書ではPIM-SMを進めません。 NATがIPv6によって必要であることは考えられないので、範囲の外にIPv6があります。
This document is a companion document to "NAT Behavioral Requirements for Unicast UDP" [RFC4787].
このドキュメントは「ユニキャストUDPのためのNATの行動の要件」[RFC4787]への仲間ドキュメントです。
2. Terminology Used in This Document
2. 本書では使用される用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Wing & Eckert Best Current Practice [Page 2] RFC 5135 NAT IP Multicast Requirements February 2008
翼とエッケルト最も良い現在の習慣[2ページ]RFC5135NAT IPマルチキャスト要件2008年2月
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」がともにネットワークでつなぐのに申し込む用語で、ポートを翻訳しないNATと同様に翻訳者(NAPT)を扱って、移植してください。
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.
'inside'という用語はNATのソースに願っているホストを含むか、またはIPマルチキャストトラフィックを受けるインタフェースについて言及します。 '外'という用語はNATが会員資格メッセージをIGMPに転送して、NATが'inside'インタフェースでホストから発するIPマルチキャストトラフィックを発送するインタフェースについて言及します。
3. Background
3. バックグラウンド
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 | +------------+
+-------------+
+-------------+ +------+ | DSLモデム| +------------+ | ホスト+---+か+//-+の青白いルータ| +------+ | ケーブルモデム| +------------+ +-------------+
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.
潜在的に複数のホストがいるLANがより多くの図1、1で見せられる独身のホストの代わりにDSLかケーブルモデムにおける同じタイプのサービス終了に関連づけられることであるなら、NATデバイスは図2に示されるように加えられます。 このデバイス、一般に、ルーティングを実行してください。そうすれば、NATが機能するので、それはDSL/ケーブルモデムに向かって独身のホストに似ています。
+----+ +-------------+
|host+---+ +---------+ | +-----------+
+----+ | |Multicast| | | DSL modem | +------------+
| | Proxy | +--+ or +-//-+ WAN Router |
'inside' | +---------+ | |cable modem| +------------+
interfaces | | +-----------+
| +------+ |
+----+ | | NAT | | 'outside'
|host+---+ +------+ | interfaces
+----+ +-------------+
IGMP Proxy NAT Device
+----+ +-------------+ |ホスト+---+ +---------+ | +-----------+ +----+ | |マルチキャスト| | | DSLモデム| +------------+ | | プロキシ| +--+か+//-+の青白いルータ| 'inside'| +---------+ | |ケーブルモデム| +------------+ インタフェース| | +-----------+ | +------+ | +----+ | | NAT| | '外'|ホスト+---+ +------+ | インタフェース+----+ +-------------+ IGMPプロキシNATデバイス
Figure 2: Network with NATing IGMP Proxy
図2: NATing 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マルチキャストサービスのための独身のホストに似ている。
Wing & Eckert Best Current Practice [Page 3] RFC 5135 NAT IP Multicast Requirements February 2008
翼とエッケルト最も良い現在の習慣[3ページ]RFC5135NAT IPマルチキャスト要件2008年2月
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 Proxying"[RFC4605]を実行するのが必要です--しかしまた、働いているNATの文脈の中で。 NATは[RFC4605]でカバーされていません。 IGMP proxyingにNATを加えると、IGMPメッセージの処理はRFC4605で定義されるように変化する必要はありません:
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 proxyingデバイスで論理的に進めますが、出典を明示するか、または決して受け取りません。 一般に、デバイスによる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プロトコルパケットがいつもそれらが送られるインタフェース('inside'か'外部')の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.
ユニキャスト流れと異なって、NATはマルチキャスト送付先IPアドレスがあるパケットでそれらの送付先IPアドレスか仕向港を変えません。 しかしながら、パケットがNATの'inside'インタフェースから'外'の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 proxyingにNATを加えると、以下のセクションで説明されるようにIGMP proxyingデバイスの向こう側に進められたIPマルチキャストデータ・パケットの処理は変化します。 これらの変化は実際に*でないのが実行する*にNATをするデバイスの上にIGMP proxyingを配布する能力を簡素化します。
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 Proxy NAT Deviceと共に、'inside'にホストから出典を明示されたIPマルチキャストデータ通信量はそれが直接接されたホストからWANルータまで出典を明示されているように見えるためのNATedです、その結果、[RFC4605]のセクション3.2で説明されたすべての標準的でないPIM-SM関心/構成を排除します。
Wing & Eckert Best Current Practice [Page 4] RFC 5135 NAT IP Multicast Requirements February 2008
翼とエッケルト最も良い現在の習慣[4ページ]RFC5135NAT IPマルチキャスト要件2008年2月
4. Requirements
4. 要件
4.1. NATing IP Multicast Data Packets
4.1. NATing IPマルチキャストデータ・パケット
4.1.1. Receiving Multicast Data Packets
4.1.1. マルチキャストデータ・パケットを受けます。
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: 'inside'インタフェースでホストに送られる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は、セッション発表(例えば、電子プログラムガイド、Session Announcementプロトコル(SAP))とセッション設立とコントロール(例えば、SIP、レアルTime Streamingプロトコル(RTSP))メッセージを変更する必要があります。 アプリケーションメッセージのそのような変更は最も良い習慣であると考えられません。 その上、NATed、マルチ、家へ帰り、ネットワークは、NATsの間のそのような書き直しを調整する必要があるでしょう。
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は'inside'インタフェースで'外'のインタフェースからマルチキャスト受信機まで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: '外部'からの非UDPプロトコル(例えば、Pragmatic Multicast司令官(PGM)[RFC3208]、Resource予約プロトコル(RSVP)[RFC2205])が'inside'インタフェースでIPマルチキャスト受信機に連結するNAT SHOULDの前進のIPマルチキャスト。
4.1.2. Sending Multicast Data Packets
4.1.2. 送付マルチキャストデータ・パケット
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が'inside'インタフェースから'外'のインタフェースに向かって到着するパケットのソース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マルチキャストパケットへの応答が適切なホストによって受け取られるのを許容するためにマッピングを作成しなければなりません。 また、Any Source Multicastに関しては、セクション4.3を見てください。
Wing & Eckert Best Current Practice [Page 5] RFC 5135 NAT IP Multicast Requirements February 2008
翼とエッケルト最も良い現在の習慣[5ページ]RFC5135NAT IPマルチキャスト要件2008年2月
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)がなければなりません、送付先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 SHOULDには、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は'inside'インタフェースから'外'のインタフェースまで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: また、上記の要件をサポートするNATsは、この特徴を無効にするために設定オプションを提供しなければなりません。 さもなければ、「マルチ-家へ帰」っているネットワークは公衆通信回線におけるマルチキャストデータ通信量の写しインスタンスを引き起こすでしょう。
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.
多くのNATsが帯域幅で強制的なアクセスリンクに隣接して位置しているとき、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) 'inside'からの[RFC2365]は'外'のインタフェースに(s)を連結します。
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がLocal Network Control Blockを進めてはいけない、(224.0 .0/24) 'inside'からの[RFC3171](また、「リンク地方のマルチキャスト」として、知られている)トラフィックは'外'のインタフェースに(s)を連結します。
4.2. IGMP Version Support
4.2. IGMPバージョンサポート
REQ-8: A NAT MAY support IGMPv1 (although IGMPv1 is considered
obsolete).
REQ-8: NATはIGMPv1をサポートするかもしれません(IGMPv1は時代遅れであると考えられますが)。
Wing & Eckert Best Current Practice [Page 6] RFC 5135 NAT IP Multicast Requirements February 2008
翼とエッケルト最も良い現在の習慣[6ページ]RFC5135NAT IPマルチキャスト要件2008年2月
REQ-9: A NAT MUST support IGMPv2.
REQ-9: NATはIGMPv2をサポートしなければなりません。
REQ-10: A NAT SHOULD support IGMPv3.
REQ-10: NAT SHOULDサポートIGMPv3。
4.2.1. IGMPv1 or IGMPv2
4.2.1. IGMPv1かIGMPv2
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は単に'inside'インタフェースに関する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.
a: 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: しかしながら、IGMP集合が役に立つ最適化を提供するので、そのようなNATがIGMP/MLD Proxying[RFC4605]を実行するのは、RECOMMENDEDです。
4.2.2. IGMPv3
4.2.2. IGMPv3
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 proxying装置が'inside'インタフェースでIGMP会員資格を受けるとき、それはそれ自身のIGMP proxying会員資格状態とそれ自身のIGMP推進テーブルを創設します。 次に、それはIPマルチキャストグループ/チャンネルを報告する'外'のインタフェースに独立しているIGMP会員資格レポートを作成します--しかし、IGMP会員資格レポートか質問のダイレクト関係か「推進」が全くインタフェースのむこうにありません。 NAT装置は次に、'inside'インタフェースへの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がそうしたので、状態(_INCLUDEが_EXCLUDEであるということである)と変化指示を区別すると報告します。(例えば、TO_INCLUDE、TO_EXCLUDE) NATはNATが2人以上のレポーターからのレポートをはさみ込む(同じグループに加わって、出て)ことであったならIGMPv3レポーター[RFC3376]と共に言いなりになっていないパケットの系列を作成するでしょう。 この理由として、以下の要件は指定されます:
Wing & Eckert Best Current Practice [Page 7] RFC 5135 NAT IP Multicast Requirements February 2008
翼とエッケルト最も良い現在の習慣[7ページ]RFC5135NAT IPマルチキャスト要件2008年2月
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 Proxying[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]のためのSourceの特定のMulticast(SSM)とSSMのためのIGMPv3/MLDv2[RFC4604]を実行しなければなりません。
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人のホストを考えてください。 発表に参加して、残してください。そして、1人のホストが別のものがセッションを残していて、NATが単にリレーすることになっていた同セッション時に加わる、終えられて、接合してくださいといって、上流、セッションに遺書を残してください、[RFC3376]のセクション5に従わないでしょう。
4.3. Any Source Multicast Transmitters
4.3. どんなソースマルチキャスト送信機
Any Source Multicast (ASM) uses the IP addresses in the 224/8 through 231/8, and 233/8 through 239/8 range [IANA-ALLOC].
どんなSource Multicast(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.
RTPを使用して、ホストがASMの流れを受けて、交通をそれに送るとき[RFC3550]、NATが単に[RFC4787]の要件に続いたなら、潜在的な問題があります。 問題はRTPがセッションメンバーを特定するのにソース輸送アドレス(ソースIPアドレスとソースUDP港)とレアル-時間Transportプロトコル/RTP Controlプロトコル(RTP/ RTCP)SSRC価値を使用するということです。 セッションメンバーが、同じSSRCが異なった輸送アドレスから到着するのを見ると、そのセッションメンバーはRTP衝突検出([RFC3550]のセクション8.2)を実行するでしょう。 NATが単に[RFC4787]の要件に続いて、調節されたなら、よりしばしば送って、RTP衝突検出はあらゆる2が書き留めるより同じSSRCを共有している他のセッションメンバーによって実行されるでしょう、診断用道具を複雑にしてことであり、外で潜在的にジターを妨げていると、2分の不活発とRTCP受信機の後のUDPセッションが、報告するアルゴリズムはバッファリングします。例えば、この状況はオーディオRTPが流す正常な50Kbpsのおよそ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マルチキャストよりむしろ)であるのでソース特有のMulticastはこの長いタイマを必要としません、そして、識別子は、特定のIPマルチキャスト受信機を特定するのにIPアドレスとUDPポートよりむしろ使用されます。(例えば、[RTCPSSM。]
Wing & Eckert Best Current Practice [Page 8] RFC 5135 NAT IP Multicast Requirements February 2008
翼とエッケルト最も良い現在の習慣[8ページ]RFC5135NAT IPマルチキャスト要件2008年2月
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の'inside'インタフェースのホストがAny Source Multicastホストグループのものて、ホストがUDPパケットを同じグループに送るなら、NAT SHOULDには、そのマッピングのための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、SHOULDを写像して、ホストがそのホストグループを出たら破壊されてください。 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: リソース、60分前に写像して、経過したNAT5月のタイムアウトがNATでくたくたになったか、しかし、これはがっかりしています。 リソース疲労困憊がある状況でさえ、NATが最低2分([RFC4787]のREQ-5)のマッピング持続時間に続くのにまだ必要であることに注意してください。
5. Requirements Summary
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: 'inside'インタフェースでホストに送られる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は'inside'インタフェースで'外'のインタフェースからマルチキャスト受信機まで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: '外部'からの非UDPプロトコル(例えば、PGM[RFC3208]、RSVP[RFC2205])が'inside'インタフェースでIPマルチキャスト受信機に連結するNAT SHOULDの前進の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が'inside'インタフェースから'外'のインタフェースに向かって到着するパケットのソース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マルチキャストパケットへの応答が適切なホストによって受け取られるのを許容するためにマッピングを作成しなければなりません。 また、Any Source Multicastに関しては、セクション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)がなければなりません、送付先IPアドレスがユニキャストアドレスかIPマルチキャストアドレスであっても。
Wing & Eckert Best Current Practice [Page 9] RFC 5135 NAT IP Multicast Requirements February 2008
翼とエッケルト最も良い現在の習慣[9ページ]RFC5135NAT IPマルチキャスト要件2008年2月
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 SHOULDには、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は'inside'インタフェースから'外'のインタフェースまで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: また、上記の要件を支持するNATsは、この特徴を無効にするために設定オプションを提供しなければなりません。 さもなければ、「マルチ-家へ帰」っているネットワークは公衆通信回線におけるマルチキャストデータ通信量の写し例を引き起こすでしょう。
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) 'inside'からの[RFC2365]は'外'のインタフェースに(s)を連結します。
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がLocal Network Control Blockを進めてはいけない、(224.0 .0/24) 'inside'インタフェースから'外'のインタフェースまでの[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 SHOULDサポート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は単に'inside'インタフェースに関する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.
a: NATがこの様にIGMPv1かIGMPv2メッセージをリレーするなら、IGMPメッセージのTTLを減少させてはいけません、TTL=1と共にそれらを既に送るとき。
Wing & Eckert Best Current Practice [Page 10] RFC 5135 NAT IP Multicast Requirements February 2008
翼とエッケルト最も良い現在の習慣[10ページ]RFC5135NAT IPマルチキャスト要件2008年2月
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 Proxying[RFC4605]を実行するのは、RECOMMENDEDです。
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 Proxying[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]のためのSourceの特定のMulticast(SSM)とSSMのためのIGMPv3/MLDv2[RFC4604]を実行しなければなりません。
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の'inside'インタフェースのホストがAny Source Multicastホストグループのものて、ホストがUDPパケットを同じグループに送るなら、NAT SHOULDには、そのマッピングのための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、SHOULDを写像して、ホストがそのホストグループを出たら破壊されてください。 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: リソース、60分前に写像して、経過したNAT5月のタイムアウトがNATでくたくたになったか、しかし、これはがっかりしています。 リソース疲労困憊がある状況でさえ、NATが最低2分([RFC4787]のREQ-5)のマッピング持続時間に続くのにまだ必要であることに注意してください。
6. Security Considerations
6. セキュリティ問題
The Security Considerations sections of IGMPv3 [RFC3376] and IGMP Proxying [RFC4605] apply to a device complying with this document.
IGMPv3[RFC3376]とIGMP Proxying[RFC4605]のSecurity Considerations部はこのドキュメントに従う装置に適用されます。
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.
ホストがAny Source MulticastセッションのときにRTPを使用して、参加するとき、ホストの周期的なRTCP受信機レポートで、NATはマッピングを作成します。 グループサイズがおよそ300未満であるときに、NATのマッピングがいつも開くように保たれるくらいの頻繁にRTCPレポートを送ります。 グループサイズがおよそ300より大きいときに、どんなより頻繁にもRTCPレポートを送りません。 保たれるNATマッピングがそのIPマルチキャストセッションにおけるホストの参加の持続時間のためにマルチキャストのサイズがホスティングしない問題を全く開くというセクション4.3 原因における推薦かホストのRTCPトランスミッションの周期性。
Wing & Eckert Best Current Practice [Page 11] RFC 5135 NAT IP Multicast Requirements February 2008
翼とエッケルト最も良い現在の習慣[11ページ]RFC5135NAT IPマルチキャスト要件2008年2月
7. Acknowledgments
7. 承認
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 Cai、スティーブンCasner、レミデニス-Courmont、ラース・エッゲルト、ゴーリーFairhurst、アルフレッド・ハインズ、Prashant Jhingran、バラトジョーシー、フランソアLe Faucheur、アルバート・マンフレディ、Marcusマラニャン、ブライアン・マクラフリン、クリス・ニューマン、ティム・ポーク、ペッカSavola、マークTownsley、マグヌスWesterlund、およびスティVenaasをありがとうございます。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2236] Fenner, W., "Internet Group Management Protocol,
Version 2", RFC 2236, November 1997.
w.[RFC2236]フェナー、「インターネット集団経営はRFC2236、1997年11月についてバージョン2インチ議定書の中で述べます」。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast",
BCP 23, RFC 2365, July 1998.
[RFC2365] マイヤー、D.、「行政上見られたIPマルチキャスト」、BCP23、RFC2365、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ガイドラインは課題を記述します」、BCP51、RFC3171、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インチ、RFC3376、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:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、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)について議定書の中で述べてください」、RFC4604、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] フェナー、B.、彼、H.、ハーバーマン、B.、およびH.Sandick、「インターネット集団経営は(IGMP)/マルチキャストのリスナーの発見の(MLD)ベースのマルチキャスト推進("IGMP/MLD Proxying")について議定書の中で述べます」、RFC4605、2006年8月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast
for IP", RFC 4607, August 2006.
[RFC4607] ホルブルックとH.とB.カイン、「IPのためのソース特有のマルチキャスト」、RFC4607、2006年8月。
Wing & Eckert Best Current Practice [Page 12] RFC 5135 NAT IP Multicast Requirements February 2008
翼とエッケルト最も良い現在の習慣[12ページ]RFC5135NAT IPマルチキャスト要件2008年2月
[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.ジョニングス)は「ユニキャストUDPのためのアドレス変換(NAT)の行動の要件をネットワークでつなぎます」、BCP127、RFC4787、2007年1月。
8.2. Informative References
8.2. 有益な参照
[IANA-ALLOC] Internet Assigned Numbers Authority, "Internet
Multicast Addresses",
<http://www.iana.org/assignments/multicast-addresses>.
[IANA-ALLOC]インターネットは数の権威、「インターネットマルチキャストアドレス」を割り当てて、<http://www.iana.org/課題/マルチキャストアドレスは>です。
[ICE] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Work
in Progress, October 2007.
ローゼンバーグ、[氷]J.、「対話的な接続性設立(氷):」 「申し出/答えプロトコルのためのネットワークアドレス変換機構(NAT)縦断のためのプロトコル」、処理中の作業、2007年10月。
[RFC1112] Deering, S., "Host extensions for IP multicasting",
STD 5, RFC 1112, August 1989.
[RFC1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、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.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(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の機能的な仕様」、RFC2205、1997年9月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[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.、クロウクロフト、J.、Gemmell、J.、ファリナッチ、D.、リン、S.、Leshchiner、D.、Luby、M.、モンゴメリ、T.、リゾー、L.、Tweedly、A.、Bhaskar、N.、Edmonstone、R.、Sumanasekera、R.、およびL.Vicisano、「PGMの信頼できる輸送プロトコル仕様」、RFC3208(2001年12月)。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Session Description Protocol", RFC 4566, July 2006.
[RFC4566] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「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] フェナー、B.、ハンドレー、M.、ホルブルック、H.、およびI.Kouvelas、「プロトコルの独立しているマルチキャスト--まばらなモード(PIM-Sm):、」 「プロトコル仕様(改訂される)」、RFC4601、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月)で働いています。
Wing & Eckert Best Current Practice [Page 13] RFC 5135 NAT IP Multicast Requirements February 2008
翼とエッケルト最も良い現在の習慣[13ページ]RFC5135NAT IPマルチキャスト要件2008年2月
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は、リスナーがSSMチャンネル(S、G)を知るのを必要とします。(チャンネルはIPソースアドレス(S)とIPマルチキャストグループ(G)から成ります)。 SSMソースは、SSMセッション設立メッセージ(例えば、Session記述プロトコル(SDP)[RFC4566]の)のIPアドレスを伝える必要があります。 SSM送付者がNATの後ろにいて、そのNATの反対側の上にSSM受信機があるとき、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の'inside'の両方にいれば、セッション広告で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の'inside'の上の複数のSSMソースが同じマルチキャストグループアドレスを選ぶなら、彼らのIPアドレスがユニークであるので、それらのソースは唯一身元保証可能です。 しかしながら、それらのマルチキャスト交通がNATedであり、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].)
同じくらい多くのNATsが同じプライベート・アドレススペースを使用する、(例えば、192.168、.0、.0/16、[RFC1918)、RTPスタックがCNAMEsを適切に発生させるよう奨励されます。(.1セクション6.5[RFC3550]の終わりに遭遇してください。)
Wing & Eckert Best Current Practice [Page 14] RFC 5135 NAT IP Multicast Requirements February 2008
翼とエッケルト最も良い現在の習慣[14ページ]RFC5135NAT IPマルチキャスト要件2008年2月
Authors' Addresses
作者のアドレス
Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
西タスマン・Driveダン翼のシスコシステムズInc.170カリフォルニア95134サンノゼ(米国)
EMail: dwing@cisco.com
メール: dwing@cisco.com
Toerless Eckert Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
西タスマン・Drive ToerlessエッケルトシスコシステムズInc.170カリフォルニア95134サンノゼ(米国)
EMail: eckert@cisco.com
メール: eckert@cisco.com
Wing & Eckert Best Current Practice [Page 15] RFC 5135 NAT IP Multicast Requirements February 2008
翼とエッケルト最も良い現在の習慣[15ページ]RFC5135NAT IPマルチキャスト要件2008年2月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Wing & Eckert Best Current Practice [Page 16]
翼とエッケルトBest現在の習慣[16ページ]
一覧
スポンサーリンク
