RFC2710 日本語訳
2710 Multicast Listener Discovery (MLD) for IPv6. S. Deering, W.Fenner, B. Haberman. October 1999. (Format: TXT=46838 bytes) (Updated by RFC3590, RFC3810) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Deering
Request for Comments: 2710 Cisco Systems
Category: Standards Track W. Fenner
AT&T Research
B. Haberman
IBM
October 1999
コメントを求めるワーキンググループS.デアリングの要求をネットワークでつないでください: 2710年のシスコシステムズカテゴリ: 標準化過程W.フェナーAT&T研究B.ハーバーマンIBM1999年10月
Multicast Listener Discovery (MLD) for IPv6
IPv6のためのマルチキャストリスナー発見(MLD)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. This protocol is referred to as Multicast Listener Discovery or MLD. MLD is derived from version 2 of IPv4's Internet Group Management Protocol, IGMPv2. One important difference to note is that MLD uses ICMPv6 (IP Protocol 58) message types, rather than IGMP (IP Protocol 2) message types.
このドキュメントはIPv6ルータによって使用される、直接付属しているリンクの上にマルチキャストリスナー(すなわち、マルチキャストパケットを受けたがっているノード)の存在を発見して、どのマルチキャストアドレスがそれらの隣接しているノードに興味深いかを明確に発見するプロトコルを指定します。 このプロトコルはMulticast ListenerディスカバリーかMLDと呼ばれます。 IGMPv2、IPv4のインターネットGroup Managementプロトコルのバージョン2からMLDを得ます。 注意する1つの重要な違いはMLDがIGMP(IPプロトコル2)メッセージタイプよりむしろICMPv6(IPプロトコル58)メッセージタイプを使用するということです。
1. Definitions
1. 定義
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 [KEYWORDS].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[キーワード]で説明されるように本書では解釈されることであるべきですか?
2. Introduction
2. 序論
The purpose of Multicast Listener Discovery (MLD) is to enable each IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. This information is then
Multicast Listenerディスカバリー(MLD)の目的はそれぞれのIPv6ルータが、直接付属しているリンクの上にマルチキャストリスナー(すなわち、マルチキャストパケットを受けたがっているノード)の存在を発見して、どのマルチキャストアドレスがそれらの隣接しているノードに興味深いかを明確に発見するのを可能にすることです。 この情報はその時です。
Deering, et al. Standards Track [Page 1] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
デアリング、他 IPv6 October 1999のための標準化過程[1ページ]RFC2710マルチキャストリスナー発見
provided to whichever multicast routing protocol is being used by the router, in order to ensure that multicast packets are delivered to all links where there are interested receivers.
マルチキャストパケットが関心がある受信機があるすべてのリンクに渡されるのを確実にするのにルータによって使用されているマルチキャストルーティング・プロトコルに提供します。
MLD is an asymmetric protocol, specifying different behaviors for multicast listeners and for routers. For those multicast addresses to which a router itself is listening, the router performs both parts of the protocol, including responding to its own messages.
マルチキャストリスナーとルータのための異なった振舞いを指定して、MLDは非対称のプロトコルです。 ルータ自体が聴かれているそれらのマルチキャストアドレスのために、ルータはプロトコルの両方の部分を実行します、それ自身のメッセージに応じるのを含んでいて。
If a router has more than one interface to the same link, it need perform the router part of MLD over only one of those interfaces. Listeners, on the other hand, must perform the listener part of MLD on all interfaces from which an application or upper-layer protocol has requested reception of multicast packets.
ルータが同じリンクに1つ以上のインタフェースを持っているなら、それは1つだけの上でそれらのインタフェースについてMLDのルータ部分を実行しなければなりません。 他方では、リスナーはアプリケーションか上側の層のプロトコルがマルチキャストパケットのレセプションを要求したすべてのインタフェースにMLDのリスナー部分を実行しなければなりません。
3. Message Format
3. メッセージ・フォーマット
MLD is a sub-protocol of ICMPv6, that is, MLD message types are a subset of the set of ICMPv6 messages, and MLD messages are identified in IPv6 packets by a preceding Next Header value of 58. All MLD messages described in this document are sent with a link-local IPv6 Source Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert option [RTR-ALERT] in a Hop-by-Hop Options header. (The Router Alert option is necessary to cause routers to examine MLD messages sent to multicast addresses in which the routers themselves have no interest.)
MLDはICMPv6のサブプロトコルです、そして、すなわち、MLDメッセージタイプはICMPv6メッセージのセットの部分集合です、そして、MLDメッセージはIPv6パケットで58の前のNext Header値によって特定されます。 リンク地方のIPv6 Source Address、1のIPv6 Hop Limit、およびIPv6 Router Alertオプション[RTR-ALERT]と共にホップによるHop Optionsヘッダーで本書では説明されたすべてのMLDメッセージを送ります。 (Router Alertオプションがルータがルータ自体が関心を全く持っていないマルチキャストアドレスに送られたMLDメッセージを調べることを引き起こすのに必要です。)
MLD messages have the following format:
MLDメッセージには、以下の形式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Response Delay | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Multicast Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最大の応答遅れ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + マルチキャストアドレス+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Deering, et al. Standards Track [Page 2] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
デアリング、他 IPv6 October 1999のための標準化過程[2ページ]RFC2710マルチキャストリスナー発見
3.1. Type
3.1. タイプ
There are three types of MLD messages:
3つのタイプに関するMLDメッセージがあります:
Multicast Listener Query (Type = decimal 130)
マルチキャストリスナー質問(10進タイプ=130)
There are two subtypes of Multicast Listener Query messages:
Multicast Listener Queryメッセージの2血液型亜型があります:
- General Query, used to learn which multicast addresses have
listeners on an attached link.
- Multicast-Address-Specific Query, used to learn if a
particular multicast address has any listeners on an attached
link.
- どのマルチキャストアドレスにリスナーが付属リンクの上にいるかを学ぶのに使用されるQuery司令官。 - 特定のマルチキャストアドレスで何かリスナーが付属リンクの上にいるかどうか学ぶのに使用されるマルチキャストアドレス詳細Query。
These two subtypes are differentiated by the contents of the
Multicast Address field, as described in section 3.6.
これらの2血液型亜型はセクション3.6で説明されるようにMulticast Address分野のコンテンツによって微分されます。
Multicast Listener Report (Type = decimal 131)
マルチキャストリスナーレポート(10進タイプ=131)
Multicast Listener Done (Type = decimal 132)
行われたマルチキャストリスナー(10進タイプ=132)
In the rest of this document, the above messages types are referred to simply as "Query", "Report", and "Done".
このドキュメントの残りでは、上のメッセージタイプが、単に「質問」、「レポート」と呼ばれて、「されます」。
3.2. Code
3.2. コード
Initialized to zero by the sender; ignored by receivers.
送付者によってゼロに初期化されます。 受信機で、無視されます。
3.3. Checksum
3.3. チェックサム
The standard ICMPv6 checksum, covering the entire MLD message plus a "pseudo-header" of IPv6 header fields [ICMPv6,IPv6].
全体のMLDメッセージをカバーする標準のICMPv6チェックサムとIPv6ヘッダーフィールド[ICMPv6、IPv6]の「疑似ヘッダー。」
3.4. Maximum Response Delay
3.4. 最大の応答遅れ
The Maximum Response Delay field is meaningful only in Query messages, and specifies the maximum allowed delay before sending a responding Report, in units of milliseconds. In all other messages, it is set to zero by the sender and ignored by receivers.
Maximum Response Delay分野は、Queryメッセージだけで重要であり、応じるReportを送る前に遅れが許容された最大を指定します、ユニットのミリセカンドで。 他のすべてのメッセージでは、それは、送付者によってゼロに設定されて、受信機によって無視されます。
Varying this value allows the routers to tune the "leave latency" (the time between the moment the last node on a link ceases listening to a particular multicast address and moment the routing protocol is notified that there are no longer any listeners for that address), as discussed in section 7.8. It also allows tuning of the burstiness of MLD traffic on a link, as discussed in section 7.3.
この値を変えると、ルータは、「潜在を残す」(リンクの上の最後のノードが特定のマルチキャストが記述するのを聞くのをやめる瞬間、ルーティング・プロトコルが通知される瞬間の間のそのアドレスのためのどんなリスナーももういない時間)、セクションで議論するように7.8を調整するために許容されます。 また、それは、リンクにおけるMLD交通のburstinessセクション7.3で議論するように調整するのを許容します。
Deering, et al. Standards Track [Page 3] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
デアリング、他 IPv6 October 1999のための標準化過程[3ページ]RFC2710マルチキャストリスナー発見
3.5. Reserved
3.5. 予約されます。
Initialized to zero by the sender; ignored by receivers.
送付者によってゼロに初期化されます。 受信機で、無視されます。
3.6. Multicast Address
3.6. マルチキャストアドレス
In a Query message, the Multicast Address field is set to zero when sending a General Query, and set to a specific IPv6 multicast address when sending a Multicast-Address-Specific Query.
Queryメッセージでは、Multicastアドレス詳細Queryを送るとき、Multicast Address分野は、Query司令官を送るとき、ゼロに設定されて、特定のIPv6マルチキャストアドレスに設定されます。
In a Report or Done message, the Multicast Address field holds a specific IPv6 multicast address to which the message sender is listening or is ceasing to listen, respectively.
ReportかDoneメッセージでは、Multicast Address分野はメッセージ送付者が聴いているか、またはそれぞれ聴くのをやめている特定のIPv6マルチキャストアドレスを保持します。
3.7. Other fields
3.7. 他の分野
The length of a received MLD message is computed by taking the IPv6 Payload Length value and subtracting the length of any IPv6 extension headers present between the IPv6 header and the MLD message. If that length is greater than 24 octets, that indicates that there are other fields present beyond the fields described above, perhaps belonging to a future backwards-compatible version of MLD. An implementation of the version of MLD specified in this document MUST NOT send an MLD message longer than 24 octets and MUST ignore anything past the first 24 octets of a received MLD message. In all cases, the MLD checksum MUST be computed over the entire MLD message, not just the first 24 octets.
受信されたMLDメッセージの長さは、IPv6有効搭載量Length価値を取って、IPv6ヘッダーとMLDメッセージの間に出席しているどんなIPv6拡張ヘッダーの長さも引き算することによって、計算されます。 その長さが24以上の八重奏であるなら、それは、上で説明された分野を超えた現在の他の分野があるのを示します、恐らくMLDの将来の後方にコンパチブルバージョンに属して。 本書では指定されたMLDのバージョンの実現は、24の八重奏より長い間MLDメッセージを送ってはいけなくて、受信されたMLDメッセージの最初の24の八重奏を超えて何も無視しなければなりません。 すべての場合では、最初の24八重奏だけではなく、全体のMLDメッセージに関してMLDチェックサムを計算しなければなりません。
4. Protocol Description
4. プロトコル記述
Note that defaults for timer values are described later in this document. Timer and counter names appear in square brackets.
タイマ値のためのデフォルトが後で本書では説明されることに注意してください。 タイマとカウンタ名は角括弧に現れます。
Routers use MLD to learn which multicast addresses have listeners on each of their attached links. Each router keeps a list, for each attached link, of which multicast addresses have listeners on that link, and a timer associated with each of those addresses. Note that the router needs to learn only that listeners for a given multicast address are present on a link; it does NOT need to learn the identity (e.g., unicast address) of those listeners or even how many listeners are present.
ルータは、どのマルチキャストアドレスにリスナーがそれぞれの彼らの付属リンクの上にいるかを学ぶのにMLDを使用します。 各ルータはリストを保ちます、それぞれの付属リンク、およびそれぞれのそれらのアドレスに関連しているタイマのために。(マルチキャストアドレスで、そこでは、それのリスナーがリンクします)。 ルータが、与えられたマルチキャストアドレスのためのリスナーが単にリンクに出席していることを学ぶ必要に注意してください。 それはそれらのリスナーか何人のリスナーさえ出席しているかに関するアイデンティティ(例えば、ユニキャストアドレス)を学ぶ必要はありません。
For each attached link, a router selects one of its link-local unicast addresses on that link to be used as the IPv6 Source Address in all MLD packets it transmits on that link.
それぞれの付属リンクに関しては、それがそれで伝えるすべてのMLDパケットのIPv6 Source Addressがリンクするとき、ルータは、そのリンクに関するリンクローカルのユニキャストアドレスの1つが使用されるのを選択します。
Deering, et al. Standards Track [Page 4] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
デアリング、他 IPv6 October 1999のための標準化過程[4ページ]RFC2710マルチキャストリスナー発見
For each interface over which the router is operating the MLD protocol, the router must configure that interface to listen to all link-layer multicast address that can be generated by IPv6 multicasts. For example, an Ethernet-attached router must set its Ethernet address reception filter to accept all Ethernet multicast addresses that start with the hexadecimal value 3333 [IPv6-ETHER]; in the case of an Ethernet interface that does not support the filtering of such a range of multicast address, it must be configured to accept ALL Ethernet multicast addresses, in order to meet the requirements of MLD.
ルータがMLDプロトコルを操作している各インタフェースに関しては、ルータは、IPv6マルチキャストで作ることができるすべてのリンクレイヤマルチキャストアドレスを聞くためにそのインタフェースを構成しなければなりません。 例えば、イーサネットで付属しているルータは、イーサネット・アドレスレセプションフィルタに16進値から3333[IPv6-ETHER]を始めるすべてのイーサネットマルチキャストアドレスを受け入れるように設定しなければなりません。 そのようなさまざまなマルチキャストアドレスのフィルタリングを支持しないイーサネットインタフェースの場合では、すべてのイーサネットマルチキャストアドレスを受け入れるのは構成していなければなりません、MLDに関する必要条件を満たすために。
With respect to each of its attached links, a router may assume one of two roles: Querier or Non-Querier. There is normally only one Querier per link. All routers start up as a Querier on each of their attached links. If a router hears a Query message whose IPv6 Source Address is numerically less than its own selected address for that link, it MUST become a Non-Querier on that link. If [Other Querier Present Interval] passes without receiving, from a particular attached link, any Queries from a router with an address less than its own, a router resumes the role of Querier on that link.
それぞれの付属リンクに関して、ルータは2つの役割の1つを仮定するかもしれません: Querierか非Querier。 通常、1リンクあたり1Querierしかありません。 すべてのルータがそれぞれのそれらの付属リンクの上のQuerierとして始動します。 ルータがだれのIPv6 Source Addressがそれ自身のより数の上で少ないかがアドレスを選択したというQueryメッセージをそのリンクに聞くなら、それはそのリンクの上のNon-Querierにならなければなりません。 [他のQuerier Present Interval]が受信しないで通るなら、アドレスがそれ自身のより少ないルータからの特定の付属リンク、どんなQueriesからも、ルータはそのリンクの上のQuerierの役割を再開します。
A Querier for a link periodically [Query Interval] sends a General Query on that link, to solicit reports of all multicast addresses of interest on that link. On startup, a router SHOULD send [Startup Query Count] General Queries spaced closely together [Startup Query Interval] on all attached links in order to quickly and reliably discover the presence of multicast listeners on those links.
リンクへのQuerierは、そのリンクに関する興味深いすべてのマルチキャストアドレスのレポートに請求するために定期的にQuery司令官をそのリンクに送ります[質問Interval]。 始動に、SHOULDがすべてで密接に一緒に[始動Query Interval]区切られたQueries司令官を送る[始動Query Count]ルータは、それらのリンクの上にマルチキャストリスナーの存在をすぐに、そして確かに発見するためにリンクを取り付けました。
General Queries are sent to the link-scope all-nodes multicast address (FF02::1), with a Multicast Address field of 0, and a Maximum Response Delay of [Query Response Interval].
リンク範囲オールノードマルチキャストアドレス(FF02: : 1)にQueries司令官を送ります、0のMulticast Address分野、および[質問Response Interval]のMaximum Response Delayと共に。
When a node receives a General Query, it sets a delay timer for each multicast address to which it is listening on the interface from which it received the Query, EXCLUDING the link-scope all-nodes address and any multicast addresses of scope 0 (reserved) or 1 (node-local). Each timer is set to a different random value, using the highest clock granularity available on the node, selected from the range [0, Maximum Response Delay] with Maximum Response Delay as specified in the Query packet. If a timer for any address is already running, it is reset to the new random value only if the requested Maximum Response Delay is less than the remaining value of the running timer. If the Query packet specifies a Maximum Response Delay of zero, each timer is effectively set to zero, and the action specified below for timer expiration is performed immediately.
ノードがQuery司令官を受けるとき、それはそれがQueryを受けたインタフェースで聴いているそれぞれのマルチキャストアドレス、EXCLUDINGオールノードが記述して、どんなマルチキャストも記述する範囲のリンク範囲0(予約される)または1(ノード地方の)にディレイタイマを設定します。 各タイマは異なった無作為の値に設定されます、Maximum Response Delayと共に指定されるとして範囲[0、Maximum Response Delay]からノードで利用可能で、選択されたQueryパケットで最も高い時計粒状を使用して。 どんなアドレスのためのタイマも既に動いているなら、それは要求されたMaximum Response Delayが走行タイマの残余価値以下である場合にだけ新しい無作為の値にリセットされます。 QueryパケットがゼロのMaximum Response Delayを指定するなら、事実上、各タイマはゼロに設定されます、そして、以下でタイマ満了に指定された動作はすぐに、実行されます。
Deering, et al. Standards Track [Page 5] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
デアリング、他 IPv6 October 1999のための標準化過程[5ページ]RFC2710マルチキャストリスナー発見
When a node receives a Multicast-Address-Specific Query, if it is listening to the queried Multicast Address on the interface from which the Query was received, it sets a delay timer for that address to a random value selected from the range [0, Maximum Response Delay], as above. If a timer for the address is already running, it is reset to the new random value only if the requested Maximum Response Delay is less than the remaining value of the running timer. If the Query packet specifies a Maximum Response Delay of zero, the timer is effectively set to zero, and the action specified below for timer expiration is performed immediately.
ノードがMulticastアドレス詳細Queryを受けるとき、Queryが受け取られたインタフェースの質問されたMulticast Addressを聞いているなら、範囲[0、Maximum Response Delay]から選択された無作為の値へのそのアドレスにディレイタイマを設定します、上です。 アドレスのためのタイマが既に動いているなら、それは要求されたMaximum Response Delayが走行タイマの残余価値以下である場合にだけ新しい無作為の値にリセットされます。 QueryパケットがゼロのMaximum Response Delayを指定するなら、事実上、タイマはゼロに設定されます、そして、以下でタイマ満了に指定された動作はすぐに、実行されます。
If a node's timer for a particular multicast address on a particular interface expires, the node transmits a Report to that address via that interface; the address being reported is carried in both the IPv6 Destination Address field and the MLD Multicast Address field of the Report packet. The IPv6 Hop Limit of 1 (as well as the presence of a link-local IPv6 Source Address) prevent the packet from traveling beyond the link to which the reporting interface is attached.
特定のインタフェースに関する特定のマルチキャストアドレスのためのノードのタイマが期限が切れるなら、ノードはそのインタフェースを通してそのアドレスにReportを伝えます。 報告されるアドレスはIPv6 Destination Address分野とReportパケットのMLD Multicast Address分野の両方で運ばれます。 1(リンク地方のIPv6 Source Addressの存在と同様に)のIPv6 Hop Limitは、パケットが報告インタフェースが付けているリンクを超えて移動するのを防ぎます。
If a node receives another node's Report from an interface for a multicast address while it has a timer running for that same address on that interface, it stops its timer and does not send a Report for that address, thus suppressing duplicate reports on the link.
タイマがそれでそのインタフェースに関するその同じアドレスに立候補しますが、ノードがマルチキャストアドレスのためにインタフェースから別のノードのReportを受けるなら、タイマを止めて、そのアドレスのためにReportを送りません、その結果、リンクに関する写しレポートを抑圧します。
When a router receives a Report from a link, if the reported address is not already present in the router's list of multicast address having listeners on that link, the reported address is added to the list, its timer is set to [Multicast Listener Interval], and its appearance is made known to the router's multicast routing component. If a Report is received for a multicast address that is already present in the router's list, the timer for that address is reset to [Multicast Listener Interval]. If an address's timer expires, it is assumed that there are no longer any listeners for that address present on the link, so it is deleted from the list and its disappearance is made known to the multicast routing component.
ルータがリンクからReportを受けるとき、それのリスナーにリンクさせながら報告されたアドレスがルータのマルチキャストアドレスのリストに既に存在していないなら、報告されたアドレスはリストに追加されます、そして、タイマは[マルチキャストListener Interval]に設定されます、そして、外観はルータのマルチキャストルーティングコンポーネントに明らかにされます。 ルータのリストに既に存在しているマルチキャストアドレスのためにReportを受け取るなら、[マルチキャストListener Interval]にそのアドレスのためのタイマをリセットします。 アドレスsのタイマが期限が切れるなら、それがリストから削除されて、消滅がマルチキャストルーティングコンポーネントに明らかにされて、リンクの現在のそのアドレスのためのどんなリスナーももういないと思われます。
When a node starts listening to a multicast address on an interface, it should immediately transmit an unsolicited Report for that address on that interface, in case it is the first listener on the link. To cover the possibility of the initial Report being lost or damaged, it is recommended that it be repeated once or twice after short delays [Unsolicited Report Interval]. (A simple way to accomplish this is to send the initial Report and then act as if a Multicast-Address- Specific Query was received for that address, and set a timer appropriately).
ノードがすぐにマルチキャストアドレスをインタフェースを聞き始めるとき、そのインタフェースに関するそのアドレスのために求められていないReportを伝えるべきです、それがリンクの上の最初のリスナーであるといけないので。 なくされているか、または破損する初期のReportの可能性をカバーするために、それが少し遅れ[求められていないReport Interval]の後に一度か二度繰り返されるのは、お勧めです。 (これを達成する簡単な方法は、適切に初期のReportを送って、次に、まるでそのアドレスのためにMulticastアドレス特有のQueryを受け取るかのように行動して、タイマを設定することです。)
Deering, et al. Standards Track [Page 6] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
デアリング、他 IPv6 October 1999のための標準化過程[6ページ]RFC2710マルチキャストリスナー発見
When a node ceases to listen to a multicast address on an interface, it SHOULD send a single Done message to the link-scope all-routers multicast address (FF02::2), carrying in its Multicast Address field the address to which it is ceasing to listen. If the node's most recent Report message was suppressed by hearing another Report message, it MAY send nothing, as it is highly likely that there is another listener for that address still present on the same link. If this optimization is implemented, it MUST be able to be turned off but SHOULD default to on.
aであるときに、ノードは、インタフェースに関するマルチキャストアドレスを聞くのをやめて、それはリンク範囲オールルータマルチキャストアドレス(FF02: : 2)にただ一つのDoneメッセージを送って、Multicast Address分野でそれがやめているアドレスを運ぶと聴かれるSHOULDです。 ノードの最新のReportメッセージが別のReportメッセージを聞くことによって削除されたなら、何も送らないかもしれません、同じリンクのまだ現在のそのアドレスのための別のリスナーが非常にいそうなとき。 この最適化が実行されるなら、オフにすることができなければなりませんが、SHOULDがデフォルトとする、オンです。
When a router in Querier state receives a Done message from a link, if the Multicast Address identified in the message is present in the Querier's list of addresses having listeners on that link, the Querier sends [Last Listener Query Count] Multicast-Address-Specific Queries, one every [Last Listener Query Interval] to that multicast address. These Multicast-Address-Specific Queries have their Maximum Response Delay set to [Last Listener Query Interval]. If no Reports for the address are received from the link after the response delay of the last query has passed, the routers on the link assume that the address no longer has any listeners there; the address is therefore deleted from the list and its disappearance is made known to the multicast routing component. This process is continued to its resolution (i.e. until a Report is received or the last Multicast- Address-Specific Query is sent with no response) despite any transition from Querier to Non-Querier on this link.
Querier状態のルータがリンクからDoneメッセージを受け取るとき、それのリスナーにリンクさせながらメッセージで特定されたMulticast AddressがQuerierの住所録に存在しているなら、Querierはマルチキャストアドレス詳細Queriesを送ります[Listener Query Countを持続します]、1、あらゆる、[Listener Query Intervalを持続します] そのマルチキャストアドレスに。 これらのMulticastアドレス詳細Queriesは[最後のListener Query Interval]に用意ができさせます彼らのMaximum Response Delayを。 最後の質問の応答遅れが終わった後にリンクからアドレスのためのReportsを全く受け取らないなら、リンクの上のルータは、アドレスにはどんなリスナーももうそこにいないと仮定します。 したがって、アドレスはリストから削除されます、そして、消滅はマルチキャストルーティングコンポーネントに明らかにされます。 このリンクにおけるどんなQuerierからNon-Querierまでの変遷にもかかわらずも、この過程は解決(すなわち、Reportが受け取られているか、または応答なしで最後のMulticastのアドレス特有のQueryを送るまで)へ持続します。
Routers in Non-Querier state MUST ignore Done messages.
Non-Querier状態のルータはDoneメッセージを無視しなければなりません。
When a router in Non-Querier state receives a Multicast-Address- Specific Query, if its timer value for the identified multicast address is greater than [Last Listener Query Count] times the Maximum Response Delay specified in the message, it sets the address's timer to that latter value.
特定されたマルチキャストアドレスのためのタイマ値がMaximum Response Delayがメッセージで指定した[Listener Query Countを持続します]回より大きいならNon-Querier状態のルータがMulticastアドレス特有のQueryを受けるとき、それはその後者の値にアドレスsのタイマを設定します。
5. Node State Transition Diagram
5. ノード状態遷移ダイヤグラム
Node behavior is more formally specified by the state transition diagram below. A node may be in one of three possible states with respect to any single IPv6 multicast address on any single interface:
ノードの振舞いは以下の状態遷移ダイヤグラムで、より正式に指定されます。 どんな単一のインタフェースに関するどんなただ一つのIPv6マルチキャストアドレスに関してもノードが3つの可能な州の1つにあるかもしれません:
- "Non-Listener" state, when the node is not listening to the address
on the interface (i.e., no upper-layer protocol or application has
requested reception of packets to that multicast address). This
is the initial state for all multicast addresses on all
interfaces; it requires no storage in the node.
- ノードがインタフェースに関するアドレスを聞いていないときの(すなわち、どんな上側の層のプロトコルもアプリケーションもそのマルチキャストアドレスにパケットのレセプションを要求していません)「非リスナー」状態。 これはすべてのインタフェースに関するすべてのマルチキャストアドレスのための初期状態です。 それはノードにおける格納を全く必要としません。
Deering, et al. Standards Track [Page 7] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
デアリング、他 IPv6 October 1999のための標準化過程[7ページ]RFC2710マルチキャストリスナー発見
- "Delaying Listener" state, when the node is listening to the
address on the interface and has a report delay timer running for
that address.
- 「延着Listener」は、ノードがインタフェースに関するアドレスを聞いていて、レポートを持っているときにはそのアドレスのためのタイマ走行を遅らせるように述べます。
- "Idle Listener" state, when the node is listening to the address on
the interface and does not have a report delay timer running for
that address.
- 「使用されていないListener」は、ノードがインタフェースに関するアドレスを聞いていて、レポートを持っていないとき、そのアドレスのためのタイマ走行を遅らせるように述べます。
There are five significant events that can cause MLD state transitions:
MLDに状態遷移を引き起こす場合がある5回の重大な行事があります:
- "start listening" occurs when the node starts listening to the
address on the interface. It may occur only in the Non-Listener
state.
- ノードがアドレスをインタフェースを聞き始めると、「スタート聴取」は起こります。 それはNon-リスナー状態だけに起こるかもしれません。
- "stop listening" occurs when the node stops listening to the
address on the interface. It may occur only in the Delaying
Listener and Idle Listener states.
- ノードが、インタフェースに関するアドレスを聞くのを止めると、「停止聴取」は起こります。 それはDelaying ListenerとIdle Listener州だけに起こるかもしれません。
- "query received" occurs when the node receives either a valid
General Query message, or a valid Multicast-Address-Specific Query
message. To be valid, the Query message MUST come from a link-
local IPv6 Source Address, be at least 24 octets long, and have a
correct MLD checksum. The Multicast Address field in the MLD
message must contain either zero (a General Query) or a valid
multicast address (a Multicast- Address-Specific Query). A
General Query applies to all multicast addresses on the interface
from which the Query is received. A Multicast-Address-Specific
Query applies to a single multicast address on the interface from
which the Query is received. Queries are ignored for addresses in
the Non-Listener state.
- ノードが有効な一般Queryメッセージか有効なMulticastアドレス詳細Queryメッセージのどちらかを受け取るとき、「質問は受信したこと」が起こります。 Queryメッセージは、リンクの地方のIPv6 Source Addressから来て、長い間の少なくとも24の八重奏であり、有効に、なるように正しいMLDチェックサムを持たなければなりません。 MLDメッセージのMulticast Address分野はゼロ(Query司令官)か有効なマルチキャストアドレス(Multicastのアドレス特有のQuery)のどちらかを含まなければなりません。 Query司令官はQueryが受け取られているインタフェースに関するすべてのマルチキャストアドレスに適用します。 Multicastアドレス詳細QueryはQueryが受け取られているインタフェースでただ一つのマルチキャストアドレスに適用します。 質問はNon-リスナー状態のアドレスのために無視されます。
- "report received" occurs when the node receives a valid MLD Report
message. To be valid, the Report message MUST come from a link-
local IPv6 Source Address, be at least 24 octets long, and have a
correct MLD checksum. A Report applies only to the address
identified in the Multicast Address field of the Report, on the
interface from which the Report is received. It is ignored in the
Non-Listener or Idle Listener state.
- ノードが有効なMLD Reportメッセージを受け取るとき、「レポートは受信したこと」が起こります。 Reportメッセージは、リンクの地方のIPv6 Source Addressから来て、長い間の少なくとも24の八重奏であり、有効に、なるように正しいMLDチェックサムを持たなければなりません。 ReportはReportのMulticast Address分野で特定されたアドレスだけに適用します、Reportが受け取られているインタフェースで。 それはNon-リスナーかIdle Listener状態で無視されます。
- "timer expired" occurs when the report delay timer for the address
on the interface expires. It may occur only in the Delaying
Listener state.
- インタフェースに関するアドレスのためのレポートディレイタイマが期限が切れると、「タイマは期限が切れたこと」が起こります。 それはDelaying Listener状態だけに起こるかもしれません。
Deering, et al. Standards Track [Page 8] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
デアリング、他 IPv6 October 1999のための標準化過程[8ページ]RFC2710マルチキャストリスナー発見
All other events, such as receiving invalid MLD messages or MLD message types other than Query or Report, are ignored in all states.
QueryかReport以外の無効のMLDメッセージかMLDメッセージタイプを受け取ることなどの他のすべての出来事がすべての州で無視されます。
There are seven possible actions that may be taken in response to the above events:
上の出来事に対応して取られるかもしれない7つの可能な行動があります:
- "send report" for the address on the interface. The Report message
is sent to the address being reported.
- インタフェースに関するアドレスのための「レポートを送ってください。」 Reportメッセージを報告されるアドレスに送ります。
- "send done" for the address on the interface. If the flag saying
we were the last node to report is cleared, this action MAY be
skipped. The Done message is sent to the link-scope all-routers
address (FF02::2).
- インタフェースに関するアドレスのための「していた状態で、発信してください。」 私たちが報告する最後のノードであったと言う旗がきれいにされるなら、この動作はサボられるかもしれません。 リンク範囲オールルータアドレス(FF02: : 2)にDoneメッセージを送ります。
- "set flag" that we were the last node to send a report for this
address.
- 「旗を設定してください。」私たちはこのアドレスのためのレポートを送る最後のノードでした。
- "clear flag" since we were not the last node to send a report for
this address.
- 「明確な旗」は、私たちがaを送る最後のノードでなかったので、このアドレスを届け出ます。
- "start timer" for the address on the interface, using a delay value
chosen uniformly from the interval [0, Maximum Response Delay],
where Maximum Response Delay is specified in the Query. If this
is an unsolicited Report, the timer is set to a delay value chosen
uniformly from the interval [0, [Unsolicited Report Interval] ].
- インタフェースに関するアドレスのための「タイマを始動してください」、Maximum Response DelayがQueryで指定される間隔[0、Maximum Response Delay]から一様に選ばれた遅れ値を使用して。 これが求められていないReportであるなら、タイマは間隔から一様に選ばれた遅れ値に設定されます[0、[求められていないReport Interval]]。
- "reset timer" for the address on the interface to a new value,
using a delay value chosen uniformly from the interval [0, Maximum
Response Delay], as described in "start timer".
- 新しい値へのインタフェースに関するアドレスのための「タイマをリセットしてください」、間隔[0、Maximum Response Delay]から一様に選ばれた遅れ値を使用して、「スタートタイマ」で説明されるように。
- "stop timer" for the address on the interface.
- インタフェースに関するアドレスのための「タイマを止めてください。」
In all of the following state transition diagrams, each state transition arc is labeled with the event that causes the transition, and, in parentheses, any actions taken during the transition. Note that the transition is always triggered by the event; even if the action is conditional, the transition still occurs.
以下の状態遷移ダイヤグラムでは、全部で、それぞれの状態遷移アークはそして括弧(変遷の間に取られたどんな行動)で変遷を引き起こす出来事でラベルされます。 変遷がいつも出来事によって引き起こされることに注意してください。 動きが条件付きであっても、変遷はまだ起こっています。
Deering, et al. Standards Track [Page 9] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
デアリング、他 IPv6 October 1999のための標準化過程[9ページ]RFC2710マルチキャストリスナー発見
________________
| |
| |
| |
| |
--------->| Non-Listener |<---------
| | | |
| | | |
| | | |
| |________________| |
| | |
| stop listening | start listening | stop listening
| (stop timer, |(send report, | (send done if
| send done if | set flag, | flag set)
| flag set) | start timer) |
________|________ | ________|________
| |<--------- | |
| | | |
| |<-------------------| |
| | query received | |
| Delaying | (start timer) | Idle |
---->| Listener |------------------->| Listener |
| | | report received | |
| | | (stop timer, | |
| | | clear flag) | |
| |_________________|------------------->|_________________|
| query received | timer expired
| (reset timer if | (send report,
| Max Resp Delay | set flag)
| < current timer) |
-------------------
________________ | | | | | | | | --------->| 非リスナー| <、-、-、-、-、-、-、-、--、|、|、|、|、|、|、|、|、|、|、|、|、| |________________| | | | | | 聴くのを止めてください。| 聴き始めてください。| 聴くのを止めてください。| (タイマを止めてください、| (レポートを送ってください、|、(していた状態で発信してください、|、| 旗のセット) | 旗のセット) | | セット旗、スタートタイマであるならしていた状態で発信してください、) | ________|________ | ________|________ | | <、-、-、-、-、-、-、-、--、|、|、|、|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 質問は受信されました。| | | 延着します。| (スタートタイマ) | 怠けてください。| ---->| リスナー|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| リスナー| | | | レポートは受信されました。| | | | | (| | | | | 停止タイマ、明確な旗) | | | |_________________|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|_________________| | 質問は受信されました。| タイマは期限が切れました。| (| (| レポート、マックスResp Delayを送ってください| 旗を設定してください)| <の現在のタイマであるならタイマをリセットします) | -------------------
The link-scope all-nodes address (FF02::1) is handled as a special case. The node starts in Idle Listener state for that address on every interface, never transitions to another state, and never sends a Report or Done for that address.
リンク範囲オールノードアドレス(FF02: : 1)は特殊なものとして扱われます。 ノードは、あらゆるインタフェースに関するそのアドレスのためにIdle Listener状態で始まって、別の状態に決して移行しないで、またそのアドレスのためにReportかDoneを決して送りません。
MLD messages are never sent for multicast addresses whose scope is 0 (reserved) or 1 (node-local).
範囲が0(予約される)であるマルチキャストアドレスか1のために(ノード地方)でMLDメッセージを決して送りません。
MLD messages ARE sent for multicast addresses whose scope is 2 (link-local), including Solicited-Node multicast addresses [ADDR- ARCH], except for the link-scope, all-nodes address (FF02::1).
範囲が2(リンク地方の)であるマルチキャストアドレスのためにMLDメッセージを送ります、Solicited-ノードマルチキャストアドレス[ADDR- ARCH]を含んでいて、リンク範囲を除いて、オールノードアドレス(FF02: : 1)。
Deering, et al. Standards Track [Page 10] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
デアリング、他 IPv6 October 1999のための標準化過程[10ページ]RFC2710マルチキャストリスナー発見
6. Router State Transition Diagram
6. ルータ状態遷移ダイヤグラム
Router behavior is more formally specified by the state transition diagrams below.
ルータの振舞いは以下の状態遷移ダイヤグラムで、より正式に指定されます。
A router may be in one of two possible states with respect to any single attached link:
A router may be in one of two possible states with respect to any single attached link:
- "Querier", when this router is designated to transmit MLD Queries
on this link.
- "Querier", when this router is designated to transmit MLD Queries on this link.
- "Non-Querier", when there is another router designated to transmit
MLD Queries on this link.
- "Non-Querier", when there is another router designated to transmit MLD Queries on this link.
The following three events can cause the router to change states:
The following three events can cause the router to change states:
- "query timer expired" occurs when the timer set for query
transmission expires. This event is significant only when in the
Querier state.
- "query timer expired" occurs when the timer set for query transmission expires. This event is significant only when in the Querier state.
- "query received from a router with a lower IP address" occurs when
a valid MLD Query is received from a router on the same link with
a lower IPv6 Source Address. To be valid, the Query message MUST
come from a link-local IPv6 Source Address, be at least 24 octets
long, and have a correct MLD checksum.
- "query received from a router with a lower IP address" occurs when a valid MLD Query is received from a router on the same link with a lower IPv6 Source Address. To be valid, the Query message MUST come from a link-local IPv6 Source Address, be at least 24 octets long, and have a correct MLD checksum.
- "other querier present timer expired" occurs when the timer set to
note the presence of another querier with a lower IP address on
the link expires. This event is significant only when in the
Non-Querier state.
- "other querier present timer expired" occurs when the timer set to note the presence of another querier with a lower IP address on the link expires. This event is significant only when in the Non-Querier state.
There are three actions that may be taken in response to the above events:
There are three actions that may be taken in response to the above events:
- "start general query timer" for the attached link to [Query
Interval].
- "start general query timer" for the attached link to [Query Interval].
- "start other querier present timer" for the attached link to [Other
Querier Present Interval].
- "start other querier present timer" for the attached link to [Other Querier Present Interval].
- "send general query" on the attached link. The General Query is
sent to the link-scope all-nodes address (FF02::1), and has a
Maximum Response Delay of [Query Response Interval].
- "send general query" on the attached link. The General Query is sent to the link-scope all-nodes address (FF02::1), and has a Maximum Response Delay of [Query Response Interval].
Deering, et al. Standards Track [Page 11] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
Deering, et al. Standards Track [Page 11] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
--------------------------------
_______|________ gen. query timer |
--------- | | expired |
| Initial |---------------->| | (send general query, |
--------- (send gen. q., | | start gen. q. timer) |
start initial gen. q. | |<----------------------
timer) | Querier |
| |
-----| |<---
| | | |
| |________________| |
query received from a | | other querier
router with a lower | | present timer
IP address | | expired
(start other querier | ________________ | (send gen. query,
present timer) | | | | start gen. q. timer)
| | | |
| | | |
---->| Non |----
| Querier |
| |
| |
---->| |----
| |________________| |
| query received from a |
| router with a lower IP |
| address |
| (start other querier |
| present timer) |
---------------------------
-------------------------------- _______|________ gen. query timer | --------- | | expired | | Initial |---------------->| | (send general query, | --------- (send gen. q., | | start gen. q. timer) | start initial gen. q. | |<---------------------- timer) | Querier | | | -----| |<--- | | | | | |________________| | query received from a | | other querier router with a lower | | present timer IP address | | expired (start other querier | ________________ | (send gen. query, present timer) | | | | start gen. q. timer) | | | | | | | | ---->| Non |---- | Querier | | | | | ---->| |---- | |________________| | | query received from a | | router with a lower IP | | address | | (start other querier | | present timer) | ---------------------------
A router starts in the Initial state on all attached links, and immediately transitions to Querier state.
A router starts in the Initial state on all attached links, and immediately transitions to Querier state.
In addition, to keep track of which multicast addresses have listeners, a router may be in one of three possible states with respect to any single IPv6 multicast address on any single attached link:
In addition, to keep track of which multicast addresses have listeners, a router may be in one of three possible states with respect to any single IPv6 multicast address on any single attached link:
- "No Listeners Present" state, when there are no nodes on the link
that have sent a Report for this multicast address. This is the
initial state for all multicast addresses on the router; it
requires no storage in the router.
- "No Listeners Present" state, when there are no nodes on the link that have sent a Report for this multicast address. This is the initial state for all multicast addresses on the router; it requires no storage in the router.
- "Listeners Present" state, when there is a node on the link that
has sent a Report for this multicast address.
- "Listeners Present" state, when there is a node on the link that has sent a Report for this multicast address.
Deering, et al. Standards Track [Page 12] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
Deering, et al. Standards Track [Page 12] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
- "Checking Listeners" state, when the router has received a Done
message but has not yet heard a Report for the identified address.
- "Checking Listeners" state, when the router has received a Done message but has not yet heard a Report for the identified address.
There are five significant events that can cause router state transitions:
There are five significant events that can cause router state transitions:
- "report received" occurs when the router receives a Report for the
address from the link. To be valid, the Report message MUST come
from a link-local IPv6 Source Address, be at least 24 octets long,
and have a correct MLD checksum.
- "report received" occurs when the router receives a Report for the address from the link. To be valid, the Report message MUST come from a link-local IPv6 Source Address, be at least 24 octets long, and have a correct MLD checksum.
- "done received" occurs when the router receives a Done message for
the address from the link. To be valid, the Done message MUST
come from a link-local IPv6 Source Address, be at least 24 octets
long, and have a correct MLD checksum. This event is significant
only in the "Listerners Present" state and when the router is a
Querier.
- "done received" occurs when the router receives a Done message for the address from the link. To be valid, the Done message MUST come from a link-local IPv6 Source Address, be at least 24 octets long, and have a correct MLD checksum. This event is significant only in the "Listerners Present" state and when the router is a Querier.
- "multicast-address-specific query received" occurs when a router
receives a Multicast-Address-Specific Query for the address from
the link. To be valid, the Query message MUST come from a link-
local IPv6 Source Address, be at least 24 octets long, and have a
correct MLD checksum. This event is significant only in the
"Listeners Present" state and when the router is a Non-Querier.
- "multicast-address-specific query received" occurs when a router receives a Multicast-Address-Specific Query for the address from the link. To be valid, the Query message MUST come from a link- local IPv6 Source Address, be at least 24 octets long, and have a correct MLD checksum. This event is significant only in the "Listeners Present" state and when the router is a Non-Querier.
- "timer expired" occurs when the timer set for a multicast address
expires. This event is significant only in the "Listeners
Present" or "Checking Listeners" state.
- "timer expired" occurs when the timer set for a multicast address expires. This event is significant only in the "Listeners Present" or "Checking Listeners" state.
- "retransmit timer expired" occurs when the timer set to retransmit
a Multicast-Address-Specific Query expires. This event is
significant only in the "Checking Listeners" state.
- "retransmit timer expired" occurs when the timer set to retransmit a Multicast-Address-Specific Query expires. This event is significant only in the "Checking Listeners" state.
There are seven possible actions that may be taken in response to the above events:
There are seven possible actions that may be taken in response to the above events:
- "start timer" for the address on the link - also resets the timer
to its initial value [Multicast Listener Interval] if the timer is
currently running.
- "start timer" for the address on the link - also resets the timer to its initial value [Multicast Listener Interval] if the timer is currently running.
- "start timer*" for the address on the link - this alternate action
sets the timer to the minimum of its current value and either
[Last Listener Query Interval] * [Last Listener Query Count] if
this router is a Querier, or the Maximum Response Delay in the
Query message * [Last Listener Query Count] if this router is a
non-Querier.
- "start timer*" for the address on the link - this alternate action sets the timer to the minimum of its current value and either [Last Listener Query Interval] * [Last Listener Query Count] if this router is a Querier, or the Maximum Response Delay in the Query message * [Last Listener Query Count] if this router is a non-Querier.
Deering, et al. Standards Track [Page 13] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
Deering, et al. Standards Track [Page 13] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
- "start retransmit timer" for the address on the link [Last Listener
Query Interval].
- "start retransmit timer" for the address on the link [Last Listener Query Interval].
- "clear retransmit timer" for the address on the link.
- "clear retransmit timer" for the address on the link.
- "send multicast-address-specific query" for the address on the
link. The Multicast-Address-Specific Query is sent to the address
being queried, and has a Maximum Response Delay of [Last Listener
Query Interval].
- "send multicast-address-specific query" for the address on the link. The Multicast-Address-Specific Query is sent to the address being queried, and has a Maximum Response Delay of [Last Listener Query Interval].
- "notify routing +" internally notify the multicast routing protocol
that there are listeners to this address on this link.
- "notify routing +" internally notify the multicast routing protocol that there are listeners to this address on this link.
- "notify routing -" internally notify the multicast routing protocol
that there are no longer any listeners to this address on this
link.
- "notify routing -" internally notify the multicast routing protocol that there are no longer any listeners to this address on this link.
The following state diagrams apply per group per link. There are two diagrams; one for routers in Querier state and one for routers in Non-Querier state. The transition between Querier and Non-Querier state on a link is handled specially. All groups on that link in "No Listeners Present" or "Listeners Present" states switch state transition diagrams when the Querier/Non-Querier state transition occurs. However, any groups in "Checking Listeners" state continue with the same state transition diagram until the "Checking Listeners" state is exited. E.g. a router that starts as a Querier, receives a Done message for a group and then receives a Query from a router with a lower address (causing a transition to the Non-Querier state) continues to send multicast-address-specific queries for the group in question until it either receives a Report or its timer expires, at which time it starts performing the actions of a Non-Querier for this group.
The following state diagrams apply per group per link. There are two diagrams; one for routers in Querier state and one for routers in Non-Querier state. The transition between Querier and Non-Querier state on a link is handled specially. All groups on that link in "No Listeners Present" or "Listeners Present" states switch state transition diagrams when the Querier/Non-Querier state transition occurs. However, any groups in "Checking Listeners" state continue with the same state transition diagram until the "Checking Listeners" state is exited. E.g. a router that starts as a Querier, receives a Done message for a group and then receives a Query from a router with a lower address (causing a transition to the Non-Querier state) continues to send multicast-address-specific queries for the group in question until it either receives a Report or its timer expires, at which time it starts performing the actions of a Non-Querier for this group.
Deering, et al. Standards Track [Page 14] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
Deering, et al. Standards Track [Page 14] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
The state transition diagram for a router in Querier state follows:
The state transition diagram for a router in Querier state follows:
________________
| |
| |timer expired
timer expired| |(notify routing -,
(notify routing -)| No Listeners |clear rxmt tmr)
------->| Present |<---------
| | | |
| | | |
| |________________| | ---------------
| | | | rexmt timer |
| report received| | | expired |
| (notify routing +,| | | (send m-a-s |
| start timer)| | | query, |
__________|______ | ________|_|______ st rxmt |
| |<------------ | | tmr) |
| | | |<-------
| | report received | |
| | (start timer, | |
| | clear rxmt tmr) | |
| Listeners |<-------------------| Checking |
| Present | done received | Listeners |
| | (start timer*, | |
| | start rxmt timer, | |
| | send m-a-s query) | |
--->| |------------------->| |
| |_________________| |_________________|
| report received |
| (start timer) |
-----------------
________________ | | | |timer expired timer expired| |(notify routing -, (notify routing -)| No Listeners |clear rxmt tmr) ------->| Present |<--------- | | | | | | | | | |________________| | --------------- | | | | rexmt timer | | report received| | | expired | | (notify routing +,| | | (send m-a-s | | start timer)| | | query, | __________|______ | ________|_|______ st rxmt | | |<------------ | | tmr) | | | | |<------- | | report received | | | | (start timer, | | | | clear rxmt tmr) | | | Listeners |<-------------------| Checking | | Present | done received | Listeners | | | (start timer*, | | | | start rxmt timer, | | | | send m-a-s query) | | --->| |------------------->| | | |_________________| |_________________| | report received | | (start timer) | -----------------
Deering, et al. Standards Track [Page 15] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
Deering, et al. Standards Track [Page 15] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
The state transition diagram for a router in Non-Querier state is similar, but non-Queriers do not send any messages and are only driven by message reception.
The state transition diagram for a router in Non-Querier state is similar, but non-Queriers do not send any messages and are only driven by message reception.
________________
| |
| |
timer expired| |timer expired
(notify routing -)| No Listeners |(notify routing -)
--------->| Present |<---------
| | | |
| | | |
| | | |
| |________________| |
| | |
| |report received |
| |(notify routing +,|
| | start timer) |
________|________ | ________|________
| |<--------- | |
| | report received | |
| | (start timer) | |
| Listeners |<-------------------| Checking |
| Present | m-a-s query rec'd | Listeners |
| | (start timer*) | |
---->| |------------------->| |
| |_________________| |_________________|
| report received |
| (start timer) |
-----------------
________________ | | | | timer expired| |timer expired (notify routing -)| No Listeners |(notify routing -) --------->| Present |<--------- | | | | | | | | | | | | | |________________| | | | | | |report received | | |(notify routing +,| | | start timer) | ________|________ | ________|________ | |<--------- | | | | report received | | | | (start timer) | | | Listeners |<-------------------| Checking | | Present | m-a-s query rec'd | Listeners | | | (start timer*) | | ---->| |------------------->| | | |_________________| |_________________| | report received | | (start timer) | -----------------
7. List of timers and default values
7. List of timers and default values
Most of these timers are configurable. If non-default settings are used, they MUST be consistent among all routers on a single link. Note that parentheses are used to group expressions to make the algebra clear.
Most of these timers are configurable. If non-default settings are used, they MUST be consistent among all routers on a single link. Note that parentheses are used to group expressions to make the algebra clear.
7.1. Robustness Variable
7.1. Robustness Variable
The Robustness Variable allows tuning for the expected packet loss on a link. If a link is expected to be lossy, the Robustness Variable may be increased. MLD is robust to (Robustness Variable - 1) packet losses. The Robustness Variable MUST NOT be zero, and SHOULD NOT be one. Default: 2
The Robustness Variable allows tuning for the expected packet loss on a link. If a link is expected to be lossy, the Robustness Variable may be increased. MLD is robust to (Robustness Variable - 1) packet losses. The Robustness Variable MUST NOT be zero, and SHOULD NOT be one. Default: 2
Deering, et al. Standards Track [Page 16] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
Deering, et al. Standards Track [Page 16] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
7.2. Query Interval
7.2. Query Interval
The Query Interval is the interval between General Queries sent by the Querier. Default: 125 seconds.
The Query Interval is the interval between General Queries sent by the Querier. Default: 125 seconds.
By varying the [Query Interval], an administrator may tune the number of MLD messages on the link; larger values cause MLD Queries to be sent less often.
By varying the [Query Interval], an administrator may tune the number of MLD messages on the link; larger values cause MLD Queries to be sent less often.
7.3. Query Response Interval
7.3. Query Response Interval
The Maximum Response Delay inserted into the periodic General Queries. Default: 10000 (10 seconds)
The Maximum Response Delay inserted into the periodic General Queries. Default: 10000 (10 seconds)
By varying the [Query Response Interval], an administrator may tune the burstiness of MLD messages on the link; larger values make the traffic less bursty, as node responses are spread out over a larger interval. The number of seconds represented by the [Query Response Interval] must be less than the [Query Interval].
By varying the [Query Response Interval], an administrator may tune the burstiness of MLD messages on the link; larger values make the traffic less bursty, as node responses are spread out over a larger interval. The number of seconds represented by the [Query Response Interval] must be less than the [Query Interval].
7.4. Multicast Listener Interval
7.4. Multicast Listener Interval
The Multicast Listener Interval is the amount of time that must pass before a router decides there are no more listeners for an address on a link. This value MUST be ((the Robustness Variable) times (the Query Interval)) plus (one Query Response Interval).
The Multicast Listener Interval is the amount of time that must pass before a router decides there are no more listeners for an address on a link. This value MUST be ((the Robustness Variable) times (the Query Interval)) plus (one Query Response Interval).
7.5. Other Querier Present Interval
7.5. Other Querier Present Interval
The Other Querier Present Interval is the length of time that must pass before a router decides that there is no longer another router which should be the querier on a link. This value MUST be ((the Robustness Variable) times (the Query Interval)) plus (one half of one Query Response Interval).
The Other Querier Present Interval is the length of time that must pass before a router decides that there is no longer another router which should be the querier on a link. This value MUST be ((the Robustness Variable) times (the Query Interval)) plus (one half of one Query Response Interval).
7.6. Startup Query Interval
7.6. Startup Query Interval
The Startup Query Interval is the interval between General Queries sent by a Querier on startup. Default: 1/4 the Query Interval.
The Startup Query Interval is the interval between General Queries sent by a Querier on startup. Default: 1/4 the Query Interval.
7.7. Startup Query Count
7.7. Startup Query Count
The Startup Query Count is the number of Queries sent out on startup, separated by the Startup Query Interval. Default: the Robustness Variable.
The Startup Query Count is the number of Queries sent out on startup, separated by the Startup Query Interval. Default: the Robustness Variable.
Deering, et al. Standards Track [Page 17] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
Deering, et al. Standards Track [Page 17] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
7.8. Last Listener Query Interval
7.8. Last Listener Query Interval
The Last Listener Query Interval is the Maximum Response Delay inserted into Multicast-Address-Specific Queries sent in response to Done messages, and is also the amount of time between Multicast- Address-Specific Query messages. Default: 1000 (1 second)
The Last Listener Query Interval is the Maximum Response Delay inserted into Multicast-Address-Specific Queries sent in response to Done messages, and is also the amount of time between Multicast- Address-Specific Query messages. Default: 1000 (1 second)
This value may be tuned to modify the "leave latency" of the link. A reduced value results in reduced time to detect the departure of the last listener for an address.
This value may be tuned to modify the "leave latency" of the link. A reduced value results in reduced time to detect the departure of the last listener for an address.
7.9. Last Listener Query Count
7.9. Last Listener Query Count
The Last Listener Query Count is the number of Multicast-Address- Specific Queries sent before the router assumes there are no remaining listeners for an address on a link. Default: the Robustness Variable.
The Last Listener Query Count is the number of Multicast-Address- Specific Queries sent before the router assumes there are no remaining listeners for an address on a link. Default: the Robustness Variable.
7.10. Unsolicited Report Interval
7.10. Unsolicited Report Interval
The Unsolicited Report Interval is the time between repetitions of a node's initial report of interest in a multicast address. Default: 10 seconds.
The Unsolicited Report Interval is the time between repetitions of a node's initial report of interest in a multicast address. Default: 10 seconds.
8. Message Destinations
8. Message Destinations
This information is provided elsewhere in the document, but is summarized here for convenience.
This information is provided elsewhere in the document, but is summarized here for convenience.
Message Type IPv6 Destination Address ------------ ------------------------ General Query link-scope all-nodes (FF02::1) Multicast-Address-Specific Query the multicast address being queried Report the multicast address being reported Done link-scope all-routers (FF02::2)
Message Type IPv6 Destination Address ------------ ------------------------ General Query link-scope all-nodes (FF02::1) Multicast-Address-Specific Query the multicast address being queried Report the multicast address being reported Done link-scope all-routers (FF02::2)
9. Security Considerations
9. Security Considerations
We consider the ramifications of a forged message of each type. Note that the requirement that nodes verify that the IPv6 Source Address of all received MLD messages is a link-local address defends them from acting on forged MLD messages originated off-link, so we discuss only the effects of on-link forgery.
We consider the ramifications of a forged message of each type. Note that the requirement that nodes verify that the IPv6 Source Address of all received MLD messages is a link-local address defends them from acting on forged MLD messages originated off-link, so we discuss only the effects of on-link forgery.
Deering, et al. Standards Track [Page 18] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
Deering, et al. Standards Track [Page 18] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
Query message:
Query message:
A forged Query message from a machine with a lower IP address
than the current Querier will cause Querier duties to be
assigned to the forger. If the forger then sends no more Query
messages, other routers' Other Querier Present timer will time
out and one will resume the role of Querier. During this time,
if the forger ignores Done messages, traffic might flow to
addresses with no listeners for up to [Multicast Listener
Interval].
A forged Query message from a machine with a lower IP address than the current Querier will cause Querier duties to be assigned to the forger. If the forger then sends no more Query messages, other routers' Other Querier Present timer will time out and one will resume the role of Querier. During this time, if the forger ignores Done messages, traffic might flow to addresses with no listeners for up to [Multicast Listener Interval].
A forged Query message sent to an address with listeners will
cause one or more nodes that are listeners to that address to
send a Report. This causes a small amount of extra traffic on
the link, but causes no protocol problems.
A forged Query message sent to an address with listeners will cause one or more nodes that are listeners to that address to send a Report. This causes a small amount of extra traffic on the link, but causes no protocol problems.
Report message:
Report message:
A forged Report message may cause routers to think there are
listeners for an address present on a link when there are not.
However, since listening to a multicast address is generally an
unprivileged operation, a local user may trivially gain the same
result without forging any messages.
A forged Report message may cause routers to think there are listeners for an address present on a link when there are not. However, since listening to a multicast address is generally an unprivileged operation, a local user may trivially gain the same result without forging any messages.
Done message:
Done message:
A forged Done message will cause the Querier to send out
Multicast-Address-Specific Queries for the address in question.
This causes extra processing on each router and on each of the
address's listeners, and extra packets on the link, but cannot
cause loss of desired traffic.
A forged Done message will cause the Querier to send out Multicast-Address-Specific Queries for the address in question. This causes extra processing on each router and on each of the address's listeners, and extra packets on the link, but cannot cause loss of desired traffic.
10. Acknowledgments
10. Acknowledgments
MLD was derived from IGMPv2 [IGMPv2], which was designed by Rosen Sharma and Steve Deering and documented by Bill Fenner.
MLD was derived from IGMPv2 [IGMPv2], which was designed by Rosen Sharma and Steve Deering and documented by Bill Fenner.
Deering, et al. Standards Track [Page 19] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
Deering, et al. Standards Track [Page 19] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
11. References
11. References
[ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[IGMPv2] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997.
[IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC 2464, December, 1998.
[IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December, 1998.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RTR-ALERT] Partridge, C. and A. Jackson, "IPv6 Router Alert
Option", RFC 2711, October 1999.
[RTR-ALERT] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[STD-PROC] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[STD-PROC] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
Deering, et al. Standards Track [Page 20] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
Deering, et al. Standards Track [Page 20] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
12. Authors' Addresses
12. Authors' Addresses
Stephen E. Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
Stephen E. Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
Phone: +1 408 527 8213 EMail: deering@cisco.com
Phone: +1 408 527 8213 EMail: deering@cisco.com
William C. Fenner AT&T Research 75 Willow Road Menlo Park, CA 94025 USA
William C. Fenner AT&T Research 75 Willow Road Menlo Park, CA 94025 USA
Phone: +1 650 867 6073 EMail: fenner@research.att.com
Phone: +1 650 867 6073 EMail: fenner@research.att.com
Brian Haberman IBM Corporation 800 Park Office Drive Research Triangle Park, NC 27709 USA
Brian Haberman IBM Corporation 800 Park Office Drive Research Triangle Park, NC 27709 USA
Phone: +1 919 254 2673 EMail: haberman@raleigh.ibm.com
Phone: +1 919 254 2673 EMail: haberman@raleigh.ibm.com
Deering, et al. Standards Track [Page 21] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
Deering, et al. Standards Track [Page 21] RFC 2710 Multicast Listener Discovery for IPv6 October 1999
13. Full Copyright Statement
13. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
Acknowledgement
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Deering, et al. Standards Track [Page 22]
Deering, et al. Standards Track [Page 22]
一覧
スポンサーリンク
