RFC4541 日本語訳
4541 Considerations for Internet Group Management Protocol (IGMP) andMulticast Listener Discovery (MLD) Snooping Switches. M. Christensen,K. Kimball, F. Solensky. May 2006. (Format: TXT=38555 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Christensen
Request for Comments: 4541 Thrane & Thrane
Category: Informational K. Kimball
Hewlett-Packard
F. Solensky
Calix
May 2006
コメントを求めるワーキンググループM.クリステンセンの要求をネットワークでつないでください: 4541年のトラーネとトラーネCategory: 情報のK.のキンボールヒューレット・パッカードF.Solenskyカリックス2006年5月
Considerations for Internet Group Management Protocol (IGMP)
and Multicast Listener Discovery (MLD) Snooping Switches
インターネットグループ管理プロトコル(IGMP)と詮索が切り替わるというマルチキャストリスナー発見(MLD)のための問題
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This memo describes the recommendations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping switches. These are based on best current practices for IGMPv2, with further considerations for IGMPv3- and MLDv2-snooping. Additional areas of relevance, such as link layer topology changes and Ethernet-specific encapsulation issues, are also considered.
このメモは、インターネットGroup Managementプロトコル(IGMP)とMulticast Listenerディスカバリー(MLD)のためにスイッチについて詮索しながら、推薦について説明します。 これらはIGMPv3とMLDv2-詮索のためのさらなる問題でIGMPv2に、最も良い現在の実務に基づいています。 また、リンクレイヤトポロジー変化やイーサネット特有のカプセル化問題などの関連性の追加領域は考えられます。
1. Introduction
1. 序論
The IEEE bridge standard [BRIDGE] specifies how LAN packets are 'bridged', or as is more commonly used today, switched between LAN segments. The operation of a switch with respect to multicast packets can be summarized as follows. When processing a packet whose destination MAC address is a multicast address, the switch will forward a copy of the packet into each of the remaining network interfaces that are in the forwarding state in accordance with [BRIDGE]. The spanning tree algorithm ensures that the application of this rule at every switch in the network will make the packet accessible to all nodes connected to the network.
IEEE橋の規格[BRIDGE]はLANパケットが'橋を架けられる'か、または今日以上のようにどう一般的に使用されるかを指定します、LANセグメントの間に切り換えられて。 以下の通りマルチキャストパケットに関するスイッチの操作をまとめることができます。 送付先MACアドレスがマルチキャストアドレスであるパケットを処理するとき、スイッチは[BRIDGE]に従って推進状態にあるそれぞれの残っているネットワーク・インターフェースにパケットのコピーを送るでしょう。 スパニングツリーアルゴリズムは、あらゆるスイッチでのネットワークにおける、この規則の適用でパケットがネットワークに接続されたすべてのノードにアクセスしやすくなるのを確実にします。
This behaviour works well for broadcast packets that are intended to be seen or processed by all connected nodes. In the case of multicast packets, however, this approach could lead to less efficient use of network bandwidth, particularly when the packet is
このふるまいはすべての接続ノードによって見られるか、または処理されることを意図する放送パケットに、うまくいきます。 しかしながら、マルチキャストパケットのケースでは、このアプローチはネットワーク回線容量のそれほど効率的でない使用につながるかもしれません、特にパケットがそうときに
Christensen, et al. Informational [Page 1] RFC 4541 IGMP and MLD Snooping Switches Considerations May 2006
クリステンセン、他 情報[1ページ]のRFC4541IGMPと問題2006年5月にスイッチについて詮索するMLD
intended for only a small number of nodes. Packets will be flooded into network segments where no node has any interest in receiving the packet. While nodes will rarely incur any processing overhead to filter packets addressed to unrequested group addresses, they are unable to transmit new packets onto the shared media for the period of time that the multicast packet is flooded. In general, significant bandwidth can be wasted by flooding.
少ない数のノードだけのために、意図しています。 どんなノードもパケットを受けるのにどんな関心も持っていないところにパケットはネットワークセグメントへあふれるでしょう。 ノードは非要求されたグループアドレスに記述されたパケットをフィルターにかけるためにめったに少しの処理オーバヘッドも被らないでしょうが、彼らはマルチキャストパケットが水につかっていることの期間のための共有されたメディアに新しいパケットを伝えることができません。 一般に、氾濫は重要な帯域幅を浪費できます。
In recent years, a number of commercial vendors have introduced products described as "IGMP snooping switches" to the market. These devices do not adhere to the conceptual model that provides the strict separation of functionality between different communications layers in the ISO model, and instead utilize information in the upper level protocol headers as factors to be considered in processing at the lower levels. This is analogous to the manner in which a router can act as a firewall by looking into the transport protocol's header before allowing a packet to be forwarded to its destination address.
近年、多くの商業業者が「IGMP詮索は切り替わる」として記述された製品を市場に挿入しました。 これらの装置は、ISOモデルで異なったコミュニケーション層の間に機能性の厳しい分離を供給する概念モデルを固く守って、代わりに処理で下のレベルで考えられる要素として上側の平らなプロトコルヘッダーで情報を利用しません。 これはルータがファイアウォールとしてパケットが送付先アドレスに送られるのを許容する前にトランスポート・プロトコルのヘッダーを調べることによって機能できる方法に類似しています。
In the case of IP multicast traffic, an IGMP snooping switch provides the benefit of conserving bandwidth on those segments of the network where no node has expressed interest in receiving packets addressed to the group address. This is in contrast to normal switch behavior where multicast traffic is typically forwarded on all interfaces.
IPマルチキャスト交通の場合では、IGMP詮索スイッチはどんなノードもグループアドレスに記述されたパケットを受けることへの関心を示していないネットワークのそれらの区分における帯域幅を保存する利益を提供します。 これはマルチキャスト交通がすべてのインタフェースで通常送られるところに通常のスイッチの振舞いと対照的になっています。
Many switch datasheets state support for IGMP snooping, but no recommendations for this exist today. It is the authors' hope that the information presented in this document will supply this foundation.
多くのスイッチデータシートが、IGMP詮索のサポートが存在していますが、これのためのどんな推薦も今日存在しないと述べます。 本書では提示された情報がこの基礎を供給するのは、作者の望みです。
The recommendations presented here are based on the following information sources: The IGMP specifications [RFC1112], [RFC2236] and [IGMPv3], vendor-supplied technical documents [CISCO], bug reports [MSOFT], discussions with people involved in the design of IGMP snooping switches, MAGMA mailing list discussions, and on replies by switch vendors to an implementation questionnaire.
ここに提示された推薦は以下の情報源に基づいています: IGMP仕様[RFC1112]、[RFC2236]、および[IGMPv3](業者によって供給された技術文献[シスコ])はレポート[MSOFT]を悩まして、スイッチについて詮索するIGMPのデザイン、MAGMAメーリングリスト議論にかかわって、オンな人々との議論は実現アンケートへのスイッチ業者による回答です。
Interoperability issues that arise between different versions of IGMP are not the focus of this document. Interested readers are directed to [IGMPv3] for a thorough description of problem areas.
IGMPの異なった見解の間に起こる相互運用性問題はこのドキュメントの焦点ではありません。 興味のある読者は問題領域の綿密な描写のために[IGMPv3]に向けられます。
The suggestions in this document are based on IGMP, which applies only to IPv4. For IPv6, Multicast Listener Discovery [MLD] must be used instead. Because MLD is based on IGMP, we do not repeat the entire description and recommendations for MLD snooping switches. Instead, we point out the few cases where there are differences from IGMP.
提案は本書ではIGMPに基づいています。(IGMPはIPv4だけに適用します)。 IPv6のために、代わりに、Multicast Listenerディスカバリー[MLD]を使用しなければなりません。 MLDがIGMPに基づいているので、私たちはスイッチについて詮索するMLDのために全体の記述と推薦を繰り返しません。 代わりに、私たちはIGMPから違いがあるわずかなケースを指摘します。
Christensen, et al. Informational [Page 2] RFC 4541 IGMP and MLD Snooping Switches Considerations May 2006
クリステンセン、他 情報[2ページ]のRFC4541IGMPと問題2006年5月にスイッチについて詮索するMLD
Note that the IGMP snooping function should apply only to IPv4 multicasts. Other multicast packets, such as IPv6, might be suppressed by IGMP snooping if additional care is not taken in the implementation as mentioned in the recommendations section. It is desired not to restrict the flow of non-IPv4 multicasts other than to the degree which would happen as a result of regular bridging functions. Likewise, MLD snooping switches are discouraged from using topological information learned from IPv6 traffic to alter the forwarding of IPv4 multicast packets.
IGMP詮索機能がIPv4マルチキャストだけに適用されるべきであることに注意してください。 IPv6などの他のマルチキャストパケットは追加注意が推薦部で言及されるように実現で払われないなら詮索するIGMPによって抑圧されるかもしれません。 通常の橋を架ける機能の結果、起こる度以外の非IPv4マルチキャストの流れを制限しないのは必要です。 同様に、スイッチについて詮索するMLDが、IPv4マルチキャストパケットの推進を変更するのにIPv6交通から学習された位相的な情報を使用して、がっかりしています。
2. IGMP Snooping Recommendations
2. 推薦について詮索するIGMP
The following sections list the recommendations for an IGMP snooping switch. The recommendation is stated and is supplemented by a description of a possible implementation approach. All implementation discussions are examples only and there may well be other ways to achieve the same functionality.
以下のセクションはスイッチについて詮索するIGMPのために推薦を記載します。 推薦は、述べられていて、可能な実現アプローチの記述で補われます。 すべての実現議論が例専用です、そして、たぶん、同じ機能性を達成する他の方法があるでしょう。
2.1. Forwarding rules
2.1. 推進規則
The IGMP snooping functionality is separated into a control section (IGMP forwarding) and a data section (Data forwarding).
機能性について詮索するIGMPは制御セクション(IGMP推進)と資料課(データ推進)に切り離されます。
2.1.1. IGMP Forwarding Rules
2.1.1. IGMP推進規則
1) A snooping switch should forward IGMP Membership Reports only to
those ports where multicast routers are attached.
1) 詮索スイッチはマルチキャストルータが付属しているそれらのポートだけにIGMP Membership Reportsを送るはずです。
Alternatively stated: a snooping switch should not forward IGMP
Membership Reports to ports on which only hosts are attached. An
administrative control may be provided to override this
restriction, allowing the report messages to be flooded to other
ports.
代わりに述べられています: 詮索スイッチはホストだけが付属しているポートにIGMP Membership Reportsを送るはずがありません。 他のポートへあふれるべきレポートメッセージを許容して、この制限をくつがえすために運営管理コントロールを提供するかもしれません。
This is the main IGMP snooping functionality for the control path.
これはコントロール経路のための機能性について詮索する主なIGMPです。
Sending membership reports to other hosts can result, for IGMPv1
and IGMPv2, in unintentionally preventing a host from joining a
specific multicast group.
会員資格レポートを他のホストに送るのは結果として生じることができます、IGMPv1とIGMPv2のために、ホストが特定のマルチキャストグループに加わるのを何気なく防ぐ際に。
When an IGMPv1 or IGMPv2 host receives a membership report for a
group address that it intends to join, the host will suppress its
own membership report for the same group. This join or message
suppression is a requirement for IGMPv1 and IGMPv2 hosts.
However, if a switch does not receive a membership report from the
host it will not forward multicast data to it.
IGMPv1かIGMPv2ホストがグループアドレスのための接合するつもりであるという会員資格レポートを受け取るとき、ホストは同じグループのためにそれ自身の会員資格レポートを抑圧するでしょう。 これは接合するか、メッセージ抑圧がIGMPv1とIGMPv2ホストのための要件です。 しかしながら、スイッチがホストから会員資格レポートを受け取らないと、それはマルチキャストデータをそれに転送しないでしょう。
Christensen, et al. Informational [Page 3] RFC 4541 IGMP and MLD Snooping Switches Considerations May 2006
クリステンセン、他 情報[3ページ]のRFC4541IGMPと問題2006年5月にスイッチについて詮索するMLD
This is not a problem in an IGMPv3-only network because there is
no suppression of IGMP Membership reports.
IGMP Membershipレポートの秘匿が全くないので、これはIGMPv3だけネットワークで問題ではありません。
The administrative control allows IGMP Membership Report messages
to be processed by network monitoring equipment such as packet
analyzers or port replicators.
運営管理コントロールはパケット分析器かポートレプリケータなどのネットワークモニタリング設備によって処理されるべきメッセージをIGMP Membership Reportに許容します。
The switch supporting IGMP snooping must maintain a list of
multicast routers and the ports on which they are attached. This
list can be constructed in any combination of the following ways:
IGMP詮索を支持するスイッチはマルチキャストルータのリストとそれらが付属しているポートを維持しなければなりません。 以下の方法のどんな組み合わせでもこのリストを構成できます:
a) This list should be built by the snooping switch sending
Multicast Router Solicitation messages as described in IGMP
Multicast Router Discovery [MRDISC]. It may also snoop
Multicast Router Advertisement messages sent by and to other
nodes.
a) このリストはIGMP Multicast Routerディスカバリー[MRDISC]で説明されるように詮索しているスイッチ送付Multicast Router Solicitationメッセージによって造られるべきです。 また、それはノードと他のノードに送られたMulticast Router Advertisementメッセージについて詮索するかもしれません。
b) The arrival port for IGMP Queries (sent by multicast routers)
where the source address is not 0.0.0.0.
b) ソースアドレスが0.0でないIGMP Queries(マルチキャストルータで、発信する)のための到着ポート、.0 .0。
The 0.0.0.0 address represents a special case where the switch
is proxying IGMP Queries for faster network convergence, but is
not itself the Querier. The switch does not use its own IP
address (even if it has one), because this would cause the
Queries to be seen as coming from a newly elected Querier. The
0.0.0.0 address is used to indicate that the Query packets are
NOT from a multicast router.
0.0に、.0が記述する.0は、より速いネットワーク集合のために、スイッチがproxying IGMP Queriesである特別なケースを表しますが、それ自体でQuerierではありません。 スイッチはそれ自身のIPアドレスを使用しません(それに1つがあっても)、これで新たに選出されたQuerierから来るのをQueriesを見るでしょう、したがって。 0.0に、Queryパケットがマルチキャストルータからのそうでないことを示すのにおいて.0が記述する.0は使用されています。
c) Ports explicitly configured by management to be IGMP-forwarding
ports, in addition to or instead of any of the above methods to
detect router ports.
c) ポートはいずれかルータポートを検出する上の方法のどれかの代わりにIGMP-推進ポートであることを明らかに管理で構成されました。
2) IGMP networks may also include devices that implement "proxy-
reporting", in which reports received from downstream hosts are
summarized and used to build internal membership states. Such
proxy-reporting devices may use the all-zeros IP Source-Address
when forwarding any summarized reports upstream. For this reason,
IGMP membership reports received by the snooping switch must not
be rejected because the source IP address is set to 0.0.0.0.
2) また、IGMPネットワークは「プロキシ報告」を実行する装置を含むかもしれません。そこでは、川下のホストから受け取られたレポートは、内部の会員資格州を建てるのにまとめられて、使用されます。 どんなまとめられたレポート上流も進めるとき、そのようなプロキシを報告する装置はオールゼロIP Source-アドレスを使用するかもしれません。 ソースIPアドレスが.0に0.0に.0を設定することであるので、この理由に関しては、詮索スイッチによって受け取られたIGMP会員資格レポートを拒絶してはいけません。
3) The switch that supports IGMP snooping must flood all unrecognized
IGMP messages to all other ports and must not attempt to make use
of any information beyond the end of the network layer header.
3) IGMP詮索を支持するスイッチは、すべての認識されていないIGMPメッセージを他のすべてのポートへあふれさせなければならなくて、ネットワーク層ヘッダーの端のどんな情報も利用するのを試みてはいけません。
In addition, earlier versions of IGMP should interpret IGMP fields
as defined for their versions and must not alter these fields when
forwarding the message. When generating new messages, a given
IGMP version should set fields to the appropriate values for its
さらに、IGMPの以前のバージョンは、それらのバージョンのために定義されるようにIGMP分野を解釈するべきであり、メッセージを転送するとき、これらの分野を変更してはいけません。 新しいメッセージを発生させて、与えられたIGMPバージョンがいつの間、適切な値に分野を設定するべきであるか、それ
Christensen, et al. Informational [Page 4] RFC 4541 IGMP and MLD Snooping Switches Considerations May 2006
クリステンセン、他 情報[4ページ]のRFC4541IGMPと問題2006年5月にスイッチについて詮索するMLD
own version. If any fields are reserved or otherwise undefined
for a given IGMP version, the fields should be ignored when
parsing the message and must be set to zeroes when new messages
are generated by implementations of that IGMP version. An
exception may occur if the switch is performing a spoofing
function, and is aware of the settings for new or reserved fields
that would be required to correctly spoof for a different IGMP
version.
バージョンを所有してください。 何か分野が予約されているか、または与えられたIGMPバージョンに、そうでなければ、未定義であるなら、新しいメッセージがそのIGMPバージョンの実現で発生するとき、分野をメッセージを分析するとき、無視されるべきであり、ゼロに設定しなければなりません。 スイッチがスプーフィング機能を実行していて、異なったIGMPバージョンのために正しくだますのに必要である新しいか予約された分野において、設定を知っているなら、例外は起こるかもしれません。
The reason to worry about these trivialities is that IGMPv3
overloads the old IGMP query message using the same type number
(0x11) but with an extended header. Therefore there is a risk
that IGMPv3 queries may be interpreted as older version queries
by, for example, IGMPv2 snooping switches. This has already been
reported [IETF56] and is discussed in section 2.2.
これらの些細な事を心配する理由はIGMPv3が数(0×11)にもかかわらず、拡張ヘッダーと共に同じタイプを使用することで古いIGMP質問メッセージを積みすぎるということです。 したがって、IGMPv3質問が旧式のバージョン質問として例えば、スイッチについて詮索するIGMPv2によって解釈されるかもしれないというリスクがあります。 これについて、既に報告されて[IETF56]、セクション2.2で議論します。
4) An IGMP snooping switch should be aware of link layer topology
changes caused by Spanning Tree operation. When a port is enabled
or disabled by Spanning Tree, a General Query may be sent on all
active non-router ports in order to reduce network convergence
time. Non-Querier switches should be aware of whether the Querier
is in IGMPv3 mode. If so, the switch should not spoof any General
Queries unless it is able to send an IGMPv3 Query that adheres to
the most recent information sent by the true Querier. In no case
should a switch introduce a spoofed IGMPv2 Query into an IGMPv3
network, as this may create excessive network disruption.
4) IGMP詮索スイッチはSpanning Tree操作で引き起こされたリンクレイヤトポロジー変化を意識しているべきです。 Spanning Treeがポートを可能にするか、または無能にするとき、ネットワーク集合時間を短縮するためにすべてのアクティブな非ルータポートにQuery司令官を送るかもしれません。 非QuerierスイッチはQuerierがIGMPv3モードであるかを意識しているべきです。 そうだとすれば、本当のQuerierによって送られた最新の情報を固く守るIGMPv3 Queryを送ることができないなら、スイッチは少しのQueries司令官もだますはずがありません。 これが過度のネットワーク分裂を作成するとき、スイッチはIGMPv3ネットワークにだまされたIGMPv2 Queryを決して、取り入れるはずがありません。
If the switch is not the Querier, it should use the 'all-zeros' IP
Source Address in these proxy queries (even though some hosts may
elect to not process queries with a 0.0.0.0 IP Source Address).
When such proxy queries are received, they must not be included in
the Querier election process.
スイッチがQuerierでないなら、それはこれらのプロキシ質問に'オールゼロ'IP Source Addressを使用するべきです(何人かのホストが、0.0.0.0IP Source Addressとの質問を処理しないのを選ぶかもしれませんが)。 そのようなプロキシ質問が受け取られているとき、Querier選挙の過程にそれらを含んではいけません。
5) An IGMP snooping switch must not make use of information in IGMP
packets where the IP or IGMP headers have checksum or integrity
errors. The switch should not flood such packets but if it does,
it should also take some note of the event (i.e., increment a
counter). These errors and their processing are further discussed
in [IGMPv3], [MLD] and [MLDv2].
5) IGMP詮索スイッチはIGMPパケットのIPかIGMPヘッダーがチェックサムか保全誤りを持っている情報を利用してはいけません。 そうするなら、スイッチはそのようなパケットをあふれさせるはずがありませんが、また、それは出来事の何らかのノートを取るべきです(すなわち、カウンタを増加してください)。 [IGMPv3]、[MLD]、および[MLDv2]でさらにこれらの誤りと彼らの処理について議論します。
6) The snooping switch must not rely exclusively on the appearance of
IGMP Group Leave announcements to determine when entries should be
removed from the forwarding table. It should implement a
membership timeout mechanism such as the router-side functionality
of the IGMP protocol as described in the IGMP and MLD
specifications (See Normative Reference section for IGMPv1-3 and
MLDv1-2) on all its non-router ports. This timeout value should
be configurable.
6) 詮索スイッチは、エントリーがいつ推進テーブルから取り除かれるべきであるかを決定するために排他的にIGMP Group Leave発表の外観に依存してはいけません。 それはIGMPとMLD仕様で説明されるように(IGMPv1-3とMLDv1-2に関してNormative Reference部を見ます)すべての非ルータポートの上でIGMPプロトコルのルータサイドの機能性などの会員資格タイムアウトメカニズムを実行するべきです。 このタイムアウト値は構成可能であるべきです。
Christensen, et al. Informational [Page 5] RFC 4541 IGMP and MLD Snooping Switches Considerations May 2006
クリステンセン、他 情報[5ページ]のRFC4541IGMPと問題2006年5月にスイッチについて詮索するMLD
2.1.2. Data Forwarding Rules
2.1.2. データ推進規則
1) Packets with a destination IP address outside 224.0.0.X which are
not IGMP should be forwarded according to group-based port
membership tables and must also be forwarded on router ports.
1) IGMPでない224.0.0.Xの外に送付先IPアドレスがあるパケットをグループベースのポート会員資格テーブルに応じて進めるべきであり、また、ルータポートの上で進めなければなりません。
This is the main IGMP snooping functionality for the data path.
One approach that an implementation could take would be to
maintain separate membership and multicast router tables in
software and then "merge" these tables into a forwarding cache.
これはデータ経路のための機能性について詮索する主なIGMPです。 「実現が取ることができた1つのアプローチは、ソフトウェアで別々の会員資格とマルチキャストルータテーブルを維持して、次に、これらのテーブルを推進キャッシュに合併するだろう」ことです。
2) Packets with a destination IP (DIP) address in the 224.0.0.X range
which are not IGMP must be forwarded on all ports.
2) すべてのポートの上で送付先IP(DIP)アドレスが224.0.0.X範囲にあるIGMPでないパケットを進めなければなりません。
This recommendation is based on the fact that many host systems do
not send Join IP multicast addresses in this range before sending
or listening to IP multicast packets. Furthermore, since the
224.0.0.X address range is defined as link-local (not to be
routed), it seems unnecessary to keep the state for each address
in this range. Additionally, some routers operate in the
224.0.0.X address range without issuing IGMP Joins, and these
applications would break if the switch were to prune them due to
not having seen a Join Group message from the router.
この推薦はIPマルチキャストパケットを送るか、または聞く前に多くのホストシステムがこの範囲でIPマルチキャストアドレスをJoinに送らないという事実に基づいています。 その上、224.0.0.Xアドレスの範囲がリンク地方(発送されない)と定義されるので、この範囲の各アドレスのために状態を維持するのは不要に思えます。 さらに、IGMP Joinsを発行しないで、いくつかのルータが224.0.0.Xアドレスの範囲で作動します、そして、ルータからJoin Groupメッセージを見ていないためスイッチがそれらを剪定するなら、これらのアプリケーションは壊れるでしょうに。
3) An unregistered packet is defined as an IPv4 multicast packet with
a destination address which does not match any of the groups
announced in earlier IGMP Membership Reports.
3) 登録されていないパケットは以前のIGMP Membership Reportsで発表されたグループのいずれにも合っていない送付先アドレスでIPv4マルチキャストパケットと定義されます。
If a switch receives an unregistered packet, it must forward that
packet on all ports to which an IGMP router is attached. A switch
may default to forwarding unregistered packets on all ports.
Switches that do not forward unregistered packets to all ports
must include a configuration option to force the flooding of
unregistered packets on specified ports.
スイッチが登録されていないパケットを受けるなら、それはIGMPルータが付けているすべてのポートの上でそのパケットを進めなければなりません。 スイッチはすべてのポートの上で登録されていないパケットを進めるのをデフォルトとするかもしれません。 登録されていないパケットをすべてのポートに送らないスイッチは、登録されていないパケットの氾濫を指定されたポートに押しつけるために設定オプションを含まなければなりません。
In an environment where IGMPv3 hosts are mixed with snooping
switches that do not yet support IGMPv3, the switch's failure to
flood unregistered streams could prevent v3 hosts from receiving
their traffic. Alternatively, in environments where the snooping
switch supports all of the IGMP versions that are present,
flooding unregistered streams may cause IGMP hosts to be
overwhelmed by multicast traffic, even to the point of not
receiving Queries and failing to issue new membership reports for
their own groups.
まだIGMPv3を支持していないスイッチについて詮索するのにIGMPv3ホストと交際する環境で、スイッチが登録されていない流れをあふれさせない場合、v3ホストが彼らの交通を受けるのを防ぐかもしれません。 あるいはまた、詮索スイッチが存在しているIGMPバージョンのすべてを支持する環境で登録されていない流れをあふれさせるのはマルチキャスト交通でIGMPホストを圧倒させるかもしれません、Queriesを受けて、必ずそれら自身のグループのための新しい会員資格レポートを発行さえするまで。
It is encouraged that snooping switches at least recognize and
process IGMPv3 Join Reports, even if this processing is limited to
the behavior for IGMPv2 Joins, i.e., is done without considering
それがそう、考えないで、奨励されて、すなわち、この処理がIGMPv2 Joinsのために振舞いに制限されても、スイッチについて詮索するのは、IGMPv3 Join Reportsを少なくとも認識して、処理します。
Christensen, et al. Informational [Page 6] RFC 4541 IGMP and MLD Snooping Switches Considerations May 2006
クリステンセン、他 情報[6ページ]のRFC4541IGMPと問題2006年5月にスイッチについて詮索するMLD
any additional "include source" or "exclude source" filtering.
When IGMPv3 Joins are not recognized, a snooping switch may
incorrectly prune off the unregistered data streams for the groups
(as noted above); alternatively, it may fail to add in forwarding
to any new IGMPv3 hosts if the group has previously been joined as
IGMPv2 (because the data stream is seen as already having been
registered).
どんな追加「ソースを含めてください」や「ソースを除いてください」フィルタリング。 IGMPv3 Joinsが認識されないとき、詮索スイッチはグループ(上で述べたように)のために登録されていないデータで不当に流れを剪定するかもしれません。 あるいはまた、グループが以前にIGMPv2として加わられたなら(データ・ストリームが既に登録されたのが見られるので)、それはどんな新しいIGMPv3ホストにも推進を加えないかもしれません。
4) All non-IPv4 multicast packets should continue to be flooded out
to all remaining ports in the forwarding state as per normal IEEE
bridging operations.
4) 非IPv4マルチキャストパケットはすべて、通常のIEEE橋を架ける作業に従って推進状態のすべての残っているポートに水浸しにされ続けているはずです。
This recommendation is a result of the fact that groups made up of
IPv4 hosts and IPv6 hosts are completely separate and distinct
groups. As a result, information gleaned from the topology
between members of an IPv4 group would not be applicable when
forming the topology between members of an IPv6 group.
この推薦はグループがIPv4ホストに仲直りしたという事実の結果です、そして、IPv6ホストは完全に別々の、そして、異なったグループです。 IPv6グループのメンバーの間でトポロジーを形成するとき、その結果、IPv4グループのメンバーの間のトポロジーから収集された情報は適切でないでしょう。
5) IGMP snooping switches may maintain forwarding tables based on
either MAC addresses or IP addresses. If a switch supports both
types of forwarding tables then the default behavior should be to
use IP addresses. IP address based forwarding is preferred
because the mapping between IP multicast addresses and link-layer
multicast addresses is ambiguous. In the case of Ethernet, there
is a multiplicity of 1 Ethernet address to 32 IP addresses
[RFC1112].
5) スイッチについて詮索するIGMPはMACアドレスかIPアドレスのどちらかに基づく推進テーブルを維持するかもしれません。 スイッチが両方のタイプの推進テーブルを支えるなら、デフォルトの振舞いはIPアドレスを使用することであるべきです。 IPマルチキャストアドレスとリンクレイヤマルチキャストアドレスの間のマッピングがあいまいであるので、進めながら基づくIPアドレスは好まれます。 イーサネットの場合には、32のIPアドレス[RFC1112]への1つのイーサネット・アドレスの多様性があります。
6) Switches which rely on information in the IP header should verify
that the IP header checksum is correct. If the checksum fails,
the information in the packet must not be incorporated into the
forwarding table. Further, the packet should be discarded.
6) IPヘッダーで情報を当てにするスイッチは、IPヘッダーチェックサムが正しいことを確かめるはずです。 チェックサムが失敗するなら、パケットの情報を推進テーブルに組み入れてはいけません。 さらに、パケットは捨てられるべきです。
7) When IGMPv3 "include source" and "exclude source" membership
reports are received on shared segments, the switch needs to
forward the superset of all received membership reports on to the
shared segment. Forwarding of traffic from a particular source S
to a group G must happen if at least one host on the shared
segment reports an IGMPv3 membership of the type INCLUDE(G,
Slist1) or EXCLUDE(G, Slist2), where S is an element of Slist1 and
not an element of Slist2.
7) IGMPv3が「ソースを含ん」で、「ソースを除く」とき、共用セグメント(すべての受け取られていている会員資格レポートのスーパーセットを共用セグメントに送るスイッチの必要性)に会員資格レポートを受け取ります。 共用セグメントの少なくとも1人のホストがタイプINCLUDE(G、Slist1)かSがSlist2の要素ではなく、Slist1の要素であるEXCLUDE(G、Slist2)のIGMPv3会員資格を報告するなら、交通の特定のソースSからグループGまでの推進は起こらなければなりません。
The practical implementation of the (G,S1,S2,...) based data
forwarding tables are not within the scope of this document.
However, one possibility is to maintain two (G,S) forwarding
lists: one for the INCLUDE filter where a match of a specific
(G,S) is required before forwarding will happen, and one for the
EXCLUDE filter where a match of a specific (G,S) will result in no
forwarding.
このドキュメントの範囲の中に(G、S1、S2)ベースのデータ推進テーブルの実用的な実現がありません。 しかしながら、1つの可能性は2つ(G、S)の推進リストを維持することです: 推進が起こる前に詳細(G、S)のマッチが必要であるINCLUDEフィルタのためのもの、および詳細(G、S)のマッチが進めないことをもたらすEXCLUDEフィルタのためのもの。
Christensen, et al. Informational [Page 7] RFC 4541 IGMP and MLD Snooping Switches Considerations May 2006
クリステンセン、他 情報[7ページ]のRFC4541IGMPと問題2006年5月にスイッチについて詮索するMLD
2.2. IGMP Snooping-Related Problems
2.2. IGMPの詮索関連の問題
A special problem arises in networks consisting of IGMPv3 routers as well as IGMPv2 and IGMPv3 hosts interconnected by an IGMPv2 snooping switch as recently reported [IETF56]. The router will continue to maintain IGMPv3 even in the presence of IGMPv2 hosts, and thus the network will not converge on IGMPv2. But it is likely that the IGMPv2 snooping switch will not recognize or process the IGMPv3 membership reports. Groups for these unrecognized reports will then either be flooded (with all of the problems that may create for hosts in a network with a heavy multicast load) or pruned by the snooping switch.
特別な問題はIGMPv2と同様にIGMPv3ルータと最近報告されているとしてIGMPv2詮索スイッチによってインタコネクトされたIGMPv3ホスト[IETF56]から成るネットワークで起こります。 ルータは、IGMPv2ホストの面前でさえIGMPv3を維持し続けるでしょう、そして、その結果、ネットワークはIGMPv2に集まらないでしょう。 しかし、IGMPv2詮索スイッチは、IGMPv3会員資格レポートを認識しそうにはありませんし、また処理しそうにないでしょう。 そして、これらの認識されていないレポートのためのグループは、詮索スイッチによってあふれるか(それがホストのために重いマルチキャスト負荷でネットワークで生じさせるかもしれない問題のすべてで)、または剪定されるでしょう。
Therefore, it is recommended that in such a network, the multicast router be configured to use IGMPv2. If this is not possible, and if the snooping switch cannot recognize and process the IGMPv3 membership reports, it is instead recommended that the switch's IGMP snooping functionality be disabled, as there is no clear solution to this problem.
したがって、そのようなもののネットワーク、マルチキャストルータがIGMPv2を使用するために構成されるのは、お勧めです。 詮索スイッチがIGMPv3会員資格レポートをこれが可能でなく、認識して、処理できないなら、機能性について詮索するスイッチのIGMPが無効にされることが代わりに勧められます、この問題のどんな明確な解決もないとき。
3. IPv6 Considerations
3. IPv6問題
In order to avoid confusion, the previous discussions have been based on the IGMP protocol which only applies to IPv4 multicast. In the case of IPv6, most of the above discussions are still valid with a few exceptions that we will describe here.
混乱を避けるために、前の議論はIPv4マルチキャストに適用されるだけであるIGMPプロトコルに基づきました。 IPv6の場合では、上の議論の大部分は私たちがここで説明するつもりであるいくつかの例外のためにまだ有効です。
The control and data forwarding rules in the IGMP section can, with a few considerations, also be applied to MLD. This means that the basic functionality of intercepting MLD packets, and building membership lists and multicast router lists, is the same as for IGMP.
また、いくつかの問題で、IGMP部の規則を進めるコントロールとデータはMLDに適用できます。 これは、MLDパケットを妨害して、会員名簿とマルチキャストルータリストを造る基本機能がIGMPのように同じであることを意味します。
In IPv6, the data forwarding rules are more straight forward because MLD is mandated for addresses with scope 2 (link-scope) or greater. The only exception is the address FF02::1 which is the all hosts link-scope address for which MLD messages are never sent. Packets with the all hosts link-scope address should be forwarded on all ports.
IPv6では、MLDが範囲2(リンク範囲)があるアドレスのために強制されているか、または、よりすばらしいので、前方では、データ推進規則が、よりまっすぐです。 唯一の例外がアドレスFF02です:、:そうする1、すべてがMLDメッセージが決して送られないリンク範囲アドレスをホスティングします。 アドレスがすべてで転送されるべきであるすべてのホストリンク範囲港があるパケット。
MLD messages are also not sent regarding groups with addresses in the range FF00::/15 (which encompasses both the reserved FF00::/16 and node-local FF01::/16 IPv6 address spaces). These addresses should never appear in packets on the link.
アドレスが範囲FF00にある状態で、またメッセージが見なさされないMLDは以下を分類します:/15(予約されたFF00: : /16とノード地方のFF01: : /16IPv6アドレス空間の両方を取り囲みます)。 これらのアドレスはリンクの上にパケットに決して現れるべきではありません。
Equivalent to the IPv4 behaviors regarding the null IP Source address, MLD membership reports must not be rejected by an MLD snooping switch because of an unspecified IP source address (::). Additionally, if a non-Querier switch spoofs any General Queries (as
ヌルIP Sourceアドレスに関してIPv4の振舞いに同等です、MLD会員資格レポートが不特定のIPソースアドレスでMLD詮索スイッチによって拒絶されてはいけない、(:、:、) さらに、スイッチが非QuerierであるならどんなQueries司令官もだます、(
Christensen, et al. Informational [Page 8] RFC 4541 IGMP and MLD Snooping Switches Considerations May 2006
クリステンセン、他 情報[8ページ]のRFC4541IGMPと問題2006年5月にスイッチについて詮索するMLD
addressed in Section 2.1 above, for Spanning Tree topology changes), the switch should use the null IP source address (::) when sending said queries. When such proxy queries are received, they must not be included in the Querier election process.
Spanning Treeトポロジーにおける、上のセクション2.1が変える記述されたコネ)、スイッチがヌルIPソースアドレスを使用するはずである、(:、:)、前述の質問を送るとき。 そのようなプロキシ質問が受け取られているとき、Querier選挙の過程にそれらを含んではいけません。
The three major differences between IPv4 and IPv6 in relation to multicast are:
マルチキャストと関連したIPv4とIPv6の3つの主要な違いは以下の通りです。
- The IPv6 protocol for multicast group maintenance is called
Multicast Listener Discovery [MLDv2]. MLDv2 uses ICMPv6 message
types instead of IGMP message types.
- マルチキャストグループメンテナンスのためのIPv6プロトコルはMulticast Listenerディスカバリー[MLDv2]と呼ばれます。 MLDv2はIGMPメッセージタイプの代わりにICMPv6メッセージタイプを使用します。
- The RFCs [IPV6-ETHER] and [IPV6-FDDI] describe how 32 of the 128
bit DIP addresses are used to form the 48 bit DMAC addresses for
multicast groups, while [IPV6-TOKEN] describes the mapping for
token ring DMAC addresses by using three low-order bits. The
specification [IPV6-1394] makes use of a 6 bit channel number.
- RFCs[IPV6-ETHER]と[IPV6-FDDI]は128ビットの32のDIPアドレスがDMACがマルチキャストグループのために記述する48ビットを形成するのにどう使用されるかを説明します、[IPV6-TOKEN]は3下位のビットを使用することによって、トークンリングDMACアドレスのためのマッピングについて説明しますが。 仕様[IPV6-1394]は6ビットの論理機番を利用します。
- Multicast router discovery is accomplished using the Multicast
Router Discovery Protocol (MRDISC) defined in [MRDISC].
- マルチキャストルータ発見は[MRDISC]で定義されたMulticast Routerディスカバリープロトコル(MRDISC)を使用するのに優れています。
The IPv6 packet header does not include a checksum field. Nevertheless, the switch should detect other packet integrity issues such as address version and payload length consistencies if possible. When the snooping switch detects such an error, it must not include information from the corresponding packet in the MLD forwarding table. The forwarding code should instead drop the packet and take further reasonable actions as advocated above.
IPv6パケットのヘッダーはチェックサム分野を入れません。 それにもかかわらず、できれば、スイッチはアドレスバージョンやペイロード長の一貫性などの他のパケット保全問題を検出するはずです。 詮索スイッチがそのような誤りを検出するとき、それはMLD推進テーブルの対応するパケットからの情報を含んではいけません。 推進コードは、上で提唱されるように代わりにパケットを落として、さらなる合理的な行動を取るべきです。
The fact that MLDv2 is using ICMPv6 adds new requirements to a snooping switch because ICMPv6 has multiple uses aside from MLD. This means that it is no longer sufficient to detect that the next- header field of the IP header is ICMPv6 in order to identify packets relevant for MLD snooping. A software-based implementation which treats all ICMPv6 packets as candidates for MLD snooping could easily fill its receive queue and bog down the CPU with irrelevant packets. This would prevent the snooping functionality from performing its intended purpose and the non-MLD packets destined for other hosts could be lost.
MLDは別としてICMPv6には複数の用途があるので、MLDv2がICMPv6を使用しているという事実は詮索スイッチに新しい要件を加えます。 これは、IPヘッダーの次のヘッダーフィールドがMLD詮索において、関連しているパケットを特定するICMPv6であることが検出するためにもう十分でないことを意味します。 MLD詮索の候補としてすべてのICMPv6パケットを扱うソフトウェアベースの実現が容易にいっぱいになることができた、それ、無関係のパケットで待ち行列と沼沢地をCPUの下側に受けてください。 これは、詮索の機能性が本来の目的を実行するのを防ぐでしょう、そして、他のホストのために運命づけられた非MLDパケットは失われる場合がありました。
A solution is either to require that the snooping switch looks further into the packets, or to be able to detect a multicast DMAC address in conjunction with ICMPv6. The first solution is desirable when a configuration option allows the administrator to specify which ICMPv6 message types should trigger a CPU redirect and which should not. The reason is that a hardcoding of message types is inflexible for the introduction of new message types. The second solution introduces the risk that new protocols that use ICMPv6 and multicast
解決策は詮索スイッチがパケットに遠くまで探しに行くのが必要である、またはICMPv6に関連してマルチキャストDMACアドレスを検出できるどちらかです。 管理者が設定オプションでどのICMPv6メッセージタイプが再直接でCPUの引き金となるべきであるか、そして、どれが引き金となるべきでないかを指定できるとき、最初の解決策は望ましいです。 理由は新しいメッセージタイプの導入に、メッセージタイプのhardcodingが融通がきかないということです。 2番目の解決策が導入する、ICMPv6とマルチキャストを使用するプロトコルをそんなに新しく危険にさらしてください。
Christensen, et al. Informational [Page 9] RFC 4541 IGMP and MLD Snooping Switches Considerations May 2006
クリステンセン、他 情報[9ページ]のRFC4541IGMPと問題2006年5月にスイッチについて詮索するMLD
DMAC addresses could be incorrectly identified as MLD. It is suggested that solution one is preferred when the configuration option is provided. If this is not the case, then the implementor should seriously consider making it available since Neighbor Discovery messages would be among those that fall into this false positive case and are vital for the operational integrity of IPv6 networks.
MLDとして不当にDMACアドレスを特定できました。 設定オプションを提供するとき、解決策1を好むことが提案されます。 これがそうでないなら、作成者は、Neighborディスカバリーメッセージがこの無病誤診ケースになるものにあって、IPv6ネットワークの操作上の保全に、重大であるのでそれを利用可能にすると真剣に考えるべきです。
The mapping from IP multicast addresses to multicast DMAC addresses introduces a potentially enormous overlap. The structure of an IPv6 multicast address is shown in the figure below. As a result, there are 2 ** (112 - 32), or more than 1.2e24 unique DIP addresses which map into a single DMAC address in Ethernet and FDDI. This should be compared to 2**5 in the case of IPv4.
IPマルチキャストアドレスからマルチキャストDMACアドレスまでのマッピングは潜在的に莫大なオーバラップを導入します。 IPv6マルチキャストアドレスの構造は以下の図に示されます。 その結果、2**(112--32)、またはDMACがイーサネットでシングルへのそれの地図を扱う1.2e24のユニークなDIPアドレスとFDDI以上があります。 これはIPv4の場合で2**5と比較されるべきです。
Initial allocation of IPv6 multicast addresses, as described in [RFC3307], however, cover only the lower 32 bits of group ID. While this reduces the problem of address ambiguity to group IDs with different flag and scope values for now, it should be noted that the allocation policy may change in the future. Because of the potential overlap it is recommended that IPv6 address based forwarding is preferred to MAC address based forwarding.
IPv6マルチキャストアドレスの配分に頭文字をつけてください、そして、しかしながら、[RFC3307]で説明されるようにグループIDの低級32ビットだけをカバーしてください。 これが当分異なった旗と範囲値でIDを分類するためにアドレスのあいまいさの問題を減少させている間、配分方針が将来変化するかもしれないことに注意されるべきです。 潜在的オーバラップのために、ベースの推進が好まれるそのIPv6アドレスはMACアドレスが推進を基礎づけたことが勧められます。
| 8 | 4 | 4 | 112 bits |
+--------+----+----+---------------------------------------+
|11111111|flgs|scop| group ID |
+--------+----+----+---------------------------------------+
| 8 | 4 | 4 | 112ビット| +--------+----+----+---------------------------------------+ |11111111|flgs|scop| グループID| +--------+----+----+---------------------------------------+
4. IGMP Questionnaire
4. IGMPアンケート
As part of this work, the following questions were asked on the MAGMA discussion list and were sent to known switch vendors implementing IGMP snooping. The individual contributions have been anonymized upon request and do not necessarily apply to all of the vendors' products.
この仕事の一部として、以下の質問をMAGMA議論リストで尋ねて、IGMP詮索を実装する知られているスイッチベンダーに送りました。 個人拠出は、要求のときにanonymizedされて、必ずベンダーの製品のすべてに適用されるというわけではありません。
The questions were:
質問は以下の通りでした。
Q1 Do your switches perform IGMP Join aggregation? In other
words, are IGMP joins intercepted, absorbed by the
hardware/software so that only one Join is forwarded to the
querier?
Q1は実行します。あなたのスイッチはIGMP Join集合を実行しますか? 言い換えれば、唯一ようにIGMPが妨害されていた状態で接合するということであり、ハードウェア/ソフトウェアで吸収して、1Joinをquerierに送りますか?
Q2 Is multicast forwarding based on MAC addresses? Would
datagrams addressed to multicast IP addresses 224.1.2.3 and
239.129.2.3 be forwarded on the same ports-groups?
Q2はMACアドレスに基づくマルチキャスト推進ですか? そして、データグラムがIPが224.1に.2を扱うマルチキャストに.3を扱った、239.129 .2 .3 同じくらいでは、グループを移植する状態で、進めるでしょうか?
Christensen, et al. Informational [Page 10] RFC 4541 IGMP and MLD Snooping Switches Considerations May 2006
クリステンセン、他 情報[10ページ]のRFC4541IGMPと問題2006年5月にスイッチについて詮索するMLD
Q3 Is it possible to forward multicast datagrams based on IP
addresses (not routed)? In other words, could 224.1.2.3 and
239.129.2.3 be forwarded on different port-groups with
unaltered TTL?
Q3、IPアドレス(掘らない)に基づくマルチキャストデータグラムを進めるのは可能ですか? そして、言い換えれば、224.1にそうすることができた、.2、.3、239.129 .2 .3 unaltered TTLがある異なったポートグループでは、進めますか?
Q4 Are multicast datagrams within the range 224.0.0.1 to
224.0.0.255 forwarded on all ports whether or not IGMP Joins
have been sent?
Q4が範囲の中のマルチキャストデータグラムである、224.0、.0、.1、224.0 IGMP Joinsを送ったか否かに関係なく、.255がすべてのポートの上で進めた.0?
Q5 Are multicast frames within the MAC address range
01:00:5E:00:00:01 to 01:00:5E:00:00:FF forwarded on all ports
whether or not IGMP joins have been sent?
Q5は01:00:5E: 00:00:01〜01:00:5E MACアドレスの範囲の中のマルチキャストフレームです: IGMPが接合するか否かに関係なく、すべてのポートの上で進められた00:00:FFを送りましたか?
Q6 Does your switch support forwarding to ports on which IP
multicast routers are attached in addition to the ports where
IGMP Joins have been received?
Q6はIPマルチキャストルータがIGMP Joinsが受け取られたポートに加えて付けられているポートにあなたのスイッチサポート推進をしますか?
Q7 Is your IGMP snooping functionality fully implemented in
hardware?
Q7は機能性がハードウェアで完全に実装したあなたのIGMP詮索ですか?
Q8 Is your IGMP snooping functionality partly software
implemented?
Q8は機能性について一部詮索することでのあなたのIGMPです。ソフトウェアは実装しましたか?
Q9 Can topology changes (for example spanning tree configuration
changes) be detected by the IGMP snooping functionality so
that for example new queries can be sent or tables can be
updated to ensure robustness?
Q9、例えば、新しい質問を送ることができるか、または丈夫さを確実にするためにテーブルをアップデートできるように機能性について詮索するIGMPはトポロジー変化(例えば、スパニングツリー構成変更)を検出できますか?
The answers were:
---------------------------+-----------------------+
| Switch Vendor |
---------------------------+---+---+---+---+---+---+
| 1 | 2 | 3 | 4 | 5 | 6 |
---------------------------+---+---+---+---+---+---+
Q1 Join aggregation | x | x | x | | x | x |
Q2 Layer-2 forwarding | x | x | x | x |(1)| |
Q3 Layer-3 forwarding |(1)| |(1)| |(1)| x |
Q4 224.0.0.X aware |(1)| x |(1)|(2)| x | x |
Q5 01:00:5e:00:00:XX aware | x | x | x |(2)| x | x |
Q6 Mcast router list | x | x | x | x | x | x |
Q7 Hardware implemented | | | | | | |
Q8 Software assisted | x | x | x | x | x | x |
Q9 Topology change aware | x | x | x | x | |(2)|
---------------------------+---+---+---+---+---+---+
x Means that the answer was Yes.
(1) In some products (typically high-end) Yes; in others No.
(2) Not at the time that the questionnaire was received
but expected in the near future.
答えは以下の通りでした。 ---------------------------+-----------------------+ | スイッチベンダー| ---------------------------+---+---+---+---+---+---+ | 1 | 2 | 3 | 4 | 5 | 6 | ---------------------------+---+---+---+---+---+---+ Q1は集合を接合します。| x| x| x| | x| x| Q2層-2推進| x| x| x| x|(1)| | Q3層-3推進|(1)| |(1)| |(1)| x| Q4 224.0.0.X意識しています。|(1)| x|(1)|(2)| x| x| Q5 01:00:5e:00:00:XX意識しています。| x| x| x|(2)| x| x| Q6 Mcastルータリスト| x| x| x| x| x| x| ハードウェアが実装したQ7| | | | | | | Q8ソフトウェアは補助されました。| x| x| x| x| x| x| Q9トポロジー変化意識しています。| x| x| x| x| |(2)| ---------------------------+---+---+---+---+---+---+xは、答えがそうであったことを意味します。はい。 (1) 何らかの製品(通常ハイエンド)はいで。 他のものNo.で (2) 近い将来アンケートを受け取りましたが、予想した時にどんなそうしません。
Christensen, et al. Informational [Page 11] RFC 4541 IGMP and MLD Snooping Switches Considerations May 2006
クリステンセン、他 情報[11ページ]のRFC4541IGMPと問題2006年5月にスイッチについて詮索するMLD
5. References
5. 参照
5.1. Normative References
5.1. 引用規格
[BRIDGE] IEEE Std. 802.1D-2004 IEEE Standard for Local and
metropolitan area networks, Media Access Control (MAC)
Bridges
[ブリッジ]IEEE Std。 Localとメトロポリタンエリアネットワークのための802.1D-2004 IEEE Standard、メディアAccess Control(MAC)ブリッジ
[IGMPv3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002.
[IGMPv3] カイン、B.とデアリングとS.とKouvelasとI.とフェナー、B.とA.Thyagarajan、「インターネット集団経営は議定書を作ります、バージョン3インチ、RFC3376、2002年10月。」
[IPV6-1394] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets
over IEEE 1394 Networks", RFC 3146, October 2001.
[IPV6-1394] 藤沢とK.とA.尾上、「IEEE1394ネットワークの上のIPv6パケットのトランスミッション」、RFC3146、2001年10月。
[IPV6-ETHER] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC 2464, December 1998.
[IPV6-エーテル] クロフォード、M.、「イーサネットネットワークの上のIPv6パケットのトランスミッション」、RFC2464、1998年12月。
[IPV6-FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI
Networks", RFC 2467, December 1998.
[IPV6-FDDI] クロフォード、M.、「FDDIネットワークの上のIPv6パケットのトランスミッション」、RFC2467、1998年12月。
[IPV6-TOKEN] Crawford, M., Narten, T., and S. Thomas, "Transmission
of IPv6 Packets over Token Ring Networks", RFC 2470,
December 1998.
[IPV6-トークン] 1998年12月のクロフォードとM.とNarten、T.とS.トーマス、「トークンリングネットワークの上のIPv6パケットのトランスミッション」RFC2470。
[MLD] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[MLD] デアリング、S.、フェナー、W.、およびB.ハーバーマン、「IPv6"、RFC2710、1999年10月のためのマルチキャストリスナー発見(MLD)。」
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
そして、[MLDv2]ビーダ、R.、L.コスタ、「IPv6"、RFC3810、2004年6月のためのマルチキャストリスナー発見バージョン2(MLDv2)。」
[MRDISC] Haberman, B. and J. Martin, "Multicast Router
Discovery", RFC 4286, December 2005.
[MRDISC] ハーバーマンとB.とJ.マーチン、「マルチキャストルータ発見」、RFC4286、2005年12月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD
5, RFC 1112, August 1989.
[RFC1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997.
w.[RFC2236]フェナー、「インターネット集団経営はRFC2236、1997年11月についてバージョン2インチ議定書の中で述べます」。
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002.
[RFC3307] ハーバーマン、B.、「IPv6マルチキャストアドレスのための配分ガイドライン」、RFC3307、2002年8月。
Christensen, et al. Informational [Page 12] RFC 4541 IGMP and MLD Snooping Switches Considerations May 2006
クリステンセン、他 情報[12ページ]のRFC4541IGMPと問題2006年5月にスイッチについて詮索するMLD
5.2. Informative References
5.2. 有益な参照
[CISCO] Cisco Tech Notes, "Multicast In a Campus Network: CGMP
and IGMP snooping",
http://www.cisco.com/warp/public/473/22.html
[コクチマス]コクチマス技術メモ、「キャンパスのマルチキャストは以下をネットワークでつなぎます」。 「CGMPとIGMP詮索」、 http://www.cisco.com/warp/public/473/22.html
[IETF56] Briefing by Dave Thaler, Microsoft, presented to the
MAGMA WG at the 56'th IETF meeting in San Francisco,
http://www.ietf.org/proceedings/03mar/index.html
デーヴでThalerに事情を知らせる[IETF56](マイクロソフト)が56で'MAGMA WGに提示した、サンフランシスコ、 http://www.ietf.org/proceedings/03mar/index.html で会う第IETF、'
[MSOFT] Microsoft support article Q223136, "Some LAN Switches
with IGMP Snooping Stop Forwarding Multicast Packets on
RRAS Startup", http://support.microsoft.com/
support/articles/Q223/1/36.ASP
[MSOFT]マイクロソフトサポート記事Q223136、「IGMPが詮索しているいくつかのLANスイッチが、RRAS始動でマルチキャストパケットを進めるのを止める」 http://support.microsoft.com/ サポート/記事/Q223/1/36.ASP
6. Security Considerations
6. セキュリティ問題
Under normal network operation, the snooping switch is expected to improve overall network performance by limiting the scope of multicast flooding to a smaller portion of the local network. In the event of forged IGMP messages, the benefits of using a snooping switch might be reduced or eliminated.
通常のネットワーク操作で、詮索スイッチがマルチキャスト氾濫の範囲を企業内情報通信網の、より小さい部分に制限するのによる総合的なネットワーク性能を向上させると予想されます。 偽造IGMPメッセージの場合、詮索スイッチを使用する利益は、下げられるか、または除去されるかもしれません。
Security considerations for IGMPv3 at the network layer of the protocol stack are described in [IGMPv3]. The introduction of IGMP snooping functionality does not alter the handling of multicast packets by the router as it does not make use of link layer information.
プロトコル・スタックのネットワーク層におけるIGMPv3のためのセキュリティ問題は[IGMPv3]で説明されます。 リンクレイヤ情報を利用しないとき、機能性について詮索するIGMPの導入はルータからマルチキャストパケットの取り扱いを変更しません。
There are, however, changes in the way that the IGMP snooping switch handles multicast packets within the local network. In particular:
しかしながら、IGMP詮索スイッチが企業内情報通信網の中でマルチキャストパケットを扱う方法における変化があります。 特に:
- A Query message with a forged source address which is less than
that of the current Querier could cause snooping switches to
forward subsequent Membership reports to the wrong network
interface. It is for this reason that IGMP Membership Reports
should be sent to all multicast routers as well as the current
Querier.
- 現在のQuerierのもの以下である偽造ソースアドレスがあるQueryメッセージで、スイッチについて詮索すると、その後のMembershipレポートは間違ったネットワーク・インターフェースに転送されるかもしれません。 それは現在のQuerierと同様にすべてのマルチキャストルータにIGMP Membership Reportsを送るべきであるこの理由であります。
- It is possible for a host on the local network to generate
Current-State Report Messages that would cause the switch to
incorrectly believe that there is a multicast listener on the same
network segment as the originator of the forged message. This
will cause unrequested multicast packets to be forwarded into the
network segments between the source and the router. If the router
requires that all Multicast Report messages be authenticated as
described in section 9.4 of [IGMPv3], it will discard the forged
Report message from the host inside the network in the same way
- 企業内情報通信網のホストがスイッチにマルチキャストリスナーが偽造メッセージの創始者と同じネットワークセグメントにいると不当に信じさせるCurrent-州のReport Messagesを生成するのは、可能です。 これで、ソースとルータの間のネットワークセグメントに非要求されたマルチキャストパケットを送るでしょう。 ルータが、すべてのMulticast Reportメッセージが[IGMPv3]のセクション9.4で説明されるように認証されるのを必要とすると、同様に、それはネットワークの中でホストからの偽造Reportメッセージを捨てるでしょう。
Christensen, et al. Informational [Page 13] RFC 4541 IGMP and MLD Snooping Switches Considerations May 2006
クリステンセン、他 情報[13ページ]のRFC4541IGMPと問題2006年5月にスイッチについて詮索するMLD
that it would discard one which originates from a remote location.
It is worth noting that if the router accepts unauthenticated
Report messages by virtue of them having arrived over a network
interface associated with the internal network, investigating the
affected network segments will quickly narrow the search for the
source of the forged messages.
それは離れた場所から発するものを捨てるでしょう。 内部のネットワークに関連しているネットワーク・インターフェースの上で到着して、ルータがそれらによってunauthenticated Reportメッセージを受け入れると、影響を受けるネットワークセグメントを調査すると偽造メッセージの源の検索がすぐに狭くされることに注意する価値があります。
- As noted in [IGMPv3], there is little motivation for an attacker
to forge a Membership report message since joining a group is
generally an unprivileged operation. The sender of the forged
Membership report will be the only recipient of the multicast
traffic to that group. This is in contrast to a shared LAN
segment (HUB) or network without snooping switches, where all
other hosts on the same segment would be unable to transmit when
the network segment is flooding the unwanted traffic.
- [IGMPv3]に述べられるように、攻撃者が仲間に入るのが、一般に「非-特権を与え」させられた操作であるのでMembershipレポートメッセージを作り出す動機がほとんどありません。 偽造Membershipレポートの送付者はそのグループへのマルチキャストトラフィックの唯一の受取人になるでしょう。 スイッチについて詮索しないで、これは共有されたLANセグメント(HUB)かネットワークと対照的になっています。(ネットワークセグメントが求められていないトラフィックをあふれさせているとき、そこでは、同じセグメントの他のすべてのホストが伝わることができないでしょう)。
The worst case result for each attack would remove the performance improvements that the snooping functionality would otherwise provide. It would, however, be no worse than that experienced on a network with switches that do not perform multicast snooping.
各攻撃のための最悪の場合結果は詮索の機能性が別の方法で提供する性能改良を取り除くでしょう。 しかしながら、それはネットワークでマルチキャスト詮索を実行しないスイッチで経験されたそれほど悪くないでしょう。
7. Acknowledgements
7. 承認
We would like to thank Martin Bak, Les Bell, Yiqun Cai, Ben Carter, Paul Congdon, Toerless Eckert, Bill Fenner, Brian Haberman, Edward Hilquist, Hugh Holbrook, Kevin Humphries, Isidor Kouvelas, Pekka Savola, Suzuki Shinsuke, Jaff Thomas, Rolland Vida, and Margaret Wasserman for comments and suggestions on this document.
このドキュメントの上にコメントと提案についてマーチン・バク、レス・ベル、Yiqun Cai、ベン・カーター、ポール・コングドン、Toerlessエッケルト、ビル・フェナー、ブライアン・ハーバーマン、エドワードHilquist、ヒューHolbrook、ケビン・ハンフリーズ、Isidor Kouvelas、ペッカSavola、鈴木Shinsuke、Jaffトーマス、ロラン・ビーダ、およびマーガレット・ワッサーマンに感謝申し上げます。
Furthermore, the following companies are acknowledged for their contributions: 3Com, Alcatel, Cisco Systems, Enterasys Networks, Hewlett-Packard, Vitesse Semiconductor Corporation, Thrane & Thrane. The ordering of these names do not necessarily correspond to the column numbers in the response table.
その上、以下の会社は彼らの貢献のために承認されます: 3Com、アルカテル、シスコシステムズ、Enterasysネットワーク、ヒューレット・パッカード、Vitesse半導体社、トラーネ、およびトラーネ。 これらの名前の注文は必ず応答テーブルの桁位置に対応するというわけではありません。
Christensen, et al. Informational [Page 14] RFC 4541 IGMP and MLD Snooping Switches Considerations May 2006
クリステンセン、他 情報[14ページ]のRFC4541IGMPと問題2006年5月にスイッチについて詮索するMLD
Authors' Addresses
作者のアドレス
Morten Jagd Christensen Thrane & Thrane Lundtoftegaardsvej 93 D 2800 Lyngby DENMARK
モーテン・JagdクリステンセンのトラーネとトラーネLundtoftegaardsvej93D2800Lyngbyデンマーク
EMail: mjc@tt.dk
メール: mjc@tt.dk
Karen Kimball Hewlett-Packard 8000 Foothills Blvd. Roseville, CA 95747 USA
カレンキンボールヒューレット・パッカード8000山麓の丘Blvd. ローズビル、カリフォルニア95747米国
EMail: karen.kimball@hp.com
メール: karen.kimball@hp.com
Frank Solensky Calix 43 Nanog Park Acton, MA 01720 USA
フランクSolensky Calix43Nanog Park MA01720アクトン(米国)
EMail: frank.solensky@calix.com
メール: frank.solensky@calix.com
Christensen, et al. Informational [Page 15] RFC 4541 IGMP and MLD Snooping Switches Considerations May 2006
クリステンセン、他 情報[15ページ]のRFC4541IGMPと問題2006年5月にスイッチについて詮索するMLD
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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に情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Christensen, et al. Informational [Page 16]
クリステンセン、他 情報[16ページ]
一覧
スポンサーリンク
