[要約] RFC 8114は、IPv6マルチキャストネットワーク上のIPv4クライアントへのIPv4マルチキャストサービスの提供に関するものです。このRFCの目的は、IPv6ネットワーク上でIPv4マルチキャストをサポートするためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 8114 Orange
Category: Standards Track C. Qin
ISSN: 2070-1721 Cisco
C. Jacquenet
Orange
Y. Lee
Comcast
Q. Wang
China Telecom
March 2017
Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network
IPv6マルチキャストネットワークを介したIPv4クライアントへのIPv4マルチキャストサービスの配信
Abstract
概要
This document specifies a solution for the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and uses an IPv6 multicast distribution tree to deliver IPv4 multicast traffic. The solution is particularly useful for the delivery of multicast service offerings to customers serviced by Dual-Stack Lite (DS-Lite).
このドキュメントでは、IPv6マルチキャストネットワークを介してIPv4クライアントにIPv4マルチキャストサービスを配信するためのソリューションについて説明します。このソリューションは、ステートレスIPv4-in-IPv6カプセル化スキームに依存し、IPv6マルチキャスト配布ツリーを使用してIPv4マルチキャストトラフィックを配信します。このソリューションは、Dual-Stack Lite（DS-Lite）がサービスを提供する顧客にマルチキャストサービスを提供する場合に特に役立ちます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8114.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8114で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6
4.1. IPv4-Embedded IPv6 Prefixes . . . . . . . . . . . . . . . 7
4.2. Multicast Distribution Tree Computation . . . . . . . . . 8
4.3. Multicast Data Forwarding . . . . . . . . . . . . . . . . 9
5. IPv4/IPv6 Address Mapping . . . . . . . . . . . . . . . . . . 9
5.1. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 9
5.2. Multicast Address Translation Algorithm . . . . . . . . . 10
5.3. Textual Representation . . . . . . . . . . . . . . . . . 10
5.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Multicast B4 (mB4) . . . . . . . . . . . . . . . . . . . . . 11
6.1. IGMP-MLD Interworking Function . . . . . . . . . . . . . 11
6.2. Multicast Data Forwarding . . . . . . . . . . . . . . . . 12
6.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 12
6.4. Host Built-In mB4 Function . . . . . . . . . . . . . . . 12
6.5. Preserve the Scope . . . . . . . . . . . . . . . . . . . 13
7. Multicast AFTR (mAFTR) . . . . . . . . . . . . . . . . . . . 13
7.1. Routing Considerations . . . . . . . . . . . . . . . . . 13
7.2. Processing PIM Messages . . . . . . . . . . . . . . . . . 14
7.3. Switching from Shared Tree to Shortest Path Tree . . . . 15
7.4. Multicast Data Forwarding . . . . . . . . . . . . . . . . 15
7.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Deployment Considerations . . . . . . . . . . . . . . . . . . 16
8.1. Other Operational Modes . . . . . . . . . . . . . . . . . 16
8.1.1. The IPv6 DR is Co-located with the mAFTR . . . . . . 16
8.1.2. The IPv4 DR is Co-located with the mAFTR . . . . . . 16
8.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 16
8.3. mAFTR Policy Configuration . . . . . . . . . . . . . . . 16
8.4. Static vs. Dynamic PIM Triggering . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9.1. Firewall Configuration . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Use Case: IPTV . . . . . . . . . . . . . . . . . . . 21
Appendix B. Older Versions of Group Membership Management
Protocols . . . . . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
DS-Lite [RFC6333] is an IPv4 address-sharing technique that enables operators to multiplex public IPv4 addresses while provisioning only IPv6 to users. A typical DS-Lite scenario is the delivery of an IPv4 service to an IPv4 user over an IPv6 network (denoted as a 4-6-4 scenario). [RFC6333] covers unicast services exclusively.
DS-Lite [RFC6333]は、オペレーターがパブリックIPv4アドレスを多重化しながら、ユーザーにIPv6のみをプロビジョニングできるようにするIPv4アドレス共有技術です。典型的なDS-Liteシナリオは、IPv6ネットワークを介したIPv4ユーザーへのIPv4サービスの配信です（4-6-4シナリオとして示されています）。 [RFC6333]はユニキャストサービスのみを対象としています。
This document specifies a generic solution for the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution was developed with DS-Lite in mind (see more discussion below). However, the solution is not limited to DS-Lite; it can also be applied in other deployment contexts, such as the ones described in [RFC7596] and [RFC7597].
このドキュメントでは、IPv6マルチキャストネットワークを介してIPv4クライアントにIPv4マルチキャストサービスを配信するための一般的なソリューションについて説明します。このソリューションはDS-Liteを念頭に置いて開発されました（以下の説明を参照）。ただし、ソリューションはDS-Liteに限定されません。 [RFC7596]や[RFC7597]で説明されているものなど、他のデプロイメントコンテキストにも適用できます。
If customers have to access IPv4 multicast-based services through a DS-Lite environment, Address Family Transition Router (AFTR) devices will have to process all the Internet Group Management Protocol (IGMP) Report messages [RFC2236] [RFC3376] that have been forwarded by the Customer Premises Equipment (CPE) into the IPv4-in-IPv6 tunnels. From that standpoint, AFTR devices are likely to behave as a replication point for downstream multicast traffic, and the multicast packets will be replicated for each tunnel endpoint that IPv4 receivers are connected to.
お客様がDS-Lite環境を介してIPv4マルチキャストベースのサービスにアクセスする必要がある場合、アドレスファミリ遷移ルーター（AFTR）デバイスは、転送されたすべてのインターネットグループ管理プロトコル（IGMP）レポートメッセージ[RFC2236] [RFC3376]を処理する必要があります。 Customer Premises Equipment（CPE）によってIPv4-in-IPv6トンネルに。その観点から、AFTRデバイスはダウンストリームマルチキャストトラフィックのレプリケーションポイントとして動作する可能性が高く、マルチキャストパケットはIPv4レシーバーが接続されているトンネルエンドポイントごとに複製されます。
This kind of DS-Lite environment raises two major issues:
この種のDS-Lite環境には、2つの大きな問題があります。
1. The IPv6 network loses the benefits of efficient multicast traffic forwarding because it is unable to deterministically replicate the data as close to the receivers as possible. As a consequence, the downstream bandwidth in the IPv6 network will be vastly consumed by sending multicast data over a unicast infrastructure.
1. IPv6ネットワークは、レシーバーのできるだけ近くでデータを確定的に複製することができないため、効率的なマルチキャストトラフィック転送の利点を失います。その結果、IPv6ネットワークのダウンストリーム帯域幅は、ユニキャストインフラストラクチャを介してマルチキャストデータを送信することによって大幅に消費されます。
2. The AFTR is responsible for replicating multicast traffic and forwarding it into each tunnel endpoint connecting IPv4 receivers that have explicitly asked for the corresponding content. This process may significantly consume the AFTR's resources and overload the AFTR.
2. AFTRは、マルチキャストトラフィックを複製し、対応するコンテンツを明示的に要求したIPv4レシーバーを接続する各トンネルエンドポイントに転送します。このプロセスは、AFTRのリソースを大幅に消費し、AFTRに過負荷をかける可能性があります。
This document specifies an extension to the DS-Lite model to deliver IPv4 multicast services to IPv4 clients over an IPv6 multicast-enabled network.
このドキュメントでは、IPv6マルチキャスト対応ネットワークを介してIPv4クライアントにIPv4マルチキャストサービスを配信するためのDS-Liteモデルの拡張について説明します。
This document describes a stateless translation mechanism that supports either Source-Specific Multicast (SSM) or Any-Source Multicast (ASM) operation. The recommendation in Section 1 of [RFC4607] is that multicast services use SSM where possible; the operation of the translation mechanism is also simplified when SSM is used, e.g., considerations for placement of the IPv6 Rendezvous Point (RP) are no longer relevant.
このドキュメントでは、Source-Specific Multicast（SSM）またはAny-Source Multicast（ASM）操作をサポートするステートレス変換メカニズムについて説明します。 [RFC4607]のセクション1の推奨事項は、マルチキャストサービスは可能な限りSSMを使用することです。 SSMを使用すると、変換メカニズムの操作も簡素化されます。たとえば、IPv6ランデブーポイント（RP）の配置に関する考慮事項は、もはや関係ありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This document makes use of the following terms:
このドキュメントでは、次の用語を使用しています。
IPv4-embedded IPv6 address: an IPv6 address that embeds a 32-bit-encoded IPv4 address. An IPv4-embedded IPv6 address can be unicast or multicast.
IPv4埋め込みIPv6アドレス：32ビットでエンコードされたIPv4アドレスを埋め込んだIPv6アドレス。 IPv4組み込みIPv6アドレスは、ユニキャストまたはマルチキャストにすることができます。
mPrefix64: a dedicated multicast IPv6 prefix for constructing IPv4-embedded IPv6 multicast addresses. mPrefix64 can be of two types: ASM_mPrefix64 used in Any-Source Multicast (ASM) mode or SSM_mPrefix64 used in Source-Specific Multicast (SSM) mode [RFC4607]. The size of this prefix is /96.
mPrefix64：IPv4埋め込みIPv6マルチキャストアドレスを構築するための専用マルチキャストIPv6プレフィックス。 mPrefix64には、Any_Source Multicast（ASM）モードで使用されるASM_mPrefix64またはSource-Specific Multicast（SSM）モードで使用されるSSM_mPrefix64の2つのタイプがあります[RFC4607]。このプレフィックスのサイズは/ 96です。
Note: "64" is used as an abbreviation for IPv6-IPv4 interconnection.
注：「64」はIPv6-IPv4相互接続の略語として使用されます。
uPrefix64: a dedicated IPv6 unicast prefix for constructing IPv4-embedded IPv6 unicast addresses [RFC6052]. This prefix may be either the Well-Known Prefix (i.e., 64:ff9b::/96) or a Network-Specific Prefix (NSP).
uPrefix64：IPv4埋め込みIPv6ユニキャストアドレスを構築するための専用IPv6ユニキャストプレフィックス[RFC6052]。このプレフィックスは、既知のプレフィックス（64：ff9b :: / 96など）またはネットワーク固有のプレフィックス（NSP）のいずれかです。
Multicast AFTR (mAFTR): a functional entity that supports an IPv4-IPv6 multicast interworking function (refer to Figure 3). It receives and encapsulates the IPv4 multicast packets into IPv4-in-IPv6 packets. Also, it behaves as the corresponding IPv6 multicast source for the encapsulated IPv4-in-IPv6 packets.
マルチキャストAFTR（mAFTR）：IPv4-IPv6マルチキャストインターワーキング機能をサポートする機能エンティティ（図3を参照）。 IPv4マルチキャストパケットを受信してIPv4-in-IPv6パケットにカプセル化します。また、カプセル化されたIPv4-in-IPv6パケットの対応するIPv6マルチキャストソースとして動作します。
Multicast Basic Bridging BroadBand (mB4): a functional entity that supports an IGMP-MLD Interworking function (refer to Section 6.1) that translates the IGMP messages into the corresponding Multicast Listener Discovery (MLD) messages and sends the MLD messages to the IPv6 network. In addition, the mB4 decapsulates IPv4-in-IPv6 multicast packets.
Multicast Basic Bridging BroadBand（mB4）：IGMPメッセージを対応するMulticast Listener Discovery（MLD）メッセージに変換し、MLDメッセージをIPv6ネットワークに送信するIGMP-MLDインターワーキング機能（セクション6.1を参照）をサポートする機能エンティティ。さらに、mB4はIPv4-in-IPv6マルチキャストパケットのカプセル化を解除します。
PIMv4: refers to Protocol Independent Multicast (PIM) when deployed in an IPv4 infrastructure (i.e., IPv4 transport capabilities are used to exchange PIM messages).
PIMv4：IPv4インフラストラクチャーにデプロイされたときのプロトコル独立マルチキャスト（PIM）を指します（つまり、IPv4トランスポート機能がPIMメッセージの交換に使用されます）。
PIMv6: refers to PIM when deployed in an IPv6 infrastructure (i.e., IPv6 transport capabilities are used to exchange PIM messages).
PIMv6：IPv6インフラストラクチャーにデプロイされたときのPIMを指します（つまり、IPv6トランスポート機能がPIMメッセージの交換に使用されます）。
Host portion of the MLD protocol: refers to the part of MLD that applies to all multicast address listeners (Section 6 of [RFC3810]). As a reminder, MLD specifies separate behaviors for multicast address listeners (i.e., hosts or routers that listen to multicast packets) and multicast routers.
MLDプロトコルのホスト部分：すべてのマルチキャストアドレスリスナーに適用されるMLDの部分を指します（[RFC3810]のセクション6）。注意として、MLDはマルチキャストアドレスリスナー（つまり、マルチキャストパケットをリッスンするホストまたはルーター）とマルチキャストルーターに対して別々の動作を指定します。
Router portion of IGMP: refers to the part of IGMP that is performed by multicast routers (Section 6 of [RFC3376]).
IGMPのルーター部分：マルチキャストルーターによって実行されるIGMPの部分を指します（[RFC3376]のセクション6）。
DR: refers to the Designated Router as defined in [RFC7761].
DR：[RFC7761]で定義されている指定ルーターを指します。
This document focuses only on the subscription to IPv4 multicast groups and the delivery of IPv4-formatted content to IPv4 receivers over an IPv6-only network. In particular, only the following case is covered:
このドキュメントでは、IPv4マルチキャストグループへのサブスクリプションと、IPv6のみのネットワークを介したIPv4受信者へのIPv4形式のコンテンツの配信にのみ焦点を当てています。特に、次のケースのみがカバーされています。
IPv4 receivers access IPv4 multicast content over IPv6-only multicast-enabled networks.
IPv4レシーバーは、IPv6のみのマルチキャスト対応ネットワークを介してIPv4マルチキャストコンテンツにアクセスします。
This document does not cover the source/receiver heuristics, where IPv4 receivers can also behave as IPv4 multicast sources. This document assumes that hosts behind the mB4 are IPv4 multicast receivers only. Also, the document covers the host built-in mB4 function.
このドキュメントでは、IPv4レシーバーがIPv4マルチキャストソースとしても動作できるソース/レシーバーヒューリスティックについては説明していません。このドキュメントでは、mB4の背後にあるホストはIPv4マルチキャストレシーバーのみであると想定しています。また、このドキュメントでは、ホストの組み込みmB4関数についても説明しています。
In the DS-Lite specification [RFC6333], an IPv4-in-IPv6 tunnel is used to carry bidirectional IPv4 unicast traffic between a B4 and an AFTR. The solution specified in this document provides an IPv4-in-IPv6 encapsulation scheme to deliver unidirectional IPv4 multicast traffic from an mAFTR to an mB4.
DS-Lite仕様[RFC6333]では、IPv4内IPv6トンネルを使用して、B4とAFTRの間で双方向のIPv4ユニキャストトラフィックを伝送します。このドキュメントで指定されているソリューションは、mAFTRからmB4に単方向IPv4マルチキャストトラフィックを配信するIPv4-in-IPv6カプセル化スキームを提供します。
An overview of the solution is provided in this section; it is intended as an introduction to how it works but is not normative. For the normative specifications of the two new functional elements, mB4 and mAFTR (Figure 1), refer to Sections 6 and 7.
このセクションでは、ソリューションの概要について説明します。それがどのように機能するかの紹介として意図されていますが、規範的ではありません。 2つの新しい機能要素、mB4とmAFTR（図1）の規範的な仕様については、セクション6と7を参照してください。
------------
/ \
| IPv4 network |
\ /
------------
IPv4 multicast : | ^ PIMv4 Join
v | :
+-------------+
| mAFTR |
+-------------+
IPv6 multicast |:| | ^ PIMv6 Join (PIMv6
(IPv4 embedded) |:| | : routers in between)
------------
/ \
| IPv6 network |
\ /
------------
|:| | ^ MLD Report
|v| | :
+-----------+
| mB4 |
+-----------+
IPv4 multicast : | ^ IGMP Report
v | :
+-----------+
| IPv4 |
| receiver |
+-----------+
Figure 1: Functional Architecture
図1：機能アーキテクチャ
In order to map the addresses of IPv4 multicast traffic with IPv6 multicast addresses, an IPv6 multicast prefix (mPrefix64) and an IPv6 unicast prefix (uPrefix64) are provided to the mAFTR and the mB4 elements, both of which contribute to the computation and the maintenance of the IPv6 multicast distribution tree that extends the IPv4 multicast distribution tree into the IPv6 multicast network. The IPv4/IPv6 address mapping is stateless.
IPv4マルチキャストトラフィックのアドレスをIPv6マルチキャストアドレスにマップするために、IPv6マルチキャストプレフィックス（mPrefix64）およびIPv6ユニキャストプレフィックス（uPrefix64）がmAFTRおよびmB4要素に提供されます。これらはどちらも計算とメンテナンスに寄与します。 IPv4マルチキャスト配布ツリーをIPv6マルチキャストネットワークに拡張するIPv6マルチキャスト配布ツリーの例。 IPv4 / IPv6アドレスマッピングはステートレスです。
The mAFTR and the mB4 use mPrefix64 to convert an IPv4 multicast address (G4) into an IPv4-embedded IPv6 multicast address (G6). The mAFTR and the mB4 use uPrefix64 to convert an IPv4 source address (S4) into an IPv4-embedded IPv6 address (S6). The mAFTR and the mB4 must use the same mPrefix64 and uPrefix64; they also run the same algorithm for building IPv4-embedded IPv6 addresses. Refer to Section 5 for more details about the address mapping.
mAFTRとmB4はmPrefix64を使用して、IPv4マルチキャストアドレス（G4）をIPv4組み込みIPv6マルチキャストアドレス（G6）に変換します。 mAFTRとmB4はuPrefix64を使用して、IPv4ソースアドレス（S4）をIPv4埋め込みIPv6アドレス（S6）に変換します。 mAFTRとmB4は同じmPrefix64とuPrefix64を使用する必要があります。また、IPv4埋め込みIPv6アドレスを構築するために同じアルゴリズムを実行します。アドレスマッピングの詳細については、セクション5を参照してください。
When an IPv4 receiver connected to the device that embeds the mB4 capability wants to subscribe to an IPv4 multicast group, it sends an IGMP Report message towards the mB4. The mB4 creates the IPv6 multicast group (G6) address using mPrefix64 and the original IPv4 multicast group address. If the receiver sends a source-specific IGMPv3 Report message, the mB4 will create the IPv6 source address (S6) using uPrefix64 and the original IPv4 source address.
mB4機能を組み込んだデバイスに接続されたIPv4レシーバーがIPv4マルチキャストグループにサブスクライブする場合、それはIGMPレポートメッセージをmB4に送信します。 mB4は、mPrefix64と元のIPv4マルチキャストグループアドレスを使用して、IPv6マルチキャストグループ（G6）アドレスを作成します。受信者が送信元固有のIGMPv3レポートメッセージを送信すると、mB4はuPrefix64と元のIPv4送信元アドレスを使用してIPv6送信元アドレス（S6）を作成します。
The mB4 uses the G6 (and both S6 and G6 in SSM) to create the corresponding MLD Report message. The mB4 sends the Report message towards the IPv6 network. The PIMv6 DR receives the MLD Report message and sends the PIMv6 Join message to join the IPv6 multicast distribution tree. It can send either PIMv6 Join (*,G6) in ASM or PIMv6 Join (S6,G6) in SSM to the mAFTR.
mB4はG6（およびSSMのS6とG6の両方）を使用して、対応するMLDレポートメッセージを作成します。 mB4はIPv6ネットワークに向けてレポートメッセージを送信します。 PIMv6 DRはMLDレポートメッセージを受信し、PIMv6参加メッセージを送信してIPv6マルチキャスト配信ツリーに参加します。 ASMのPIMv6結合（*、G6）またはSSMのPIMv6結合（S6、G6）のいずれかをmAFTRに送信できます。
The mAFTR acts as the IPv6 DR to which the uPrefix64-derived S6 is connected. The mAFTR will receive the source-specific PIMv6 Join message (S6,G6) from the IPv6 multicast network. If the mAFTR is the Rendezvous Point (RP) of G6, it will receive the any-source PIMv6 Join message (*,G6) from the IPv6 multicast network. If the mAFTR is not the RP of G6, it will send the PIM Register message to the RP of G6 located in the IPv6 multicast network. For the sake of simplicity, it is recommended to configure the mAFTR as the RP for the IPv4-embedded IPv6 multicast groups it manages; no registration procedure is required under this configuration.
mAFTRは、uPrefix64から派生したS6が接続されているIPv6 DRとして機能します。 mAFTRは、IPv6マルチキャストネットワークからソース固有のPIMv6 Joinメッセージ（S6、G6）を受信します。 mAFTRがG6のランデブーポイント（RP）の場合、IPv6マルチキャストネットワークから任意のソースのPIMv6 Joinメッセージ（*、G6）を受信します。 mAFTRがG6のRPでない場合、PIM RegisterメッセージをIPv6マルチキャストネットワークにあるG6のRPに送信します。簡単にするために、mAFTRを管理するIPv4組み込みIPv6マルチキャストグループのRPとして設定することをお勧めします。この構成では、登録手順は必要ありません。
When the mAFTR receives the PIMv6 Join message (*,G6), it will extract the IPv4 multicast group address (G4). If the mAFTR is the RP of G4 in the IPv4 multicast network, it will create a (*,G4) entry (if such entry does not already exist) in its own IPv4 multicast routing table. If the mAFTR is not the RP of G4, it will send the corresponding PIMv4 Join message (*,G4) towards the RP of G4 in the IPv4 multicast network.
mAFTRがPIMv6加入メッセージ（*、G6）を受信すると、IPv4マルチキャストグループアドレス（G4）を抽出します。 mAFTRがIPv4マルチキャストネットワークのG4のRPである場合、mAFTRは独自のIPv4マルチキャストルーティングテーブルに（*、G4）エントリを作成します（そのようなエントリがまだ存在しない場合）。 mAFTRがG4のRPでない場合、対応するPIMv4 Joinメッセージ（*、G4）をIPv4マルチキャストネットワークのG4のRPに送信します。
When the mAFTR receives the PIMv6 Join message (S6,G6), it will extract the IPv4 multicast group address (G4) and IPv4 source address (S4) and send the corresponding (S4,G4) PIMv4 Join message directly to the IPv4 source.
mAFTRがPIMv6加入メッセージ（S6、G6）を受信すると、IPv4マルチキャストグループアドレス（G4）およびIPv4送信元アドレス（S4）を抽出し、対応する（S4、G4）PIMv4加入メッセージをIPv4送信元に直接送信します。
A branch of the multicast distribution tree is thus constructed, comprising both an IPv4 part (from the mAFTR upstream) and an IPv6 part (from mAFTR downstream towards the mB4).
このようにして、マルチキャスト配布ツリーのブランチが構築され、IPv4部分（mAFTR上流から）とIPv6部分（mAFTR下流からmB4に向かって）の両方を含みます。
The mAFTR advertises the route of uPrefix64 with an IPv6 Interior Gateway Protocol (IGP), so as to represent the IPv4-embedded IPv6 source in the IPv6 multicast network and to allow IPv6 routers to run the Reverse Path Forwarding (RPF) check procedure on incoming multicast traffic. Injecting internal /96 routes is not problematic given the recommendation in [RFC7608] that requires that forwarding processes must be designed to process prefixes of any length up to /128.
mAFTRは、IPv6 Interior Gateway Protocol（IGP）を使用してuPrefix64のルートをアドバタイズし、IPv6マルチキャストネットワーク内のIPv4組み込みIPv6ソースを表し、IPv6ルーターが着信でリバースパス転送（RPF）チェック手順を実行できるようにしますマルチキャストトラフィック。内部/ 96ルートの注入は、転送プロセスが/ 128までの任意の長さのプレフィックスを処理するように設計されなければならないことを要求する[RFC7608]の推奨事項を考慮すると問題にはなりません。
When the mAFTR receives an IPv4 multicast packet, it will encapsulate the packet into an IPv6 multicast packet using the IPv4-embedded IPv6 multicast address as the destination address and an IPv4-embedded IPv6 unicast address as the source address. The encapsulated IPv6 multicast packet will be forwarded down the IPv6 multicast distribution tree, and the mB4 will eventually receive the packet.
mAFTRはIPv4マルチキャストパケットを受信すると、IPv4埋め込みIPv6マルチキャストアドレスを宛先アドレスとして、IPv4埋め込みIPv6ユニキャストアドレスを送信元アドレスとして使用して、パケットをIPv6マルチキャストパケットにカプセル化します。カプセル化されたIPv6マルチキャストパケットはIPv6マルチキャスト配信ツリーを下に転送され、mB4は最終的にパケットを受信します。
The IPv6 multicast network treats the IPv4-in-IPv6 encapsulated multicast packets as native IPv6 multicast packets. The IPv6 multicast routers use the outer IPv6 header to make their forwarding decisions.
IPv6マルチキャストネットワークは、IPv4-in-IPv6カプセル化マルチキャストパケットをネイティブIPv6マルチキャストパケットとして扱います。 IPv6マルチキャストルーターは、外部IPv6ヘッダーを使用して転送を決定します。
When the mB4 receives the IPv6 multicast packet (to G6) derived by mPrefix64, it decapsulates it and forwards the original IPv4 multicast packet towards the receivers subscribing to G4.
mB4は、mPrefix64によって導出された（G6への）IPv6マルチキャストパケットを受信すると、カプセル化を解除し、元のIPv4マルチキャストパケットをG4にサブスクライブする受信者に転送します。
Note: At this point, only IPv4-in-IPv6 encapsulation is defined; however, other types of encapsulation could be defined in the future.
注：この時点では、IPv4-in-IPv6カプセル化のみが定義されています。ただし、他のタイプのカプセル化が将来定義される可能性があります。
A dedicated IPv6 multicast prefix (mPrefix64) is provisioned to the mAFTR and the mB4. The mAFTR and the mB4 use the mPrefix64 to form an IPv6 multicast group address from an IPv4 multicast group address. The mPrefix64 can be of two types: ASM_mPrefix64 (an mPrefix64 used in ASM mode) or SSM_mPrefix64 (an mPrefix64 used in SSM mode). The mPrefix64 MUST be derived from the corresponding IPv6 multicast address space (e.g., the SSM_mPrefix64 must be in the range of the multicast address space specified in [RFC4607]).
専用IPv6マルチキャストプレフィックス（mPrefix64）がmAFTRとmB4にプロビジョニングされます。 mAFTRとmB4はmPrefix64を使用して、IPv4マルチキャストグループアドレスからIPv6マルチキャストグループアドレスを形成します。 mPrefix64には、ASM_mPrefix64（ASMモードで使用されるmPrefix64）またはSSM_mPrefix64（SSMモードで使用されるmPrefix64）の2つのタイプがあります。 mPrefix64は、対応するIPv6マルチキャストアドレススペースから派生する必要があります（たとえば、SSM_mPrefix64は、[RFC4607]で指定されたマルチキャストアドレススペースの範囲内にある必要があります）。
The IPv6 part of the multicast distribution tree can be seen as an extension of the IPv4 part of the multicast distribution tree. The IPv4 source address MUST be mapped to an IPv6 source address. An IPv6 unicast prefix (uPrefix64) is provisioned to the mAFTR and the mB4. The mAFTR and the mB4 use the uPrefix64 to form an IPv6 source address from an IPv4 source address as specified in [RFC6052]. The uPrefix-formed IPv6 source address will represent the original IPv4 source in the IPv6 multicast network. The uPrefix64 MUST be derived from the IPv6 unicast address space.
マルチキャスト配信ツリーのIPv6部分は、マルチキャスト配信ツリーのIPv4部分の拡張と見なすことができます。 IPv4送信元アドレスは、IPv6送信元アドレスにマップする必要があります。 IPv6ユニキャストプレフィックス（uPrefix64）がmAFTRおよびmB4にプロビジョニングされます。 mAFTRとmB4は、uPrefix64を使用して、[RFC6052]で指定されているIPv4送信元アドレスからIPv6送信元アドレスを形成します。 uPrefix形式のIPv6送信元アドレスは、IPv6マルチキャストネットワークの元のIPv4送信元を表します。 uPrefix64はIPv6ユニキャストアドレススペースから派生する必要があります。
The multicast address translation MUST follow the algorithm defined in Section 5.2.
マルチキャストアドレス変換は、セクション5.2で定義されたアルゴリズムに従う必要があります。
The mPrefix64 and uPrefix64 can be configured in the mB4 using a variety of methods, including an out-of-band mechanism, manual configuration, or a dedicated provisioning protocol (e.g., using DHCPv6 [RFC8115]).
mPrefix64とuPrefix64は、帯域外メカニズム、手動構成、または専用のプロビジョニングプロトコル（DHCPv6 [RFC8115]など）を含むさまざまな方法を使用して、mB4で構成できます。
The stateless translation mechanism described in Section 5 does not preclude use of Embedded-RP [RFC3956] [RFC7371].
セクション5で説明されているステートレス変換メカニズムは、Embedded-RP [RFC3956] [RFC7371]の使用を排除しません。
IPv4-embedded IPv6 multicast addresses are composed according to the following algorithm:
IPv4組み込みIPv6マルチキャストアドレスは、次のアルゴリズムに従って構成されます。
o Concatenate the 96 bits of the mPrefix64 and the 32 bits of the IPv4 address to obtain a 128-bit address.
o mPrefix64の96ビットとIPv4アドレスの32ビットを連結して、128ビットアドレスを取得します。
The IPv4 multicast addresses are extracted from the IPv4-embedded IPv6 multicast addresses according to the following algorithm:
IPv4マルチキャストアドレスは、次のアルゴリズムに従ってIPv4埋め込みIPv6マルチキャストアドレスから抽出されます。
o If the multicast address has a pre-configured mPrefix64, extract the last 32 bits of the IPv6 multicast address.
o マルチキャストアドレスにmPrefix64が事前構成されている場合は、IPv6マルチキャストアドレスの最後の32ビットを抽出します。
An IPv4 source is represented in the IPv6 realm with its IPv4-converted IPv6 address [RFC6052].
IPv4ソースは、IPv4変換されたIPv6アドレス[RFC6052]でIPv6レルムに表されます。
The embedded IPv4 address in an IPv6 multicast address is included in the last 32 bits; therefore, dotted decimal notation can be used.
IPv6マルチキャストアドレスに埋め込まれたIPv4アドレスは、最後の32ビットに含まれています。したがって、ドット付き10進表記を使用できます。
Group address mapping example:
グループアドレスマッピングの例：
+---------------------+--------------+----------------------------+
| mPrefix64 | IPv4 address | IPv4-Embedded IPv6 address |
+---------------------+--------------+----------------------------+
| ff0x::db8:0:0/96 | 233.252.0.1 | ff0x::db8:233.252.0.1 |
+---------------------+--------------+----------------------------+
Source address mapping example when a /96 is used:
+---------------------+--------------+----------------------------+
| uPrefix64 | IPv4 address | IPv4-Embedded IPv6 address |
+---------------------+--------------+----------------------------+
| 2001:db8::/96 | 192.0.2.33 | 2001:db8::192.0.2.33 |
+---------------------+--------------+----------------------------+
IPv4 and IPv6 addresses used in this example are derived from the IPv4 and IPv6 blocks reserved for documentation, as per [RFC6676]. The unicast IPv4 address of the above example is derived from the documentation address block defined in [RFC6890].
この例で使用されるIPv4およびIPv6アドレスは、[RFC6676]に従って、ドキュメント用に予約されているIPv4およびIPv6ブロックから派生しています。上記の例のユニキャストIPv4アドレスは、[RFC6890]で定義されているドキュメンテーションアドレスブロックから派生しています。
The IGMP-MLD Interworking function combines the IGMP/MLD Proxying function and the address-synthesizing operations. The IGMP/MLD Proxying function is specified in [RFC4605]. The address translation is stateless and MUST follow the address mapping specified in Section 5.
IGMP-MLDインターワーキング機能は、IGMP / MLDプロキシ機能とアドレス合成操作を組み合わせたものです。 IGMP / MLDプロキシ機能は、[RFC4605]で指定されています。アドレス変換はステートレスであり、セクション5で指定されたアドレスマッピングに従う必要があります。
The mB4 performs the host portion of the MLD protocol on the upstream interface. The composition of IPv6 membership in this context is constructed through address-synthesizing operations and MUST synchronize with the membership database maintained in the IGMP domain. MLD messages are sent natively to the direct-connected IPv6 multicast routers (they will be processed by the PIM DR). The mB4 also performs the router portion of IGMP on the downstream interface(s). Refer to [RFC4605] for more details.
mB4は、アップストリームインターフェイスでMLDプロトコルのホスト部分を実行します。このコンテキストでのIPv6メンバーシップの構成は、アドレス合成操作によって構築され、IGMPドメインで維持されるメンバーシップデータベースと同期する必要があります。 MLDメッセージは、直接接続されたIPv6マルチキャストルーターにネイティブに送信されます（PIM DRによって処理されます）。 mB4は、ダウンストリームインターフェイスでIGMPのルーター部分も実行します。詳細については、[RFC4605]を参照してください。
+----------+ IGMP +-------+ MLD +---------+
| IPv4 |---------| mB4 |---------| PIM |
| Receiver | | | | DR |
+----------+ +-------+ +---------+
Figure 2: IGMP-MLD Interworking
図2：IGMP-MLDインターワーキング
If SSM is deployed, the mB4 MUST construct the IPv6 source address (or retrieve the IPv4 source address) using the uPrefix64. The mB4 MAY create a membership database that associates the IPv4-IPv6 multicast groups with the interfaces (e.g., WLAN and Wired Ethernet) facing IPv4 multicast receivers.
SSMが展開されている場合、mB4はuPrefix64を使用してIPv6送信元アドレスを構築する（またはIPv4送信元アドレスを取得する）必要があります。 mB4は、IPv4-IPv6マルチキャストグループを、IPv4マルチキャストレシーバーに面するインターフェイス（WLANやワイヤードイーサネットなど）に関連付けるメンバーシップデータベースを作成できます（MAY）。
When the mB4 receives an IPv6 multicast packet, it MUST check the group address and the source address. If the IPv6 multicast group prefix is mPrefix64 and the IPv6 source prefix is uPrefix64, the mB4 MUST decapsulate the IPv6 header [RFC2473]; the decapsulated IPv4 multicast packet will be forwarded through each relevant interface following standard IPv4 multicast forwarding procedures. Otherwise, the mB4 MUST silently drop the packet.
mB4がIPv6マルチキャストパケットを受信すると、グループアドレスと送信元アドレスを確認する必要があります。 IPv6マルチキャストグループプレフィックスがmPrefix64で、IPv6ソースプレフィックスがuPrefix64である場合、mB4はIPv6ヘッダー[RFC2473]をカプセル化解除する必要があります。カプセル化解除されたIPv4マルチキャストパケットは、標準のIPv4マルチキャスト転送手順に従って、関連する各インターフェイスを介して転送されます。そうでなければ、mB4は静かにパケットを落とさなければなりません（MUST）。
As an illustration, if a packet is received from source 2001:db8::192.0.2.33 and needs to be forwarded to group ff3x:20:2001:db8::233.252.0.1, the mB4 decapsulates it into an IPv4 multicast packet using 192.0.2.33 as the IPv4 source address and using 233.252.0.1 as the IPv4 destination multicast group. This example assumes that the mB4 is provisioned with uPrefix64 (2001:db8::/96) and mPrefix64 (ff3x:20:2001:db8::/96).
例として、パケットがソース2001：db8 :: 192.0.2.33から受信され、グループff3x：20：2001：db8 :: 233.252.0.1に転送される必要がある場合、mB4は192.0を使用してIPv4マルチキャストパケットにカプセル化解除します.2.33をIPv4送信元アドレスとして、233.252.0.1をIPv4宛先マルチキャストグループとして使用します。この例では、mB4がuPrefix64（2001：db8 :: / 96）およびmPrefix64（ff3x：20：2001：db8 :: / 96）でプロビジョニングされていると想定しています。
Encapsulating IPv4 multicast packets into IPv6 multicast packets that will be forwarded by the mAFTR towards the mB4 along the IPv6 multicast distribution tree reduces the effective MTU size by the size of an IPv6 header. In this specification, the data flow is unidirectional from the mAFTR to the mB4. The mAFTR MUST fragment the oversized IPv6 packet after the encapsulation into two IPv6 packets. The mB4 MUST reassemble the IPv6 packets, decapsulate the IPv6 header, and forward the IPv4 packet to the hosts that have subscribed to the corresponding multicast group. Further considerations about fragmentation issues are documented in Sections 5.3 and 6.3 of [RFC6333].
IPv4マルチキャストパケットをIPv6マルチキャストパケットにカプセル化すると、mAFTRによってIPv6マルチキャスト配布ツリーに沿ってmB4に転送され、有効なMTUサイズがIPv6ヘッダーのサイズだけ減少します。この仕様では、データフローはmAFTRからmB4への一方向です。 mAFTRは、カプセル化後の特大のIPv6パケットを2つのIPv6パケットにフラグメント化する必要があります。 mB4はIPv6パケットを再構成し、IPv6ヘッダーのカプセル化を解除し、対応するマルチキャストグループにサブスクライブしているホストにIPv4パケットを転送する必要があります。断片化の問題に関するさらなる考慮事項は、[RFC6333]のセクション5.3および6.3に文書化されています。
If the mB4 function is implemented in the host that is directly connected to an IPv6-only network, the host MUST implement the behaviors specified in Sections 6.1, 6.2, and 6.3. The host MAY optimize the implementation to provide an Application Programming Interface (API) or kernel module to skip the IGMP-MLD Interworking function. Optimization considerations are out of scope of this specification.
IPv6のみのネットワークに直接接続されているホストにmB4関数が実装されている場合、ホストはセクション6.1、6.2、および6.3で指定されている動作を実装する必要があります。ホストは、実装を最適化して、アプリケーションプログラミングインターフェイス（API）またはカーネルモジュールを提供し、IGMP-MLDインターワーキング機能をスキップする場合があります。最適化の考慮事項は、この仕様の範囲外です。
When several mPrefix64s are available, if each enclosed IPv4-embedded IPv6 multicast prefix has a distinct scope, the mB4 MUST select the appropriate IPv4-embedded IPv6 multicast prefix whose scope matches the IPv4 multicast address used to synthesize an IPv4-embedded IPv6 multicast address (specific mappings are listed in Section 8 of [RFC2365]). Mapping is achieved such that the scope of the selected IPv6 multicast prefix does not exceed the original IPv4 multicast scope. If the mB4 is instructed to preserve the scope but no IPv6 multicast prefix that matches the IPv4 multicast scope is found, IPv6 multicast address mapping SHOULD fail.
複数のmPrefix64が利用可能な場合、囲まれた各IPv4埋め込みIPv6マルチキャストプレフィックスに個別のスコープがある場合、mB4は、IPv4埋め込みIPv6マルチキャストアドレスの合成に使用されるIPv4マルチキャストアドレスとスコープが一致する適切なIPv4埋め込みIPv6マルチキャストプレフィックスを選択する必要があります（特定のマッピングは、[RFC2365]のセクション8に記載されています。マッピングは、選択したIPv6マルチキャストプレフィックスのスコープが元のIPv4マルチキャストスコープを超えないように行われます。 mB4がスコープを保持するように指示されているが、IPv4マルチキャストスコープに一致するIPv6マルチキャストプレフィックスが見つからない場合、IPv6マルチキャストアドレスマッピングは失敗する必要があります（SHOULD）。
The mB4 MAY be configured to not preserve the scope when enforcing the address translation algorithm.
mB4は、アドレス変換アルゴリズムを適用するときにスコープを保持しないように構成できます（MAY）。
Consider that an mB4 is configured with two mPrefix64s, ff0e::db8:0:0/96 (global scope) and ff08::db8:0:0/96 (organization scope). If the mB4 receives an IGMP Report message from an IPv4 receiver to subscribe to 233.252.0.1, it checks which mPrefix64 to use in order to preserve the scope of the requested IPv4 multicast group. In this example, given that 233.252.0.1 is intended for global use, the mB4 creates the IPv6 multicast group (G6) address using ff0e::db8:0:0/96 and the original IPv4 multicast group address (233.252.0.1): ff0e::db8:233.252.0.1.
mB4が2つのmPrefix64、ff0e :: db8：0：0/96（グローバルスコープ）とff08 :: db8：0：0/96（組織スコープ）で構成されていることを考慮してください。 mB4がIPv4レシーバーからIGMPレポートメッセージを受信して233.252.0.1にサブスクライブする場合、mB4は要求されたIPv4マルチキャストグループのスコープを維持するためにどのmPrefix64を使用するかを確認します。この例では、233.252.0.1がグローバルに使用されることを想定しているため、mB4はff0e :: db8：0：0/96と元のIPv4マルチキャストグループアドレス（233.252.0.1）を使用してIPv6マルチキャストグループ（G6）アドレスを作成します。 ff0e :: db8：233.252.0.1。
The mAFTR is responsible for interconnecting the IPv4 multicast distribution tree with the corresponding IPv6 multicast distribution tree. The mAFTR MUST use the uPrefix64 to build the IPv6 source addresses of the multicast group address derived from mPrefix64. In other words, the mAFTR MUST be the multicast source whose address is derived from uPrefix64.
mAFTRは、IPv4マルチキャスト配布ツリーを対応するIPv6マルチキャスト配布ツリーと相互接続する役割を果たします。 mAFTRは、uPrefix64を使用して、mPrefix64から派生したマルチキャストグループアドレスのIPv6ソースアドレスを構築する必要があります。つまり、mAFTRはアドレスがuPrefix64から派生したマルチキャストソースである必要があります。
The mAFTR MUST advertise the route towards uPrefix64 with the IPv6 IGP. This is needed by the IPv6 multicast routers so that they acquire the routing information to discover the source.
mAFTRは、IPv6 IGPを使用してuPrefix64へのルートをアドバタイズする必要があります。これは、IPv6マルチキャストルーターがルーティング情報を取得してソースを発見するために必要です。
The mAFTR MUST interwork PIM Join/Prune messages for (*,G6) and (S6,G6) on their corresponding (*,G4) and (S4,G4). The following text specifies the expected behavior of the mAFTR for PIM Join messages.
mAFTRは、対応する（*、G4）および（S4、G4）で（*、G6）および（S6、G6）のPIM Join / Pruneメッセージをインターワークする必要があります。次のテキストは、PIM JoinメッセージのmAFTRの予想される動作を示しています。
+---------+
---------| mAFTR |---------
PIMv6 |uPrefix64| PIMv4
|mPrefix64|
+---------+
Figure 3: PIMv6-PIMv4 Interworking Function
図3：PIMv6-PIMv4インターワーキング機能
The mAFTR contains two separate Tree Information Bases (TIBs): the IPv4 Tree Information Base (TIB4) and the IPv6 Tree Information Base (TIB6), which are bridged by one IPv4-in-IPv6 virtual interface. It should be noted that TIB implementations may vary (e.g., some may rely upon a single integrated TIB without any virtual interface), but they should follow this specification for the sake of global and functional consistency.
mAFTRには、IPv4ツリー情報ベース（TIB4）とIPv6ツリー情報ベース（TIB6）の2つの個別のツリー情報ベース（TIB）が含まれ、これらは1つのIPv4-in-IPv6仮想インターフェイスによってブリッジされます。 TIBの実装は異なる場合があります（たとえば、一部は仮想インターフェイスのない単一の統合TIBに依存する場合があります）が、グローバルおよび機能の一貫性のためにこの仕様に従う必要があることに注意してください。
When an mAFTR receives a PIMv6 Join message (*,G6) with an IPv6 multicast group address (G6) that is derived from the mPrefix64, it MUST check its IPv6 Tree Information Base (TIB6). If there is an entry for this G6 address, it MUST check whether the interface through which the PIMv6 Join message has been received is in the outgoing interface (oif) list. If not, the mAFTR MUST add the interface to the oif list. If there is no entry in the TIB6, the mAFTR MUST create a new entry (*,G6) for the multicast group. Whether or not the IPv4-in-IPv6 virtual interface is set as the incoming interface of the newly created entry is up to the implementation, but it should comply with the mAFTR's multicast data forwarding behavior (see Section 7.4).
mAFTRは、mPrefix64から派生したIPv6マルチキャストグループアドレス（G6）を含むPIMv6 Joinメッセージ（*、G6）を受信すると、そのIPv6ツリー情報ベース（TIB6）を確認する必要があります。このG6アドレスのエントリがある場合は、PIMv6参加メッセージを受信したインターフェイスが発信インターフェイス（oif）リストにあるかどうかを確認する必要があります。そうでない場合、mAFTRはインターフェースをoifリストに追加する必要があります。 TIB6にエントリがない場合、mAFTRはマルチキャストグループの新しいエントリ（*、G6）を作成する必要があります。 IPv4-in-IPv6仮想インターフェースが新しく作成されたエントリーの着信インターフェースとして設定されるかどうかは実装次第ですが、mAFTRのマルチキャストデータ転送動作に準拠する必要があります（セクション7.4を参照）。
The mAFTR MUST extract the IPv4 multicast group address (G4) from the IPv4-embedded IPv6 multicast address (G6) contained in the PIMv6 Join message. The mAFTR MUST check its IPv4 Tree Information Base (TIB4). If there is an entry for G4, it MUST check whether the IPv4-in-IPv6 virtual interface is in the outgoing interface list. If not, the mAFTR MUST add the interface to the oif list. If there is no entry for G4, the mAFTR MUST create a new (*,G4) entry in its TIB4 and initiate the procedure for building the shared tree in the IPv4 multicast network without any additional requirement.
mAFTRは、PIMv6参加メッセージに含まれるIPv4埋め込みIPv6マルチキャストアドレス（G6）からIPv4マルチキャストグループアドレス（G4）を抽出する必要があります。 mAFTRは、そのIPv4ツリー情報ベース（TIB4）を確認する必要があります。 G4のエントリがある場合、IPv4-in-IPv6仮想インターフェイスが発信インターフェイスリストにあるかどうかを確認する必要があります。そうでない場合、mAFTRはインターフェースをoifリストに追加する必要があります。 G4のエントリがない場合、mAFTRはTIB4に新しい（*、G4）エントリを作成し、追加の要件なしでIPv4マルチキャストネットワークで共有ツリーを構築する手順を開始する必要があります。
If the mAFTR receives a source-specific Join message, the (S6,G6) is processed rather than (*,G6). The procedures of processing (S6,G6) and (*,G6) are almost the same. Differences have been detailed in [RFC7761].
mAFTRがソース固有のJoinメッセージを受信した場合、（*、G6）ではなく（S6、G6）が処理されます。 （S6、G6）と（*、G6）の処理手順はほぼ同じです。違いは[RFC7761]で詳述されています。
When the mAFTR receives the first IPv4 multicast packet, it may extract the source address (S4) from the packet and send an Explicit PIMv4 (S4,G4) Join message directly to S4. The mAFTR switches from the shared Rendezvous Point Tree (RPT) to the Shortest Path Tree (SPT) for G4.
mAFTRが最初のIPv4マルチキャストパケットを受信すると、パケットから送信元アドレス（S4）を抽出し、明示的なPIMv4（S4、G4）Joinメッセージを直接S4に送信します。 mAFTRは、共有ランデブーポイントツリー（RPT）からG4の最短パスツリー（SPT）に切り替わります。
For IPv6 multicast routers to switch to the SPT, there is no new requirement. IPv6 multicast routers may send an Explicit PIMv6 Join to the mAFTR once the first (S6,G6) multicast packet arrives from upstream multicast routers.
IPv6マルチキャストルーターがSPTに切り替える場合、新しい要件はありません。 IPv6マルチキャストルーターは、最初の（S6、G6）マルチキャストパケットが上流のマルチキャストルーターから到着すると、明示的なPIMv6結合をmAFTRに送信できます。
When the mAFTR receives an IPv4 multicast packet, it checks its TIB4 to find a matching entry and then forwards the packet to the interface(s) listed in the outgoing interface list. If the IPv4-in-IPv6 virtual interface also belongs to this list, the packet is encapsulated with the mPrefix64-derived and uPrefix64-derived IPv4-embedded IPv6 addresses to form an IPv6 multicast packet [RFC2473]. Then another lookup is made by the mAFTR to find a matching entry in the TIB6. Whether or not the RPF check for the second lookup is performed is up to the implementation and is out of the scope of this document. The IPv6 multicast packet is then forwarded along the IPv6 multicast distribution tree, based upon the outgoing interface list of the matching entry in the TIB6.
mAFTRはIPv4マルチキャストパケットを受信すると、TIB4をチェックして一致するエントリを見つけ、そのパケットを発信インターフェイスリストにリストされているインターフェイスに転送します。 IPv4-in-IPv6仮想インターフェースもこのリストに属している場合、パケットはmPrefix64派生およびuPrefix64派生のIPv4埋め込みIPv6アドレスでカプセル化され、IPv6マルチキャストパケット[RFC2473]を形成します。次に、mAFTRによって別の検索が行われ、TIB6で一致するエントリが検索されます。 2番目のルックアップのRPFチェックが実行されるかどうかは実装次第であり、このドキュメントの範囲外です。次に、IPv6マルチキャストパケットは、TIB6内の一致するエントリの発信インターフェイスリストに基づいて、IPv6マルチキャスト配信ツリーに沿って転送されます。
As an illustration, if a packet is received from source 192.0.2.33 and needs to be forwarded to group 233.252.0.1, the mAFTR encapsulates it into an IPv6 multicast packet using ff3x:20:2001:db8::233.252.0.1 as the IPv6 destination multicast group and using 2001:db8::192.0.2.33 as the IPv6 source address.
例として、パケットがソース192.0.2.33から受信され、グループ233.252.0.1に転送される必要がある場合、mAFTRはff3x：20：2001：db8 :: 233.252.0.1をIPv6として使用してIPv6マルチキャストパケットにカプセル化します。宛先マルチキャストグループであり、IPv6ソースアドレスとして2001：db8 :: 192.0.2.33を使用します。
The Scope field of IPv4-in-IPv6 multicast addresses should be valued accordingly (e.g., to "E" for global scope) in the deployment environment. This specification does not discuss the scope value that should be used.
IPv4-in-IPv6マルチキャストアドレスのScopeフィールドは、デプロイメント環境でそれに応じて（たとえば、グローバルスコープの場合は「E」に）値を設定する必要があります。この仕様では、使用する必要があるスコープ値については説明していません。
The considerations in Section 6.5 are to be followed by the mAFTR.
セクション6.5の考慮事項の後には、mAFTRが続きます。
The mAFTR can embed the MLD Querier function (as well as the PIMv6 DR) for optimization purposes. When the mB4 sends an MLD Report message to this mAFTR, the mAFTR should process the MLD Report message that contains the IPv4-embedded IPv6 multicast group address and then send the corresponding PIMv4 Join message (Figure 4).
mAFTRは、最適化の目的でMLDクエリア関数（およびPIMv6 DR）を埋め込むことができます。 mB4がMLDレポートメッセージをこのmAFTRに送信すると、mAFTRはIPv4埋め込みIPv6マルチキャストグループアドレスを含むMLDレポートメッセージを処理し、対応するPIMv4 Joinメッセージを送信する必要があります（図4）。
+---------+
---------| mAFTR |---------
MLD |uPrefix64| PIMv4
|mPrefix64|
+---------+
Figure 4: MLD-PIMv4 Interworking Function
図4：MLD-PIMv4インターワーキング機能
Discussions about the location of the mAFTR capability and related ASM or SSM multicast design considerations are out of the scope of this document.
mAFTR機能の場所および関連するASMまたはSSMマルチキャスト設計の考慮事項に関する説明は、このドキュメントの範囲外です。
If the mAFTR is co-located with the IPv4 DR connected to the original IPv4 source, it may simply use the uPrefix64 and mPrefix64 prefixes to build the IPv4-embedded IPv6 multicast packets, and the sending of PIMv4 Join messages becomes unnecessary.
mAFTRが元のIPv4ソースに接続されたIPv4 DRと同じ場所に配置されている場合、uPrefix64およびmPrefix64プレフィックスを使用してIPv4埋め込みIPv6マルチキャストパケットを構築するだけでよく、PIMv4 Joinメッセージの送信は不要になります。
For robustness and load distribution purposes, several nodes in the network can embed the mAFTR function. In such case, the same IPv6 prefixes (i.e., mPrefix64 and uPrefix64) and algorithm to build IPv4-embedded IPv6 addresses must be configured on those nodes.
堅牢性と負荷分散の目的で、ネットワーク内のいくつかのノードにmAFTR機能を組み込むことができます。そのような場合、同じIPv6プレフィックス（つまり、mPrefix64とuPrefix64）と、IPv4埋め込みIPv6アドレスを構築するアルゴリズムをそれらのノードで構成する必要があります。
The mAFTR may be configured with a list of IPv4 multicast groups and sources. Only multicast flows bound to the configured addresses should be handled by the mAFTR. Otherwise, packets are silently dropped.
mAFTRは、IPv4マルチキャストグループおよびソースのリストで構成できます。設定されたアドレスにバインドされたマルチキャストフローのみがmAFTRで処理されます。それ以外の場合、パケットは通知なしでドロップされます。
To optimize the usage of network resources in current deployments, all multicast streams are conveyed in the core network while only the most popular ones are forwarded in the aggregation/access networks (static mode). Less popular streams are forwarded in the access network upon request (dynamic mode). Depending on the location of the mAFTR in the network, two modes can be envisaged: static and dynamic.
現在の展開でネットワークリソースの使用を最適化するために、すべてのマルチキャストストリームはコアネットワークで伝達され、最も一般的なものだけが集約/アクセスネットワークで転送されます（静的モード）。あまり人気のないストリームは、要求に応じてアクセスネットワークで転送されます（動的モード）。ネットワーク内のmAFTRの場所に応じて、静的モードと動的モードの2つのモードを想定できます。
Static Mode: The mAFTR is configured to instantiate permanent (S6,G6) and (*,G6) entries in its TIB6 using a pre-configured (S4,G4) list.
静的モード：mAFTRは、事前構成された（S4、G4）リストを使用して、TIB6の永続的な（S6、G6）および（*、G6）エントリをインスタンス化するように構成されています。
Dynamic Mode: The instantiation or withdrawal of (S6,G6) or (*,G6) entries is triggered by the receipt of PIMv6 messages.
動的モード：（S6、G6）または（*、G6）エントリーのインスタンス化または撤回は、PIMv6メッセージの受信によってトリガーされます。
Besides multicast scoping considerations (see Sections 6.5 and 7.5), this document does not introduce any new security concerns in addition to those discussed in Section 5 of [RFC6052], Section 10 of [RFC3810], and Section 6 of [RFC7761].
マルチキャストスコーピングの考慮事項（セクション6.5および7.5を参照）の他に、このドキュメントでは、[RFC6052]のセクション5、[RFC3810]のセクション10、および[RFC7761]のセクション6で説明されているものに加えて、新しいセキュリティ上の懸念は紹介されていません。
Unlike solutions that map IPv4 multicast flows to IPv6 unicast flows, this document does not exacerbate Denial-of-Service (DoS) attacks.
IPv4マルチキャストフローをIPv6ユニキャストフローにマッピングするソリューションとは異なり、このドキュメントはサービス拒否（DoS）攻撃を悪化させることはありません。
An mB4 SHOULD be provided with appropriate configuration information to preserve the scope of a multicast message when mapping an IPv4 multicast address into an IPv4-embedded IPv6 multicast address and vice versa.
IPv4マルチキャストアドレスをIPv4組み込みIPv6マルチキャストアドレスに、またはその逆にマッピングするときに、マルチキャストメッセージのスコープを維持するために、mB4には適切な構成情報を提供する必要があります（SHOULD）。
The CPE that embeds the mB4 function SHOULD be configured to accept incoming MLD messages and traffic forwarded to multicast groups subscribed to by receivers located in the customer premises.
mB4機能を組み込んだCPEは、顧客の敷地内にある受信者がサブスクライブするマルチキャストグループに転送される着信MLDメッセージとトラフィックを受け入れるように構成する必要があります（SHOULD）。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, DOI 10.17487/RFC2365, July 1998, <http://www.rfc-editor.org/info/rfc2365>.
[RFC2365] Meyer、D。、「Administratively Scoped IP Multicast」、BCP 23、RFC 2365、DOI 10.17487 / RFC2365、1998年7月、<http://www.rfc-editor.org/info/rfc2365>。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, <http://www.rfc-editor.org/info/rfc2473>.
[RFC2473] Conta、A。およびS. Deering、「Generic Packet Tunneling in IPv6 Specification」、RFC 2473、DOI 10.17487 / RFC2473、1998年12月、<http://www.rfc-editor.org/info/rfc2473>。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, <http://www.rfc-editor.org/info/rfc3376>.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、DOI 10.17487 / RFC3376、2002年10月、< http://www.rfc-editor.org/info/rfc3376>。
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <http://www.rfc-editor.org/info/rfc3810>.
[RFC3810] Vida、R.、Ed。 L.コスタ編、「IPv6のマルチキャストリスナーディスカバリバージョン2（MLDv2）」、RFC 3810、DOI 10.17487 / RFC3810、2004年6月、<http://www.rfc-editor.org/info/rfc3810>。
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, August 2006, <http://www.rfc-editor.org/info/rfc4605>.
[RFC4605] Fenner、B.、He、H.、Haberman、B。、およびH. Sandick、「Internet Group Management Protocol（IGMP）/ Multicast Listener Discovery（MLD）-Based Multicast Forwarding（ "IGMP / MLD Proxying"） "、RFC 4605、DOI 10.17487 / RFC4605、2006年8月、<http://www.rfc-editor.org/info/rfc4605>。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, <http://www.rfc-editor.org/info/rfc4607>.
[RFC4607] Holbrook、H.およびB. Cain、「Source-Specific Multicast for IP」、RFC 4607、DOI 10.17487 / RFC4607、2006年8月、<http://www.rfc-editor.org/info/rfc4607>。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, <http://www.rfc-editor.org/info/rfc6052>.
[RFC6052] Bao、C.、Huitema、C.、Bagnulo、M.、Boucadair、M。、およびX. Li、「IPv4 / IPv6トランスレータのIPv6アドレッシング」、RFC 6052、DOI 10.17487 / RFC6052、2010年10月、< http://www.rfc-editor.org/info/rfc6052>。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, <http://www.rfc-editor.org/info/rfc6333>.
[RFC6333] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4枯渇後のデュアルスタックLiteブロードバンド展開」、RFC 6333、DOI 10.17487 / RFC6333、2011年8月、<http：/ /www.rfc-editor.org/info/rfc6333>。
[RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix Length Recommendation for Forwarding", BCP 198, RFC 7608, DOI 10.17487/RFC7608, July 2015, <http://www.rfc-editor.org/info/rfc7608>.
[RFC7608] Boucadair、M.、Petrescu、A。、およびF. Baker、「IPv6 Prefix Length Forwarding for Forwarding」、BCP 198、RFC 7608、DOI 10.17487 / RFC7608、2015年7月、<http：//www.rfc- editor.org/info/rfc7608>。
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <http://www.rfc-editor.org/info/rfc7761>.
[RFC7761] Fenner、B.、Handley、M.、Holbrook、H.、Kouvelas、I.、Parekh、R.、Zhang、Z。、およびL. Zheng、「Protocol Independent Multicast-Sparse Mode（PIM-SM） ：プロトコル仕様（改訂）」、STD 83、RFC 7761、DOI 10.17487 / RFC7761、2016年3月、<http://www.rfc-editor.org/info/rfc7761>。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, <http://www.rfc-editor.org/info/rfc2236>.
[RFC2236] Fenner、W。、「インターネットグループ管理プロトコル、バージョン2」、RFC 2236、DOI 10.17487 / RFC2236、1997年11月、<http://www.rfc-editor.org/info/rfc2236>。
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, DOI 10.17487/RFC3956, November 2004, <http://www.rfc-editor.org/info/rfc3956>.
[RFC3956] Savola、P。およびB. Haberman、「Rendezvous Point（RP）Address in an IPv6 Multicast Address」、RFC 3956、DOI 10.17487 / RFC3956、2004年11月、<http：//www.rfc-editor。 org / info / rfc3956>。
[RFC6676] Venaas, S., Parekh, R., Van de Velde, G., Chown, T., and M. Eubanks, "Multicast Addresses for Documentation", RFC 6676, DOI 10.17487/RFC6676, August 2012, <http://www.rfc-editor.org/info/rfc6676>.
[RFC6676] Venaas、S.、Parekh、R.、Van de Velde、G.、Chown、T。、およびM. Eubanks、「ドキュメントのマルチキャストアドレス」、RFC 6676、DOI 10.17487 / RFC6676、2012年8月、<http ：//www.rfc-editor.org/info/rfc6676>。
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <http://www.rfc-editor.org/info/rfc6890>.
[RFC6890]綿、M。、ベゴダ、L。、ボニカ、R。、エド、およびB.ハーバーマン、「特別な目的のIPアドレスレジストリ」、BCP 153、RFC 6890、DOI 10.17487 / RFC6890、2013年4月、< http://www.rfc-editor.org/info/rfc6890>。
[RFC7371] Boucadair, M. and S. Venaas, "Updates to the IPv6 Multicast Addressing Architecture", RFC 7371, DOI 10.17487/RFC7371, September 2014, <http://www.rfc-editor.org/info/rfc7371>.
[RFC7371] Boucadair、M。、およびS. Venaas、「Updates to the IPv6 Multicast Addressing Architecture」、RFC 7371、DOI 10.17487 / RFC7371、2014年9月、<http://www.rfc-editor.org/info/rfc7371> 。
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, <http://www.rfc-editor.org/info/rfc7596>.
[RFC7596] Cui、Y.、Sun、Q.、Boucadair、M.、Tsou、T.、Lee、Y.、I。Farrer、「Lightweight 4over6：An Extension to the Dual-Stack Lite Architecture」、RFC 7596 、DOI 10.17487 / RFC7596、2015年7月、<http://www.rfc-editor.org/info/rfc7596>。
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, <http://www.rfc-editor.org/info/rfc7597>.
[RFC7597] Troan、O.、Ed。、Dec、W.、Li、X.、Bao、C.、Matsushima、S.、Murakami、T.、and T. Taylor、Ed。、 "Mapping of Address and Portカプセル化あり（MAP-E）」、RFC 7597、DOI 10.17487 / RFC7597、2015年7月、<http://www.rfc-editor.org/info/rfc7597>。
[RFC8115] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes", RFC 8115, DOI 10.17487/RFC8115, March 2017, <http://www.rfc-editor.org/info/rfc8115>.
[RFC8115] Boucadair、M.、Qin、J.、Tsou、T。、およびX. Deng、「DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes」、RFC 8115、DOI 10.17487 / RFC8115、2017年3月、<http ：//www.rfc-editor.org/info/rfc8115>。
Appendix A. Use Case: IPTV
付録A.ユースケース：IPTV
IPTV generally includes two categories of service offerings:
IPTVには通常、次の2つのカテゴリのサービスが含まれます。
o Video on Demand (VoD) that streams unicast video content to receivers.
o ユニキャストビデオコンテンツをレシーバーにストリーミングするビデオオンデマンド（VoD）。
o Multicast live TV broadcast services.
o マルチキャストライブTV放送サービス。
Two types of provider are involved in the delivery of this service:
このサービスの提供には、2つのタイプのプロバイダーが関与しています。
o Content Providers, who usually own the content that is multicast to receivers. Content providers may contractually define an agreement with network providers to deliver content to receivers.
o コンテンツプロバイダー。通常、受信者にマルチキャストされるコンテンツを所有します。コンテンツプロバイダーは、コンテンツをレシーバーに配信するためにネットワークプロバイダーとの契約を契約で定義する場合があります。
o Network Providers, who provide network connectivity services (e.g., network providers are responsible for carrying multicast flows from head-ends to receivers).
o ネットワーク接続サービスを提供するネットワークプロバイダー（たとえば、ネットワークプロバイダーは、マルチキャストフローをヘッドエンドからレシーバーに運ぶ責任があります）。
Note that some contract agreements prevent a network provider from altering the content as sent by the content provider for various reasons. Depending on these contract agreements, multicast streams should be delivered unaltered to the requesting users.
契約の合意によっては、ネットワークプロバイダーがさまざまな理由でコンテンツプロバイダーから送信されたコンテンツを変更できないことに注意してください。これらの契約に応じて、マルチキャストストリームは変更されずに要求元のユーザーに配信されます。
Most current IPTV content is likely to remain IPv4-formatted and out of the control of network providers. Additionally, there are numerous legacy receivers (e.g., IPv4-only Set-Top Boxes (STBs)) that can't be upgraded or easily replaced to support IPv6. As a consequence, IPv4 service continuity must be guaranteed during the transition period, including the delivery of multicast services such as Live TV Broadcasting to users.
現在のほとんどのIPTVコンテンツはIPv4形式のままであり、ネットワークプロバイダーの管理外にあります。さらに、アップグレードやIPv6をサポートするための簡単な交換ができないレガシーレシーバー（IPv4のみのセットトップボックス（STB）など）は数多くあります。その結果、ユーザーへのライブTVブロードキャストなどのマルチキャストサービスの配信を含む、移行期間中のIPv4サービスの継続性を保証する必要があります。
Given the multiple versions of group membership management protocols, mismatch issues may arise at the mB4 (refer to Section 6.1).
グループメンバーシップ管理プロトコルのバージョンが複数ある場合、mB4で不一致の問題が発生する可能性があります（セクション6.1を参照）。
If IGMPv2 operates on the IPv4 receivers while MLDv2 operates on the MLD Querier, or if IGMPv3 operates on the IPv4 receivers while MLDv1 operates on the MLD Querier, a version mismatch issue will be encountered. To solve this problem, the mB4 should perform the router portion of IGMP, which is similar to the corresponding MLD version (IGMPv2 for MLDv1 or IGMPv3 for MLDv2) operating in the IPv6 domain. Then, the protocol interaction approach specified in Section 7 of [RFC3376] can be applied to exchange signaling messages with the IPv4 receivers on which the different version of IGMP is operating.
MLDv2がMLDクエリアで動作しているときにIGMPv2がIPv4レシーバーで動作している場合、またはMLDv1がMLDクエリアで動作しているときにIGMPv3がIPv4レシーバーで動作している場合、バージョンの不一致の問題が発生します。この問題を解決するには、mB4がIGMPのルーター部分を実行する必要があります。これは、IPv6ドメインで動作する対応するMLDバージョン（MLDv1のIGMPv2またはMLDv2のIGMPv3）と同様です。次に、[RFC3376]のセクション7で指定されたプロトコル相互作用アプローチを適用して、異なるバージョンのIGMPが動作しているIPv4レシーバーとシグナリングメッセージを交換できます。
Note that the support of IPv4 SSM requires MLDv2 to be enabled in the IPv6 network.
IPv4 SSMをサポートするには、IPv6ネットワークでMLDv2を有効にする必要があることに注意してください。
Acknowledgements
謝辞
The authors would like to thank Dan Wing for his guidance in the early discussions that initiated this work. We also thank Peng Sun, Jie Hu, Qiong Sun, Lizhong Jin, Alain Durand, Dean Cheng, Behcet Sarikaya, Tina Tsou, Rajiv Asati, Xiaohong Deng, and Stig Venaas for their valuable comments.
著者は、この作業を開始した初期のディスカッションでのガイダンスを提供してくれたDan Wingに感謝します。また、Peng Sun、Jie Hu、Qiong Sun、Lizhong Jin、Alain Durand、Dean Cheng、Behcet Sarikaya、Tina Tsou、Rajiv Asati、Xiaohong Deng、Stig Venaasの貴重なコメントにも感謝します。
Many thanks to Ian Farrer for the review.
レビューしてくれたIan Farrerに感謝します。
Thanks to Zhen Cao, Tim Chown, Francis Dupont, Jouni Korhonen, and Stig Venaas for the directorates review.
総局のレビューを行ったZhen Cao、Tim Chown、Francis Dupont、Jouni Korhonen、Stig Venaasに感謝します。
Authors' Addresses
著者のアドレス
Mohamed Boucadair Orange Rennes 35000 France
Mohamed Boucadair Orange Rennes 35000フランス
Email: mohamed.boucadair@orange.com
Chao Qin Cisco Shanghai China
Cisco Shanghai ChinaのC good Q
Email: jacni@jacni.com
Christian Jacquenet Orange Rennes 35000 France
クリスチャンジャケネオレンジレンヌ35000フランス
Email: christian.jacquenet@orange.com
Yiu L. Lee Comcast United States of America
Yiu L. Lee Comcastアメリカ合衆国
Email: yiu_lee@cable.comcast.com
URI: http://www.comcast.com
Qian Wang China Telecom China
銭王中国テレコム中国
Phone: +86 10 58502462
Email: 13301168516@189.cn