RFC 3590 - Source Address Selection for the Multicast Listener Discovery (MLD) Protocol 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3590
タイトル : RFC 3590 - マルチキャストリスナーディスカバリー（MLD）プロトコルのソースアドレス選択
翻訳編集 : 自動生成

[要約] RFC 3590は、MLDプロトコルのためのソースアドレス選択に関する規格です。その目的は、マルチキャストリスナーのディスカバリにおいて適切なソースアドレスを選択するためのガイドラインを提供することです。

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

マルチキャストリスナーディスカバリー（MLD）プロトコルのソースアドレス選択

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）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

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.

ノードがStatelessアドレスAutoconfigurationを実行しているときに、マルチキャストリスナーディスカバリー（MLD）メッセージに適したIPv6ソースアドレスの選択に問題があることが明らかになりました。このドキュメントは、MLDメッセージに使用するIPv6アドレスを選択するルールを明確にすることを目的としています。

1. Introduction

1. はじめに

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 [RFC 2710]のマルチキャストリスナーディスカバリープロトコル（MLD）の元の仕様は、MLDメッセージの送信にLink-Local IPv6ソースアドレスの使用を義務付けています。さらに、MLDは、IPv6マルチキャストグループに参加する際にMLDレポートメッセージを送信するためにノードを必要とします（2未満のスコープのアドレスとアドレスを除く）。

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.

これらのMLD要件は、近隣発見プロトコル[RFC 2461]内でIPv6マルチキャストの使用と矛盾しています。[RFC 2462]で定義されているように、ステートレスの自動構成の場合、いくつかのIPv6マルチキャストグループに参加して、使用前に複製アドレス検出を実行するためにノードが必要です。ノードの唯一のアドレスは暫定的であり、通信に使用することはできないため、ソースアドレスとして利用するのに適したアドレスはありません。

This document will clarify the IPv6 source address selection rules for use with MLD when no link-local addresses are available.

このドキュメントは、Link-Localアドレスが利用できない場合にMLDで使用するためのIPv6ソースアドレス選択ルールを明確にします。

2. Terminology

2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119].

「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC 2119]で説明されているように解釈される。

3. Justification

3. 正当化

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ソースアドレスで送信する必要があります。ただし、Link-Local（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）が正常に完了し、衝突が発生する可能性があります。このドキュメントでは、LLマルチキャストアドレスに送信されたメッセージ（MLDを含む）に送信されたメッセージが必要に応じてすべての適切なノードに転送されることを確認するために、MLDレポートが開始される前に不特定のソースアドレスを使用して送信されることを指定することにより、この問題を修正します。

4. MLD Source Address Selection Guidelines

4. MLDソースアドレス選択ガイドライン

An MLD speaking node is required to choose a suitable IPv6 source address for all MLD messages (Report, Done, and Query).

すべてのMLDメッセージ（レポート、完了、クエリ）に適切なIPv6ソースアドレスを選択するには、MLDスピーキングノードが必要です。

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ソースアドレスとして有効なLink-Localアドレスで送信する必要があります。ノード（ルーターまたはホスト）が、不特定のアドレス（：:)に設定された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ソースアドレスとしてLink-Localアドレスで送信されます。有効なLink-Localアドレスが使用できない場合（たとえば、構成されていません）、メッセージは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.

有効なLink-Localアドレスが利用可能になると、ノードはインターフェイスに接続されているすべてのマルチキャストアドレスの新しい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レポートまたは不特定のアドレスを使用してMLDレポートまたは完了したメッセージを受信するルーターは、パケットのコンテンツでアクションを実行せずにパケットを静かに破棄する必要があります。

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ソースアドレスとして不特定のアドレスで送信されたメッセージが送信されます。

5. Source Address Selection Implications

5. ソースアドレスの選択の意味合い

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では、Link-LocalのIPv6ソースアドレスを持つために、MLDレポートと完了したメッセージが必要です。このメモは、これらのメッセージが不特定のアドレス（：:)をソースアドレスとして含めることを許可することにより、そのルールを強化します。

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.

Link-Localアドレスのアクティブ化の前に、他のマルチキャストグループに参加することに関して、送信者に影響があります。不特定のアドレスをソースアドレスとして使用したレポートのドロップは、ノードによって予想されるマルチキャストトラフィックの不足を引き起こす可能性があります。このブラックホールは、ノードが有効なリンクローカルアドレスを含むレポートを送信できるまで一時的なものになります。

6. Security Considerations

6. セキュリティに関する考慮事項

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]のセキュリティに関する考慮事項セクションで偽造メッセージを説明するものと類似しています。

7. Intellectual Property Statement

7. 知的財産声明

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エグゼクティブディレクターに宛ててください。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC 2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.

[RFC 2710] Deering、S.、Fenner、W。and B. Haberman、「IPv6のマルチキャストリスナーディスカバリー（MLD）」、RFC 2710、1999年10月。

8.2. Informative References

8.2. 参考引用

[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. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。

[RFC 2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.

[RFC 2462] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。

9. Author's Address

9. 著者の連絡先

Brian Haberman Caspian Networks 753 Bridgewater Drive Sykesville, MD 21784

ブライアンハーバーマンカスピアンネットワーク753ブリッジウォータードライブサイクスビル、メリーランド21784

   Phone: +1-410-552-1421
   EMail: brian@innovationslab.net

10. Full Copyright Statement

10. 完全な著作権声明

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エディター機能の資金は現在、インターネット協会によって提供されています。