Network Working Group B. Haberman
Request for Comments: 3590 Caspian Networks
Updates: 2710 September 2003
Category: Standards Track
Source Address Selection for the
Multicast Listener Discovery (MLD) Protocol
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
It has come to light that there is an issue with the selection of a suitable IPv6 source address for Multicast Listener Discovery (MLD) messages when a node is performing stateless address autoconfiguration. This document is intended to clarify the rules on selecting an IPv6 address to use for MLD messages.
これは、ノードがステートレスアドレス自動設定を実行しているマルチキャストリスナ発見（MLD）メッセージに適したIPv6ソースアドレスの選択に問題があることが明るみに出ました。この文書は、MLDメッセージのために使用するIPv6アドレスを選択する上でのルールを明確にすることを意図しています。
The original specification of the Multicast Listener Discovery Protocol (MLD) for IPv6 [RFC 2710] mandates the use of a link-local IPv6 source address for the transmission of MLD messages. In addition, MLD also requires nodes to send MLD Report messages when joining any IPv6 multicast group (except the All-Nodes address and addresses of scope less than 2).
IPv6のマルチキャストリスナーディスカバリプロトコル（MLD）[RFC 2710]の元の仕様は、MLDメッセージの送信のためにリンクローカルIPv6ソースアドレスを使用することを義務付け。また、MLDは、（全ノードのアドレス及び2未満の範囲のアドレスを除く）任意のIPv6マルチキャストグループに参加するときMLD報告メッセージを送信するためにノードを必要とします。
These MLD requirements conflict with the use of IPv6 multicast within the Neighbor Discovery Protocol [RFC 2461]. For stateless autoconfiguration, as defined in [RFC 2462], a node is required to join several IPv6 multicast groups in order to perform Duplicate Address Detection prior to its use. Since the only address the node has is tentative, and cannot be used for communication, it does not have a suitable address to utilize as a source address.
近隣探索プロトコル[RFC 2461]内のIPv6マルチキャストを利用してこれらのMLD要件の競合。 [RFC 2462]で定義されるようにステートレス自動設定のために、ノードは、その使用前に重複アドレス検出を実行するためにいくつかのIPv6マルチキャストグループに参加する必要があります。ノードが持つアドレスのみが仮であり、通信のために使用することができないので、送信元アドレスとして使用するために適切なアドレスを持っていません。
This document will clarify the IPv6 source address selection rules for use with MLD when no link-local addresses are available.
何のリンクローカルアドレスを使用できない場合は、この文書では、MLDで使用するためのIPv6送信元アドレス選択ルールを明確にします。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC 2119]に記載されているように解釈されます。
In [RFC 2710], Section 3 requires that all MLD messages be sent with a valid link-local IPv6 source address. However, a node in the process of performing duplicate address detection for its link-local (LL) address will not have one available to use as a source address. For this reason, this document allows the unspecified address to be used as a source address for MLD messages being used during duplicate address detection.
[RFC 2710]では、第3節では、すべてのMLDメッセージが有効なリンクローカルIPv6ソースアドレスで送信されている必要があります。しかし、そのリンクローカル（LL）アドレスの重複アドレス検出を実行するプロセス内のノードは、送信元アドレスとして使用するために利用可能なものを持っていないであろう。このため、このドキュメントは、MLDメッセージの送信元アドレスが重複アドレス検出の際に使用されるように、不特定のアドレスを使用することができます。
The discrepancies in the rules defined in [RFC 2710] and [RFC 2462] has led to implementation issues. Several IPv6 implementations skip sending MLD Report messages during duplicate address detection because they have no valid link-local address. This leads to operational problems when a node is attached to switches that perform MLD snooping. In this scenario, duplicate address detection (DAD) will complete successfully and collisions can occur once the address is put into use because switches may not have forwarded the DAD messages to all nodes on the link as required. This document fixes this problem by specifying that MLD reports are to be sent using an unspecified source address prior to DAD being started in order to ensure that messages sent to LL multicast addresses (e.g., including MLD) are forwarded to all appropriate nodes as required.
[RFC 2710]と[RFC 2462]で定義されたルールの矛盾は、実装上の問題につながっています。いくつかのIPv6実装は、彼らが有効なリンクローカルアドレスを持っていないため、重複アドレス検出時にMLDレポートメッセージを送信スキップします。これは、ノードがMLDスヌーピングを実行するスイッチに接続された操作上の問題につながります。このシナリオでは、重複アドレス検出（DAD）が正常に完了しますと、必要に応じて、スイッチがリンク上のすべてのノードにDADメッセージを転送していない可能性がありますので、アドレスが使用に供されると、衝突が発生する可能性があります。 MLDレポートは前DADが必要とされる（MLDを含む例えば、）マルチキャストアドレスをLLに送信されたメッセージは、すべての適切なノードに転送されることを確実にするために開始されるのに指定されていない送信元アドレスを使用して送信することを指定することで、これは、文書の修正この問題を。
An MLD speaking node is required to choose a suitable IPv6 source address for all MLD messages (Report, Done, and Query).
MLD圏のノードは、すべてのMLDメッセージ（完了報告書、およびクエリ）に適したIPv6ソースアドレスを選択する必要があります。
MLD Query messages MUST be sent with a valid link-local address as the IPv6 source address. If a node (router or host) receives a query message with an IPv6 source address set to the unspecified address (::), it MUST silently discard the message and SHOULD log a warning.
MLDクエリーメッセージは、IPv6送信元アドレスとして有効なリンクローカルアドレスに送らなければなりません。ノード（ルータまたはホスト）がIPv6ソース未指定アドレス（に設定されたアドレスでクエリメッセージを受信した場合：:)、それは静かにメッセージを破棄しなければならないと警告をログに記録すべきです。
MLD Report and Done messages are sent with a link-local address as the IPv6 source address, if a valid address is available on the interface. If a valid link-local address is not available (e.g., one has not been configured), the message is sent with the unspecified address (::) as the IPv6 source address.
有効なアドレスは、インターフェイス上で利用可能な場合MLDレポートと完了のメッセージは、IPv6送信元アドレスとしてリンクローカルアドレスに送信されます。 :) IPv6ソースアドレスとして有効なリンクローカルアドレスが使用できない場合（例えば、一方が設定されていない）、メッセージが不特定のアドレス（と送られます。
Once a valid link-local address is available, a node SHOULD generate new MLD Report messages for all multicast addresses joined on the interface.
有効なリンクローカルアドレスが利用可能になると、ノードはインタフェースに接続されたすべてのマルチキャストアドレスのための新しいMLDレポートメッセージを生成する必要があります。
Routers receiving an MLD Report or Done message with the unspecified address as the IPv6 source address MUST silently discard the packet without taking any action on the packets contents.
IPv6送信元アドレスとして不特定のアドレスでMLDレポートまたはDoneメッセージを受信したルータは黙ってパケットの内容に任意のアクションを取ることなく、パケットを捨てなければなりません。
Snooping switches MUST manage multicast forwarding state based on MLD Report and Done messages sent with the unspecified address as the IPv6 source address.
スヌーピングスイッチは、MLDレポートとIPv6ソースアドレスとして不特定のアドレスに送信され実行されたメッセージに基づいて、マルチキャスト転送状態を管理する必要があります。
In RFC 2710, MLD Report and Done messages are required to have an IPv6 source address that is link-local. This memo augments that rule by allowing these messages to contain the unspecified address (::) as the source address.
RFC 2710では、MLDレポートと完了のメッセージがリンクローカルであるIPv6送信元アドレスを持つことが必要とされています。送信元アドレスとして:)：このメモは、これらのメッセージは未指定アドレスを（含有させることによって、そのルールを強化します。
The behavior of RFC 2710 implementations, when receiving a message with a source address of ::, is dependent upon how the implementation treats the unspecified address. That is, these messages will be dropped if the implementation does not consider the unspecified address to be link-local in scope.
::の送信元アドレスを持つメッセージを受信した場合、RFC 2710個の実装の動作は、実装が未指定アドレスを処理する方法に依存しています。実装はリンクローカルスコープであることを未指定アドレスを考慮しない場合、すなわち、これらのメッセージはドロップされます。
As the unspecified address is only used when there is no link-local address, RFC 2710 implementations discarding these packets will have no affect on the packet's sender as the use should only be for joining the link-local solicited-node multicast group [RFC 2462].
何のリンクローカルアドレスがない場合、不特定のアドレスのみが使用されているとして、使用のみリンクローカル要請ノードマルチキャストグループに参加するためにする必要がありますように、これらのパケットを破棄するRFC 2710個の実装には、パケットの送信者に影響を与えていません[RFC 2462 ]。
There is an implication to senders with respect to joining other multicast groups prior to the activation of a link-local address. The dropping of Reports using the unspecified address as a source address could cause a lack of multicast traffic that is expected by the node. This black hole will be temporary until the node can send a Report with a valid link-local address.
リンクローカルアドレスの活性化に先立って他のマルチキャストグループに参加に対する送信者の含意があります。送信元アドレスとして不特定のアドレスを使用したレポートの落下は、ノードが期待されているマルチキャストトラフィックの不足を引き起こす可能性があります。ノードが有効なリンクローカルアドレスを使用してレポートを送信できるようになるまで、このブラックホールは一時的になります。
General security issues related to MLD are discussed in [RFC 2710].
MLDに関連する一般的なセキュリティ上の問題は、[RFC 2710]で議論されています。
For hosts and routers, all received MLD messages from an unspecified source address are silently discarded. This is the required behavior from [RFC 2710] and is not changed by this document. Thus, the changes have no new security impacts.
ホストとルータのために、未指定の送信元アドレスから受信したすべてのMLDメッセージは黙って破棄されます。これは、[RFC 2710]から必要な動作であり、このドキュメントでは変更されません。このため、変更には、新しいセキュリティへの影響を持っていません。
In the case of snooping switches, multicast forwarding state will be maintained based on Report and Done messages sent with the unspecified address as the source address. However, the security vulnerabilities in this scenario are similar to those describing forged messages in the security considerations section of [RFC 2710].
スイッチをスヌーピングする場合には、マルチキャスト転送状態がレポート送信元アドレスとして不特定のアドレスに送信された完了メッセージに基づいて維持されます。しかし、このシナリオでは、セキュリティの脆弱性は、[RFC 2710]のセキュリティ問題部に偽造メッセージを記述したものと同様です。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC 2710] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
"IPv6のためのマルチキャストリスナー発見（MLD）" [RFC 2710]デアリング、S.、フェナー、W.およびB.ハーバーマン、RFC 2710、1999年10月。
[RFC 2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC 2461] Narten氏、T.、Nordmarkと、E.およびW.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[RFC 2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC 2462]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。
Brian Haberman Caspian Networks 753 Bridgewater Drive Sykesville, MD 21784
ブライアンハーバーマンカスピアン・ネットワーク753ブリッジウォータードライブSykesville、MD 21784
Phone: +1-410-552-1421 EMail: brian@innovationslab.net
電話：+ 1-410-552-1421 Eメール：brian@innovationslab.net
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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 assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
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
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。