[要約] RFC 7450は、自動マルチキャストトンネリングの仕組みを定義しており、IPv6ネットワークでのマルチキャストトラフィックの効率的な配信を目的としています。
Internet Engineering Task Force (IETF) G. Bumgardner
Request for Comments: 7450 February 2015
Category: Standards Track
ISSN: 2070-1721
Automatic Multicast Tunneling
自動マルチキャストトンネリング
Abstract
概要
This document describes Automatic Multicast Tunneling (AMT), a protocol for delivering multicast traffic from sources in a multicast-enabled network to receivers that lack multicast connectivity to the source network. The protocol uses UDP encapsulation and unicast replication to provide this functionality.
このドキュメントでは、自動マルチキャストトンネリング（AMT）について説明します。これは、マルチキャスト対応ネットワークのソースから、ソースネットワークへのマルチキャスト接続のない受信者にマルチキャストトラフィックを配信するためのプロトコルです。プロトコルは、UDPカプセル化とユニキャスト複製を使用して、この機能を提供します。
The AMT protocol is specifically designed to support rapid deployment by requiring minimal changes to existing network infrastructure.
AMTプロトコルは、既存のネットワークインフラストラクチャへの変更を最小限に抑えて迅速な展開をサポートするように特別に設計されています。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション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/rfc7450.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7450で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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 ....................................................3
2. Applicability ...................................................3
3. Terminology .....................................................4
3.1. Requirements Notation ......................................4
3.2. Definitions ................................................4
3.3. Abbreviations ..............................................5
4. Protocol Overview ...............................................6
4.1. General Architecture .......................................6
4.1.1. Relationship to IGMP and MLD Protocols ..............6
4.1.2. Gateways ............................................7
4.1.3. Relays .............................................10
4.1.4. Deployment .........................................13
4.1.5. Discovery ..........................................14
4.2. General Operation .........................................15
4.2.1. Message Sequences ..................................15
4.2.2. Tunneling ..........................................26
5. Protocol Description ...........................................31
5.1. Protocol Messages .........................................31
5.1.1. Relay Discovery ....................................31
5.1.2. Relay Advertisement ................................32
5.1.3. Request ............................................34
5.1.4. Membership Query ...................................35
5.1.5. Membership Update ..................................39
5.1.6. Multicast Data .....................................41
5.1.7. Teardown ...........................................43
5.2. Gateway Operation .........................................45
5.2.1. IP/IGMP/MLD Protocol Requirements ..................45
5.2.2. Pseudo-Interface Configuration .....................47
5.2.3. Gateway Service ....................................48
5.3. Relay Operation ...........................................61
5.3.1. IP/IGMP/MLD Protocol Requirements ..................61
5.3.2. Startup ............................................61
5.3.3. Running ............................................62
5.3.4. Shutdown ...........................................73
5.3.5. Response MAC Generation ............................73
5.3.6. Private Secret Generation ..........................74
6. Security Considerations ........................................74
6.1. Relays ....................................................74
6.2. Gateways ..................................................76
6.3. Encapsulated IP Packets ...................................76
7. IANA Considerations ............................................77
7.1. IPv4 and IPv6 Anycast Prefix Allocation ...................77
7.1.1. IPv4 ...............................................77
7.1.2. IPv6 ...............................................78
7.2. UDP Port Number ...........................................78
8. References .....................................................78
8.1. Normative References ......................................78
8.2. Informative References ....................................79
Acknowledgments ...................................................81
Contributors ......................................................82
Author's Address ..................................................82
The advantages and benefits provided by multicast technologies are well known. There are a number of application areas that are ideal candidates for the use of multicast, including media broadcasting, video conferencing, collaboration, real-time data feeds, data replication, and software updates. Unfortunately, many of these applications lack multicast connectivity to networks that carry traffic generated by multicast sources. The reasons for the lack of connectivity vary but are primarily the result of service provider policies and network limitations.
マルチキャスト技術によって提供される利点と利点はよく知られています。メディアブロードキャスト、ビデオ会議、コラボレーション、リアルタイムデータフィード、データレプリケーション、ソフトウェアの更新など、マルチキャストを使用するのに理想的な候補となるアプリケーション領域がいくつかあります。残念ながら、これらのアプリケーションの多くには、マルチキャストソースによって生成されたトラフィックを伝送するネットワークへのマルチキャスト接続がありません。接続の欠如の理由はさまざまですが、主にサービスプロバイダーのポリシーとネットワークの制限の結果です。
Automatic Multicast Tunneling (AMT) is a protocol that uses UDP-based encapsulation to overcome the aforementioned lack of multicast connectivity. AMT enables sites, hosts, or applications that do not have native multicast access to a network with multicast connectivity to a source, to request and receive Source-Specific Multicast (SSM) [RFC4607] and Any-Source Multicast (ASM) [RFC1112] traffic from a network that does provide multicast connectivity to that source.
自動マルチキャストトンネリング（AMT）は、UDPベースのカプセル化を使用して、前述のマルチキャスト接続の欠如を克服するプロトコルです。 AMTは、ソースへのマルチキャスト接続を備えたネットワークへのネイティブマルチキャストアクセスを持たないサイト、ホスト、またはアプリケーションが、Source-Specific Multicast（SSM）[RFC4607]およびAny-Source Multicast（RFC1112]を要求および受信できるようにします。そのソースへのマルチキャスト接続を提供するネットワークからのトラフィック。
This document describes a protocol that may be used to deliver multicast traffic from a multicast-enabled network to sites that lack multicast connectivity to the source network. This document does not describe any methods for sourcing multicast traffic from isolated sites, as this topic is out of scope.
このドキュメントでは、マルチキャスト対応ネットワークからソースネットワークへのマルチキャスト接続のないサイトにマルチキャストトラフィックを配信するために使用できるプロトコルについて説明します。このトピックは範囲外であるため、このドキュメントでは、分離されたサイトからマルチキャストトラフィックを送信する方法については説明していません。
AMT is not intended to be used as a substitute for native multicast, especially in conditions or environments requiring high traffic flow. AMT uses unicast replication to reach multiple receivers, and the bandwidth cost for this replication will be higher than that required if the receivers were reachable via native multicast.
AMTは、特に高トラフィックフローを必要とする条件や環境で、ネイティブマルチキャストの代わりとして使用することを意図していません。 AMTはユニキャストレプリケーションを使用して複数のレシーバーに到達します。このレプリケーションの帯域幅コストは、レシーバーがネイティブマルチキャスト経由で到達可能である場合に必要なコストよりも高くなります。
AMT is designed to be deployed at the border of networks possessing native multicast capabilities where access and provisioning can be managed by the AMT service provider.
AMTは、AMTサービスプロバイダーがアクセスとプロビジョニングを管理できるネイティブマルチキャスト機能を備えたネットワークの境界に配置されるように設計されています。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document adopts the following definitions for use in describing the protocol:
このドキュメントでは、プロトコルの説明に使用する次の定義を採用しています。
Downstream: A downstream interface or connection that faces away from the multicast distribution root or towards multicast receivers.
ダウンストリーム：マルチキャスト配布ルートとは反対側、またはマルチキャストレシーバーに向かうダウンストリームインターフェイスまたは接続。
Upstream: An upstream interface or connection that faces a multicast distribution root or source.
アップストリーム：マルチキャスト配布ルートまたはソースに面するアップストリームインターフェイスまたは接続。
Non-Broadcast Multi-Access (NBMA): An NBMA network or interface is one to which multiple network nodes (hosts or routers) are attached, but where packets are transmitted directly from one node to another node over a virtual circuit or physical link. NBMA networks do not support multicast or broadcast traffic -- a node that sources multicast traffic must replicate the multicast packets for separate transmission to each node that has requested the multicast traffic.
Non-Broadcast Multi-Access（NBMA）：NBMAネットワークまたはインターフェースは、複数のネットワークノード（ホストまたはルーター）が接続されているものですが、パケットは、仮想回線または物理リンクを介して1つのノードから別のノードに直接送信されます。 NBMAネットワークは、マルチキャストまたはブロードキャストトラフィックをサポートしていません。マルチキャストトラフィックを送信するノードは、マルチキャストトラフィックを要求した各ノードに個別に送信するために、マルチキャストパケットを複製する必要があります。
Multicast Receiver: An entity that requests and receives multicast traffic. A receiver may be a router, host, application, or application component. The method by which a receiver transmits group membership requests and receives multicast traffic varies according to receiver type.
マルチキャストレシーバー：マルチキャストトラフィックを要求および受信するエンティティ。レシーバーは、ルーター、ホスト、アプリケーション、またはアプリケーションコンポーネントです。レシーバがグループメンバーシップ要求を送信し、マルチキャストトラフィックを受信する方法は、レシーバのタイプによって異なります。
Group Membership Database: A group membership database describes the current multicast subscription state (also referred to as "reception state") for an interface or system. See Section 3 of [RFC3376] for a detailed definition.
グループメンバーシップデータベース：グループメンバーシップデータベースは、インターフェイスまたはシステムの現在のマルチキャストサブスクリプションの状態（「受信状態」とも呼ばれます）を記述します。詳細な定義については、[RFC3376]のセクション3を参照してください。
Reception State: The multicast subscription state of a pseudo-interface, virtual interface, or physical network interface. Often synonymous with group membership database.
受信状態：疑似インターフェース、仮想インターフェース、または物理ネットワークインターフェースのマルチキャストサブスクリプション状態。多くの場合、グループメンバーシップデータベースと同義です。
Subscription: A group or state entry in a group membership database or reception state table. The presence of a subscription entry indicates membership in an IP multicast group.
サブスクリプション：グループメンバーシップデータベースまたは受信状態テーブルのグループまたは状態エントリ。サブスクリプションエントリの存在は、IPマルチキャストグループのメンバーであることを示します。
Group Membership Protocol: The term "group membership protocol" is used as a generic reference to the Internet Group Management Protocol (IGMP) [RFC1112] [RFC2236] [RFC3376] or the Multicast Listener Discovery protocol [RFC2710] [RFC3810].
グループメンバーシッププロトコル：「グループメンバーシッププロトコル」という用語は、インターネットグループ管理プロトコル（IGMP）[RFC1112] [RFC2236] [RFC3376]またはマルチキャストリスナーディスカバリプロトコル[RFC2710] [RFC3810]の総称として使用されます。
Multicast Protocol: The term "multicast protocol" is used as a generic reference to multicast routing protocols used to join or leave multicast distribution trees, such as Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601].
マルチキャストプロトコル：「マルチキャストプロトコル」という用語は、プロトコルに依存しないマルチキャスト-スパースモード（PIM-SM）[RFC4601]など、マルチキャスト配信ツリーへの参加または離脱に使用されるマルチキャストルーティングプロトコルの総称として使用されます。
Network Address Translation (NAT): Network Address Translation is the process of modifying the source IP address and port numbers carried by an IP packet while transiting a network node (see [RFC2663]). Intervening NAT devices may change the source address and port carried by messages sent from an AMT gateway to an AMT relay, possibly producing changes in protocol state and behavior.
ネットワークアドレス変換（NAT）：ネットワークアドレス変換は、ネットワークノードを通過する間にIPパケットによって運ばれるソースIPアドレスとポート番号を変更するプロセスです（[RFC2663]を参照）。介入するNATデバイスは、AMTゲートウェイからAMTリレーに送信されたメッセージによって送信されるソースアドレスとポートを変更し、プロトコルの状態と動作に変化をもたらす可能性があります。
Anycast: A network addressing and routing method in which packets from a single sender are routed to the topologically nearest node in a group of potential receivers all identified by the same destination address. See [RFC4786].
エニーキャスト：単一の送信者からのパケットが、すべて同じ宛先アドレスで識別される潜在的な受信者のグループ内のトポロジ的に最も近いノードにルーティングされるネットワークアドレス指定およびルーティング方法。 [RFC4786]を参照してください。
AMT - Automatic Multicast Tunneling protocol.
AMT-自動マルチキャストトンネリングプロトコル。
ASM - Any-Source Multicast.
ASM-Any-Source Multicast。
DoS - Denial-of-Service (attack) and DDoS for distributed DoS.
DoS-サービス拒否（攻撃）および分散DoSのDDoS。
IGMP - Internet Group Management Protocol (v1, v2, and v3).
IGMP-インターネットグループ管理プロトコル（v1、v2、およびv3）。
IP - Internet Protocol (v4 and v6).
IP-インターネットプロトコル（v4およびv6）。
MAC - Message Authentication Code (or Cookie).
MAC-メッセージ認証コード（またはCookie）。
MLD - Multicast Listener Discovery protocol (v1 and v2).
MLD-マルチキャストリスナーディスカバリプロトコル（v1およびv2）。
NAT - Network Address Translation (or translation node).
NAT-ネットワークアドレス変換（または変換ノード）。
NBMA - Non-Broadcast Multi-Access (network, interface, or mode).
NBMA-非ブロードキャストマルチアクセス（ネットワーク、インターフェース、またはモード）。
PIM - Protocol Independent Multicast.
PIM-Protocol Independent Multicast。
SSM - Source-Specific Multicast.
SSM-ソース固有のマルチキャスト。
This section provides an informative description of the protocol. A normative description of the protocol and implementation requirements may be found in Section 5.
このセクションでは、プロトコルについて説明します。プロトコルと実装要件の規範的な説明はセクション5にあります。
Isolated Site | Unicast Network | Native Multicast
| (Internet) |
| |
| |
| Group Membership |
+-------+ =========================> +-------+ Multicast +------+
|Gateway| | | | Relay |<----//----|Source|
+-------+ <========================= +-------+ +------+
| Multicast Data |
| |
| |
Figure 1: Basic AMT Architecture
図1：基本的なAMTアーキテクチャ
The AMT protocol employs a client-server model in which a "gateway" sends requests to receive specific multicast traffic to a "relay" that responds by delivering the requested multicast traffic back to the gateway.
AMTプロトコルは、「ゲートウェイ」が特定のマルチキャストトラフィックを受信するための要求を「リレー」に送信し、要求されたマルチキャストトラフィックをゲートウェイに配信して応答するクライアントサーバーモデルを採用しています。
Gateways are generally deployed within networks that lack multicast support or lack connectivity to a multicast-enabled network containing multicast sources of interest.
ゲートウェイは通常、マルチキャストサポートが不足しているネットワーク、または対象のマルチキャストソースを含むマルチキャスト対応ネットワークへの接続が不足しているネットワーク内に配置されます。
Relays are deployed within multicast-enabled networks that contain, or have connectivity to, multicast sources.
リレーは、マルチキャストソースを含む、またはマルチキャストソースに接続できるマルチキャスト対応ネットワーク内に展開されます。
AMT relies on the Internet Group Management Protocol (IGMP) [RFC3376] and the Multicast Listener Discovery (MLD) protocol [RFC3810] to provide the functionality required to manage, communicate, and act on changes in multicast group membership. A gateway or relay implementation does not necessarily require a fully functional, conforming implementation of IGMP or MLD to adhere to this specification, but the protocol description that appears in this document assumes that this is the case. The minimum functional and behavioral requirements for the IGMP and MLD protocols are described in Sections 5.2.1 and 5.3.1.
AMTは、インターネットグループ管理プロトコル（IGMP）[RFC3376]とマルチキャストリスナー探索（MLD）プロトコル[RFC3810]に依存して、マルチキャストグループメンバーシップの変更を管理、通信、および操作するために必要な機能を提供します。ゲートウェイまたはリレーの実装では、この仕様に準拠するためにIGMPまたはMLDの完全に機能する準拠実装が必ずしも必要ではありませんが、このドキュメントに記載されているプロトコルの説明ではそうであると想定しています。 IGMPおよびMLDプロトコルの最小の機能要件および動作要件は、セクション5.2.1および5.3.1で説明されています。
Gateway Relay
ゲートウェイリレー
General _____ _____
___________ Query | | | | Query ___________
| |<------| | | |<------| |
| Host-Mode | | AMT | | AMT | |Router-Mode|
| IGMP/MLD | | | UDP | | | IGMP/MLD |
|___________|------>| |<----->| |------>|___________|
Report | | | | Report
Leave/Done | | | | Leave/Done
| | | |
IP Multicast <------| | | |<------ IP Multicast
|_____| |_____|
Figure 2: Multicast Reception State Managed by IGMP/MLD
図2：IGMP / MLDによって管理されるマルチキャスト受信状態
A gateway runs the host portion of the IGMP and MLD protocols to generate group membership updates that are sent via AMT messages to a relay. A relay runs the router portion of the IGMP and MLD protocols to process the group membership updates to produce the required changes in multicast forwarding state. A relay uses AMT messages to send incoming multicast IP datagrams to gateways according to their current group membership state.
ゲートウェイは、IGMPおよびMLDプロトコルのホスト部分を実行して、AMTメッセージを介してリレーに送信されるグループメンバーシップの更新を生成します。リレーは、IGMPおよびMLDプロトコルのルーター部分を実行して、グループメンバーシップの更新を処理し、マルチキャスト転送状態に必要な変更を生成します。リレーは、AMTメッセージを使用して、現在のグループメンバーシップの状態に応じて、着信マルチキャストIPデータグラムをゲートウェイに送信します。
The primary function of AMT is to provide the handshaking, encapsulation, and decapsulation required to transport the IGMP and MLD messages and multicast IP datagrams between the gateways and relays. The IGMP and MLD messages that are exchanged between gateways and relays are encapsulated as complete IP datagrams within AMT control messages. Multicast IP datagrams are replicated and encapsulated in AMT data messages. All AMT messages are sent via unicast UDP/IP.
AMTの主な機能は、ゲートウェイとリレー間でIGMPおよびMLDメッセージとマルチキャストIPデータグラムを転送するために必要なハンドシェイク、カプセル化、およびカプセル化解除を提供することです。ゲートウェイとリレーの間で交換されるIGMPおよびMLDメッセージは、AMT制御メッセージ内の完全なIPデータグラムとしてカプセル化されます。マルチキャストIPデータグラムは複製され、AMTデータメッセージにカプセル化されます。すべてのAMTメッセージはユニキャストUDP / IP経由で送信されます。
The downstream side of a gateway services one or more receivers -- the gateway accepts group membership requests from receivers and forwards requested multicast traffic back to those receivers. The gateway functionality may be directly implemented in the host requesting the multicast service or within an application running on a host.
ゲートウェイのダウンストリーム側は、1つ以上のレシーバーにサービスを提供します。ゲートウェイは、レシーバーからのグループメンバーシップ要求を受け入れ、要求されたマルチキャストトラフィックをそれらのレシーバーに転送します。ゲートウェイ機能は、マルチキャストサービスを要求するホストに直接実装することも、ホストで実行されているアプリケーション内に実装することもできます。
The upstream side of a gateway connects to relays. A gateway sends encapsulated IGMP and MLD messages to a relay to indicate an interest in receiving specific multicast traffic.
ゲートウェイの上流側はリレーに接続します。ゲートウェイは、カプセル化されたIGMPおよびMLDメッセージをリレーに送信して、特定のマルチキャストトラフィックの受信に関心があることを示します。
Each gateway possesses a logical pseudo-interface:
各ゲートウェイには、論理的な擬似インターフェースがあります。
join/leave ---+ +----------+
| | |
V IGMPv3/MLDv2 | |
+---------+ General Query| | AMT
|IGMP/MLD |<-------------| AMT | Messages +------+
|Host-Mode| | Gateway |<-------->|UDP/IP|
|Protocol |------------->|Pseudo-I/F| +------+
+---------+ IGMP/MLD | | ^
Report | | |
Leave/Done | | V
IP Multicast <---------------------| | +---+
+----------+ |I/F|
+---+
Figure 3: AMT Gateway Pseudo-Interface
図3：AMTゲートウェイの疑似インターフェイス
The pseudo-interface is conceptually a network interface on which the gateway executes the host portion of the IPv4/IGMP (v2 or v3) and IPv6/MLD (v1 or v2) protocols. The multicast reception state of the pseudo-interface is manipulated using the IGMP or MLD service interface. The IGMP and MLD host protocols produce IP datagrams containing group membership messages that the gateway will send to the relay. The IGMP and MLD protocols also supply the retransmission and timing behavior required for protocol robustness.
疑似インターフェースは、概念的には、ゲートウェイがIPv4 / IGMP（v2またはv3）およびIPv6 / MLD（v1またはv2）プロトコルのホスト部分を実行するネットワークインターフェースです。疑似インターフェイスのマルチキャスト受信状態は、IGMPまたはMLDサービスインターフェイスを使用して操作されます。 IGMPおよびMLDホストプロトコルは、ゲートウェイがリレーに送信するグループメンバーシップメッセージを含むIPデータグラムを生成します。 IGMPおよびMLDプロトコルは、プロトコルの堅牢性に必要な再送信およびタイミング動作も提供します。
All AMT encapsulation, decapsulation, and relay interaction are assumed to occur within the pseudo-interface.
すべてのAMTカプセル化、カプセル化解除、およびリレーの相互作用は、疑似インターフェース内で発生すると想定されています。
A gateway host or application may create separate interfaces for IPv4/IGMP and IPv6/MLD. A gateway host or application may also require additional pseudo-interfaces for each source or domain-specific relay address.
ゲートウェイホストまたはアプリケーションは、IPv4 / IGMPおよびIPv6 / MLDの個別のインターフェイスを作成する場合があります。ゲートウェイホストまたはアプリケーションでは、各送信元またはドメイン固有のリレーアドレスに対して追加の疑似インターフェイスが必要になる場合もあります。
Within this document, the term "gateway" may be used as a generic reference to an entity executing the gateway protocol, a gateway pseudo-interface, or a gateway device that has one or more interfaces connected to a unicast internetwork and one or more AMT gateway pseudo-interfaces.
このドキュメントでは、「ゲートウェイ」という用語は、ゲートウェイプロトコル、ゲートウェイ疑似インターフェース、またはユニキャストインターネットワークに接続された1つ以上のインターフェースと1つ以上のAMTを持つゲートウェイデバイスを実行するエンティティの総称として使用されるゲートウェイ疑似インターフェース。
The following diagram illustrates how an existing host IP stack implementation might be used to provide AMT gateway functionality to a multicast application:
次の図は、既存のホストIPスタック実装を使用して、AMTゲートウェイ機能をマルチキャストアプリケーションに提供する方法を示しています。
+-----------------------------------------------------+
|Host |
| ______________________________________ |
| | | |
| | ___________________________ | |
| | | | | |
| | | v | |
| | | +-----------+ +--------------+ |
| | | |Application| | AMT Daemon | |
| | | +-----------+ +--------------+ |
| | | join/leave | ^ data ^ AMT |
| | | | | | |
| | | +----|---|-------------|-+ |
| | | | __| |_________ | | |
| | | | | | | | |
| | | | | Sockets | | | |
| | | +-|------+-------+-|---|-+ |
| | | | | IGMP | TCP | |UDP| | |
| | | +-|------+-------+-|---|-+ |
| | | | | ^ IP | | | |
| | | | | | ____________| | | |
| | | | | | | | | |
| | | +-|-|-|----------------|-+ |
| | | | | | | |
| | | IP(IGMP)| | |IP(UDP(data)) |IP(UDP(AMT)) |
| | | v | | v |
| | | +-----------+ +---+ |
| | | |Virtual I/F| |I/F| |
| | | +-----------+ +---+ |
| | | | ^ ^ |
| | | IP(IGMP)| |IP(UDP(data)) | |
| | |_________| |IP(IGMP) | |
| | | | |
| |_________________| | |
| | |
+--------------------------------------|--------------+
v
AMT Relay
Figure 4: Virtual Interface Implementation Example
図4：仮想インターフェイスの実装例
In this example, the host IP stack uses a virtual network interface to interact with a gateway pseudo-interface implementation.
この例では、ホストIPスタックは仮想ネットワークインターフェイスを使用して、ゲートウェイの疑似インターフェイス実装と対話します。
Use cases for gateway functionality include the following:
ゲートウェイ機能の使用例は次のとおりです。
IGMP/MLD Proxy An IGMP/MLD proxy that runs AMT on an upstream interface and router-mode IGMP/MLD on downstream interfaces to provide host access to multicast traffic via the IGMP and MLD protocols.
IGMP / MLDプロキシIGMPおよびMLDプロトコルを介してマルチキャストトラフィックへのホストアクセスを提供するために、アップストリームインターフェイスでAMTを実行し、ダウンストリームインターフェイスでルーターモードIGMP / MLDを実行するIGMP / MLDプロキシ。
Virtual Network Interface A virtual network interface or pseudo-network device driver that runs AMT on a physical network interface to provide socket-layer access to multicast traffic via the IGMP/MLD service interface provided by the host IP stack.
仮想ネットワークインターフェイス仮想ネットワークインターフェイスまたは疑似ネットワークデバイスドライバー。物理ネットワークインターフェイスでAMTを実行し、ホストIPスタックによって提供されるIGMP / MLDサービスインターフェイスを介してマルチキャストトラフィックへのソケットレイヤーアクセスを提供します。
Application An application or application component that implements and executes IGMP/MLD and AMT internally to gain access to multicast traffic.
アプリケーションマルチキャストトラフィックにアクセスするためにIGMP / MLDおよびAMTを内部で実装および実行するアプリケーションまたはアプリケーションコンポーネント。
The downstream side of a relay services gateways -- the relay accepts encapsulated IGMP and MLD group membership messages from gateways and encapsulates and forwards the requested multicast traffic back to those gateways.
リレーサービスゲートウェイのダウンストリーム側-リレーは、ゲートウェイからのカプセル化されたIGMPおよびMLDグループメンバーシップメッセージを受け入れ、要求されたマルチキャストトラフィックをカプセル化して、それらのゲートウェイに転送します。
The upstream side of a relay communicates with a native multicast infrastructure -- the relay sends join and prune/leave requests towards multicast sources and accepts requested multicast traffic from those sources.
リレーのアップストリーム側は、ネイティブマルチキャストインフラストラクチャと通信します。リレーは、結合およびプルーニング/脱退要求をマルチキャストソースに送信し、それらのソースから要求されたマルチキャストトラフィックを受け入れます。
Each relay possesses a logical pseudo-interface:
各リレーは論理的な疑似インターフェースを持っています：
+------------------------------+
+--------+ | Multicast Control Plane |
| |IGMP/MLD| |
| | Query* | +------------+ +----------+ |
| |<---//----|IGMPv3/MLDv2| |Multicast | |
AMT | | | |Router-Mode |->|Routing |<->
+------+ Messages | AMT |----//--->|Protocol | |Protocol | |
|UDP/IP|<-------->| Relay |IGMP/MLD| +------------+ +----------+ |
+------+ | Pseudo-| Report | | | |
^ | I/F | Leave/ +------|---------------|-------+
| | | Done | |
| | | v |
V | | IP +-----------+ |
+---+ | | Multicast |Multicast |<------+
|I/F| | |<---//-----|Forwarding |
+---+ +--------+ |Plane |<--- IP Multicast
+-----------+
* Queries, if generated, are consumed by the pseudo-interface.
* クエリが生成された場合、疑似インターフェースによって消費されます。
Figure 5: AMT Relay Pseudo-Interface (Router-Based)
図5：AMTリレー疑似インターフェイス（ルーターベース）
The pseudo-interface is conceptually a network interface on which the relay runs the router portion of the IPv4/IGMPv3 and IPv6/MLDv2 protocols. Relays do not send unsolicited IGMPv3/MLDv2 query messages to gateways so relays must consume or discard any local queries normally generated by IGMPv3 or MLDv2. Note that the protocol mandates the use of IGMPv3 and MLDv2 for query messages. The AMT protocol is primarily intended for use in SSM applications and relies on several values provided by IGMPv3/MLDv2 to control gateway behavior.
疑似インターフェースは、概念的には、リレーがIPv4 / IGMPv3およびIPv6 / MLDv2プロトコルのルーター部分を実行するネットワークインターフェースです。リレーは非送信請求IGMPv3 / MLDv2クエリメッセージをゲートウェイに送信しないため、リレーは通常IGMPv3またはMLDv2によって生成されるローカルクエリを消費または破棄する必要があります。このプロトコルでは、クエリメッセージにIGMPv3およびMLDv2の使用が義務付けられていることに注意してください。 AMTプロトコルは主にSSMアプリケーションでの使用を目的としており、ゲートウェイの動作を制御するためにIGMPv3 / MLDv2によって提供されるいくつかの値に依存しています。
A relay maintains group membership state for each gateway connected through the pseudo-interface as well as for the entire pseudo-interface (if multiple gateways are managed via a single interface). Multicast packets received on upstream interfaces on the relay are routed to the pseudo-interface where they are replicated, encapsulated, and sent to interested gateways. Changes in the pseudo-interface group membership state may trigger the transmission of multicast protocol requests upstream towards a given source or rendezvous point and cause changes in internal routing/forwarding state.
リレーは、疑似インターフェースを介して接続された各ゲートウェイおよび疑似インターフェース全体（複数のゲートウェイが単一のインターフェースを介して管理されている場合）のグループメンバーシップ状態を維持します。リレーのアップストリームインターフェイスで受信されたマルチキャストパケットは、疑似インターフェイスにルーティングされ、そこで複製、カプセル化されて、関係するゲートウェイに送信されます。疑似インターフェイスグループメンバーシップの状態が変化すると、マルチキャストプロトコル要求が特定の送信元またはランデブーポイントに向けてアップストリームに送信され、内部ルーティング/転送状態が変化する可能性があります。
The relay pseudo-interface is an architectural abstraction used to describe AMT protocol operation. For the purposes of this document, the pseudo-interface is most easily viewed as an interface to a single gateway -- encapsulation, decapsulation, and other AMT-specific processing occurs "within" the pseudo-interface while forwarding and replication occur outside of it.
リレー疑似インターフェースは、AMTプロトコル操作を記述するために使用されるアーキテクチャーの抽象概念です。このドキュメントの目的上、疑似インターフェイスは、単一のゲートウェイへのインターフェイスとして最も簡単に表示されます。カプセル化、カプセル化解除、およびその他のAMT固有の処理は、疑似インターフェイスの「内部」で行われ、転送と複製はその外部で行われます。 。
An alternative view is to treat the pseudo-interface as a non-broadcast multi-access (NBMA) network interface whose link layer is the unicast-only network over which AMT messages are exchanged with gateways. Individual gateways are conceptually treated as logical NBMA links on the interface. In this architectural model, group membership tracking, replication, and forwarding functions occur in the pseudo-interface.
別の見方は、疑似インターフェースを、AMTメッセージがゲートウェイと交換されるユニキャストのみのネットワークであるリンク層を持つ非ブロードキャストマルチアクセス（NBMA）ネットワークインターフェースとして扱うことです。個々のゲートウェイは、概念上、インターフェイス上の論理NBMAリンクとして扱われます。このアーキテクチャモデルでは、グループメンバーシップの追跡、レプリケーション、および転送機能が疑似インターフェイスで発生します。
This document does not specify any particular architectural solution -- a relay developer may choose to implement and distribute protocol functionality as required to take advantage of existing relay platform services and architecture.
このドキュメントでは、特定のアーキテクチャソリューションを指定していません。リレー開発者は、既存のリレープラットフォームサービスとアーキテクチャを利用するために、必要に応じてプロトコル機能を実装および配布することを選択できます。
Within this document, the term "relay" may be used as a generic reference to an entity executing the relay protocol, a relay pseudo-interface, or a relay device that has one or more network interfaces with multicast connectivity to a native multicast infrastructure, zero or more interfaces connected to a unicast internetwork, and one or more relay pseudo-interfaces.
このドキュメントでは、「リレー」という用語は、リレープロトコル、リレー疑似インターフェース、またはネイティブマルチキャストインフラストラクチャへのマルチキャスト接続を備えた1つ以上のネットワークインターフェースを持つリレーデバイスを実行するエンティティへの一般的な参照として使用されます。ユニキャストインターネットワークに接続された0個以上のインターフェース、および1つ以上のリレー疑似インターフェース。
Use cases for relay functionality include the following:
リレー機能の使用例は次のとおりです。
Multicast Router A multicast router that runs AMT on a downstream interface to provide gateway access to multicast traffic. A "relay router" uses a multicast routing protocol (e.g., PIM-SM [RFC4601]) to construct a forwarding path for multicast traffic by sending join and prune messages to neighboring routers to join or leave multicast distribution trees for a given SSM source or ASM rendezvous point.
マルチキャストルーターマルチキャストトラフィックへのゲートウェイアクセスを提供するために、ダウンストリームインターフェイスでAMTを実行するマルチキャストルーター。 「リレールーター」は、マルチキャストルーティングプロトコル（PIM-SM [RFC4601]など）を使用して、参加およびプルーニングメッセージを隣接ルーターに送信し、特定のSSMソースのマルチキャスト配信ツリーに参加または脱退することにより、マルチキャストトラフィックの転送パスを構築します。 ASMランデブーポイント。
IGMP/MLD Proxy Router An IGMP/MLD proxy that runs AMT on a downstream interface and host-mode IGMPv3/MLDv2 on an upstream interface. This "relay proxy" sends group membership reports to a local, multicast-enabled router to join and leave specific SSM or ASM groups.
IGMP / MLDプロキシルーターダウンストリームインターフェイスでAMTを実行し、アップストリームインターフェイスでホストモードIGMPv3 / MLDv2を実行するIGMP / MLDプロキシ。この「リレープロキシ」は、グループメンバーシップレポートをローカルのマルチキャスト対応ルーターに送信して、特定のSSMまたはASMグループに参加したり離脱したりします。
The AMT protocol calls for a relay deployment model that uses anycast addressing [RFC1546] [RFC4291] to pair gateways with relays.
AMTプロトコルは、エニーキャストアドレス指定[RFC1546] [RFC4291]を使用してゲートウェイをリレーとペアにするリレー展開モデルを要求します。
Under this approach, one or more relays advertise a route for the same IP address prefix. To find a relay with which to communicate, a gateway sends a message to an anycast IP address within that prefix. This message is routed to the topologically nearest relay that has advertised the prefix. The relay that receives the message responds by sending its unicast address back to the gateway. The gateway uses this address as the destination address for any messages it subsequently sends to the relay.
このアプローチでは、1つ以上のリレーが同じIPアドレスプレフィックスのルートをアドバタイズします。ゲートウェイは、通信するリレーを見つけるために、そのプレフィックス内のエニーキャストIPアドレスにメッセージを送信します。このメッセージは、プレフィックスをアドバタイズしたトポロジ的に最も近いリレーにルーティングされます。メッセージを受信したリレーは、ユニキャストアドレスをゲートウェイに送り返すことで応答します。ゲートウェイは、このアドレスを、その後リレーに送信するメッセージの宛先アドレスとして使用します。
The use of anycast addressing provides the following benefits:
エニーキャストアドレス指定を使用すると、次の利点があります。
o Relays may be deployed at multiple locations within a single multicast-enabled network. Relays might be installed "near" gateways to reduce bandwidth requirements and latency and to limit the number of gateways that might be serviced by a single relay.
o リレーは、単一のマルチキャスト対応ネットワーク内の複数の場所に配置できます。リレーは、帯域幅の要件と待ち時間を削減し、単一のリレーによって処理される可能性のあるゲートウェイの数を制限するために、ゲートウェイの「近く」にインストールされる場合があります。
o Relays may be added or removed at any time, thereby allowing staged deployment, scaling, and hot-swapping -- the relay discovery process will always return the nearest operational relay.
o リレーはいつでも追加または削除できるため、段階的な展開、スケーリング、およびホットスワップが可能です。リレー検出プロセスでは、常に最も近い動作中のリレーが返されます。
o Relays may take themselves offline when they exhaust resources required to service additional gateways. Existing gateway connections may be preserved, but new gateway requests would be routed to the next-nearest relay.
o リレーは、追加のゲートウェイにサービスを提供するために必要なリソースを使い果たすと、オフラインになることがあります。既存のゲートウェイ接続は保持されますが、新しいゲートウェイ要求は次の最も近いリレーにルーティングされます。
Ideally, the AMT protocol would provide a universal solution for connecting receivers to multicast sources, so that any gateway could be used to access any globally advertised multicast source via publicly accessible, widely deployed relays. Unfortunately, today's Internet does not yet allow this, because many relays will lack native multicast access to sources even though they may be globally accessible via unicast.
理想的には、AMTプロトコルは、レシーバーをマルチキャストソースに接続するためのユニバーサルソリューションを提供し、あらゆるゲートウェイを使用して、公にアクセス可能な、広く展開されているリレーを介してグローバルにアドバタイズされたマルチキャストソースにアクセスできます。残念ながら、今日のインターネットはまだこれを許可していません。ユニキャストを介してグローバルにアクセスできる場合でも、多くのリレーがソースへのネイティブマルチキャストアクセスを欠いているためです。
In these cases, a provider may deploy relays within their own source network to allow for multicast distribution within that network. Gateways that use these relays must use a provider-specific relay discovery mechanism or a private anycast address to obtain access to these relays.
これらの場合、プロバイダーは自身のソースネットワーク内にリレーを展開して、そのネットワーク内でマルチキャスト配信を可能にする場合があります。これらのリレーを使用するゲートウェイは、プロバイダー固有のリレー検出メカニズムまたはプライベートエニーキャストアドレスを使用して、これらのリレーにアクセスする必要があります。
AMT relies on UDP to provide best-effort delivery of multicast data to gateways. Neither AMT nor UDP provides the congestion control mechanisms required to regulate the flow of data messages passing through a network. While congestion remediation might be provided by multicast receiver applications via multicast group selection or upstream reporting mechanisms, there are no means by which to ensure that such mechanisms are employed. To limit the possible congestion across a network or wider Internet, AMT service providers are expected to deploy AMT relays near the provider's network border and its interface with edge routers. The provider must limit relay address advertisements to those edges to prevent distant gateways from being able to access a relay and potentially generate flows that consume or exceed the capacity of intervening links.
AMTはUDPに依存して、ゲートウェイへのマルチキャストデータのベストエフォート配信を提供します。 AMTもUDPも、ネットワークを通過するデータメッセージのフローを規制するために必要な輻輳制御メカニズムを提供しません。輻輳修正は、マルチキャストグループ選択またはアップストリームレポートメカニズムを介してマルチキャストレシーバーアプリケーションによって提供される場合がありますが、そのようなメカニズムが採用されていることを確認する手段はありません。ネットワークまたはより広いインターネット全体で起こりうる輻輳を制限するために、AMTサービスプロバイダーは、プロバイダーのネットワーク境界とエッジルーターとのインターフェイスの近くにAMTリレーを展開することが期待されています。プロバイダーは、リレーアドレスアドバタイズメントをこれらのエッジに制限して、離れたゲートウェイがリレーにアクセスできず、介在するリンクの容量を消費または超えるフローを生成する可能性がないようにする必要があります。
To execute the gateway portion of the protocol, a gateway requires a unicast IP address of an operational relay. This address may be obtained using a number of methods -- it may be statically assigned or dynamically chosen via some form of relay discovery process.
プロトコルのゲートウェイ部分を実行するには、ゲートウェイに運用中のリレーのユニキャストIPアドレスが必要です。このアドレスは、いくつかの方法を使用して取得できます。静的に割り当てることも、何らかの形のリレー検出プロセスを介して動的に選択することもできます。
As described in the previous section, the AMT protocol provides a relay discovery method that relies on anycast addressing. Gateways are not required to use AMT relay discovery, but all relay implementations must support it.
前のセクションで説明したように、AMTプロトコルは、エニーキャストアドレス指定に依存するリレー検出方法を提供します。ゲートウェイはAMTリレー検出を使用する必要はありませんが、すべてのリレー実装がそれをサポートする必要があります。
The AMT protocol uses the following terminology when describing the discovery process:
AMTプロトコルは、検出プロセスを説明するときに次の用語を使用します。
Relay Discovery Address Prefix: The anycast address prefix used to route discovery messages to a relay.
リレー検出アドレスプレフィックス：検出メッセージをリレーにルーティングするために使用されるエニーキャストアドレスプレフィックス。
Relay Discovery Address: The anycast destination address used when sending discovery messages.
リレー検出アドレス：検出メッセージの送信時に使用されるエニーキャスト宛先アドレス。
Relay Address: The unicast IP address obtained as a result of the discovery process.
リレーアドレス：検出プロセスの結果として取得されたユニキャストIPアドレス。
The selection of an anycast Relay Discovery Address may be source dependent, as a relay located via relay discovery must have multicast connectivity to a desired source.
エニーキャストリレー検出アドレスの選択は、ソースに依存する場合があります。リレー検出を介して配置されたリレーは、目的のソースへのマルチキャスト接続を持っている必要があるためです。
Similarly, the selection of a unicast Relay Address may be source dependent, as a relay contacted by a gateway to supply multicast traffic must have native multicast connectivity to the traffic source.
同様に、マルチキャストトラフィックを提供するためにゲートウェイからアクセスされるリレーには、トラフィックソースへのネイティブマルチキャスト接続が必要であるため、ユニキャストリレーアドレスの選択は送信元に依存する場合があります。
Methods that might be used to perform source-specific or group-specific relay selection are highly implementation dependent and are not further addressed by this document. Possible approaches include the use of static lookup tables, DNS-based queries, or a provision of a service interface that accepts join requests on (S,G,relay-discovery-address) or (S,G,relay-address) tuples.
ソース固有またはグループ固有のリレー選択を実行するために使用される可能性のあるメソッドは、実装に大きく依存するため、このドキュメントではこれ以上取り上げません。可能なアプローチには、静的ルックアップテーブル、DNSベースのクエリの使用、または（S、G、relay-discovery-address）または（S、G、relay-address）タプルの結合要求を受け入れるサービスインターフェイスのプロビジョニングが含まれます。
IANA has assigned IPv4 and IPv6 address prefixes for use in advertising and discovering publicly accessible relays.
IANAは、公的にアクセス可能なリレーのアドバタイズおよび検出に使用するためにIPv4およびIPv6アドレスプレフィックスを割り当てました。
A Relay Discovery Address is constructed from an address prefix by setting the low-order octet of the prefix address to 1 (for both IPv4 and IPv6). All remaining addresses within each prefix are reserved for future use.
リレー検出アドレスは、プレフィックスアドレスの下位オクテットを1に設定することにより、アドレスプレフィックスから構築されます（IPv4とIPv6の両方の場合）。各プレフィックス内の残りのすべてのアドレスは、将来の使用のために予約されています。
Public relays must advertise a route to the address prefix (e.g., via BGP [RFC4271]) and configure an interface to respond to the Relay Discovery Address.
パブリックリレーは、ルートプレフィックス（たとえば、BGP [RFC4271]を介して）にアドバタイズし、リレー検出アドレスに応答するようにインターフェイスを構成する必要があります。
The discovery address prefixes are described in Section 7.
検出アドレスのプレフィックスについては、セクション7で説明します。
The AMT protocol defines the following messages for control and encapsulation. These messages are exchanged as UDP/IP datagrams, one message per datagram.
AMTプロトコルは、制御とカプセル化のために次のメッセージを定義します。これらのメッセージは、UDP / IPデータグラムとして交換されます（データグラムごとに1つのメッセージ）。
Relay Discovery: Sent by gateways to solicit a Relay Advertisement from any relay. Used to find a relay with which to communicate.
リレー検出：リレーからリレーアドバタイズを要求するためにゲートウェイによって送信されます。通信するリレーを見つけるために使用されます。
Relay Advertisement: Sent by relays as a response to a Relay Discovery message. Used to deliver a Relay Address to a gateway.
リレーアドバタイズメント：リレー検出メッセージへの応答としてリレーによって送信されます。リレーアドレスをゲートウェイに配信するために使用されます。
Request: Sent by gateways to solicit a Membership Query message from a relay.
要求：ゲートウェイから送信され、リレーからメンバーシップクエリメッセージを要求します。
Membership Query: Sent by relays as a response to a Request message. Used to deliver an encapsulated IGMPv3 or MLDv2 query message to the gateway.
メンバーシップクエリ：リレーによってリクエストメッセージへの応答として送信されます。カプセル化されたIGMPv3またはMLDv2クエリメッセージをゲートウェイに配信するために使用されます。
Membership Update: Sent by gateways to deliver an encapsulated IGMP or MLD report/leave/done message to a relay.
メンバーシップの更新：カプセル化されたIGMPまたはMLDレポート/脱退/完了メッセージをリレーに配信するためにゲートウェイによって送信されます。
Multicast Data: Sent by relays to deliver an encapsulated IP multicast datagram or datagram fragment to a gateway.
マルチキャストデータ：リレーによって送信され、カプセル化されたIPマルチキャストデータグラムまたはデータグラムフラグメントをゲートウェイに配信します。
Teardown: Sent by gateways to stop the delivery of Multicast Data messages requested in an earlier Membership Update message.
ティアダウン：以前のMembership Updateメッセージで要求されたマルチキャストデータメッセージの配信を停止するためにゲートウェイによって送信されます。
The following sections describe how these messages are exchanged to execute the protocol.
次のセクションでは、これらのメッセージを交換してプロトコルを実行する方法について説明します。
Gateway Relay
------- -----
: :
| |
[1] |Relay Discovery |
|------------------->|
| |
| Relay Advertisement| [2]
|<-------------------|
[3] | |
: :
Figure 6: AMT Relay Discovery Sequence
図6：AMTリレー検出シーケンス
The following sequence describes how the Relay Discovery and Relay Advertisement messages are used to find a relay with which to communicate:
次のシーケンスは、リレーディスカバリメッセージとリレーアドバタイズメッセージを使用して、通信するリレーを見つける方法を示しています。
1. The gateway sends a Relay Discovery message containing a random nonce to the Relay Discovery Address. If the Relay Discovery Address is an anycast address, the message is routed to the topologically nearest network node that advertises that address.
1. ゲートウェイは、ランダムなナンスを含むリレー検出メッセージをリレー検出アドレスに送信します。リレー検出アドレスがエニーキャストアドレスの場合、メッセージは、そのアドレスをアドバタイズするトポロジ的に最も近いネットワークノードにルーティングされます。
2. The node receiving the Relay Discovery message sends a Relay Advertisement message back to the source of the Relay Discovery message. The message carries a copy of the nonce contained in the Relay Discovery message and the unicast IP address of a relay.
2. リレー検出メッセージを受信したノードは、リレーアドバタイズメッセージをリレー検出メッセージの送信元に送り返します。メッセージには、リレー検出メッセージに含まれるナンスのコピーとリレーのユニキャストIPアドレスが含まれます。
3. When the gateway receives the Relay Advertisement message, it verifies that the nonce matches the one sent in the Relay Discovery message and, if it does, uses the Relay Address carried by the Relay Advertisement as the destination address for subsequent AMT messages.
3. ゲートウェイは、リレーアドバタイズメッセージを受信すると、ナンスがリレーディスカバリメッセージで送信されたものと一致することを確認し、一致する場合、後続のAMTメッセージの宛先アドレスとしてリレーアドバタイズによって伝送されるリレーアドレスを使用します。
Note that the responder need not be a relay -- the responder may obtain a Relay Address by some other means and return the result in the Relay Advertisement (i.e., the responder is a load-balancer or broker).
レスポンダはリレーである必要はないことに注意してください-レスポンダは他の方法でリレーアドレスを取得し、その結果をリレーアドバタイズメントで返すことができます（つまり、レスポンダはロードバランサまたはブローカです）。
There exists a significant difference between normal IGMP and MLD behavior and that required by AMT. An IGMP/MLD router acting as a querier normally transmits query messages on a network interface to construct and refresh group membership state for the connected network. These query messages are multicast to all IGMP/MLD-enabled hosts on the network. Each host responds by multicasting report messages that describe their current multicast reception state.
通常のIGMPとMLDの動作とAMTに必要な動作との間には大きな違いがあります。クエリアとして機能するIGMP / MLDルーターは通常、ネットワークインターフェイスでクエリメッセージを送信して、接続されたネットワークのグループメンバーシップ状態を構築および更新します。これらのクエリメッセージは、ネットワーク上のすべてのIGMP / MLD対応ホストにマルチキャストされます。各ホストは、現在のマルチキャスト受信状態を説明するレポートメッセージをマルチキャストして応答します。
However, AMT does not allow relays to send unsolicited query messages to gateways, as the set of active gateways may be unknown to the relay and potentially quite large. Instead, AMT requires each gateway to periodically send a message to a relay to solicit a query response. A gateway accomplishes this by sending a Request message to a relay. The relay responds by sending a Membership Query message back to the gateway. The Membership Query message carries an encapsulated query that is processed by the IGMP or MLD protocol implementation on the gateway to produce a membership/listener report. Each time the gateway receives a Membership Query message, it starts a timer whose expiration will trigger the start of a new Request->Membership Query message exchange. This timer-driven sequence is used to mimic the transmission of a periodic query by an IGMP/MLD router. This query cycle may continue indefinitely once started by sending the initial Request message.
ただし、アクティブゲートウェイのセットはリレーにとって未知であり、非常に大きくなる可能性があるため、AMTはリレーが非送信請求クエリメッセージをゲートウェイに送信することを許可しません。代わりに、AMTはクエリ応答を要求するために、各ゲートウェイがリレーに定期的にメッセージを送信することを要求します。ゲートウェイは、要求メッセージをリレーに送信することでこれを実現します。リレーは、Membership Queryメッセージをゲートウェイに送り返すことによって応答します。メンバーシップクエリメッセージは、ゲートウェイ上のIGMPまたはMLDプロトコルの実装によって処理されるカプセル化されたクエリを伝達し、メンバーシップ/リスナーレポートを生成します。ゲートウェイは、メンバーシップクエリメッセージを受信するたびにタイマーを開始します。タイマーの期限が切れると、新しいリクエスト->メンバーシップクエリメッセージの交換が開始されます。このタイマー駆動シーケンスは、IGMP / MLDルーターによる定期的なクエリの送信を模倣するために使用されます。このクエリサイクルは、最初のリクエストメッセージを送信して開始すると、無期限に継続する場合があります。
A membership update occurs when an IGMP or MLD report, leave, or done message is passed to the gateway pseudo-interface. These messages may be produced as a result of the aforementioned query processing or as a result of receiver interaction with the IGMP/MLD service interface. Each report is encapsulated and sent to the relay after the gateway has successfully established communication with the relay via a Request and Membership Query message exchange. If a report is passed to the pseudo-interface before the gateway has received a Membership Query message from the relay, the gateway may discard the report or queue the report for delivery after a Membership Query is received. Subsequent IGMP/MLD report/leave/done messages that are passed to the pseudo-interface are immediately encapsulated and transmitted to the relay.
メンバーシップの更新は、IGMPまたはMLDのレポート、脱退、または完了のメッセージがゲートウェイの疑似インターフェースに渡されると発生します。これらのメッセージは、前述のクエリ処理の結果として、またはIGMP / MLDサービスインターフェイスとのレシーバーの相互作用の結果として生成される場合があります。ゲートウェイが要求およびメンバーシップクエリメッセージ交換を介してリレーとの通信を正常に確立した後、各レポートはカプセル化されてリレーに送信されます。ゲートウェイがリレーからメンバーシップクエリメッセージを受信する前に疑似インターフェイスにレポートが渡された場合、ゲートウェイはメンバーシップクエリの受信後にレポートを破棄するか、レポートをキューに入れて配信することができます。疑似インターフェイスに渡される後続のIGMP / MLDレポート/脱退/完了メッセージはすぐにカプセル化され、リレーに送信されます。
IGMP/MLD Pseudo-I/F Relay
-------- ---------- -----
: : :
| | Request |
| 1|-------------------->|
| | Membership Query |2
Query | | Q(0,{}) |
Timer | Start 3|<--------------------|
(QT)<--------------------------| |
| Q(0,{}) | |
|<--------------------| |
4| R({}) | Membership Update |
|-------------------->|5 R({}) |
| |====================>|6a
Join(S,G) : : :
()-------->|7 R({G:ALLOW({S})}) | Membership Update |
|-------------------->|8 R({G:ALLOW({S})}) |
| |====================>|9a Join(S,G)
| | |---------->()
: : :
| ------------|---------------------|------------
| | | | |
| | | Multicast Data | IP(S,G) |
| | | IP(S,G) 10|<--------() |
| | IP(S,G) 11|<====================| |
| | ()<--------| | |
| | | | |
: ------------:---------------------:------------
| Expired | |
(QT)-------------------------->|12 Request |
| 1|-------------------->|
| | Membership Query |2
| | Q(0,{}) |
| Start 3|<--------------------|
(QT)<--------------------------| |
| Q(0,{}) | |
|<--------------------| |
4| R({G:INCLUDE({S})}) | Membership Update |
|-------------------->|5 R({G:INCLUDE({S})})|
| |====================>|6b
Leave(S,G) : : :
()-------->|7 R({G:BLOCK({S})}) | Membership Update |
|-------------------->|8 R({G:BLOCK({S})}) |
| |====================>|9b Prune(S,G)
| | |---------->()
: : :
Figure 7: Membership Update Sequence (IGMPv3/MLDv2 Example)
図7：メンバーシップ更新シーケンス（IGMPv3 / MLDv2の例）
The following sequence describes how the Request, Membership Query, and Membership Update messages are used to report current group membership state or changes in group membership state:
次のシーケンスは、要求、メンバーシップクエリ、およびメンバーシップ更新メッセージを使用して、現在のグループメンバーシップの状態またはグループメンバーシップの状態の変化を報告する方法を示しています。
1. A gateway sends a Request message to the relay that contains a random nonce and a flag indicating whether the relay should return an IGMPv3 or MLDv2 General Query.
1. ゲートウェイは、ランダムなナンスと、リレーがIGMPv3またはMLDv2一般クエリを返すかどうかを示すフラグを含むリクエストメッセージをリレーに送信します。
2. When the relay receives a Request message, it generates a message authentication code (MAC), typically, by computing a hash digest from the message source IP address, source UDP port, request nonce, and a private secret. The relay then sends a Membership Query message to the gateway that contains the request nonce, the MAC, and an IGMPv3 or MLDv2 General Query.
2. リレーは、要求メッセージを受信すると、通常、メッセージの送信元IPアドレス、送信元UDPポート、要求ノンス、およびプライベートシークレットからハッシュダイジェストを計算することにより、メッセージ認証コード（MAC）を生成します。次に、リレーは、メンバーシップクエリメッセージを、要求ノンス、MAC、およびIGMPv3またはMLDv2一般クエリを含むゲートウェイに送信します。
3. When the gateway receives a Membership Query message, it verifies that the request nonce matches the one sent in the last Request, and if it does, the gateway saves the request nonce and MAC for use in sending subsequent Membership Update messages. The gateway starts a timer whose expiration will trigger the transmission of a new Request message and extracts the encapsulated General Query message for processing by the IGMP or MLD protocol. The query timer duration is specified by the relay in the Querier's Query Interval Code (QQIC) field in the IGMPv3 or MLDv2 General Query. The QQIC field is defined in Section 4.1.7 of [RFC3376] and Section 5.1.9 of [RFC3810]).
3. ゲートウェイがメンバーシップクエリメッセージを受信すると、要求ノンスが最後の要求で送信されたものと一致することを確認し、一致する場合、ゲートウェイは後続のメンバーシップ更新メッセージの送信に使用するために要求ノンスとMACを保存します。ゲートウェイはタイマーが開始し、その有効期限が新しい要求メッセージの送信をトリガーし、カプセル化された一般クエリメッセージを抽出して、IGMPまたはMLDプロトコルで処理します。クエリタイマーの期間は、リレーによって、IGMPv3またはMLDv2の一般クエリのクエリアのクエリインターバルコード（QQIC）フィールドで指定されます。 QQICフィールドは、[RFC3376]のセクション4.1.7および[RFC3810]のセクション5.1.9で定義されています。
4. The gateway's IGMP or MLD protocol implementation processes the General Query to produce a current-state report.
4. ゲートウェイのIGMPまたはMLDプロトコル実装は、一般クエリを処理して、現在の状態のレポートを生成します。
5. When an IGMP or MLD report is passed to the pseudo-interface, the gateway encapsulates the report in a Membership Update message and sends it to the relay. The request nonce and MAC fields in the Membership Update are assigned the values from the last Membership Query message received for the corresponding group membership protocol (IGMPv3 or MLDv2).
5. IGMPまたはMLDレポートが疑似インターフェースに渡されると、ゲートウェイはレポートをMembership Updateメッセージにカプセル化し、それをリレーに送信します。 Membership UpdateのリクエストnonceフィールドとMACフィールドには、対応するグループメンバーシッププロトコル（IGMPv3またはMLDv2）で受信した最後のMembership Queryメッセージの値が割り当てられます。
6. When the relay receives a Membership Update message, it computes a MAC from the message source IP address, source UDP port, request nonce, and a private secret. The relay accepts the Membership Update message if the received MAC matches the computed MAC; otherwise, the message is ignored. If the message is accepted, the relay may proceed to allocate, refresh, or modify tunnel state. This includes making any group membership, routing, and forwarding state changes, and also issuing any upstream protocol requests required to satisfy the state change. The diagram illustrates two scenarios:
6.リレーは、Membership Updateメッセージを受信すると、メッセージの送信元IPアドレス、送信元UDPポート、要求ノンス、およびプライベートシークレットからMACを計算します。受信したMACが計算されたMACと一致する場合、リレーはMembership Updateメッセージを受け入れます。それ以外の場合、メッセージは無視されます。メッセージが受け入れられると、リレーはトンネル状態の割り当て、更新、または変更に進む場合があります。これには、グループメンバーシップ、ルーティング、転送状態の変更、および状態変更を満たすために必要なアップストリームプロトコル要求の発行も含まれます。この図は、2つのシナリオを示しています。
A. The gateway has not previously reported any group subscriptions and the report does not contain any group subscriptions, so the relay takes no action.
A.ゲートウェイは以前にグループサブスクリプションを報告しておらず、レポートにはグループサブスクリプションが含まれていないため、リレーは何のアクションも実行しません。
B. The gateway has previously reported a group subscription, so the current-state report lists all current subscriptions. The relay responds by refreshing tunnel or group state and resetting any related timers.
B.ゲートウェイは以前にグループサブスクリプションを報告しているため、現在の状態のレポートにはすべての現在のサブスクリプションがリストされます。リレーは、トンネルまたはグループの状態を更新し、関連するタイマーをリセットすることによって応答します。
7. A receiver indicates to the gateway that it wishes to join (allow) or leave (block) specific multicast traffic. This request is typically made using some form of IGMP/MLD service interface (as described in Section 2 of [RFC3376] and Section 3 of [RFC3810]). The IGMP/MLD protocol responds by generating an IGMP or MLD state-change message.
7. レシーバーは、特定のマルチキャストトラフィックに参加（許可）または脱退（ブロック）することをゲートウェイに示します。このリクエストは通常、何らかの形式のIGMP / MLDサービスインターフェースを使用して行われます（[RFC3376]のセクション2および[RFC3810]のセクション3で説明）。 IGMP / MLDプロトコルは、IGMPまたはMLD状態変更メッセージを生成して応答します。
8. When an IGMP or MLD report/leave/done message is passed to the pseudo-interface, the gateway encapsulates the message in a Membership Update message and sends it to the relay. The request nonce and MAC fields in the Membership Update are assigned the values from the last Membership Query message received for the corresponding group membership protocol (IGMP or MLD).
8. IGMPまたはMLDレポート/脱退/完了メッセージが疑似インターフェースに渡されると、ゲートウェイはメッセージをメンバーシップ更新メッセージにカプセル化し、それをリレーに送信します。 Membership UpdateのリクエストnonceフィールドとMACフィールドには、対応するグループメンバーシッププロトコル（IGMPまたはMLD）について受信した最後のMembership Queryメッセージの値が割り当てられます。
The IGMP and MLD protocols may generate multiple messages to provide robustness against packet loss -- each of these must be encapsulated in a new Membership Update message and sent to the relay. The Querier's Robustness Variable (QRV) field in the last IGMP/MLD query delivered to the IGMP/MLD protocol is typically used to specify the number of repetitions (i.e., the host adopts the QRV value as its own Robustness Variable value). The QRV field is defined in Section 4.1.6 of [RFC3376] and Section 5.1.8 of [RFC3810].
IGMPおよびMLDプロトコルは、パケット損失に対する堅牢性を提供するために複数のメッセージを生成する場合があります。これらのそれぞれは、新しいMembership Updateメッセージにカプセル化され、リレーに送信される必要があります。 IGMP / MLDプロトコルに配信された最後のIGMP / MLDクエリのクエリアのロバストネス変数（QRV）フィールドは、通常、反復回数を指定するために使用されます（つまり、ホストはQRV値を独自のロバストネス変数値として採用します）。 QRVフィールドは、[RFC3376]のセクション4.1.6と[RFC3810]のセクション5.1.8で定義されています。
9. When the relay receives a Membership Update message, it again computes a MAC from the message source IP address, source UDP port, request nonce, and a private secret. The relay accepts the Membership Update message if the received MAC matches the computed MAC; otherwise, the message is ignored. If the message is accepted, the relay processes the encapsulated IGMP/MLD and allocates, modifies, or deletes tunnel state accordingly. This includes making any group membership, routing, and forwarding state changes, and also issuing any upstream protocol requests required to satisfy the state change. The diagram illustrates two scenarios:
9.リレーは、Membership Updateメッセージを受信すると、メッセージの送信元IPアドレス、送信元UDPポート、要求ノンス、およびプライベートシークレットからMACを再度計算します。受信したMACが計算されたMACと一致する場合、リレーはMembership Updateメッセージを受け入れます。それ以外の場合、メッセージは無視されます。メッセージが受け入れられると、リレーはカプセル化されたIGMP / MLDを処理し、それに応じてトンネル状態を割り当て、変更、または削除します。これには、グループメンバーシップ、ルーティング、転送状態の変更、および状態変更を満たすために必要なアップストリームプロトコル要求の発行も含まれます。この図は、2つのシナリオを示しています。
A. The gateway wishes to add a group subscription.
A.ゲートウェイはグループサブスクリプションを追加したいと考えています。
B. The gateway wishes to delete a previously reported group subscription.
B.ゲートウェイは、以前に報告されたグループサブスクリプションを削除したい。
10. Multicast datagrams transmitted from a source travel through the native multicast infrastructure to the relay. When the relay receives a multicast IP datagram that carries a source and destination address for which a gateway has expressed an interest in receiving (via the Membership Update message), it encapsulates the datagram into a Multicast Data message and sends it to the gateway using the source IP address and UDP port carried by the Membership Update message as the destination address.
10. ソースから送信されたマルチキャストデータグラムは、ネイティブのマルチキャストインフラストラクチャを経由してリレーに到達します。リレーが（Membership Updateメッセージを介して）受信に関心を示した送信元アドレスと宛先アドレスを運ぶマルチキャストIPデータグラムを受信すると、データグラムをマルチキャストデータメッセージにカプセル化し、それを使用してゲートウェイに送信します宛先アドレスとして、Membership Updateメッセージによって伝送される送信元IPアドレスとUDPポート。
11. When the gateway receives a Multicast Data message, it extracts the multicast packet from the message and passes it on to the appropriate receivers.
11. ゲートウェイは、マルチキャストデータメッセージを受信すると、メッセージからマルチキャストパケットを抽出し、適切な受信者に渡します。
12. When the query timer expires, the gateway sends a new Request message to the relay to start a new membership update cycle.
12. クエリタイマーが期限切れになると、ゲートウェイは新しい要求メッセージをリレーに送信して、新しいメンバーシップ更新サイクルを開始します。
The MAC-based source-authentication mechanism described above provides a simple defense against malicious attempts to exhaust relay resources via source-address spoofing. Flooding a relay with spoofed Request or Membership Update messages may consume computational resources and network bandwidth but will not result in the allocation of state, because the Request message is stateless and spoofed Membership Update messages will fail source authentication and be rejected by the relay.
上記のMACベースの送信元認証メカニズムは、送信元アドレスのスプーフィングによってリレーリソースを使い果たす悪意のある試みに対する単純な防御を提供します。スプーフィングされたリクエストまたはメンバーシップアップデートメッセージでリレーをフラッディングすると、計算リソースとネットワーク帯域幅が消費される可能性がありますが、リクエストメッセージはステートレスであり、スプーフィングされたメンバーシップアップデートメッセージはソース認証に失敗し、リレーによって拒否されるため、状態は割り当てられません。
A relay will only allocate new tunnel state if the IGMP/MLD report carried by the Membership Update message creates one or more group subscriptions.
Membership Updateメッセージによって伝送されるIGMP / MLDレポートが1つ以上のグループサブスクリプションを作成する場合にのみ、リレーは新しいトンネル状態を割り当てます。
A relay deallocates tunnel state after one of the following events: the gateway sends a Membership Update message containing a report that results in the deletion of all remaining group subscriptions, the IGMP/MLD state expires (due to lack of refresh by the gateway), or the relay receives a valid Teardown message from the gateway (see Section 4.2.1.3).
リレーは、次のいずれかのイベントの後にトンネル状態の割り当てを解除します。ゲートウェイは、残りのすべてのグループサブスクリプションを削除するレポートを含むMembership Updateメッセージを送信し、IGMP / MLD状態は期限切れになります（ゲートウェイによる更新がないため）。または、リレーがゲートウェイから有効なティアダウンメッセージを受信します（セクション4.2.1.3を参照）。
A gateway that accepts or reports group subscriptions for both IPv4 and IPv6 addresses will send separate Request and Membership Update messages for each protocol (IPv4/IGMP and IPv6/MLD).
IPv4アドレスとIPv6アドレスの両方のグループサブスクリプションを受け入れるまたは報告するゲートウェイは、プロトコル（IPv4 / IGMPおよびIPv6 / MLD）ごとに個別の要求およびメンバーシップ更新メッセージを送信します。
A gateway sends a Teardown message to a relay to request that it stop delivering Multicast Data messages to a tunnel endpoint created by an earlier Membership Update message. This message is intended to be used following a gateway address change (see Section 4.2.2.1) to stop the transmission of undeliverable or duplicate Multicast Data messages. Gateway support for the Teardown message is RECOMMENDED. Gateways are not required to send them and may instead rely on group membership to expire on the relay.
ゲートウェイはTeardownメッセージをリレーに送信して、以前のMembership Updateメッセージによって作成されたトンネルエンドポイントへのマルチキャストデータメッセージの配信を停止するように要求します。このメッセージは、配信不能または重複するマルチキャストデータメッセージの送信を停止するために、ゲートウェイアドレスの変更（セクション4.2.2.1を参照）の後に使用することを目的としています。ティアダウンメッセージのゲートウェイサポートは推奨されます。ゲートウェイはそれらを送信する必要はなく、代わりにグループメンバーシップに依存してリレーで期限切れになる場合があります。
Gateway Relay
------- -----
: Request :
[1] | N |
|---------------------->|
| Membership Query | [2]
| N,MAC,gADDR,gPORT |
|<======================|
[3] | Membership Update |
| ({G:INCLUDE({S})}) |
|======================>|
| |
---------------------:-----------------------:---------------------
| | | |
| | *Multicast Data | *IP Packet(S,G) |
| | gADDR,gPORT |<-----------------() |
| *IP Packet(S,G) |<======================| |
| ()<-----------------| | |
| | | |
---------------------:-----------------------:---------------------
~ ~
~ Request ~
[4] | N' |
|---------------------->|
| Membership Query | [5]
| N',MAC',gADDR',gPORT' |
|<======================|
[6] | |
| Teardown |
| N,MAC,gADDR,gPORT |
|---------------------->|
| | [7]
| Membership Update |
| ({G:INCLUDE({S})}) |
|======================>|
| |
---------------------:-----------------------:---------------------
| | | |
| | *Multicast Data | *IP Packet(S,G) |
| | gADDR',gPORT' |<-----------------() |
| *IP Packet (S,G) |<======================| |
| ()<-----------------| | |
| | | |
---------------------:-----------------------:---------------------
| |
: :
Figure 8: Teardown Message Sequence (IGMPv3/MLDv2 Example)
図8：ティアダウンメッセージシーケンス（IGMPv3 / MLDv2の例）
The following sequence describes how the Membership Query and Teardown messages are used to detect an address change and stop the delivery of Multicast Data messages to an address:
次のシーケンスは、Membership QueryメッセージとTeardownメッセージを使用してアドレスの変更を検出し、アドレスへのマルチキャストデータメッセージの配信を停止する方法を示しています。
1. A gateway sends a Request message containing a random nonce to the relay.
1. ゲートウェイは、ランダムなナンスを含むリクエストメッセージをリレーに送信します。
2. The relay sends a Membership Query message to the gateway that contains the source IP address (gADDR) and source UDP port (gPORT) values from the Request message. These values will be used to identify the tunnel should one be created by a subsequent Membership Update message.
2. リレーは、要求メッセージのソースIPアドレス（gADDR）とソースUDPポート（gPORT）の値を含むメンバーシップクエリメッセージをゲートウェイに送信します。これらの値は、後続のMembership Updateメッセージによって作成されたトンネルを識別するために使用されます。
3. When the gateway receives a Membership Query message that carries the gateway address fields, it compares the gateway IP address and UDP port number values with those received in the previous Membership Query (if any). If these values do not match, this indicates that the Request message arrived at the relay carrying a different source address than the one sent previously. At this point in the sequence, no change in source address or port has occurred.
3. ゲートウェイは、ゲートウェイアドレスフィールドを含むメンバーシップクエリメッセージを受信すると、ゲートウェイのIPアドレスとUDPポート番号の値を、前のメンバーシップクエリ（ある場合）で受信した値と比較します。これらの値が一致しない場合、これは、以前に送信されたものとは異なる送信元アドレスを運ぶ要求メッセージがリレーに到着したことを示しています。シーケンスのこの時点では、送信元アドレスまたはポートは変更されていません。
4. The gateway sends a new Request message to the relay. However, this Request message arrives at the relay carrying a different source address than that of the previous Request due to some change in network interface, address assignment, network topology, or NAT mapping.
4. ゲートウェイは新しい要求メッセージをリレーに送信します。ただし、このリクエストメッセージは、ネットワークインターフェイス、アドレス割り当て、ネットワークトポロジ、またはNATマッピングの変更により、前のリクエストとは異なる送信元アドレスを運ぶリレーに到着します。
5. The relay again responds by sending a Membership Query message to the gateway that contains the new source IP address (gADDR') and source UDP port (gPORT') values from the Request message.
5. リレーは再び、リクエストメッセージからの新しいソースIPアドレス（gADDR '）とソースUDPポート（gPORT'）の値を含むメンバーシップクエリメッセージをゲートウェイに送信することで応答します。
6. When the gateway receives the Membership Query message, it compares the gateway address and port number values against those returned in the previous Membership Query message.
6. ゲートウェイがメンバーシップクエリメッセージを受信すると、ゲートウェイアドレスとポート番号の値を、前のメンバーシップクエリメッセージで返された値と比較します。
7. If the reported address or port has changed, the gateway sends a Teardown message to the relay that contains the request nonce, MAC, gateway IP address, and gateway port number returned in the earlier Membership Query message. The gateway may send the Teardown message multiple times where the number of repetitions is governed by the Querier's Robustness Variable (QRV) value contained in the IGMPv3/MLDv2 General Query carried by the original Membership Query (see Section 4.1.6 of [RFC3376] and Section 5.1.8 of [RFC3810]). The gateway continues to process the new Membership Query message as usual.
7. 報告されたアドレスまたはポートが変更された場合、ゲートウェイは、前のメンバーシップクエリメッセージで返された要求ノンス、MAC、ゲートウェイIPアドレス、およびゲートウェイポート番号を含むティアダウンメッセージをリレーに送信します。ゲートウェイはティアダウンメッセージを複数回送信する場合があります。繰り返し数は、元のメンバーシップクエリによって運ばれるIGMPv3 / MLDv2一般クエリに含まれるクエリアのロバストネス変数（QRV）値によって制御されます（[RFC3376]のセクション4.1.6を参照）。 [RFC3810]のセクション5..1.8）。ゲートウェイは、通常どおり、新しいMembership Queryメッセージを処理し続けます。
8. When the relay receives a Teardown message, it computes a MAC from the message source IP address, source UDP port, request nonce, and a private secret. The relay accepts the Teardown message if the received MAC matches the computed MAC; otherwise, the message is ignored. If the message is accepted, the relay makes any group membership, routing, and forwarding state changes required to stop the transmission of Multicast Data messages to that address.
8. リレーがティアダウンメッセージを受信すると、メッセージの送信元IPアドレス、送信元UDPポート、要求ノンス、およびプライベートシークレットからMACを計算します。受信したMACが計算されたMACと一致する場合、リレーはTeardownメッセージを受け入れます。それ以外の場合、メッセージは無視されます。メッセージが受け入れられると、リレーは、そのアドレスへのマルチキャストデータメッセージの送信を停止するために必要なグループメンバーシップ、ルーティング、および転送状態を変更します。
The AMT protocol does not establish any requirements regarding what actions a gateway should take if it fails to receive a response from a relay. A gateway implementation may wait for an indefinite period of time to receive a response, may set a time limit on how long to wait for a response, may retransmit messages should the time limit be reached, may limit the number of retransmissions, or may simply report an error.
AMTプロトコルは、リレーからの応答の受信に失敗した場合にゲートウェイが実行する必要があるアクションに関する要件を確立しません。ゲートウェイの実装は、応答を受信するために無期限に待機する場合、応答を待機する時間に時間制限を設定する場合、時間制限に達した場合にメッセージを再送信する場合、再送信の数を制限する場合、または単にエラーを報告します。
For example, a gateway may retransmit a Request message if it fails to receive a Membership Query or expected Multicast Data messages within some time period. If the gateway fails to receive any response to a Request after several retransmissions or within some maximum period of time, it may reenter the relay discovery phase in an attempt to find a new relay. This topic is addressed in more detail in Section 5.2.
たとえば、ある期間内にメンバーシップクエリまたは予期されるマルチキャストデータメッセージを受信できない場合、ゲートウェイは要求メッセージを再送信できます。ゲートウェイが、数回の再送信後または最大時間内に要求に対する応答を受信できない場合、新しいリレーを見つけるために、リレー検出フェーズに再び入ることがあります。このトピックについては、セクション5.2で詳しく説明します。
From the standpoint of a relay, an AMT "tunnel" is identified by the IP address and UDP port pair used as the destination address for sending encapsulated multicast IP datagrams to a gateway. In this document, we refer to this address as the tunnel endpoint address.
リレーの観点からは、AMT「トンネル」は、カプセル化されたマルチキャストIPデータグラムをゲートウェイに送信するための宛先アドレスとして使用されるIPアドレスとUDPポートのペアによって識別されます。このドキュメントでは、このアドレスをトンネルエンドポイントアドレスと呼びます。
A gateway sends a Membership Update message to a relay to add or remove group subscriptions to a tunnel endpoint. The tunnel endpoint is identified by the source IP address and source UDP port carried by the Membership Update message when it arrives at a relay (this address may differ from that carried by the message when it exited the gateway as a result of network address translation).
ゲートウェイは、Membership Updateメッセージをリレーに送信して、トンネルエンドポイントへのグループサブスクリプションを追加または削除します。トンネルエンドポイントは、リレーに到着したときにMembership Updateメッセージが運ぶソースIPアドレスとソースUDPポートによって識別されます（このアドレスは、ネットワークアドレス変換の結果としてゲートウェイを出たときにメッセージが運ぶアドレスとは異なる場合があります） 。
The Membership Update messages sent by a single gateway host may originate from several source addresses or ports -- each unique combination represents a unique tunnel endpoint. A single gateway host may legitimately create and accept traffic on multiple tunnel endpoints, e.g., the gateway may use separate ports for the IPv4/IGMP and IPv6/MLD protocols.
単一のゲートウェイホストによって送信されるメンバーシップ更新メッセージは、複数の送信元アドレスまたはポートから発信される場合があります。それぞれの一意の組み合わせは、一意のトンネルエンドポイントを表します。単一のゲートウェイホストは、複数のトンネルエンドポイントでトラフィックを合法的に作成して受け入れることができます。たとえば、ゲートウェイはIPv4 / IGMPおよびIPv6 / MLDプロトコルに別々のポートを使用できます。
A tunnel is "created" when a gateway sends a Membership Update message containing an IGMP or MLD membership report that creates one or more group subscriptions when none currently existed for that tunnel endpoint address.
トンネルが「作成」されるのは、ゲートウェイがIGMPまたはMLDメンバーシップレポートを含むMembership Updateメッセージを送信し、そのトンネルエンドポイントアドレスに現在存在しないグループサブスクリプションを1つ以上作成した場合です。
A tunnel ceases to exist when all group subscriptions for a tunnel endpoint are deleted. This may occur as a result of the following events:
トンネルエンドポイントのすべてのグループサブスクリプションが削除されると、トンネルは存在しなくなります。これは、次のイベントの結果として発生する可能性があります。
o The gateway sends an IGMP or MLD report, leave, or done message to the relay that deletes the last group subscription linked to the tunnel endpoint.
o ゲートウェイは、IGMPまたはMLDレポート、脱退、または完了メッセージをリレーに送信し、トンネルエンドポイントにリンクされている最後のグループサブスクリプションを削除します。
o The gateway sends a Teardown message to the relay that causes it to delete any and all subscriptions bound to the tunnel endpoint.
o ゲートウェイはリレーにティアダウンメッセージを送信し、トンネルエンドポイントにバインドされているすべてのサブスクリプションを削除します。
o The relay stops receiving updates from the gateway until such time that per-group or per-tunnel timers expire, causing the relay to delete the subscriptions.
o リレーは、グループごとまたはトンネルごとのタイマーが期限切れになるまでゲートウェイからの更新の受信を停止し、リレーがサブスクリプションを削除する原因になります。
The tunneling approach described above conceptually transforms a unicast-only internetwork into an NBMA link layer, over which multicast traffic may be delivered. Each relay, plus the set of all gateways using the relay, together may be thought of as being on a separate logical NBMA link, where the "link layer" address is a UDP/ IP address-port pair provided by the Membership Update message.
上記のトンネリングアプローチは、ユニキャストのみのインターネットワークを、マルチキャストトラフィックが配信されるNBMAリンク層に概念的に変換します。各リレーと、そのリレーを使用するすべてのゲートウェイのセットを合わせて、個別の論理NBMAリンク上にあると考えることができます。「リンク層」アドレスは、Membership Updateメッセージによって提供されるUDP / IPアドレスとポートのペアです。
As described above, each time a relay receives a Membership Update message from a new source address-port pair, the group subscriptions described by that message apply to the tunnel endpoint identified by that address.
上記のように、リレーが新しい送信元アドレスとポートのペアからメンバーシップ更新メッセージを受信するたびに、そのメッセージで説明されているグループサブスクリプションが、そのアドレスで識別されるトンネルエンドポイントに適用されます。
This can cause problems for a gateway if the address carried by the messages it sends to a relay changes unexpectedly. These changes may cause the relay to transmit duplicate, undeliverable, or unrequested traffic back towards the gateway or an intermediate device. This may create congestion and have negative consequences for the gateway, its network, or multicast receivers and in some cases may also produce a significant amount of ICMP traffic directed back towards the relay by a NAT, router, or gateway host.
これにより、ゲートウェイがリレーに送信するメッセージに含まれるアドレスが予期せず変更された場合、ゲートウェイに問題が発生する可能性があります。これらの変更により、リレーが重複した、配信不能な、または要求されていないトラフィックをゲートウェイまたは中間デバイスに向けて送信する可能性があります。これにより、輻輳が発生し、ゲートウェイ、そのネットワーク、またはマルチキャストレシーバーに悪影響を及ぼす可能性があり、場合によっては、NAT、ルーター、またはゲートウェイホストによってリレーに向けられた大量のICMPトラフィックが生成されることもあります。
There are several scenarios in which the address carried by messages sent by a gateway may change without that gateway's knowledge -- for example, when:
ゲートウェイから送信されたメッセージによって運ばれるアドレスが、そのゲートウェイに気づかれずに変更されるシナリオがいくつかあります。たとえば、次のような場合です。
o The message originates from a different interface on a gateway that possesses multiple interfaces.
o メッセージは、複数のインターフェースを持つゲートウェイ上の別のインターフェースから発信されます。
o The DHCP assignment for a gateway interface changes.
o ゲートウェイインターフェイスのDHCP割り当てが変更されます。
o The gateway roams to a different wireless network.
o ゲートウェイは別のワイヤレスネットワークにローミングします。
o The address mapping applied by an intervening network-translation device (NAT) changes as a result of mapping expiration or routing changes in a multihomed network.
o マルチホームネットワークでのマッピングの有効期限またはルーティングの変更の結果として、介入するネットワーク変換デバイス（NAT）によって適用されるアドレスマッピング。
In the case where the address change occurs between the transmission of a Request message and subsequent Membership Update messages, the relay will simply ignore any Membership Update messages from the new address because MAC authentication will fail (see Section 4.2.1.2). The relay may continue to transmit previously requested traffic, but no duplication will occur, i.e., the possibility for the delivery of duplicate traffic does not arise until a Request message is received from the new address.
リクエストメッセージの送信とその後のメンバーシップアップデートメッセージの送信の間にアドレス変更が発生した場合、MAC認証が失敗するため、リレーは新しいアドレスからのメンバーシップアップデートメッセージを無視します（セクション4.2.1.2を参照）。リレーは以前に要求されたトラフィックを送信し続けますが、重複は発生しません。つまり、新しいアドレスから要求メッセージが受信されるまで、重複トラフィックの配信の可能性は発生しません。
The protocol provides a method for a gateway to detect an address change and explicitly request that the relay stop sending traffic to a previous address. This process involves the Membership Query and Teardown messages and is described in Section 4.2.1.3.
このプロトコルは、ゲートウェイがアドレスの変更を検出し、リレーが前のアドレスへのトラフィックの送信を停止することを明示的に要求する方法を提供します。このプロセスには、Membership QueryメッセージとTeardownメッセージが含まれ、セクション4.2.1.3で説明されています。
The messages sent by a gateway to a relay may be subject to network address translation (NAT) -- the source IP address and UDP port carried by an IP packet sent by the gateway may be modified multiple times before arriving at the relay. In the most restrictive form of NAT, the NAT device will create a new mapping for each combination of source and destination IP address and UDP port. In this case, bidirectional communication can only be conducted by sending outgoing packets to the source address and port carried by the last incoming packet.
ゲートウェイからリレーに送信されるメッセージは、ネットワークアドレス変換（NAT）の対象となる可能性があります。ゲートウェイによって送信されるIPパケットによって伝送されるソースIPアドレスとUDPポートは、リレーに到達する前に複数回変更される可能性があります。 NATの最も制限的な形式では、NATデバイスは、送信元と宛先のIPアドレスとUDPポートの各組み合わせに対して新しいマッピングを作成します。この場合、双方向通信は、発信パケットを最後の着信パケットが運ぶソースアドレスとポートに送信することによってのみ実行できます。
Membership Update Membership Update
src: iADDR:iPORT src: eADDR:ePORT
dst: rADDR:rPORT dst: rADDR:rPORT
+---------+
| NAT |
+---------+ +-----------+ +---------+
| |---------->| |--------->| |
| Gateway | | Mapping | | Relay |
| |<----------| |<---------| |
+---------+ +-----------+ +---------+
| |
+---------+
Multicast Data Multicast Data
src: rADDR:rPORT src: rADDR:rPORT
dst: iADDR:iPORT dst: eADDR:ePORT
Figure 9: Network Address Translation in AMT
図9：AMTでのネットワークアドレス変換
AMT provides automatic NAT traversal by using the source IP address and UDP port carried by the Membership Update message as received at the relay as the destination address for any Multicast Data messages the relay sends back as a result.
AMTは、リレーで受信されたMembership Updateメッセージによって伝送されたソースIPアドレスとUDPポートを、結果としてリレーが送信するマルチキャストデータメッセージの宛先アドレスとして使用することにより、自動NATトラバーサルを提供します。
The NAT mapping created by a Membership Update message will eventually expire unless it is refreshed by a passing message. This refresh will occur each time the gateway performs the periodic update required to refresh group state within the relay (see Section 4.2.1.2).
Membership Updateメッセージによって作成されたNATマッピングは、受け渡しメッセージによって更新されない限り、最終的に期限切れになります。この更新は、ゲートウェイがリレー内のグループ状態を更新するために必要な定期的な更新を実行するたびに発生します（セクション4.2.1.2を参照）。
Gateway Relay
ゲートウェイリレー
IP:IGMP IP:IGMP
| AMT:IP:IGMP AMT:IP:IGMP |
| | | |
| | IP:UDP:AMT:IP:IGMP | |
_______ | ___ | ______ | ______ | ___ | _______
|IGMP|IP| v |AMT| v |UDP|IP| v |IP|UDP| v |AMT| v |IP|IGMP|
| | | | | | | | | | | | | | | |
| |<------------------------------------------------------->| |
|____| | | | | | | | | | | | | |____|
| |<--------------------------------------------------| |
|_______| ^ |___| ^ |___|__| ^ |__|___| ^ |___| ^ |_______|
| | | | |
IP AMT:IP IP:UDP:AMT:IP AMT:IP IP
Figure 10: AMT Encapsulation
図10：AMTカプセル化
The IGMP and MLD messages used in AMT are exchanged as complete IP datagrams. These IP datagrams are encapsulated in AMT messages that are transmitted using UDP. The same holds true for multicast traffic -- each multicast IP datagram or datagram fragment that arrives at the relay is encapsulated in an AMT message and transmitted to one or more gateways via UDP.
AMTで使用されるIGMPおよびMLDメッセージは、完全なIPデータグラムとして交換されます。これらのIPデータグラムは、UDPを使用して送信されるAMTメッセージにカプセル化されます。同じことがマルチキャストトラフィックにも当てはまります。リレーに到着する各マルチキャストIPデータグラムまたはデータグラムフラグメントは、AMTメッセージにカプセル化され、UDPを介して1つ以上のゲートウェイに送信されます。
The IP protocol of the encapsulated packets need not match the IP protocol used to send the AMT messages. AMT messages sent via IPv4 may carry IPv6/MLD packets, and AMT messages sent via IPv6 may carry IPv4/IGMP packets.
カプセル化されたパケットのIPプロトコルは、AMTメッセージの送信に使用されるIPプロトコルと一致する必要はありません。 IPv4を介して送信されるAMTメッセージはIPv6 / MLDパケットを運ぶことができ、IPv6を介して送信されるAMTメッセージはIPv4 / IGMPパケットを運ぶことができます。
The Checksum field contained in the UDP header of the messages requires special consideration. Of primary concern is the cost of computing a checksum on each replicated multicast packet after it is encapsulated for delivery to a gateway. Many routing/forwarding platforms do not possess the capability to compute checksums on UDP-encapsulated packets, as they may not have access to the entire datagram.
メッセージのUDPヘッダーに含まれるチェックサムフィールドには、特別な考慮が必要です。主な関心事は、ゲートウェイに配信するためにカプセル化された後、複製された各マルチキャストパケットのチェックサムを計算するコストです。多くのルーティング/転送プラットフォームは、データグラム全体にアクセスできない可能性があるため、UDPカプセル化パケットのチェックサムを計算する機能を備えていません。
To avoid placing an undue burden on the relay platform, the protocol specifically allows zero-valued UDP checksums on the Multicast Data messages. This is not an issue in UDP over IPv4, as the UDP Checksum field may be set to zero. However, this is a problem for UDP over IPv6, as that protocol requires a valid, non-zero checksum in UDP datagrams [RFC2460]. Messages sent over IPv6 with a UDP checksum of zero may fail to reach the gateway. This is a well-known issue for UDP-based tunneling protocols and is described in [RFC6936]. A recommended solution is described in [RFC6935].
リレープラットフォームに過度の負担をかけないようにするために、プロトコルでは、マルチキャストデータメッセージでゼロ値のUDPチェックサムを明確に許可しています。 UDPチェックサムフィールドがゼロに設定されている可能性があるため、これはIPv4上のUDPでは問題ではありません。ただし、このプロトコルはUDP over IPv6の問題です。そのプロトコルは、UDPデータグラム[RFC2460]で有効なゼロ以外のチェックサムを必要とするためです。 UDPチェックサムがゼロのIPv6経由で送信されたメッセージは、ゲートウェイに到達できない場合があります。これはUDPベースのトンネリングプロトコルのよく知られた問題であり、[RFC6936]で説明されています。推奨される解決策は、[RFC6935]で説明されています。
Naive encapsulation of multicast IP datagrams within AMT data messages may produce UDP datagrams that might require fragmentation if their size exceeds the MTU of the network path between the relay and a gateway. Many multicast applications, especially those related to media streaming, are designed to deliver independent data samples in separate packets, without fragmentation, to ensure that some number of complete samples can be delivered even in the presence of packet loss. To prevent or reduce undesirable fragmentation, the AMT protocol describes specific procedures for handling multicast datagrams whose encapsulation might exceed the Path MTU. These procedures are described in Section 5.3.3.6.
AMTデータメッセージ内のマルチキャストIPデータグラムの単純なカプセル化では、サイズがリレーとゲートウェイ間のネットワークパスのMTUを超える場合、フラグメンテーションが必要になる可能性のあるUDPデータグラムが生成されることがあります。多くのマルチキャストアプリケーション、特にメディアストリーミングに関連するものは、独立したデータサンプルを断片化せずに個別のパケットで配信するように設計されており、パケット損失がある場合でもいくつかの完全なサンプルを確実に配信できます。望ましくない断片化を防止または軽減するために、AMTプロトコルは、カプセル化がパスMTUを超える可能性があるマルチキャストデータグラムを処理するための特定の手順を記述しています。これらの手順については、セクション5.3.3.6で説明します。
This section provides a normative description of the AMT protocol.
このセクションでは、AMTプロトコルの規範的な説明を提供します。
The AMT protocol defines seven message types for control and encapsulation. These messages are assigned the following names and numeric identifiers:
AMTプロトコルは、制御とカプセル化のために7つのメッセージタイプを定義します。これらのメッセージには、次の名前と数値識別子が割り当てられています。
+--------------+---------------------+
| Message Type | Message Name |
+--------------+---------------------+
| 1 | Relay Discovery |
| 2 | Relay Advertisement |
| 3 | Request |
| 4 | Membership Query |
| 5 | Membership Update |
| 6 | Multicast Data |
| 7 | Teardown |
+--------------+---------------------+
These messages are exchanged as IPv4 or IPv6 UDP datagrams.
これらのメッセージは、IPv4またはIPv6 UDPデータグラムとして交換されます。
A Relay Discovery message is used to solicit a response from a relay in the form of a Relay Advertisement message.
リレー検出メッセージは、リレーアドバタイズメッセージの形式でリレーからの応答を求めるために使用されます。
The UDP/IP datagram containing this message MUST carry a valid, non-zero UDP checksum and carry the following IP address and UDP port values:
このメッセージを含むUDP / IPデータグラムは、有効なゼロ以外のUDPチェックサムを運び、次のIPアドレスとUDPポート値を運ばなければなりません（MUST）。
Source IP Address - The IP address of the gateway interface on which the gateway will listen for a relay response. Note: The value of this field may be changed as a result of network address translation before arriving at the relay.
ソースIPアドレス-ゲートウェイがリレー応答をリッスンするゲートウェイインターフェイスのIPアドレス。注：このフィールドの値は、リレーに到達する前にネットワークアドレス変換の結果として変更される可能性があります。
Source UDP Port - The UDP port number on which the gateway will listen for a relay response. Note: The value of this field may be changed as a result of network address translation before arriving at the relay.
ソースUDPポート-ゲートウェイがリレー応答をリッスンするUDPポート番号。注：このフィールドの値は、リレーに到達する前にネットワークアドレス変換の結果として変更される可能性があります。
Destination IP Address - An anycast or unicast IP address, i.e., the Relay Discovery Address advertised by a relay.
宛先IPアドレス-エニーキャストまたはユニキャストIPアドレス、つまり、リレーによってアドバタイズされるリレー検出アドレス。
Destination UDP Port - The AMT port number (see Section 7.2).
宛先UDPポート-AMTポート番号（セクション7.2を参照）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Relay Discovery Message Format
図11：リレー検出メッセージの形式
The protocol version number for this message is 0.
このメッセージのプロトコルバージョン番号は0です。
The type number for this message is 1.
このメッセージのタイプ番号は1です。
Reserved bits that MUST be set to zero by the gateway and ignored by the relay.
ゲートウェイによってゼロに設定され、リレーによって無視される予約済みビット。
A 32-bit random value generated by the gateway and echoed by the relay in a Relay Advertisement message. This value is used by the gateway to correlate Relay Advertisement messages with Relay Discovery messages. Discovery nonce generation is described in Section 5.2.3.4.5.
ゲートウェイによって生成され、リレーアドバタイズメッセージでリレーによってエコーされる32ビットのランダムな値。この値は、ゲートウェイがリレーアドバタイズメッセージとリレーディスカバリメッセージを関連付けるために使用されます。検出ノンスの生成については、セクション5.2.3.4.5で説明しています。
The Relay Advertisement message is used to supply a gateway with a unicast IP address of a relay. A relay sends this message to a gateway when it receives a Relay Discovery message from that gateway.
リレーアドバタイズメッセージは、リレーのユニキャストIPアドレスをゲートウェイに提供するために使用されます。リレーは、ゲートウェイからリレー検出メッセージを受信すると、このメッセージをゲートウェイに送信します。
The UDP/IP datagram containing this message MUST carry a valid, non-zero UDP checksum and carry the following IP address and UDP port values:
このメッセージを含むUDP / IPデータグラムは、有効なゼロ以外のUDPチェックサムを運び、次のIPアドレスとUDPポート値を運ばなければなりません（MUST）。
Source IP Address - The destination IP address carried by the Relay Discovery message (i.e., the Relay Discovery Address advertised by the relay).
送信元IPアドレス-リレー検出メッセージによって伝えられる宛先IPアドレス（つまり、リレーによってアドバタイズされるリレー検出アドレス）。
Source UDP Port - The destination UDP port carried by the Relay Discovery message (i.e., the AMT port number).
ソースUDPポート-リレー検出メッセージによって運ばれる宛先UDPポート（つまり、AMTポート番号）。
Destination IP Address - The source IP address carried by the Relay Discovery message. Note: The value of this field may be changed as a result of network address translation before arriving at the gateway.
宛先IPアドレス-リレー検出メッセージによって運ばれる送信元IPアドレス。注：このフィールドの値は、ゲートウェイに到着する前にネットワークアドレス変換の結果として変更される可能性があります。
Destination UDP Port - The source UDP port carried by the Relay Discovery message. Note: The value of this field may be changed as a result of network address translation before arriving at the gateway.
宛先UDPポート-リレー検出メッセージによって運ばれるソースUDPポート。注：このフィールドの値は、ゲートウェイに到着する前にネットワークアドレス変換の結果として変更される可能性があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=2 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Relay Address (IPv4 or IPv6) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Relay Advertisement Message Format
図12：リレーアドバタイズメントメッセージの形式
The protocol version number for this message is 0.
このメッセージのプロトコルバージョン番号は0です。
The type number for this message is 2.
このメッセージのタイプ番号は2です。
Reserved bits that MUST be set to zero by the relay and ignored by the gateway.
リレーによってゼロに設定され、ゲートウェイによって無視される予約済みビット。
A 32-bit value copied from the Discovery Nonce field (Section 5.1.1.4) contained in the Relay Discovery message. The gateway uses this value to match a Relay Advertisement to a Relay Discovery message.
リレー検出メッセージに含まれるDiscovery Nonceフィールド（5.1.1.4節）からコピーされた32ビット値。ゲートウェイはこの値を使用して、リレーアドバタイズメントをリレーディスカバリメッセージと照合します。
The unicast IPv4 or IPv6 address of the relay. A gateway uses the length of the UDP datagram containing the Relay Advertisement message to determine the address family, i.e., length - 8 = 4 (IPv4) or 16 (IPv6). The relay returns an IP address for the protocol used to send the Relay Discovery message, i.e., an IPv4 address for an IPv4 Relay Discovery Address or an IPv6 address for an IPv6 Relay Discovery Address.
リレーのユニキャストIPv4またはIPv6アドレス。ゲートウェイは、リレーアドバタイズメッセージを含むUDPデータグラムの長さを使用して、アドレスファミリを決定します。つまり、長さ-8 = 4（IPv4）または16（IPv6）です。リレーは、リレー検出メッセージの送信に使用されたプロトコルのIPアドレス、つまりIPv4リレー検出アドレスのIPv4アドレスまたはIPv6リレー検出アドレスのIPv6アドレスを返します。
A gateway sends a Request message to a relay to solicit a Membership Query response.
ゲートウェイは、メンバーシップクエリ応答を要求するために、リレーに要求メッセージを送信します。
The successful delivery of this message marks the start of the first stage in the three-way handshake used to create or update state within a relay.
このメッセージの配信が成功すると、リレー内で状態を作成または更新するために使用される3ウェイハンドシェイクの最初のステージが開始されます。
The UDP/IP datagram containing this message MUST carry a valid, non-zero UDP checksum and carry the following IP address and UDP port values:
このメッセージを含むUDP / IPデータグラムは、有効なゼロ以外のUDPチェックサムを運び、次のIPアドレスとUDPポート値を運ばなければなりません（MUST）。
Source IP Address - The IP address of the gateway interface on which the gateway will listen for a response from the relay. Note: The value of this field may be changed as a result of network address translation before arriving at the relay.
ソースIPアドレス-ゲートウェイがリレーからの応答を待機するゲートウェイインターフェイスのIPアドレス。注：このフィールドの値は、リレーに到達する前にネットワークアドレス変換の結果として変更される可能性があります。
Source UDP Port - The UDP port number on which the gateway will listen for a response from the relay. Note: The value of this field may be changed as a result of network address translation before arriving at the relay.
ソースUDPポート-ゲートウェイがリレーからの応答をリッスンするUDPポート番号。注：このフィールドの値は、リレーに到達する前にネットワークアドレス変換の結果として変更される可能性があります。
Destination IP Address - The unicast IP address of the relay.
宛先IPアドレス-リレーのユニキャストIPアドレス。
Destination UDP Port - The AMT port number.
宛先UDPポート-AMTポート番号。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=3 | Reserved |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Request Message Format
図13：要求メッセージの形式
The protocol version number for this message is 0.
このメッセージのプロトコルバージョン番号は0です。
The type number for this message is 3.
このメッセージのタイプ番号は3です。
Reserved bits that MUST be set to zero by the gateway and ignored by the relay.
ゲートウェイによってゼロに設定され、リレーによって無視される予約済みビット。
The P flag is set to indicate which group membership protocol the gateway wishes the relay to use in the Membership Query response:
Pフラグは、ゲートウェイがリレーをMembership Query応答で使用することを希望するグループメンバーシッププロトコルを示すために設定されます。
Value Meaning
値の意味
0 The relay MUST respond with a Membership Query message that contains an IPv4 packet carrying an IGMPv3 General Query message. 1 The relay MUST respond with a Membership Query message that contains an IPv6 packet carrying an MLDv2 General Query message.
0リレーは、IGMPv3 General Queryメッセージを運ぶIPv4パケットを含むMembership Queryメッセージで応答する必要があります。 1リレーは、MLDv2 General Queryメッセージを運ぶIPv6パケットを含むMembership Queryメッセージで応答する必要があります。
A 32-bit random value generated by the gateway and echoed by the relay in a Membership Query message. This value is used by the relay to compute the Response MAC value and is used by the gateway to correlate Membership Query messages with Request messages. Request Nonce generation is described in Section 5.2.3.5.6.
ゲートウェイによって生成され、メンバーシップクエリメッセージでリレーによってエコーされる32ビットのランダムな値。この値は、リレーによって応答MAC値を計算するために使用され、ゲートウェイによってメンバーシップクエリメッセージと要求メッセージを関連付けるために使用されます。 Request Nonceの生成については、セクション5.2.3.5.6で説明しています。
A relay sends a Membership Query message to a gateway to solicit a Membership Update response, but only after receiving a Request message from the gateway.
リレーは、メンバーシップクエリメッセージをゲートウェイに送信して、メンバーシップ更新応答を要求しますが、ゲートウェイから要求メッセージを受信した後でのみです。
The successful delivery of this message to a gateway marks the start of the second stage in the three-way handshake used to create or update tunnel state within a relay.
このメッセージがゲートウェイに正常に配信されると、リレー内のトンネル状態の作成または更新に使用される3ウェイハンドシェイクの2番目のステージの開始がマークされます。
The UDP/IP datagram containing this message MUST carry a valid, non-zero UDP checksum and carry the following IP address and UDP port values:
このメッセージを含むUDP / IPデータグラムは、有効なゼロ以外のUDPチェックサムを運び、次のIPアドレスとUDPポート値を運ばなければなりません（MUST）。
Source IP Address - The destination IP address carried by the Request message (i.e., the unicast IP address of the relay).
送信元IPアドレス-要求メッセージで伝えられる宛先IPアドレス（つまり、リレーのユニキャストIPアドレス）。
Source UDP Port - The destination UDP port carried by the Request message (i.e., the AMT port number).
ソースUDPポート-リクエストメッセージによって運ばれる宛先UDPポート（すなわち、AMTポート番号）。
Destination IP Address - The source IP address carried by the Request message. Note: The value of this field may be changed as a result of network address translation before arriving at the gateway.
送信先IPアドレス-要求メッセージに含まれる送信元IPアドレス。注：このフィールドの値は、ゲートウェイに到着する前にネットワークアドレス変換の結果として変更される可能性があります。
Destination UDP Port - The source UDP port carried by the Request message. Note: The value of this field may be changed as a result of network address translation before arriving at the gateway.
宛先UDPポート-要求メッセージによって伝送される送信元UDPポート。注：このフィールドの値は、ゲートウェイに到着する前にネットワークアドレス変換の結果として変更される可能性があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=4 | Reserved |L|G| Response MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Encapsulated General Query Message |
~ IPv4:IGMPv3(Membership Query) ~
| IPv6:MLDv2(Listener Query) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway Port Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| Gateway IP Address (IPv4 or IPv6) |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Membership Query Message Format
図14：メンバーシップクエリメッセージの形式
The protocol version number for this message is 0.
このメッセージのプロトコルバージョン番号は0です。
The type number for this message is 4.
このメッセージのタイプ番号は4です。
Reserved bits that MUST be set to zero by the relay and ignored by the gateway.
リレーによってゼロに設定され、ゲートウェイによって無視される予約済みビット。
A 1-bit flag set to 1 to indicate that the relay is NOT accepting Membership Update messages from new gateway tunnel endpoints and that it will ignore any that are. A value of 0 has no special significance -- the relay may or may not be accepting Membership Update messages from new gateway tunnel endpoints. A gateway checks this flag before attempting to create new group subscription state on the relay to determine whether it should restart relay discovery. A gateway that has already created group subscriptions on the relay may ignore this flag. Support for this flag is RECOMMENDED.
1に設定された1ビットのフラグは、リレーが新しいゲートウェイトンネルエンドポイントからのメンバーシップ更新メッセージを受け入れておらず、それを無視することを示します。値0には特別な意味はありません。リレーは、新しいゲートウェイトンネルエンドポイントからのメンバーシップ更新メッセージを受け入れる場合と受け入れない場合があります。ゲートウェイは、リレーで新しいグループサブスクリプション状態を作成する前にこのフラグをチェックして、リレー検出を再開する必要があるかどうかを判断します。リレーですでにグループサブスクリプションを作成しているゲートウェイは、このフラグを無視する場合があります。このフラグのサポートは推奨されています。
A 1-bit flag set to 0 to indicate that the message does NOT carry the Gateway Port Number and Gateway IP Address fields, and 1 to indicate that it does. A relay implementation that supports the optional teardown procedure (see Section 5.3.3.5) SHOULD set this flag as well as the Gateway Port Number and Gateway IP Address field values. If a relay sets this flag, it MUST also include the Gateway Port Number and Gateway IP Address fields in the message. A gateway implementation that does not support the optional teardown procedure (see Section 5.2.3.7) MAY ignore this flag and the Gateway Address fields if they are present.
1ビットのフラグは、メッセージがゲートウェイポート番号およびゲートウェイIPアドレスフィールドを持たないことを示すために0に設定され、そうであることを示すために1に設定されます。オプションのティアダウン手順（セクション5.3.3.5を参照）をサポートするリレー実装は、このフラグと、ゲートウェイポート番号およびゲートウェイIPアドレスフィールドの値を設定する必要があります（SHOULD）。リレーがこのフラグを設定する場合は、メッセージにゲートウェイポート番号およびゲートウェイIPアドレスフィールドも含める必要があります。オプションのティアダウン手順（セクション5.2.3.7を参照）をサポートしないゲートウェイ実装は、このフラグとゲートウェイアドレスフィールドが存在する場合、それらを無視してもよい（MAY）。
A 48-bit source authentication value generated by the relay as described in Section 5.3.5. The gateway echoes this value in subsequent Membership Update messages to allow the relay to verify that the sender of a Membership Update message was the intended receiver of a Membership Query sent by the relay.
セクション5.3.5で説明されている、リレーによって生成された48ビットのソース認証値。ゲートウェイは、後続のメンバーシップ更新メッセージでこの値をエコーし、リレーがメンバーシップ更新メッセージの送信者がリレーによって送信されたメンバーシップクエリの意図された受信者であることを確認できるようにします。
A 32-bit value copied from the Request Nonce field (Section 5.1.3.5) carried by a Request message. The relay will have included this value in the Response MAC computation. The gateway echoes this value in subsequent Membership Update messages. The gateway also uses this value to match a Membership Query to a Request message.
リクエストメッセージによって運ばれるリクエストナンスフィールド（セクション5.1.3.5）からコピーされた32ビット値。リレーは、応答MAC計算にこの値を含めます。ゲートウェイは、後続のメンバーシップ更新メッセージでこの値をエコーします。ゲートウェイは、この値を使用して、メンバーシップクエリを要求メッセージと照合します。
An IP-encapsulated IGMP or MLD message generated by the relay. This field will contain one of the following IP datagrams:
リレーによって生成されたIPカプセル化IGMPまたはMLDメッセージ。このフィールドには、次のIPデータグラムのいずれかが含まれます。
IPv4:IGMPv3 Membership Query
IPv4：IGMPv3メンバーシップクエリ
IPv6:MLDv2 Listener Query
IPv6：MLDv2リスナークエリ
The source address carried by the query message should be set as described in Section 5.3.3.3.
クエリメッセージで送信される送信元アドレスは、セクション5.3.3.3の説明に従って設定する必要があります。
The Querier's Query Interval Code (QQIC) field in the General Query is used by a relay to specify the time offset a gateway should use to schedule a new three-way handshake to refresh the group membership state within the relay (current time + Query Interval). The QQIC field is defined in Section 4.1.7 of [RFC3376] and Section 5.1.9 of [RFC3810].
一般クエリのクエリアのクエリ間隔コード（QQIC）フィールドは、リレーが使用して、ゲートウェイがリレー内のグループメンバーシップ状態を更新するための新しい3ウェイハンドシェイクをスケジュールするために使用する時間オフセットを指定します（現在の時間+クエリ間隔） ）。 QQICフィールドは、[RFC3376]のセクション4.1.7と[RFC3810]のセクション5.1.9で定義されています。
The Querier's Robustness Variable (QRV) field in the General Query is used by a relay to specify the number of times a gateway should retransmit unsolicited membership reports, encapsulated within Membership Update messages, and, optionally, the number of times to send a Teardown message. The QRV field is defined in Section 4.1.6 of [RFC3376] and Section 5.1.8 of [RFC3810].
一般クエリのクエリアのロバストネス変数（QRV）フィールドはリレーによって使用され、ゲートウェイがメンバーシップ更新メッセージ内にカプセル化された非送信請求メンバーシップレポートを再送信する回数、およびオプションでティアダウンメッセージを送信する回数を指定します。 QRVフィールドは、[RFC3376]のセクション4.1.6と[RFC3810]のセクション5.1.8で定義されています。
The Gateway Port Number and Gateway Address fields are present in the Membership Query message if, and only if, the G flag is set.
ゲートウェイポート番号とゲートウェイアドレスのフィールドは、Gフラグが設定されている場合にのみ、メンバーシップクエリメッセージに表示されます。
A gateway need not parse the encapsulated IP datagram to determine the position of these fields within the UDP datagram containing the Membership Query message -- if the G flag is set, the gateway may simply subtract the total length of the fields (18 bytes) from the total length of the UDP datagram to obtain the offset.
ゲートウェイは、カプセル化されたIPデータグラムを解析して、Membership Queryメッセージを含むUDPデータグラム内のこれらのフィールドの位置を決定する必要はありません。Gフラグが設定されている場合、ゲートウェイは、フィールドの合計長（18バイト）を単純に差し引くことができます。オフセットを取得するためのUDPデータグラムの全長。
A 16-bit UDP port number containing a UDP port value.
UDPポート値を含む16ビットのUDPポート番号。
The relay sets this field to the value of the UDP source port of the Request message that triggered the Query message.
リレーは、このフィールドを、クエリメッセージをトリガーしたリクエストメッセージのUDPソースポートの値に設定します。
A 16-byte IP address that, when combined with the value contained in the Gateway Port Number field, forms the gateway endpoint address that the relay will use to identify the tunnel instance, if any, created by a subsequent Membership Update message. This field may contain an IPv6 address or an IPv4 address stored as an IPv4-compatible IPv6 address, where the IPv4 address is prefixed with 96 bits set to zero (see [RFC4291]). This address must match that used by the relay to compute the value stored in the Response MAC field.
16バイトのIPアドレス。ゲートウェイポート番号フィールドに含まれる値と組み合わせると、後続のMembership Updateメッセージによって作成されたトンネルインスタンス（存在する場合）を識別するためにリレーが使用するゲートウェイエンドポイントアドレスを形成します。このフィールドにはIPv6アドレスまたはIPv4互換IPv6アドレスとして保存されたIPv4アドレスが含まれる場合があり、IPv4アドレスの先頭には96ビットがゼロに設定されています（[RFC4291]を参照）。このアドレスは、Response MACフィールドに格納されている値を計算するためにリレーが使用するアドレスと一致する必要があります。
A gateway sends a Membership Update message to a relay to report a change in group membership state, or to report the current group membership state in response to receiving a Membership Query message. The gateway encapsulates the IGMP or MLD message as an IP datagram within a Membership Update message and sends it to the relay, where it may (see below) be decapsulated and processed by the relay to update group membership and forwarding state.
ゲートウェイは、Membership Updateメッセージをリレーに送信して、グループメンバーシップの状態の変化を報告するか、Membership Queryメッセージの受信に応じて現在のグループメンバーシップの状態を報告します。ゲートウェイは、IGMPまたはMLDメッセージをMembership Updateメッセージ内のIPデータグラムとしてカプセル化し、それをリレーに送信します。ここで、カプセル化を解除してリレーで処理し、グループメンバーシップと転送状態を更新します。
A gateway cannot send a Membership Update message until it receives a Membership Query from a relay, because the gateway must copy the Request Nonce and Response MAC values carried by a Membership Query into any subsequent Membership Update messages it sends back to that relay. These values are used by the relay to verify that the sender of the Membership Update message was the recipient of the Membership Query message from which these values were copied.
ゲートウェイは、リレーからメンバーシップクエリを受信するまで、メンバーシップ更新メッセージを送信できません。これは、ゲートウェイが、メンバーシップクエリによって運ばれるリクエストナンスおよびレスポンスMAC値を、そのリレーに送信する後続のメンバーシップ更新メッセージにコピーする必要があるためです。リレーはこれらの値を使用して、Membership Updateメッセージの送信者が、これらの値のコピー元であるMembership Queryメッセージの受信者であることを確認します。
The successful delivery of this message to the relay marks the start of the final stage in the three-way handshake. This stage concludes when the relay successfully verifies that the sender of the Membership Update message was the recipient of a Membership Query message sent earlier. At this point, the relay may proceed to process the encapsulated IGMP or MLD message to create or update group membership and forwarding state on behalf of the gateway.
このメッセージのリレーへの配信が成功すると、3ウェイハンドシェイクの最終段階が始まります。この段階は、リレーがMembership Updateメッセージの送信者が以前に送信されたMembership Queryメッセージの受信者であることを正常に確認したときに終了します。この時点で、リレーはカプセル化されたIGMPまたはMLDメッセージの処理に進み、ゲートウェイに代わってグループメンバーシップと転送状態を作成または更新します。
The UDP/IP datagram containing this message MUST carry a valid, non-zero UDP checksum and carry the following IP address and UDP port values:
このメッセージを含むUDP / IPデータグラムは、有効なゼロ以外のUDPチェックサムを運び、次のIPアドレスとUDPポート値を運ばなければなりません（MUST）。
Source IP Address - The IP address of the gateway interface on which the gateway will listen for Multicast Data messages from the relay. The address must be the same address used to send the initial Request message, or the message will be ignored. Note: The value of this field may be changed as a result of network address translation before arriving at the relay.
送信元IPアドレス-ゲートウェイがリレーからのマルチキャストデータメッセージをリッスンするゲートウェイインターフェイスのIPアドレス。このアドレスは、最初のリクエストメッセージの送信に使用したアドレスと同じでなければなりません。そうでない場合、メッセージは無視されます。注：このフィールドの値は、リレーに到達する前にネットワークアドレス変換の結果として変更される可能性があります。
Source UDP Port - The UDP port number on which the gateway will listen for Multicast Data messages from the relay. This port must be the same port used to send the initial Request message, or the message will be ignored. Note: The value of this field may be changed as a result of network address translation before arriving at the relay.
ソースUDPポート-ゲートウェイがリレーからのマルチキャストデータメッセージをリッスンするUDPポート番号。このポートは、最初のリクエストメッセージの送信に使用したポートと同じでなければなりません。そうでない場合、メッセージは無視されます。注：このフィールドの値は、リレーに到達する前にネットワークアドレス変換の結果として変更される可能性があります。
Destination IP Address - The unicast IP address of the relay.
宛先IPアドレス-リレーのユニキャストIPアドレス。
Destination UDP Port - The AMT port number.
宛先UDPポート-AMTポート番号。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=5 | Reserved | Response MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Encapsulated Group Membership Update Message |
~ IPv4:IGMP(Membership Report|Leave Group) ~
| IPv6:MLD(Listener Report|Listener Done) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Membership Update Message Format
図15：メンバーシップ更新メッセージの形式
The protocol version number for this message is 0.
このメッセージのプロトコルバージョン番号は0です。
The type number for this message is 5.
このメッセージのタイプ番号は5です。
Reserved bits that MUST be set to zero by the gateway and ignored by the relay.
ゲートウェイによってゼロに設定され、リレーによって無視される予約済みビット。
A 48-bit value copied from the Response MAC field (Section 5.1.4.6) in a Membership Query message. Used by the relay to perform source authentication.
Membership QueryメッセージのResponse MACフィールド（セクション5.1.4.6）からコピーされた48ビット値。リレーがソース認証を実行するために使用します。
A 32-bit value copied from the Request Nonce field in a Request or Membership Query message. Used by the relay to perform source authentication.
リクエストまたはメンバーシップクエリメッセージのリクエストナンスフィールドからコピーされた32ビット値。リレーがソース認証を実行するために使用します。
An IP-encapsulated IGMP or MLD message produced by the host-mode IGMP or MLD protocol running on a gateway pseudo-interface. This field will contain one of the following IP datagrams:
ゲートウェイの疑似インターフェースで実行されているホストモードのIGMPまたはMLDプロトコルによって生成されるIPカプセル化されたIGMPまたはMLDメッセージ。このフィールドには、次のIPデータグラムのいずれかが含まれます。
IPv4:IGMPv2 Membership Report
IPv4：IGMPv2メンバーシップレポート
IPv4:IGMPv2 Leave Group
IPv4：IGMPv2脱退グループ
IPv4:IGMPv3 Membership Report
IPv4：IGMPv3メンバーシップレポート
IPv6:MLDv1 Multicast Listener Report
IPv6：MLDv1マルチキャストリスナーレポート
IPv6:MLDv1 Multicast Listener Done
IPv6：MLDv1マルチキャストリスナー完了
IPv6:MLDv2 Multicast Listener Report
IPv6：MLDv2マルチキャストリスナーレポート
The source address carried by the message should be set as described in Section 5.2.1.
メッセージに含まれる送信元アドレスは、セクション5.2.1の説明に従って設定する必要があります。
A relay sends a Multicast Data message to deliver a multicast IP datagram or datagram fragment to a gateway.
リレーはマルチキャストデータメッセージを送信して、マルチキャストIPデータグラムまたはデータグラムフラグメントをゲートウェイに配信します。
The Checksum field in the UDP header of this message MAY contain a value of zero when sent over IPv4 but SHOULD, if possible, contain a valid, non-zero value when sent over IPv6 (see Section 4.2.2.3).
このメッセージのUDPヘッダーのチェックサムフィールドには、IPv4経由で送信された場合はゼロの値が含まれる場合がありますが、可能であれば、IPv6経由で送信された場合はゼロ以外の有効な値を含める必要があります（セクション4.2.2.3を参照）。
The UDP/IP datagram containing this message MUST carry the following IP address and UDP port values:
このメッセージを含むUDP / IPデータグラムは、次のIPアドレスとUDPポートの値を伝達する必要があります。
Source IP Address - The unicast IP address of the relay.
送信元IPアドレス-リレーのユニキャストIPアドレス。
Source UDP Port - The AMT port number.
ソースUDPポート-AMTポート番号。
Destination IP Address - A tunnel endpoint IP address, i.e., the source IP address carried by the Membership Update message sent by a gateway to indicate an interest in receiving the multicast packet. Note: The value of this field may be changed as a result of network address translation before arriving at the gateway.
宛先IPアドレス-トンネルエンドポイントIPアドレス、つまり、マルチキャストパケットの受信に関心があることを示すためにゲートウェイによって送信されたMembership Updateメッセージによって伝送されるソースIPアドレス。注：このフィールドの値は、ゲートウェイに到着する前にネットワークアドレス変換の結果として変更される可能性があります。
Destination UDP Port - A tunnel endpoint UDP port, i.e., the source UDP port carried by the Membership Update message sent by a gateway to indicate an interest in receiving the multicast packet. Note: The value of this field may be changed as a result of network address translation before arriving at the gateway.
宛先UDPポート-トンネルエンドポイントUDPポート、つまり、マルチキャストパケットの受信に関心があることを示すためにゲートウェイによって送信されたMembership Updateメッセージによって伝送されるソースUDPポート。注：このフィールドの値は、ゲートウェイに到着する前にネットワークアドレス変換の結果として変更される可能性があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=6 | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ IP Multicast Packet ~
| |
+ - - - - - - - - - - - - - - - - - - - - - - - -+
| : : : :
+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - - - - - - - - - -
Figure 16: Multicast Data Message Format
図16：マルチキャストデータメッセージの形式
The protocol version number for this message is 0.
このメッセージのプロトコルバージョン番号は0です。
The type number for this message is 6.
このメッセージのタイプ番号は6です。
Reserved bits that MUST be set to zero by the relay and ignored by the gateway.
リレーによってゼロに設定され、ゲートウェイによって無視される予約済みビット。
A complete IPv4 or IPv6 multicast datagram or datagram fragment.
完全なIPv4またはIPv6マルチキャストデータグラムまたはデータグラムフラグメント。
A gateway sends a Teardown message to a relay to request that it stop sending Multicast Data messages to a tunnel endpoint created by an earlier Membership Update message. A gateway sends this message when it detects that a Request message sent to the relay carries an address that differs from that carried by a previous Request message. The gateway uses the Gateway IP Address and Gateway Port Number fields in the Membership Query message to detect these address changes.
ゲートウェイはTeardownメッセージをリレーに送信し、以前のMembership Updateメッセージによって作成されたトンネルエンドポイントへのマルチキャストデータメッセージの送信を停止するように要求します。ゲートウェイは、リレーに送信された要求メッセージが、前の要求メッセージで送信されたアドレスとは異なるアドレスを送信していることを検出すると、このメッセージを送信します。ゲートウェイは、Membership QueryメッセージのGateway IP AddressおよびGateway Port Numberフィールドを使用して、これらのアドレスの変更を検出します。
To provide backwards compatibility with early implementations of the AMT protocol, support for this message and associated procedures is considered OPTIONAL -- gateways are not required to send this message, and relays are not required to act upon it.
AMTプロトコルの初期の実装との下位互換性を提供するために、このメッセージと関連する手順のサポートはオプションと見なされます-ゲートウェイはこのメッセージを送信する必要がなく、リレーはそれに応答する必要はありません。
The UDP/IP datagram containing this message MUST carry a valid, non-zero UDP checksum and carry the following IP address and UDP port values:
このメッセージを含むUDP / IPデータグラムは、有効なゼロ以外のUDPチェックサムを運び、次のIPアドレスとUDPポート値を運ばなければなりません（MUST）。
Source IP Address - The IP address of the gateway interface used to send the message. This address may differ from that used to send earlier messages. Note: The value of this field may be changed as a result of network address translation before arriving at the relay.
送信元IPアドレス-メッセージの送信に使用されるゲートウェイインターフェイスのIPアドレス。このアドレスは、以前のメッセージの送信に使用されたアドレスとは異なる場合があります。注：このフィールドの値は、リレーに到達する前にネットワークアドレス変換の結果として変更される可能性があります。
Source UDP Port - The UDP port number. This port number may differ from that used to send earlier messages. Note: The value of this field may be changed as a result of network address translation before arriving at the relay.
ソースUDPポート-UDPポート番号。このポート番号は、以前のメッセージの送信に使用されたものとは異なる場合があります。注：このフィールドの値は、リレーに到達する前にネットワークアドレス変換の結果として変更される可能性があります。
Destination IP Address - The unicast IP address of the relay.
宛先IPアドレス-リレーのユニキャストIPアドレス。
Destination UDP Port - The AMT port number.
宛先UDPポート-AMTポート番号。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=7 | Reserved | Response MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway Port Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| Gateway IP Address (IPv4 or IPv6) |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Membership Teardown Message Format
図17：メンバーシップのティアダウンメッセージの形式
The protocol version number for this message is 0.
このメッセージのプロトコルバージョン番号は0です。
The type number for this message is 7.
このメッセージのタイプ番号は7です。
Reserved bits that MUST be set to zero by the gateway and ignored by the relay.
ゲートウェイによってゼロに設定され、リレーによって無視される予約済みビット。
A 48-bit value copied from the Response MAC field (Section 5.1.4.6) in the last Membership Query message the relay sent to the gateway endpoint address of the tunnel to be torn down. The gateway endpoint address is provided by the Gateway IP Address and Gateway Port Number fields carried by the Membership Query message. The relay validates the Teardown message by comparing this value with one computed from the Gateway IP Address field, Gateway Port Number field, Request Nonce field, and a private secret (just as it does in the Membership Update message).
リレーが破棄するトンネルのゲートウェイエンドポイントアドレスに送信した最後のMembership QueryメッセージのResponse MACフィールド（セクション5.1.4.6）からコピーされた48ビット値。ゲートウェイエンドポイントアドレスは、Membership Queryメッセージによって運ばれるGateway IP AddressおよびGateway Port Numberフィールドによって提供されます。リレーは、この値をゲートウェイIPアドレスフィールド、ゲートウェイポート番号フィールド、リクエストナンスフィールド、およびプライベートシークレット（メンバーシップ更新メッセージの場合と同様）から計算された値と比較することにより、ティアダウンメッセージを検証します。
A 32-bit value copied from the Request Nonce field (Section 5.1.4.7) in the last Membership Query message the relay sent to the gateway endpoint address of the tunnel to be torn down. The gateway endpoint address is provided by the Gateway IP Address and Gateway Port Number fields carried by the Membership Query message. This value must match that used by the relay to compute the value stored in the Response MAC field.
リレーが破棄するトンネルのゲートウェイエンドポイントアドレスに送信した最後のMembership QueryメッセージのRequest Nonceフィールド（セクション5.1.4.7）からコピーされた32ビット値。ゲートウェイエンドポイントアドレスは、Membership Queryメッセージによって運ばれるGateway IP AddressおよびGateway Port Numberフィールドによって提供されます。この値は、Response MACフィールドに格納されている値を計算するためにリレーが使用する値と一致する必要があります。
A 16-bit UDP port number that, when combined with the value contained in the Gateway IP Address field, forms the tunnel endpoint address that the relay will use to identify the tunnel instance to tear down. The relay provides this value to the gateway using the Gateway Port Number field (Section 5.1.4.9.1) in a Membership Query message. This port number must match that used by the relay to compute the value stored in the Response MAC field.
16ビットのUDPポート番号。ゲートウェイIPアドレスフィールドに含まれている値と組み合わせたときに、リレーがトンネルインスタンスを特定するために使用するトンネルエンドポイントアドレスを形成します。リレーは、Membership QueryメッセージのGateway Port Numberフィールド（セクション5.1.4.9.1）を使用して、この値をゲートウェイに提供します。このポート番号は、Response MACフィールドに格納されている値を計算するためにリレーが使用するポート番号と一致する必要があります。
A 16-byte IP address that, when combined with the value contained in the Gateway Port Number field, forms the tunnel endpoint address that the relay will use to identify the tunnel instance to tear down. The relay provides this value to the gateway using the Gateway IP Address field (Section 5.1.4.9.2) in a Membership Query message. This field may contain an IPv6 address or an IPv4 address stored as an IPv4-compatible IPv6 address, where the IPv4 address is prefixed with 96 bits set to zero (see [RFC4291]). This address must match that used by the relay to compute the value stored in the Response MAC field.
16バイトのIPアドレス。ゲートウェイポート番号フィールドに含まれる値と組み合わせると、リレーがトンネルインスタンスを識別して破棄するために使用するトンネルエンドポイントアドレスを形成します。リレーは、メンバーシップクエリメッセージの[ゲートウェイIPアドレス]フィールド（セクション5.1.4.9.2）を使用して、この値をゲートウェイに提供します。このフィールドにはIPv6アドレスまたはIPv4互換IPv6アドレスとして保存されたIPv4アドレスが含まれる場合があり、IPv4アドレスの先頭には96ビットがゼロに設定されています（[RFC4291]を参照）。このアドレスは、Response MACフィールドに格納されている値を計算するためにリレーが使用するアドレスと一致する必要があります。
The following sections describe gateway implementation requirements. A non-normative discussion of gateway operation may be found in Section 4.2.
次のセクションでは、ゲートウェイの実装要件について説明します。ゲートウェイ操作の非規範的な議論はセクション4.2にあります。
Gateway operation requires a subset of host-mode IPv4/IGMP and IPv6/ MLD functionality to provide group membership tracking, query processing, and report generation. A gateway MAY use IGMPv2 (ASM), IGMPv3 (ASM and SSM), MLDv1 (ASM), or MLDv2 (ASM and SSM).
ゲートウェイ操作では、グループメンバーシップの追跡、クエリ処理、およびレポート生成を提供するために、ホストモードのIPv4 / IGMPおよびIPv6 / MLD機能のサブセットが必要です。ゲートウェイは、IGMPv2（ASM）、IGMPv3（ASMおよびSSM）、MLDv1（ASM）、またはMLDv2（ASMおよびSSM）を使用する場合があります。
An application with embedded gateway functionality must provide its own implementation of this subset of the IPv4/IGMP and IPv6/MLD protocols. The service interface used to manipulate group membership state need not match that described in the IGMP and MLD specifications, but the actions taken as a result SHOULD be similar to those described in Section 5.1 of [RFC3376] and Section 6.1 of [RFC3810]. The gateway application will likely need to implement many of the same functions as a host IP stack, including checksum verification, dispatching, datagram filtering and forwarding, and IP encapsulation/decapsulation.
組み込みゲートウェイ機能を備えたアプリケーションは、IPv4 / IGMPおよびIPv6 / MLDプロトコルのこのサブセットの独自の実装を提供する必要があります。グループメンバーシップの状態を操作するために使用されるサービスインターフェイスは、IGMPおよびMLD仕様で説明されているものと一致する必要はありませんが、結果として行われるアクションは、[RFC3376]のセクション5.1および[RFC3810]のセクション6.1で説明されているものと同様である必要があります。ゲートウェイアプリケーションは、チェックサム検証、ディスパッチ、データグラムのフィルタリングと転送、IPカプセル化/カプセル化解除など、ホストIPスタックと同じ機能の多くを実装する必要があります。
The encapsulated IGMP datagrams generated by a gateway MUST conform to the descriptions found in Section 4 of [RFC3376]. These datagrams MUST possess the IP headers, header options, and header values called for in [RFC3376], with the following exception: a gateway MAY use any source address value in an IGMP report datagram, including the "unspecified" address (all octets are zero). This exception is made because a gateway pseudo-interface might not possess a valid IPv4 address, and even if an address has been assigned to the interface, that address might not be a valid link-local source address on any relay interface. It is for this reason that a relay must accept encapsulated IGMP reports regardless of the source address they carry. See Section 5.3.1.
ゲートウェイによって生成されたカプセル化されたIGMPデータグラムは、[RFC3376]のセクション4にある説明に準拠する必要があります。これらのデータグラムは、[RFC3376]で要求されたIPヘッダー、ヘッダーオプション、およびヘッダー値を保持する必要があります。ただし、次の例外があります。ゼロ）。この例外が発生するのは、ゲートウェイの疑似インターフェースが有効なIPv4アドレスを所有していない可能性があり、アドレスがインターフェースに割り当てられている場合でも、そのアドレスはどのリレーインターフェースでも有効なリンクローカルソースアドレスではない可能性があるためです。このため、リレーは、送信元アドレスに関係なく、カプセル化されたIGMPレポートを受け入れる必要があります。セクション5.3.1を参照してください。
The encapsulated MLD messages generated by a gateway MUST conform to the description found in Section 5 of [RFC3810]. These datagrams MUST possess the IP headers, header options, and header values called for in [RFC3810], with the following exception: a gateway MAY use any source address value in an MLD report datagram, including the "unspecified" address (all octets are zero). This exception is made because a gateway pseudo-interface might not possess a valid IPv6 address, and even if an address has been assigned to the interface, that address might not be a valid link-local source address on any relay interface. As with IGMP, it is for this reason that a relay must accept encapsulated MLD reports regardless of the source address they carry. See Section 5.3.1.
ゲートウェイによって生成されたカプセル化されたMLDメッセージは、[RFC3810]のセクション5にある説明に準拠する必要があります。これらのデータグラムは、[RFC3810]で要求されたIPヘッダー、ヘッダーオプション、およびヘッダー値を保持する必要があります。ただし、次の例外があります。ゲートウェイは、「未指定」アドレスを含むMLDレポートデータグラム内の任意の送信元アドレス値を使用できます（すべてのオクテットはゼロ）。この例外が発生するのは、ゲートウェイの疑似インターフェースが有効なIPv6アドレスを所有していない可能性があり、アドレスがインターフェースに割り当てられている場合でも、そのアドレスはどのリレーインターフェースでも有効なリンクローカルソースアドレスではない可能性があるためです。 IGMPと同様に、リレーが運ぶ送信元アドレスに関係なく、リレーがカプセル化されたMLDレポートを受け入れる必要があるのはこのためです。セクション5.3.1を参照してください。
The gateway IGMP/MLD implementation SHOULD retransmit unsolicited membership state-change reports and merge new state-change reports with pending reports as described in Section 5.1 of [RFC3376] and Section 6.1 of [RFC3810]. The number of retransmissions is specified by the relay in the Querier's Robustness Variable (QRV) field in the last General Query forwarded by the pseudo-interface. See Section 4.1.6 of [RFC3376] and Section 5.1.8 of [RFC3810].
[RFC3376]のセクション5.1と[RFC3810]のセクション6.1で説明されているように、ゲートウェイIGMP / MLD実装は、未承諾のメンバーシップ状態変更レポートを再送信し、新しい状態変更レポートを保留中のレポートとマージする必要があります。再送信の数は、疑似インターフェースによって転送された最後の一般クエリのクエリアのロバストネス変数（QRV）フィールドでリレーによって指定されます。 [RFC3376]のセクション4.1.6と[RFC3810]のセクション5.1.8を参照してください。
The gateway IGMP/MLD implementation SHOULD handle General Query messages as described in Section 5.2 of [RFC3376] and Section 6.2 of [RFC3810] but MAY ignore the Max Resp Code (Maximum Response Code) field value and generate a current-state report without any delay.
[RFC3376]のセクション5.2と[RFC3810]のセクション6.2で説明されているように、ゲートウェイIGMP / MLD実装は一般クエリメッセージを処理する必要があります（SHOULD）が、最大応答コード（最大応答コード）フィールド値を無視して、現在の状態のレポートを生成します。ディレイ。
An IPv4 gateway implementation MUST accept IPv4 datagrams that carry the General Query variant of the IGMPv3 Membership Query message, as described in Section 4 of [RFC3376]. The gateway MUST accept the IGMP datagram regardless of the IP source address carried by that datagram.
[RFC3376]のセクション4で説明されているように、IPv4ゲートウェイの実装は、IGMPv3メンバーシップクエリメッセージの一般クエリバリアントを運ぶIPv4データグラムを受け入れる必要があります。ゲートウェイは、そのデータグラムによって運ばれるIP送信元アドレスに関係なく、IGMPデータグラムを受け入れる必要があります。
An IPv6 gateway implementation MUST accept IPv6 datagrams that carry the General Query variant of the MLDv2 Multicast Listener Query message, as described in Section 5 of [RFC3810]. The gateway MUST accept the MLD datagram regardless of the IP source address carried by that datagram.
[RFC3810]のセクション5で説明されているように、IPv6ゲートウェイの実装は、MLDv2マルチキャストリスナークエリメッセージの一般クエリバリアントを運ぶIPv6データグラムを受け入れる必要があります。ゲートウェイは、そのデータグラムによって運ばれるIP送信元アドレスに関係なく、MLDデータグラムを受け入れる必要があります。
A gateway host may possess or create multiple gateway pseudo-interfaces, each with a unique configuration that describes a binding to a specific IP protocol, Relay Address, Relay Discovery Address, or upstream network interface.
ゲートウェイホストは、特定のIPプロトコル、リレーアドレス、リレーディスカバリアドレス、またはアップストリームネットワークインターフェイスへのバインディングを記述する固有の構成を持つ複数のゲートウェイ疑似インターフェースを所有または作成する場合があります。
If a gateway implementation uses AMT relay discovery to obtain a Relay Address, it must first be supplied with a Relay Discovery Address. The Relay Discovery Address may be an anycast or unicast address. A gateway implementation may rely on a static address assignment or some form of dynamic address discovery. This specification does not require that a gateway implementation use any particular method to obtain a Relay Discovery Address -- an implementation may employ any method that returns a suitable Relay Discovery Address.
ゲートウェイの実装でAMTリレー検出を使用してリレーアドレスを取得する場合は、最初にリレー検出アドレスを指定する必要があります。リレー検出アドレスは、エニーキャストまたはユニキャストアドレスの場合があります。ゲートウェイの実装は、静的アドレス割り当てまたは何らかの形式の動的アドレス検出に依存する場合があります。この仕様では、ゲートウェイ実装が特定のメソッドを使用してリレー検出アドレスを取得する必要はありません。実装では、適切なリレー検出アドレスを返すメソッドを使用できます。
Before a gateway implementation can execute the AMT protocol to request and receive multicast traffic, it must be supplied with a unicast Relay Address. A gateway implementation may rely on static address assignment or support some form of dynamic address discovery. This specification does not require the use of any particular method to obtain a Relay Address -- an implementation may employ any method that returns a suitable Relay Address.
ゲートウェイ実装がAMTプロトコルを実行してマルチキャストトラフィックを要求および受信する前に、ユニキャストリレーアドレスを提供する必要があります。ゲートウェイの実装は、静的アドレス割り当てに依存するか、何らかの形の動的アドレス検出をサポートします。この仕様では、リレーアドレスを取得するために特定のメソッドを使用する必要はありません。実装では、適切なリレーアドレスを返すメソッドを使用できます。
A gateway host that possesses multiple network interfaces or addresses may allow for an explicit selection of the interface to use when communicating with a relay. The selection might be made to satisfy connectivity, tunneling, or IP protocol requirements.
複数のネットワークインターフェイスまたはアドレスを所有するゲートウェイホストでは、リレーとの通信時に使用するインターフェイスを明示的に選択できる場合があります。選択は、接続、トンネリング、またはIPプロトコルの要件を満たすように行われる場合があります。
A gateway implementation that supports retransmission MAY require the following information:
再送信をサポートするゲートウェイの実装には、次の情報が必要になる場合があります。
Discovery Timeout Initial time to wait for a response to a Relay Discovery message.
検出タイムアウトリレー検出メッセージへの応答を待つ最初の時間。
Maximum Relay Discovery Retransmission Count Maximum number of Relay Discovery retransmissions to allow before terminating relay discovery and reporting an error.
リレーディスカバリ再送信の最大数リレーディスカバリを終了してエラーを報告する前に許可するリレーディスカバリ再送信の最大数。
Request Timeout Initial time to wait for a response to a Request message.
要求タイムアウト要求メッセージへの応答を待つ最初の時間。
Maximum Request Retransmission Count Maximum number of Request retransmissions to allow before abandoning a relay and restarting relay discovery or reporting an error.
最大要求再送信カウントリレーを放棄してリレー検出を再開するか、エラーを報告する前に許可する要求再送信の最大数。
Maximum Retries Count for "Destination Unreachable" The maximum number of times a gateway should attempt to send the same Request or Membership Update message after receiving an ICMP Destination Unreachable message.
"Destination Unreachable"の最大再試行回数ICMP Destination Unreachableメッセージを受信した後、ゲートウェイが同じリクエストまたはメンバーシップ更新メッセージの送信を試行する最大回数。
In the following descriptions, a gateway pseudo-interface is treated as a passive entity managed by a gateway service. The gateway pseudo-interface provides the state, and the gateway service provides the processing. The term "gateway" is used when describing service behavior with respect to a single pseudo-interface.
以下の説明では、ゲートウェイ疑似インターフェースは、ゲートウェイサービスによって管理されるパッシブエンティティとして扱われます。ゲートウェイ疑似インターフェースは状態を提供し、ゲートウェイサービスは処理を提供します。 「ゲートウェイ」という用語は、単一の疑似インターフェースに関するサービスの動作を説明するときに使用されます。
When a gateway pseudo-interface is started, the gateway service begins listening for AMT messages sent to the UDP endpoint(s) associated with the pseudo-interface and for any locally generated IGMP/MLD messages passed to the pseudo-interface. The handling of these messages is described below.
ゲートウェイの疑似インターフェースが開始されると、ゲートウェイサービスは、疑似インターフェースに関連付けられたUDPエンドポイントに送信されたAMTメッセージと、疑似インターフェースに渡されたローカルで生成されたIGMP / MLDメッセージをリッスンし始めます。これらのメッセージの処理を以下に説明します。
When the pseudo-interface is enabled, the gateway service MAY:
疑似インターフェースが有効な場合、ゲートウェイサービスは
o Optionally execute the relay discovery procedure described in Section 5.2.3.4.
o オプションで、セクション5.2.3.4で説明されているリレー検出手順を実行します。
o Optionally execute the membership query procedure described in Section 5.2.3.5 to start the periodic membership update cycle.
o 必要に応じて、セクション5.2.3.5で説明されているメンバーシップクエリ手順を実行して、定期的なメンバーシップ更新サイクルを開始します。
A gateway MUST ignore any datagram it receives that cannot be interpreted as a Relay Advertisement, Membership Query, or Multicast Data message. The handling of Relay Advertisement, Membership Query, and Multicast Data messages is addressed in the sections that follow.
ゲートウェイは、リレーアドバタイズメント、メンバーシップクエリ、またはマルチキャストデータメッセージとして解釈できない受信したデータグラムを無視する必要があります。リレーアドバタイズメント、メンバーシップクエリ、およびマルチキャストデータメッセージの処理については、次のセクションで説明します。
A gateway that conforms to this specification MUST ignore any message with a Version field value other than zero.
この仕様に準拠するゲートウェイは、ゼロ以外のバージョンフィールド値を持つメッセージを無視する必要があります。
While listening for AMT messages, a gateway may be notified that an ICMP Destination Unreachable message was received as a result of an AMT message transmission. Handling of ICMP Destination Unreachable messages is described in Section 5.2.3.9.
AMTメッセージをリッスンしているときに、AMTメッセージ送信の結果としてICMP宛先到達不能メッセージが受信されたことがゲートウェイに通知される場合があります。 ICMP宛先到達不能メッセージの処理については、セクション5.2.3.9で説明しています。
A gateway may receive Multicast Data messages after it sends a Membership Update message to a relay that adds a group subscription. The gateway may continue to receive Multicast Data messages long after the gateway sends a Membership Update message that deletes existing group subscriptions. The gateway MUST be prepared to receive these messages at any time but MAY ignore them or discard their contents if the gateway no longer has any interest in receiving the multicast datagrams contained within them.
ゲートウェイは、グループサブスクリプションを追加するリレーにMembership Updateメッセージを送信した後、マルチキャストデータメッセージを受信する場合があります。ゲートウェイは、既存のグループサブスクリプションを削除するMembership Updateメッセージを送信した後も、マルチキャストデータメッセージを受信し続けることがあります。ゲートウェイはいつでもこれらのメッセージを受信できるように準備する必要がありますが、ゲートウェイがメッセージに含まれるマルチキャストデータグラムの受信に関心を持たなくなった場合は、メッセージを無視するか、その内容を破棄できます。
A gateway MUST ignore a Multicast Data message if it fails to satisfy any of the following requirements:
ゲートウェイは、次のいずれかの要件を満たさない場合、マルチキャストデータメッセージを無視する必要があります。
o The source IP address and UDP port carried by the Multicast Data message MUST be equal to the destination IP address and UDP port carried by the matching Membership Update message (i.e., the current Relay Address).
o マルチキャストデータメッセージによって伝送されるソースIPアドレスとUDPポートは、一致するメンバーシップ更新メッセージによって伝送される宛先IPアドレスとUDPポート（つまり、現在のリレーアドレス）と等しくなければなりません（MUST）。
o The destination address carried by the encapsulated IP datagram MUST fall within the multicast address allocation assigned to the relevant IP protocol, i.e., 224.0.0.0/4 for IPv4 and ff00::/8 for IPv6.
o カプセル化されたIPデータグラムによって運ばれる宛先アドレスは、関連するIPプロトコルに割り当てられたマルチキャストアドレス割り当て内に収まる必要があります。つまり、IPv4の場合は224.0.0.0/4、IPv6の場合はff00 :: / 8です。
The gateway extracts the encapsulated IP datagram and forwards it to the local IP protocol implementation for checksum verification, fragmented datagram reassembly, source and group filtering, and transport-layer protocol processing.
ゲートウェイは、カプセル化されたIPデータグラムを抽出し、それをローカルIPプロトコル実装に転送して、チェックサム検証、断片化されたデータグラムの再構成、ソースとグループのフィルタリング、およびトランスポート層プロトコル処理を行います。
Because AMT uses UDP encapsulation to deliver multicast datagrams to gateways, it qualifies as a tunneling protocol subject to the limitations described in [RFC6936]. If supported, a gateway SHOULD employ the solution described in [RFC6936] to ensure that the local IP stack does not discard IPv6 datagrams with zero checksums. If Multicast Data message datagrams are processed directly within the gateway (instead of the host IP stack), the gateway MUST NOT discard any of these datagrams because they carry a UDP checksum of zero.
AMTはUDPカプセル化を使用してマルチキャストデータグラムをゲートウェイに配信するため、[RFC6936]で説明されている制限の対象となるトンネリングプロトコルと見なされます。サポートされている場合、ゲートウェイは[RFC6936]で説明されているソリューションを採用して、ローカルIPスタックがチェックサムがゼロのIPv6データグラムを破棄しないようにする必要があります（SHOULD）。マルチキャストデータメッセージのデータグラムが（ホストIPスタックの代わりに）ゲートウェイ内で直接処理される場合、ゲートウェイはUDPチェックサムがゼロであるため、これらのデータグラムを破棄してはなりません（MUST NOT）。
This section describes gateway requirements related to the relay discovery message sequence described in Section 4.2.1.1.
このセクションでは、セクション4.2.1.1で説明されているリレー検出メッセージシーケンスに関連するゲートウェイ要件について説明します。
A gateway may start or restart the relay discovery procedure in response to the following events:
ゲートウェイは、次のイベントに応答して、リレー検出手順を開始または再開します。
o When a gateway pseudo-interface is started (enabled).
o ゲートウェイ疑似インターフェースが開始された（有効にされた）とき。
o When the gateway wishes to report a group subscription when none currently exist.
o ゲートウェイが現在存在しないグループサブスクリプションを報告する場合。
o Before sending the next Request message in a membership update cycle, i.e., each time the query timer expires (see below).
o Before sending the next Request message in a membership update cycle, i.e., each time the query timer expires (see below).
o After the gateway fails to receive a response to a Request message.
o ゲートウェイが要求メッセージへの応答の受信に失敗した後。
o After the gateway receives a Membership Query message with the L flag set to 1.
o ゲートウェイがLフラグが1に設定されたMembership Queryメッセージを受信した後。
A gateway sends a Relay Discovery message to a relay to start the relay discovery process.
ゲートウェイは、リレー検出メッセージをリレーに送信して、リレー検出プロセスを開始します。
The gateway MUST send the Relay Discovery message using the current Relay Discovery Address and AMT port number as the destination. The Discovery Nonce value in the Relay Discovery message MUST be computed as described in Section 5.2.3.4.5.
ゲートウェイは、現在のリレー検出アドレスとAMTポート番号を宛先として使用して、リレー検出メッセージを送信する必要があります。リレー検出メッセージのDiscovery Nonce値は、セクション5.2.3.4.5の説明に従って計算する必要があります。
The gateway MUST save a copy of the Relay Discovery message or save the Discovery Nonce value for possible retransmission and verification of a Relay Advertisement response.
ゲートウェイは、可能性のある再送信およびリレーアドバタイズメント応答の検証のために、リレーディスカバリメッセージのコピーを保存するか、ディスカバリナンス値を保存する必要があります。
When a gateway sends a Relay Discovery message, it may be notified that an ICMP Destination Unreachable message was received as a result of an earlier AMT message transmission. Handling of ICMP Destination Unreachable messages is described in Section 5.2.3.9.
When a gateway sends a Relay Discovery message, it may be notified that an ICMP Destination Unreachable message was received as a result of an earlier AMT message transmission. Handling of ICMP Destination Unreachable messages is described in Section 5.2.3.9.
A gateway MAY retransmit a Relay Discovery message if it does not receive a matching Relay Advertisement message within some timeout period. If the gateway retransmits the message multiple times, the timeout period SHOULD be adjusted to provide a random exponential back-off. The RECOMMENDED timeout is a random value in the range [initial_timeout, MIN(initial_timeout * 2^retry_count, maximum_timeout)], with a RECOMMENDED initial_timeout of 1 second and a RECOMMENDED maximum_timeout of 120 seconds (which is the recommended minimum NAT mapping timeout described in [RFC4787]).
ゲートウェイは、タイムアウト期間内に一致するリレーアドバタイズメントメッセージを受信しない場合、リレーディスカバリメッセージを再送信してもよい（MAY）。ゲートウェイがメッセージを複数回再送信する場合、ランダムな指数バックオフを提供するようにタイムアウト期間を調整する必要があります（SHOULD）。 RECOMMENDEDタイムアウトは、[initial_timeout、MIN（initial_timeout * 2 ^ retry_count、maximum_timeout）]の範囲のランダムな値で、1秒のRECOMMENDED initial_timeoutと120秒のRECOMMENDED maximum_timeout（これは、 [RFC4787]）。
When a gateway receives a Relay Advertisement message, it must first determine whether it should accept or ignore the message. A gateway MUST ignore a Relay Advertisement message if it fails to satisfy any of the following requirements:
ゲートウェイがリレーアドバタイズメントメッセージを受信すると、最初に、メッセージを受け入れるか無視するかを決定する必要があります。ゲートウェイは、次の要件のいずれかを満たさない場合、リレーアドバタイズメッセージを無視する必要があります。
o The gateway MUST be waiting for a Relay Advertisement message.
o ゲートウェイは、リレーアドバタイズメントメッセージを待機している必要があります。
o The Discovery Nonce value contained in the Relay Advertisement message MUST be equal to the Discovery Nonce value contained in the Relay Discovery message.
o リレーアドバタイズメントメッセージに含まれるDiscovery Nonce値は、リレーディスカバリメッセージに含まれるDiscovery Nonce値と等しくなければなりません。
o The source IP address and UDP port of the Relay Advertisement message MUST be equal to the destination IP address and UDP port of the matching Relay Discovery message.
o リレーアドバタイズメッセージのソースIPアドレスとUDPポートは、一致するリレーディスカバリメッセージの宛先IPアドレスとUDPポートと同じでなければなりません。
Once a gateway receives a Relay Advertisement response to a Relay Discovery message, it SHOULD ignore any other Relay Advertisements that arrive on the AMT interface until it sends a new Relay Discovery message.
ゲートウェイがリレー検出メッセージへのリレーアドバタイズメント応答を受信すると、新しいリレー検出メッセージを送信するまで、AMTインターフェースに到着する他のリレーアドバタイズメントを無視する必要があります（SHOULD）。
If a gateway executes the relay discovery procedure at the start of each membership update cycle and the Relay Address returned in the latest Relay Advertisement message differs from the address returned in a previous Relay Advertisement message, then the gateway SHOULD send a Teardown message (if supported) to the old Relay Address, using information from the last Membership Query message received from that relay, as described in Section 5.2.3.7. This behavior is illustrated in the following diagram.
ゲートウェイが各メンバーシップ更新サイクルの開始時にリレー検出手順を実行し、最新のリレーアドバタイズメッセージで返されたリレーアドレスが前のリレーアドバタイズメッセージで返されたアドレスと異なる場合、ゲートウェイはティアダウンメッセージを送信する必要があります（サポートされている場合） ）セクション5.2.3.7で説明されているように、そのリレーから受信した最後のメンバーシップクエリメッセージからの情報を使用して、古いリレーアドレスに。この動作を次の図に示します。
Gateway Relay-1
------- -------
: :
Query Expired | |
Timer (QT)-------->| |
| Relay Discovery |
|------------------->|
| |
| Relay Advertisement|
|<-------------------|
| |
| Request |
|------------------->|
| |
| Membership Query |
|<===================|
Start | |
(QT)<--------| Membership Update |
|===================>|
| |
~ ~ Relay-2
Expired | | -------
(QT)-------->| | :
| Relay Discovery | |
|------------------------------------>|
| | |
| Relay Advertisement| |
|<------------------------------------|
| | |
| Teardown | |
|------------------->| |
| | |
| Request | |
|------------------------------------>|
| | |
| Membership Query | |
|<====================================|
Start | | |
(QT)<--------| Membership Update | |
|====================================>|
| | |
: : :
Figure 18: Teardown after Relay Address Change
Figure 18: Teardown after Relay Address Change
The discovery nonce MUST be a random, non-zero 32-bit value and, if possible, SHOULD be computed using a cryptographically secure pseudorandom number generator. A new nonce SHOULD be generated each time the gateway restarts the relay discovery process. The same nonce SHOULD be used when retransmitting a Relay Discovery message.
発見ノンスはランダムでゼロでない32ビット値でなければならず（MUST）、可能であれば、暗号的に安全な疑似乱数ジェネレータを使用して計算する必要があります。ゲートウェイがリレー検出プロセスを再開するたびに、新しいノンスが生成されるべきです（SHOULD）。リレー検出メッセージを再送信するときにも同じノンスを使用する必要があります。
This section describes gateway requirements related to the membership update message sequence described in Section 4.2.1.2.
このセクションでは、セクション4.2.1.2で説明したメンバーシップ更新メッセージシーケンスに関連するゲートウェイ要件について説明します。
A gateway may send a Request message to start a membership update cycle (following the optional relay discovery procedure) in response to the following events:
ゲートウェイは、次のイベントに応答して、（オプションのリレー検出手順に従って）メンバーシップ更新サイクルを開始するために要求メッセージを送信できます。
o When the gateway pseudo-interface is activated.
o ゲートウェイ疑似インターフェースがアクティブ化されたとき。
o When the gateway wishes to report a group subscription when none currently exist.
o ゲートウェイが現在存在しないグループサブスクリプションを報告する場合。
Starting the membership update cycle when a gateway pseudo-interface is started provides several benefits:
Starting the membership update cycle when a gateway pseudo-interface is started provides several benefits:
o Better performance by allowing state-change reports to be sent as they are generated, thus minimizing the time to join.
o 状態変更レポートが生成されるときに送信できるようにすることでパフォーマンスが向上し、参加する時間を最小限に抑えます。
o More robustness by relying on unsolicited state-change reports to update group membership state rather than the current-state reports generated by the membership update cycle. Unsolicited state-change reports are typically retransmitted multiple times while current-state reports are not.
o メンバーシップの更新サイクルによって生成された現在の状態のレポートではなく、未承諾の状態変更レポートを利用してグループのメンバーシップの状態を更新することにより、より堅牢になります。未承諾の状態変化レポートは通常、複数回再送信されますが、現在の状態レポートはそうではありません。
o Simplified implementation by eliminating any need to queue IGMP/ MLD messages for delivery after a Membership Query is received, since the IGMP/MLD state-change messages may be sent as they are generated.
o IGMP / MLD状態変更メッセージが生成されると送信される可能性があるため、メンバーシップクエリの受信後にIGMP / MLDメッセージをキューに入れて配信する必要がなくなるため、実装が簡素化されます。
However, this approach places an additional load on relays, as a gateway will send periodic requests even when it has no multicast subscriptions. To reduce load on a relay, a gateway SHOULD only send a Membership Update message while it has active group subscriptions. A relay will still need to compute a Response MAC for each Request but will not be required to recompute it a second time to authenticate a Membership Update message that contains no subscriptions.
ただし、この方法では、ゲートウェイがマルチキャストサブスクリプションがない場合でも定期的にリクエストを送信するため、リレーに追加の負荷がかかります。リレーの負荷を減らすために、ゲートウェイは、アクティブなグループサブスクリプションがある間のみ、メンバーシップ更新メッセージを送信する必要があります（SHOULD）。リレーは引き続き各要求の応答MACを計算する必要がありますが、サブスクリプションを含まないメンバーシップ更新メッセージを認証するために再度再計算する必要はありません。
A gateway sends a Request message to a relay to solicit a Membership Query response and start the membership update cycle.
A gateway sends a Request message to a relay to solicit a Membership Query response and start the membership update cycle.
A gateway constructs a Request message containing a Request Nonce value computed as described in Section 5.2.3.5.6. The gateway MUST set the P flag in the Request message to identify the protocol the gateway wishes the relay to use for the General Query response.
ゲートウェイは、セクション5.2.3.5.6で説明されているように計算されたリクエストノンス値を含むリクエストメッセージを作成します。ゲートウェイは、ゲートウェイがリレーが一般クエリ応答に使用することを希望するプロトコルを識別するために、要求メッセージにPフラグを設定する必要があります。
A gateway MUST send a Request message using the current Relay Address and AMT port number as the destination.
ゲートウェイは、現在のリレーアドレスとAMTポート番号を宛先として使用して要求メッセージを送信する必要があります。
A gateway MUST save a copy of the Request message or save the Request Nonce and P flag values for possible retransmission and verification of a Membership Query response.
ゲートウェイは、可能な再送信とメンバーシップクエリ応答の検証のために、要求メッセージのコピーを保存するか、要求ノンスとPフラグの値を保存する必要があります。
When a gateway sends a Request message, it may be notified that an ICMP Destination Unreachable message was received as a result of an earlier AMT message transmission. Handling of ICMP Destination Unreachable messages is described in Section 5.2.3.9.
ゲートウェイが要求メッセージを送信すると、以前のAMTメッセージ送信の結果としてICMP宛先到達不能メッセージが受信されたことが通知される場合があります。 ICMP宛先到達不能メッセージの処理については、セクション5.2.3.9で説明しています。
A gateway MAY retransmit a Request message if it does not receive a matching Membership Query message within some timeout period. If the gateway retransmits the message multiple times, the timeout period SHOULD be adjusted to provide a random exponential back-off. The RECOMMENDED timeout is a random value in the range [initial_timeout, MIN(initial_timeout * 2^retry_count, maximum_timeout)], with a RECOMMENDED initial_timeout of 1 second and a RECOMMENDED maximum_timeout of 120 seconds (which is the recommended minimum NAT mapping timeout described in [RFC4787]).
ゲートウェイは、タイムアウト期間内に一致するメンバーシップクエリメッセージを受信しない場合、リクエストメッセージを再送信できます。ゲートウェイがメッセージを複数回再送信する場合、ランダムな指数バックオフを提供するようにタイムアウト期間を調整する必要があります（SHOULD）。 RECOMMENDEDタイムアウトは、[initial_timeout、MIN（initial_timeout * 2 ^ retry_count、maximum_timeout）]の範囲のランダムな値で、1秒のRECOMMENDED initial_timeoutと120秒のRECOMMENDED maximum_timeout（これは、 [RFC4787]）。
If a gateway that uses relay discovery does not receive a Membership Query within a specified time period or after a specified number of retries, the gateway SHOULD stop waiting for a Membership Query message and restart relay discovery to locate another relay.
リレー検出を使用するゲートウェイが、指定された期間内または指定された再試行回数の後にメンバーシップクエリを受信しない場合、ゲートウェイは、メンバーシップクエリメッセージの待機を停止し、リレー検出を再開して別のリレーを見つける必要があります。
When a gateway receives a Membership Query message, it must first determine whether it should accept or ignore the message. A gateway MUST ignore a Membership Query message, or the encapsulated IP datagram within it, if the message fails to satisfy any of the following requirements:
ゲートウェイは、Membership Queryメッセージを受信すると、まずメッセージを受け入れるか無視するかを決定する必要があります。メッセージが次の要件のいずれかを満たさない場合、ゲートウェイはMembership Queryメッセージ、またはその中にカプセル化されたIPデータグラムを無視する必要があります。
o The gateway MUST be waiting for a Membership Query message.
o ゲートウェイは、メンバーシップクエリメッセージを待機している必要があります。
o The Request Nonce value contained in the Membership Query MUST equal the Request Nonce value contained in the Request message.
o メンバーシップクエリに含まれるリクエストナンス値は、リクエストメッセージに含まれるリクエストナンス値と等しくなければなりません。
o The source IP address and UDP port of the Membership Query MUST equal the destination IP address and UDP port of the matching Request message (i.e., the current Relay Address).
o メンバーシップクエリのソースIPアドレスとUDPポートは、一致するリクエストメッセージの宛先IPアドレスとUDPポート（つまり、現在のリレーアドレス）と等しくなければなりません。
o The encapsulated IP datagram MUST carry an IGMPv3 or MLDv2 message. The protocol MUST match the protocol identified by the P flag in the Request message.
o カプセル化されたIPデータグラムは、IGMPv3またはMLDv2メッセージを運ぶ必要があります。プロトコルは、要求メッセージのPフラグで識別されるプロトコルと一致する必要があります。
o The IGMPv3 or MLDv2 message MUST be a General Query message.
o The IGMPv3 or MLDv2 message MUST be a General Query message.
o The total length of the encapsulated IP datagram as computed from the lengths contained in the datagram header(s) MUST NOT exceed the available field length within the Membership Query message.
o データグラムヘッダーに含まれる長さから計算されたカプセル化されたIPデータグラムの全長は、メンバーシップクエリメッセージ内の利用可能なフィールド長を超えてはなりません。
Once a gateway receives a Membership Query response to a Request message, it SHOULD ignore any other Membership Query messages that arrive on the AMT interface until it sends a new Request message.
ゲートウェイがリクエストメッセージに対するメンバーシップクエリ応答を受信すると、新しいリクエストメッセージを送信するまで、AMTインターフェイスに到着する他のメンバーシップクエリメッセージを無視する必要があります（SHOULD）。
The gateway MUST save the Membership Query message, or the Request Nonce, Response MAC, Gateway IP Address, and Gateway Port Number fields for use in sending subsequent Membership Update and Teardown messages.
ゲートウェイは、Membership Queryメッセージ、または後続のMembership UpdateメッセージとTeardownメッセージの送信に使用するために、Request Nonce、Response MAC、Gateway IPアドレス、およびGateway Port Numberフィールドを保存する必要があります。
The gateway extracts the encapsulated IP datagram and forwards it to the local IP protocol implementation for checksum verification and dispatching to the IGMP or MLD implementation running on the pseudo-interface. The gateway MUST NOT forward any octets that might exist between the encapsulated IP datagram and the end of the message or Gateway Address fields.
ゲートウェイはカプセル化されたIPデータグラムを抽出し、ローカルIPプロトコル実装に転送してチェックサムを検証し、疑似インターフェースで実行されているIGMPまたはMLD実装にディスパッチします。ゲートウェイは、カプセル化されたIPデータグラムとメッセージの終わりまたはゲートウェイアドレスフィールドの間に存在する可能性のあるオクテットを転送してはなりません（MUST NOT）。
The MLD protocol specification indicates that senders should use a link-local source IP address in message datagrams. This requirement must be relaxed for AMT because gateways and relays do not normally share a common subnet. For this reason, a gateway implementation MUST accept MLD (and IGMP) query message datagrams regardless of the source IP address they carry. This may require additional processing on the part of the gateway that might be avoided if the relay and gateway use the IPv4 and IPv6 addresses allocated for use in AMT-encapsulated control packets as described in Section 5.2.1.
MLDプロトコル仕様では、送信者はメッセージデータグラムでリンクローカルソースIPアドレスを使用する必要があることを示しています。ゲートウェイとリレーは通常、共通のサブネットを共有しないため、AMTではこの要件を緩和する必要があります。このため、ゲートウェイ実装は、それらが運ぶソースIPアドレスに関係なく、MLD（およびIGMP）クエリメッセージデータグラムを受け入れる必要があります。セクション5.2.1で説明されているように、リレーとゲートウェイがAMTカプセル化制御パケットで使用するために割り当てられたIPv4アドレスとIPv6アドレスを使用する場合は、ゲートウェイの一部で追加処理が必要になる場合があります。
The gateway MUST start a timer that will trigger the next iteration of the membership update cycle by executing the membership query procedure. The gateway SHOULD compute the timer duration from the Querier's Query Interval Code carried by the General Query. A gateway MAY use a smaller timer duration if required to refresh a NAT mapping that would otherwise time out. A gateway MAY use a larger timer duration if it has no group subscriptions to report.
ゲートウェイは、メンバーシップクエリプロシージャを実行して、メンバーシップ更新サイクルの次の反復をトリガーするタイマーを開始する必要があります。ゲートウェイは、一般クエリによって運ばれるクエリアのクエリ間隔コードからタイマー期間を計算する必要があります（SHOULD）。ゲートウェイは、タイムアウトになるはずのNATマッピングを更新する必要がある場合は、より短いタイマー期間を使用できます。レポートするグループサブスクリプションがない場合、ゲートウェイはより長いタイマー期間を使用できます。
If the gateway supports the Teardown message and the G flag is set in the Membership Query message, the gateway MUST compare the Gateway IP Address and Gateway Port Number on the new Membership Query message with the values carried by the previous Membership Query message. If either value has changed, the gateway MUST send a Teardown message to the relay as described in Section 5.2.3.7.
ゲートウェイがティアダウンメッセージをサポートし、Gフラグがメンバーシップクエリメッセージで設定されている場合、ゲートウェイは、新しいメンバーシップクエリメッセージのゲートウェイIPアドレスとゲートウェイポート番号を、以前のメンバーシップクエリメッセージで伝送された値と比較する必要があります。いずれかの値が変更された場合、ゲートウェイは、セクション5.2.3.7で説明されているように、Teardownメッセージをリレーに送信する必要があります。
If the L flag is set in the Membership Query message, the relay is reporting that it is NOT accepting Membership Update messages that create new tunnel endpoints and will simply ignore any that do. If the L flag is set and the gateway is not currently reporting any group subscriptions to the relay, the gateway SHOULD stop sending periodic Request messages and restart the relay discovery procedure (if discovery is enabled) to find a new relay with which to communicate. Even if the L flag is set, the gateway MAY continue to send updates if it has previously reported group subscriptions to the relay, one or more subscriptions still exist, and the gateway endpoint address has not changed since the last Membership Query was received (see previous paragraph).
メンバーシップクエリメッセージでLフラグが設定されている場合、リレーは、新しいトンネルエンドポイントを作成するメンバーシップ更新メッセージを受け入れていないことを報告しており、それを無視します。 Lフラグが設定されていて、ゲートウェイが現在リレーへのグループサブスクリプションを報告していない場合、ゲートウェイは定期的なリクエストメッセージの送信を停止し、リレーディスカバリ手順を再開して（ディスカバリが有効な場合）、通信する新しいリレーを見つける必要があります。 Lフラグが設定されている場合でも、以前にリレーにグループサブスクリプションを報告し、1つ以上のサブスクリプションがまだ存在し、最後のメンバーシップクエリが受信されてからゲートウェイエンドポイントアドレスが変更されていない場合、ゲートウェイは更新を送信し続けることができます（参照前の段落）。
When the query timer (started in the previous step) expires, the gateway should execute the membership query procedure again to continue the membership update cycle.
クエリタイマー（前のステップで開始）が期限切れになると、ゲートウェイはメンバーシップクエリプロシージャを再度実行して、メンバーシップ更新サイクルを継続する必要があります。
The Request Nonce MUST be a random value and, if possible, SHOULD be computed using a cryptographically secure pseudorandom number generator. A new nonce MUST be generated each time the gateway starts the membership query process. The same nonce SHOULD be used when retransmitting a Request message.
Request Nonceはランダムな値でなければならず（MUST）、可能であれば、暗号的に安全な疑似乱数ジェネレータを使用して計算する必要があります（SHOULD）。ゲートウェイがメンバーシップクエリプロセスを開始するたびに、新しいナンスを生成する必要があります。要求メッセージを再送信する場合も、同じノンスを使用する必要があります（SHOULD）。
This section describes gateway requirements related to the membership update message sequence described in Section 4.2.1.2.
このセクションでは、セクション4.2.1.2で説明したメンバーシップ更新メッセージシーケンスに関連するゲートウェイ要件について説明します。
The membership update process is primarily driven by the host-mode IGMP or MLD protocol implementation running on the gateway pseudo-interface. The IGMP and MLD protocols produce current-state reports in response to General Query messages generated by the pseudo-interface via AMT and produce state-change reports in response to receiver requests made using the IGMP or MLD service interface.
メンバーシップ更新プロセスは、主にゲートウェイの疑似インターフェースで実行されているホストモードのIGMPまたはMLDプロトコルの実装によって駆動されます。 IGMPおよびMLDプロトコルは、AMTを介して疑似インターフェイスによって生成された一般クエリメッセージに応答して現在の状態レポートを生成し、IGMPまたはMLDサービスインターフェイスを使用して行われたレシーバー要求に応答して状態変更レポートを生成します。
The gateway pseudo-interface MUST accept the following IP datagrams from the IPv4/IGMP and IPv6/MLD protocols running on the pseudo-interface:
ゲートウェイの疑似インターフェースは、疑似インターフェースで実行されているIPv4 / IGMPおよびIPv6 / MLDプロトコルから次のIPデータグラムを受け入れる必要があります。
o IPv4 datagrams that carry an IGMPv2 or IGMPv3 Membership Report or an IGMPv2 Leave Group message as described in Section 4 of [RFC3376].
o [RFC3376]のセクション4で説明されているように、IGMPv2またはIGMPv3メンバーシップレポートまたはIGMPv2 Leave Groupメッセージを運ぶIPv4データグラム。
o IPv6 datagrams that carry an MLDv1 or MLDv2 Multicast Listener Report or an MLDv1 Multicast Listener Done message as described in Section 5 of [RFC3810].
o [RFC3810]のセクション5で説明されている、MLDv1またはMLDv2マルチキャストリスナーレポートまたはMLDv1マルチキャストリスナー完了メッセージを運ぶIPv6データグラム。
The gateway must be prepared to receive these messages any time the pseudo-interface is running. The gateway MUST ignore any datagrams not listed above.
ゲートウェイは、疑似インターフェースが実行されているときにいつでもこれらのメッセージを受信できるように準備する必要があります。ゲートウェイは、上記にリストされていないデータグラムを無視する必要があります。
A gateway that waits to start a membership update cycle until after it receives a datagram containing an IGMP/MLD state-change message MAY:
IGMP / MLD状態変更メッセージを含むデータグラムを受信するまでメンバーシップ更新サイクルの開始を待機するゲートウェイは、次のような場合があります。
o Discard IGMP or MLD datagrams until it receives a Membership Query message, at which time it processes the Membership Query message as normal to eventually produce a current-state report on the pseudo-interface, which describes the end state (RECOMMENDED).
o メンバーシップクエリメッセージを受信するまでIGMPまたはMLDデータグラムを破棄します。メンバーシップクエリメッセージを受信すると、通常どおりにメンバーシップクエリメッセージを処理し、最終的に、最終状態を示す疑似インターフェイスに関する現在の状態レポートを生成します（推奨）。
o Insert IGMP or MLD datagrams into a queue for transmission after it receives a Membership Query message.
o メンバーシップクエリメッセージを受信した後、IGMPまたはMLDデータグラムをキューに挿入して送信します。
If and when a gateway receives a Membership Query message (for IGMP or MLD), it sends any queued or incoming IGMP or MLD datagrams to the relay as described in the next section.
ゲートウェイが（IGMPまたはMLDの）メンバーシップクエリメッセージを受信すると、次のセクションで説明するように、キューに入れられた、または着信のIGMPまたはMLDデータグラムをリレーに送信します。
A gateway cannot send a Membership Update message to a relay until it has received a Membership Query message from a relay. If the gateway has not yet located a relay with which to communicate, it MUST first execute the relay discovery procedure described in Section 5.2.3.4 to obtain a Relay Address. If the gateway has a Relay Address but has not yet received a Membership Query message, it MUST first execute the membership query procedure described in Section 5.2.3.5 to obtain a Request Nonce and Response MAC that can be used to send a Membership Update message.
ゲートウェイは、リレーからメンバーシップクエリメッセージを受信するまで、メンバーシップ更新メッセージをリレーに送信できません。ゲートウェイがまだ通信するリレーを見つけていない場合は、まず5.2.3.4で説明されているリレー検出手順を実行して、リレーアドレスを取得する必要があります。ゲートウェイがリレーアドレスを持っているが、まだメンバーシップクエリメッセージを受信していない場合、最初にセクション5.2.3.5で説明されているメンバーシップクエリ手順を実行して、メンバーシップ更新メッセージの送信に使用できるリクエストナンスとレスポンスMACを取得する必要があります。
Once a gateway possesses a valid Relay Address, Request Nonce, and Response MAC, it may encapsulate the IP datagram containing the IGMP/ MLD message into a Membership Update message. The gateway MUST copy the Request Nonce and Response MAC values from the last Membership Query received from the relay into the corresponding fields in the Membership Update. The gateway MUST send the Membership Update message using the Relay Address and AMT port number as the destination.
ゲートウェイが有効なリレーアドレス、リクエストナンス、およびレスポンスMACを取得すると、IGMP / MLDメッセージを含むIPデータグラムをメンバーシップ更新メッセージにカプセル化できます。ゲートウェイは、リレーから受信した最後のメンバーシップクエリのリクエストナンスおよびレスポンスMAC値を、メンバーシップアップデートの対応するフィールドにコピーする必要があります。ゲートウェイは、リレーアドレスとAMTポート番号を宛先として使用して、メンバーシップ更新メッセージを送信する必要があります。
When a gateway sends a Membership Update message, it may be notified that an ICMP Destination Unreachable message was received as a result of an earlier AMT message transmission. Handling of ICMP Destination Unreachable messages is described in Section 5.2.3.9.
ゲートウェイがMembership Updateメッセージを送信すると、以前のAMTメッセージ送信の結果としてICMP Destination Unreachableメッセージが受信されたことが通知される場合があります。 ICMP宛先到達不能メッセージの処理については、セクション5.2.3.9で説明しています。
This section describes gateway requirements related to the teardown message sequence described in Section 4.2.1.3.
このセクションでは、セクション4.2.1.3で説明されているティアダウンメッセージシーケンスに関連するゲートウェイ要件について説明します。
Gateway support for the Teardown message is RECOMMENDED.
ティアダウンメッセージのゲートウェイサポートは推奨されます。
A gateway that supports Teardown SHOULD make use of Teardown functionality if it receives a Membership Query message from a relay that has the G flag set to indicate that it contains valid Gateway Address fields.
ティアダウンをサポートするゲートウェイは、有効なゲートウェイアドレスフィールドが含まれていることを示すGフラグが設定されているリレーからメンバーシップクエリメッセージを受信する場合、ティアダウン機能を利用する必要があります。
As described in Section 5.2.3.5.4, if a gateway supports the Teardown message, has reported active group subscriptions, and receives a Membership Query message with the G flag set, the gateway MUST compare the Gateway IP Address and Gateway Port Number on the new Membership Query message with the values carried by the previous Membership Query message. If either value has changed, the gateway MUST send a Teardown message as described in the next section.
セクション5.2.3.5.4で説明されているように、ゲートウェイがティアダウンメッセージをサポートし、アクティブなグループサブスクリプションを報告し、Gフラグが設定されたメンバーシップクエリメッセージを受信した場合、ゲートウェイはゲートウェイのIPアドレスとゲートウェイポート番号を比較する必要があります。以前のメンバーシップクエリメッセージで伝えられた値を持つ新しいメンバーシップクエリメッセージ。いずれかの値が変更された場合、ゲートウェイは次のセクションで説明するようにティアダウンメッセージを送信する必要があります。
A gateway sends a Teardown message to a relay to request that it stop delivering Multicast Data messages to the gateway and delete any group memberships created by the gateway.
ゲートウェイはTeardownメッセージをリレーに送信して、ゲートウェイへのマルチキャストデータメッセージの配信を停止し、ゲートウェイによって作成されたグループメンバーシップを削除するように要求します。
When a gateway constructs a Teardown message, it MUST copy the Request Nonce, Response MAC, Gateway IP Address, and Gateway Port Number fields from the Membership Query message that provided the Response MAC for the last Membership Update message sent, into the corresponding fields of the Teardown message.
ゲートウェイがティアダウンメッセージを作成するとき、要求ナンス、応答MAC、ゲートウェイIPアドレス、およびゲートウェイポート番号フィールドを、送信された最後のメンバーシップ更新メッセージの応答MACを提供したメンバーシップクエリメッセージから、対応するフィールドにコピーする必要があります。ティアダウンメッセージ。
A gateway MUST send the Teardown message using the Relay Address and AMT port number as the destination. A gateway MAY send the Teardown message multiple times for robustness. The gateway SHOULD use the Querier's Robustness Variable (QRV) field contained in the query encapsulated within the last Membership Query to set the limit on the number of retransmissions (see Section 4.1.6 of [RFC3376] and Section 5.1.8 of [RFC3810]). If the gateway sends the Teardown message multiple times, it SHOULD insert a delay between each transmission using the timing algorithm employed in IGMP/MLD for transmitting unsolicited state-change reports. The RECOMMENDED default delay value is 1 second.
ゲートウェイは、リレーアドレスとAMTポート番号を宛先として使用してTeardownメッセージを送信する必要があります。ゲートウェイは、堅牢性のためにティアダウンメッセージを複数回送信する場合があります。ゲートウェイは、最後のメンバーシップクエリ内にカプセル化されたクエリに含まれるクエリアのロバストネス変数（QRV）フィールドを使用して、再送信回数の制限を設定する必要があります（[RFC3376]のセクション4.1.6および[RFC3810]のセクション5.1.8を参照）。 ）。ゲートウェイがティアダウンメッセージを複数回送信する場合、非送信請求の状態変更レポートを送信するためにIGMP / MLDで採用されているタイミングアルゴリズムを使用して、各送信の間に遅延を挿入する必要があります（SHOULD）。推奨されるデフォルトの遅延値は1秒です。
When a gateway sends a Teardown message, it may be notified that an ICMP Destination Unreachable message was received as a result of an earlier AMT message transmission. Handling of ICMP Destination Unreachable messages is described in Section 5.2.3.9.
ゲートウェイがTeardownメッセージを送信すると、以前のAMTメッセージ送信の結果としてICMP Destination Unreachableメッセージが受信されたことが通知される場合があります。 ICMP宛先到達不能メッセージの処理については、セクション5.2.3.9で説明しています。
When a gateway pseudo-interface is stopped and the gateway has existing group subscriptions, the gateway SHOULD either:
ゲートウェイの疑似インターフェースが停止し、ゲートウェイに既存のグループサブスクリプションがある場合、ゲートウェイは次のいずれかである必要があります。
o Send a Teardown message to the relay as described in Section 5.2.3.7, but only if the gateway supports the Teardown message and the current relay is returning Gateway Address fields in Membership Query messages, or
o セクション5.2.3.7で説明されているように、Teardownメッセージをリレーに送信しますが、ゲートウェイがTeardownメッセージをサポートし、現在のリレーがMembership QueryメッセージのGateway Addressフィールドを返す場合のみ、または
o Send a Membership Update message to the relay that will delete existing group subscriptions.
o Send a Membership Update message to the relay that will delete existing group subscriptions.
A gateway may receive an ICMP Destination Unreachable message [RFC0792] after sending an AMT message. Whether the gateway is notified that an ICMP message was received is highly dependent on firewall and gateway IP stack behavior and gateway implementation.
A gateway may receive an ICMP Destination Unreachable message [RFC0792] after sending an AMT message. Whether the gateway is notified that an ICMP message was received is highly dependent on firewall and gateway IP stack behavior and gateway implementation.
If the reception of an ICMP Destination Unreachable message is reported to the gateway while waiting to receive an AMT message, the gateway may respond as follows, depending on platform capabilities and which outgoing message triggered the ICMP response:
ICMP宛先到達不能メッセージの受信がAMTメッセージの受信を待機している間にゲートウェイに報告された場合、ゲートウェイは、プラットフォームの機能とICMP応答をトリガーした送信メッセージに応じて、次のように応答します。
1. The gateway MAY simply abandon the current relay and restart relay discovery (if used). This is the least desirable approach, as it does not allow for transient network changes.
1. ゲートウェイは、現在のリレーを単に破棄し、リレーの検出を再開する場合があります（使用されている場合）。これは、一時的なネットワーク変更を許可しないため、最も望ましくないアプローチです。
2. If the last message sent was a Relay Discovery or Request message, the gateway MAY simply ignore the ICMP response and continue waiting for incoming AMT messages. If the gateway is configured to retransmit Relay Discovery or Request messages, the normal retransmission behavior for those messages is preserved to prevent the gateway from prematurely abandoning a relay.
2. If the last message sent was a Relay Discovery or Request message, the gateway MAY simply ignore the ICMP response and continue waiting for incoming AMT messages. If the gateway is configured to retransmit Relay Discovery or Request messages, the normal retransmission behavior for those messages is preserved to prevent the gateway from prematurely abandoning a relay.
3. If the last message sent was a Membership Update message, the gateway MAY start a new membership update and associated Request retransmission cycle.
3. 送信された最後のメッセージがメンバーシップ更新メッセージだった場合、ゲートウェイは新しいメンバーシップ更新と関連する要求再送信サイクルを開始する場合があります。
If the reception of an ICMP Destination Unreachable message is reported to the gateway when attempting to transmit a new AMT message, the gateway may respond as follows, depending on platform capabilities and which outgoing message triggered the ICMP response:
新しいAMTメッセージを送信しようとしたときに、ICMP宛先到達不能メッセージの受信がゲートウェイに報告された場合、プラットフォームの機能とICMP応答をトリガーした発信メッセージに応じて、ゲートウェイは次のように応答します。
1. The gateway MAY simply abandon the current relay and restart relay discovery (if used). This is the least desirable approach, as it does not allow for transient network changes.
1. ゲートウェイは、現在のリレーを単に破棄し、リレーの検出を再開する場合があります（使用されている場合）。これは、一時的なネットワーク変更を許可しないため、最も望ましくないアプローチです。
2. If the last message sent was a Relay Discovery, Request, or Teardown message, the gateway MAY attempt to transmit the new message. If the gateway is configured to retransmit Relay Discovery, Request, or Teardown messages, the normal retransmission behavior for those messages is preserved to prevent the gateway from prematurely abandoning a relay.
2. 送信された最後のメッセージがリレー検出、要求、または破棄メッセージであった場合、ゲートウェイは新しいメッセージの送信を試みてもよい（MAY）。ゲートウェイがリレー検出、要求、または破棄メッセージを再送信するように構成されている場合、それらのメッセージの通常の再送信動作は保持され、ゲートウェイが途中でリレーを放棄するのを防ぎます。
3. If the last message sent was a Membership Update message, the gateway SHOULD start a new membership update and associated Request retransmission cycle.
3. 送信された最後のメッセージがメンバーシップ更新メッセージであった場合、ゲートウェイは新しいメンバーシップ更新と関連する要求再送信サイクルを開始する必要があります（SHOULD）。
The following sections describe relay implementation requirements. A non-normative discussion of relay operation may be found in Section 4.2.
次のセクションでは、リレーの実装要件について説明します。リレー操作の非規範的な議論はセクション4.2にあります。
A relay requires a subset of router-mode IGMP and MLD functionality to provide group membership tracking and report processing.
リレーには、グループメンバーシップの追跡とレポート処理を提供するために、ルーターモードのIGMPおよびMLD機能のサブセットが必要です。
A relay accessible via IPv4 MUST support IPv4/IGMPv3 and MAY support IPv6/MLDv2. A relay accessible via IPv6 MUST support IPv6/MLDv2 and MAY support IPv4/IGMPv3.
IPv4を介してアクセス可能なリレーは、IPv4 / IGMPv3をサポートする必要があり、IPv6 / MLDv2をサポートする場合があります。 IPv6経由でアクセス可能なリレーはIPv6 / MLDv2をサポートしなければならず（MUST）、IPv4 / IGMPv3をサポートしてもかまいません（MAY）。
A relay MUST apply the forwarding rules described in Section 6.3 of [RFC3376] and Section 7.3 of [RFC3810].
リレーは、[RFC3376]のセクション6.3および[RFC3810]のセクション7.3で説明されている転送ルールを適用する必要があります。
A relay MUST handle incoming reports as described in Section 6.4 of [RFC3376] and Section 7.4 of [RFC3810], with the exception that actions that lead to queries MAY be modified to eliminate query generation. A relay MUST accept IGMP and MLD report datagrams regardless of the IP source address carried by those datagrams.
リレーは、[RFC3376]のセクション6.4および[RFC3810]のセクション7.4で説明されているように、受信レポートを処理する必要があります。ただし、クエリにつながるアクションを変更して、クエリ生成を排除することができます。リレーは、それらのデータグラムによって運ばれるIP送信元アドレスに関係なく、IGMPおよびMLDレポートデータグラムを受け入れる必要があります。
All other aspects of IGMP/MLD router behavior, such as the handling of queries, querier election, etc., are not used or required for relay operation.
クエリの処理、クエリア選択などのIGMP / MLDルーター動作の他のすべての側面は、リレー操作には使用されず、必須でもありません。
If a relay is deployed for anycast discovery, the relay MUST advertise an anycast Relay Discovery Address Prefix into the unicast routing system of the anycast domain. An address within that prefix, i.e., a Relay Discovery Address, MUST be assigned to a relay interface.
リレーがエニーキャストディスカバリに展開されている場合、リレーはエニーキャストリレーディスカバリアドレスプレフィックスをエニーキャストドメインのユニキャストルーティングシステムにアドバタイズする必要があります。そのプレフィックス内のアドレス、つまりリレー検出アドレスは、リレーインターフェイスに割り当てられる必要があります。
A unicast IPv4 and/or IPv6 address MUST be assigned to the relay interface that will be used to send and receive AMT control and data messages. This address or addresses are returned in Relay Advertisement messages.
AMT制御およびデータメッセージの送受信に使用されるリレーインターフェイスには、ユニキャストIPv4またはIPv6、あるいはその両方のアドレスを割り当てる必要があります。このアドレスは、Relay Advertisementメッセージで返されます。
The remaining details of relay "startup" are highly implementation dependent and are not addressed in this document.
リレーの「起動」の残りの詳細は、実装に大きく依存するため、このドキュメントでは扱いません。
When a relay is started, it begins listening for AMT messages on the interface to which the unicast Relay Address(es) has been assigned, i.e., the address returned in Relay Advertisement messages.
リレーが開始されると、ユニキャストリレーアドレスが割り当てられたインターフェース、つまりリレーアドバタイズメッセージで返されたアドレスで、AMTメッセージのリッスンを開始します。
A relay MUST ignore any message other than a Relay Discovery, Request, Membership Update, or Teardown message. The handling of Relay Discovery, Request, Membership Update, and Teardown messages is addressed in the sections that follow.
リレーは、リレー検出、要求、メンバーシップ更新、またはティアダウンメッセージ以外のメッセージを無視する必要があります。リレーディスカバリ、リクエスト、メンバーシップアップデート、ティアダウンメッセージの処理については、以降のセクションで説明します。
Support for the Teardown message is OPTIONAL. If a relay does not support the Teardown message, it MUST also ignore this message.
ティアダウンメッセージのサポートはオプションです。リレーがティアダウンメッセージをサポートしていない場合は、このメッセージも無視する必要があります。
A relay that conforms to this specification MUST ignore any message with a Version field value other than zero.
この仕様に準拠するリレーは、バージョンフィールド値がゼロ以外のメッセージを無視する必要があります。
This section describes relay requirements related to the relay discovery message sequence described in Section 4.2.1.1.
このセクションでは、セクション4.2.1.1で説明されているリレー検出メッセージシーケンスに関連するリレー要件について説明します。
A relay MUST accept and respond to Relay Discovery messages sent to an anycast Relay Discovery Address or the unicast Relay Address. If a relay receives a Relay Discovery message sent to its unicast address, it MUST respond just as it would if the message had been sent to its anycast Relay Discovery Address.
リレーは、エニーキャストリレー検出アドレスまたはユニキャストリレーアドレスに送信されたリレー検出メッセージを受け入れて応答する必要があります。リレーがユニキャストアドレスに送信されたリレー検出メッセージを受信した場合、メッセージがそのエニーキャストリレー検出アドレスに送信された場合と同様に応答する必要があります。
When a relay receives a Relay Discovery message, it responds by sending a Relay Advertisement message back to the source of the Relay Discovery message.
リレーがリレー検出メッセージを受信すると、リレーは、リレー検出メッセージのソースにリレーアドバタイズメントメッセージを送信して応答します。
The relay MUST use the source IP address and UDP port number of the Relay Discovery message as the destination IP address and UDP port number for the Relay Advertisement message. The source IP address and UDP port number carried by the Relay Advertisement message MUST match the destination IP address and UDP port number of the Relay Discovery message to ensure successful NAT traversal.
The relay MUST use the source IP address and UDP port number of the Relay Discovery message as the destination IP address and UDP port number for the Relay Advertisement message. The source IP address and UDP port number carried by the Relay Advertisement message MUST match the destination IP address and UDP port number of the Relay Discovery message to ensure successful NAT traversal.
The relay MUST copy the value contained in the Discovery Nonce field of the Relay Discovery message into the Discovery Nonce field in the Relay Advertisement message.
The relay MUST copy the value contained in the Discovery Nonce field of the Relay Discovery message into the Discovery Nonce field in the Relay Advertisement message.
If the Relay Discovery message was received as an IPv4 datagram, the relay MUST return an IPv4 address in the Relay Address field of the Relay Advertisement message. If the Relay Discovery message was received as an IPv6 datagram, the relay MUST return an IPv6 address in the Relay Address field.
リレー検出メッセージがIPv4データグラムとして受信された場合、リレーは、リレーアドバタイズメッセージのリレーアドレスフィールドにIPv4アドレスを返さなければなりません（MUST）。リレー検出メッセージがIPv6データグラムとして受信された場合、リレーは、リレーアドレスフィールドにIPv6アドレスを返さなければなりません（MUST）。
This section describes relay requirements related to the membership query portion of the message sequence described in Section 4.2.1.2.
このセクションでは、セクション4.2.1.2で説明されているメッセージシーケンスのメンバーシップクエリ部分に関連するリレー要件について説明します。
When a relay receives a Request message, it responds by sending a Membership Query message back to the source of the Request message.
リレーは、リクエストメッセージを受信すると、メンバーシップクエリメッセージをリクエストメッセージの送信元に送り返すことで応答します。
The relay MUST use the source IP address and UDP port of the Request message as the destination IP address and UDP port for the Membership Query message. The source IP address and UDP port carried by the Membership Query MUST match the destination IP address and UDP port of the Request to ensure successful NAT traversal.
The relay MUST use the source IP address and UDP port of the Request message as the destination IP address and UDP port for the Membership Query message. The source IP address and UDP port carried by the Membership Query MUST match the destination IP address and UDP port of the Request to ensure successful NAT traversal.
The relay MUST return the value contained in the Request Nonce field of the Request message in the Request Nonce field of the Membership Query message. The relay MUST compute a MAC value, as described in Section 5.3.5, and return that value in the Response MAC field of the Membership Query message.
リレーは、メンバーシップクエリメッセージのリクエストノンスフィールドのリクエストメッセージのリクエストノンスフィールドに含まれる値を返さなければなりません（MUST）。リレーは、セクション5.3.5で説明されているようにMAC値を計算し、その値をメンバーシップクエリメッセージの応答MACフィールドで返す必要があります。
If a relay supports the Teardown message, it MUST set the G flag in the Membership Query message and return the source IP address and UDP port carried by the Request message in the corresponding Gateway IP Address and Gateway Port Number fields. If the relay does not support the Teardown message, it SHOULD NOT set these fields, as this may cause the gateway to generate unnecessary Teardown messages.
リレーがティアダウンメッセージをサポートしている場合は、メンバーシップクエリメッセージにGフラグを設定し、対応するゲートウェイIPアドレスフィールドとゲートウェイポート番号フィールドに、要求メッセージによって伝送される送信元IPアドレスとUDPポートを返す必要があります。リレーがティアダウンメッセージをサポートしていない場合は、これらのフィールドを設定しないでください。これにより、ゲートウェイが不要なティアダウンメッセージを生成する可能性があります。
If the P flag in the Request message is 0, the relay MUST return an IPv4-encapsulated IGMPv3 General Query in the Membership Query message. If the P flag is 1, the relay MUST return an IPv6-encapsulated MLDv2 General Query in the Membership Query message.
要求メッセージのPフラグが0の場合、リレーは、メンバーシップクエリメッセージでIPv4カプセル化IGMPv3一般クエリを返さなければなりません（MUST）。 Pフラグが1の場合、リレーは、メンバーシップクエリメッセージでIPv6カプセル化MLDv2一般クエリを返さなければなりません（MUST）。
If the relay is not accepting Membership Update messages that create new tunnel endpoints due to resource limitations, it SHOULD set the L flag in the Membership Query message to notify the gateway of this state. Support for the L flag is OPTIONAL. See Section 5.3.3.8.
リレーがリソース制限のために新しいトンネルエンドポイントを作成するメンバーシップ更新メッセージを受け入れない場合、この状態をゲートウェイに通知するためにメンバーシップクエリメッセージにLフラグを設定する必要があります。 Lフラグのサポートはオプションです。セクション5.3.3.8を参照してください。
The encapsulated IGMPv3 General Query datagrams generated by a relay MUST conform to the descriptions found in Section 4.1 of [RFC3376]. These datagrams MUST possess the IP headers, header options, and header values called for in [RFC3376], with the following exception: a relay MAY use any source IP address for an IGMP General Query datagram, including the "unspecified" address (all octets are zero). This exception is made because any source address that a relay might normally send may not be a valid link-local address on any gateway interface. It is for this reason that a gateway must accept encapsulated IGMP queries regardless of the source address they carry. See Section 5.2.1.
リレーによって生成されたカプセル化されたIGMPv3 General Queryデータグラムは、[RFC3376]のセクション4.1にある説明に準拠する必要があります。これらのデータグラムは、[RFC3376]で要求されたIPヘッダー、ヘッダーオプション、およびヘッダー値を保持する必要があります。ただし、次の例外があります。リレーは、「未指定」アドレス（すべてのオクテット）を含むIGMP一般クエリデータグラムの送信元IPアドレスを使用できます（MAY）。ゼロです）。この例外が発生するのは、リレーが通常送信する可能性のあるソースアドレスは、ゲートウェイインターフェイスの有効なリンクローカルアドレスではない可能性があるためです。このため、ゲートウェイは、送信元アドレスに関係なく、カプセル化されたIGMPクエリを受け入れる必要があります。セクション5.2.1を参照してください。
The encapsulated MLDv2 General Query datagrams generated by a relay MUST conform to the descriptions found in Section 5.1 of [RFC3810]. These datagrams MUST possess the IP headers, header options, and header values called for in [RFC3810], with the following exception: a relay MAY use any source IP address for an MLD General Query datagram, including the "unspecified" address (all octets are zero). This exception is made because any source address that a relay might normally send may not be a valid link-local address on any gateway interface. As with IGMP, it is for this reason that a gateway must accept encapsulated MLD queries regardless of the source address they carry. See Section 5.2.1.
リレーによって生成されたカプセル化されたMLDv2 General Queryデータグラムは、[RFC3810]のセクション5.1にある説明に準拠する必要があります。これらのデータグラムは、[RFC3810]で要求されたIPヘッダー、ヘッダーオプション、およびヘッダー値を保持する必要があります。ただし、次の例外があります。リレーは、「未指定」アドレス（すべてのオクテット）を含む、MLD一般クエリデータグラムの送信元IPアドレスを使用できます（MAY）。ゼロです）。この例外が発生するのは、リレーが通常送信する可能性のあるソースアドレスは、ゲートウェイインターフェイスの有効なリンクローカルアドレスではない可能性があるためです。 IGMPの場合と同様に、ゲートウェイは、送信元アドレスに関係なく、カプセル化されたMLDクエリを受け入れる必要があるのはこのためです。セクション5.2.1を参照してください。
A relay MUST set the Querier's Query Interval Code (QQIC) field in the General Query to supply the gateway with a suggested time duration to use for the membership query timer. The QQIC field is defined in Section 4.1.7 of [RFC3376] and Section 5.1.9 of [RFC3810]. A relay MAY adjust this value to affect the rate at which the Request messages are sent from a gateway. However, a gateway is allowed to use a shorter duration than the duration specified in the QQIC field, so a relay may be limited in its ability to spread out Requests coming from a gateway.
リレーは、一般クエリのクエリアのクエリ間隔コード（QQIC）フィールドを設定して、メンバーシップクエリタイマーに使用する推奨期間をゲートウェイに提供する必要があります。 QQICフィールドは、[RFC3376]のセクション4.1.7と[RFC3810]のセクション5.1.9で定義されています。リレーは、この値を調整して、要求メッセージがゲートウェイから送信される速度に影響を与える場合があります。ただし、ゲートウェイはQQICフィールドで指定された期間よりも短い期間を使用することが許可されているため、ゲートウェイからの要求を分散する機能がリレーで制限される場合があります。
A relay MUST set the Querier's Robustness Variable (QRV) field in the General Query to a non-zero value. This value SHOULD be greater than one. If a gateway retransmits membership state-change messages, it will retransmit them (Robustness Variable - 1) times. The QRV field is defined in Section 4.1.6 of [RFC3376] and Section 5.1.8 of [RFC3810].
リレーは、一般クエリのクエリアのロバストネス変数（QRV）フィールドをゼロ以外の値に設定する必要があります。この値は1より大きい必要があります。ゲートウェイがメンバーシップの状態変更メッセージを再送信すると、それらは（Robustness Variable-1）回再送信されます。 QRVフィールドは、[RFC3376]のセクション4.1.6と[RFC3810]のセクション5.1.8で定義されています。
A relay SHOULD set the Maximum Response Code field in the General Query to a value of 1 to trigger an immediate response from the gateway (some host IGMP/MLD implementations may not accept a value of zero). A relay SHOULD NOT use the IGMPv3/MLDv2 Query Response Interval variable, if available, to generate the Maximum Response Code field value, as the Query Response Interval variable is used in setting the duration of group state timers and must not be set to such a small value. The Maximum Response Code field is defined in Section 4.1.1 of [RFC3376] and Section 5.1.3 of [RFC3810]. See Section 5.3.3.7.
リレーは、一般クエリの最大応答コードフィールドを値1に設定して、ゲートウェイからの即時応答をトリガーする必要があります（一部のホストIGMP / MLD実装は値0を受け入れない場合があります）。クエリ応答間隔変数はグループ状態タイマーの継続時間の設定に使用され、そのような値に設定してはならないので、リレーはIGMPv3 / MLDv2クエリ応答間隔変数を使用しないでください（可能な場合）、最大応答コードフィールド値を生成します。小さい値。最大応答コードフィールドは、[RFC3376]のセクション4.1.1および[RFC3810]のセクション5.1.3で定義されています。セクション5.3.3.7を参照してください。
This section describes relay requirements related to the membership update portion of the message sequence described in Section 4.2.1.2.
このセクションでは、セクション4.2.1.2で説明されているメッセージシーケンスのメンバーシップ更新部分に関連するリレー要件について説明します。
When a relay receives a Membership Update message, it must first determine whether it should accept or ignore the message. A relay MUST NOT make any changes to group membership and forwarding state if the message fails to satisfy any of the following requirements:
When a relay receives a Membership Update message, it must first determine whether it should accept or ignore the message. A relay MUST NOT make any changes to group membership and forwarding state if the message fails to satisfy any of the following requirements:
o The IP datagram encapsulated within the message MUST be one of the following:
o メッセージ内にカプセル化されたIPデータグラムは、次のいずれかである必要があります。
* IPv4 datagram carrying an IGMPv2 or IGMPv3 Membership Report message.
* IGMPv2またはIGMPv3メンバーシップレポートメッセージを運ぶIPv4データグラム。
* IPv4 datagram carrying an IGMPv2 Leave Group message.
* IGMPv2 Leave Groupメッセージを運ぶIPv4データグラム。
* IPv6 datagram carrying an MLDv1 or MLDv2 Multicast Listener Report message.
* MLDv1またはMLDv2マルチキャストリスナーレポートメッセージを運ぶIPv6データグラム。
* IPv6 datagram carrying MLDv1 Multicast Listener Done message.
* MLDv1マルチキャストリスナー完了メッセージを運ぶIPv6データグラム。
o The encapsulated IP datagram MUST satisfy the IP header requirements for the IGMP or MLD message type as described in Section 4 of [RFC3376], Section 2 of [RFC2236], Section 5 of [RFC3810], and Section 3 of [RFC2710], with the following exception: a relay MUST accept an IGMP or MLD message regardless of the IP source address carried by the datagram.
o カプセル化されたIPデータグラムは、[RFC3376]のセクション4、[RFC2236]のセクション2、[RFC3810]のセクション5、[RFC2710]のセクション3で説明されているように、IGMPまたはMLDメッセージタイプのIPヘッダー要件を満たす必要があります。次の例外：リレーは、データグラムが運ぶIP送信元アドレスに関係なく、IGMPまたはMLDメッセージを受け入れる必要があります。
o The total length of the encapsulated IP datagram as computed from the lengths contained in the datagram header(s) MUST NOT exceed the available field length within the Membership Update message.
o データグラムヘッダーに含まれる長さから計算されたカプセル化されたIPデータグラムの全長は、Membership Updateメッセージ内の利用可能なフィールド長を超えてはなりません（MUST NOT）。
o The computed checksums for the encapsulated IP datagram and its payload MUST match the values contained therein. Checksum computation and verification vary by protocol; see [RFC0791] for IPv4, [RFC3376] for IGMPv3, and [RFC4443] for MLD (ICMPv6).
o カプセル化されたIPデータグラムとそのペイロードの計算されたチェックサムは、そこに含まれている値と一致する必要があります。チェックサムの計算と検証はプロトコルによって異なります。 IPv4については[RFC0791]、IGMPv3については[RFC3376]、MLD（ICMPv6）については[RFC4443]を参照してください。
o If processing of the encapsulated IGMP or MLD message would result in an allocation of new state or a modification of existing state, the relay MUST authenticate the source of the message by verifying that the value contained in the Response MAC field equals the MAC value computed from the fields in the Membership Update message datagram. If a time-varying private secret is used in the computation of a Response MAC, the relay MUST retain the previous version of the private secret for use in authenticating Membership Updates sent during the subsequent query interval. If the first attempt at Response MAC authentication fails, the relay MUST attempt to authenticate the Response MAC using the previous private secret value unless 2 * query_interval time has elapsed since the private secret change. See Section 5.3.5.
oカプセル化されたIGMPまたはMLDメッセージの処理の結果、新しい状態の割り当てまたは既存の状態の変更が発生する場合、リレーは、応答MACフィールドに含まれる値が計算されたMAC値と等しいことを確認することにより、メッセージのソースを認証する必要があります。 Membership Updateメッセージデータグラムのフィールドから。応答MACの計算に時変プライベートシークレットを使用する場合、リレーは、後続のクエリ間隔中に送信されるメンバーシップ更新の認証に使用するために、以前のバージョンのプライベートシークレットを保持する必要があります。レスポンスシーク認証の最初の試行が失敗した場合、リレーは、プライベートシークレットの変更から2 * query_interval時間が経過しない限り、以前のプライベートシークレット値を使用してレスポンスMACの認証を試行する必要があります。セクション5.3.5を参照してください。
A relay MAY skip source authentication to reduce the computational cost of handling Membership Update messages if the relay can make a trivial determination that the IGMP/MLD message carried by the Membership Update message will produce no changes in group membership or forwarding state. The relay does not need to compute and compare MAC values if it finds there are no group subscriptions for the source of the Membership Update message and either of the following is true:
リレーがメンバーシップ更新メッセージによって運ばれるIGMP / MLDメッセージがグループメンバーシップまたは転送状態に変化をもたらさないという簡単な決定を行うことができる場合、リレーはソース認証をスキップしてメンバーシップ更新メッセージを処理する計算コストを削減できます。 Membership Updateメッセージのソースにグループサブスクリプションがなく、次のいずれかが当てはまる場合、リレーはMAC値を計算および比較する必要はありません。
o The encapsulated IP datagram is an IGMPv3 Membership Report or MLDv2 Multicast Listener Report message that contains no group records. This may often be the case for gateways that continuously repeat the membership update cycle even though they have no group subscriptions to report.
o カプセル化されたIPデータグラムは、グループレコードを含まないIGMPv3メンバーシップレポートまたはMLDv2マルチキャストリスナーレポートメッセージです。これは、報告するグループサブスクリプションがない場合でも、メンバーシップの更新サイクルを継続的に繰り返すゲートウェイの場合によく見られます。
o The encapsulated IP datagram is an IGMPv2 Leave Group or MLDv1 Multicast Listener Done message.
o カプセル化されたIPデータグラムは、IGMPv2 Leave GroupまたはMLDv1 Multicast Listener Doneメッセージです。
The IGMP and MLD protocol specifications indicate that senders SHOULD use a link-local source IP address in message datagrams. This requirement must be relaxed for AMT because gateways and relays do not share a common subnet. For this reason, a relay implementation MUST accept IGMP and MLD datagrams regardless of the source IP address they carry.
IGMPおよびMLDプロトコルの仕様では、送信者はメッセージデータグラムでリンクローカルソースIPアドレスを使用する必要がある（SHOULD）。ゲートウェイとリレーは共通のサブネットを共有しないため、AMTのこの要件を緩和する必要があります。このため、リレー実装は、それらが運ぶソースIPアドレスに関係なく、IGMPおよびMLDデータグラムを受け入れる必要があります。
Once a relay has determined that the Membership Update message is valid, it processes the encapsulated IGMP or MLD message to update group membership state and communicates with the multicast protocol to update forwarding state and possibly send multicast protocol messages towards upstream routers. The relay MUST ignore any octets that might exist between the encapsulated IP datagram and the end of the Membership Update message.
リレーは、Membership Updateメッセージが有効であると判断すると、カプセル化されたIGMPまたはMLDメッセージを処理してグループメンバーシップの状態を更新し、マルチキャストプロトコルと通信して転送状態を更新し、場合によっては上流のルーターにマルチキャストプロトコルメッセージを送信します。リレーは、カプセル化されたIPデータグラムとメンバーシップ更新メッセージの終わりの間に存在する可能性のあるオクテットを無視しなければなりません（MUST）。
As described in Section 4.2.2, a relay uses the source IP address and source UDP port carried by a Membership Update message to identify a tunnel endpoint. A relay uses the tunnel endpoint as the destination address for any Multicast Data messages it sends as a result of the group membership and forwarding state created by processing the IGMP/ MLD messages contained in Membership Update messages received from the endpoint.
セクション4.2.2で説明されているように、リレーは、Membership Updateメッセージによって伝送されるソースIPアドレスとソースUDPポートを使用して、トンネルエンドポイントを識別します。リレーは、エンドポイントから受信したMembership Updateメッセージに含まれるIGMP / MLDメッセージを処理することによって作成されたグループメンバーシップと転送状態の結果として送信するマルチキャストデータメッセージの宛先アドレスとして、トンネルエンドポイントを使用します。
If a Membership Update message originates from a new endpoint, the relay MUST determine whether it can accept updates from a new endpoint. If a relay has been configured with a limit on the total number of endpoints, or a limit on the total number of endpoints for a given source address, then the relay MAY ignore the Membership Update message and possibly withdraw any Relay Discovery Address Prefix announcement that it might have made. See Section 5.3.3.8.
Membership Updateメッセージが新しいエンドポイントから発信された場合、リレーは新しいエンドポイントからの更新を受け入れることができるかどうかを判断する必要があります。リレーがエンドポイントの総数の制限、または特定の送信元アドレスのエンドポイントの総数の制限で構成されている場合、リレーはメンバーシップ更新メッセージを無視して、可能性のあるリレー発見アドレスプレフィックスのアナウンスを取り消す場合があります。それは作ったかもしれない。セクション5.3.3.8を参照してください。
A relay MUST maintain some form of group membership database for each endpoint. The per-endpoint databases are used to update a forwarding table containing entries that map a (*,G) or (S,G) subscription to a list of tunnel endpoints.
リレーは、エンドポイントごとに何らかの形式のグループメンバーシップデータベースを維持する必要があります。エンドポイントごとのデータベースは、（*、G）または（S、G）サブスクリプションをトンネルエンドポイントのリストにマップするエントリを含む転送テーブルを更新するために使用されます。
A relay MUST maintain some form of group membership database representing a merger of the group membership databases of all endpoints. The merged group membership database is used to update upstream multicast forwarding state.
リレーは、すべてのエンドポイントのグループメンバーシップデータベースの統合を表す、何らかの形式のグループメンバーシップデータベースを維持する必要があります。マージされたグループメンバーシップデータベースは、アップストリームマルチキャスト転送状態を更新するために使用されます。
A relay MUST maintain a forwarding table that maps each unique (*,G) and (S,G) subscription to a list of tunnel endpoints. A relay uses this forwarding table to provide the destination address when performing UDP/IP encapsulation of the incoming multicast IP datagrams to form Multicast Data messages.
リレーは、一意の（*、G）および（S、G）サブスクリプションをトンネルエンドポイントのリストにマップする転送テーブルを維持する必要があります。リレーは、着信マルチキャストIPデータグラムのUDP / IPカプセル化を実行してマルチキャストデータメッセージを形成するときに、この転送テーブルを使用して宛先アドレスを提供します。
If a group filter mode for a group entry on a tunnel endpoint is EXCLUDE, the relay SHOULD NOT forward datagrams that originate from sources in the filter source list unless the relay architecture does not readily support source filtering. A relay MAY ignore the source list if necessary because gateways are expected to do their own source filtering.
トンネルエンドポイントのグループエントリのグループフィルターモードがEXCLUDEの場合、リレーアーキテクチャがソースフィルタリングを容易にサポートしない限り、リレーはフィルターソースリストのソースから発信されたデータグラムを転送してはなりません（SHOULD NOT）。ゲートウェイは独自のソースフィルタリングを行うことが期待されているため、リレーは必要に応じてソースリストを無視してもよい（MAY）。
This section describes relay requirements related to the teardown message sequence described in Section 4.2.1.3.
このセクションでは、セクション4.2.1.3で説明されているティアダウンメッセージシーケンスに関連するリレー要件について説明します。
When a relay (that supports the Teardown message) receives a Teardown message, it MUST first authenticate the source of the Teardown message by verifying that the Response MAC carried by the Teardown message is equal to a MAC value computed from the fields carried by the Teardown message. The method used to compute the MAC differs from that used to generate and validate the Membership Query and Membership Update messages in that the source IP address and source UDP port number used to compute the MAC are taken from the Gateway IP Address and Gateway Port Number fields in the Teardown message rather than from the IP and UDP headers in the datagram that carries the Teardown message. The MAC computation is described in Section 5.3.5. A relay MUST ignore a Teardown message if the computed MAC does not equal the value of the Response MAC field.
リレー（Teardownメッセージをサポートする）がTeardownメッセージを受信すると、最初にTeardownメッセージによって送信された応答MACがTeardownによって送信されたフィールドから計算されたMAC値と等しいことを確認して、Teardownメッセージのソースを認証する必要があります。メッセージ。 MACの計算に使用される方法は、MACの計算に使用される送信元IPアドレスおよび送信元UDPポート番号がゲートウェイIPアドレスおよびゲートウェイポート番号フィールドから取得されるという点で、メンバーシップクエリおよびメンバーシップ更新メッセージの生成および検証に使用される方法とは異なります。ティアダウンメッセージを運ぶデータグラムのIPおよびUDPヘッダーからではなく、ティアダウンメッセージ内。 MAC計算については、セクション5.3.5で説明します。計算されたMACが応答MACフィールドの値と等しくない場合、リレーはティアダウンメッセージを無視する必要があります。
If a relay determines that a Teardown message is authentic, it MUST immediately stop transmitting Multicast Data messages to the endpoint identified by the Gateway IP Address and Gateway Port Number fields in the message. The relay MUST eventually delete any group membership and forwarding state associated with the endpoint but MAY delay doing so to allow a gateway to recreate group membership state on a new endpoint and thereby avoid making unnecessary (temporary) changes in upstream routing/forwarding state.
リレーがティアダウンメッセージが本物であると判断した場合、メッセージのゲートウェイIPアドレスおよびゲートウェイポート番号フィールドで識別されるエンドポイントへのマルチキャストデータメッセージの送信を直ちに停止する必要があります。リレーは最終的にエンドポイントに関連付けられたグループメンバーシップと転送状態を削除する必要がありますが、ゲートウェイが新しいエンドポイントでグループメンバーシップ状態を再作成できるようにし、それにより、アップストリームのルーティング/転送状態で不要な（一時的な）変更が行われないようにする必要があります。
The state changes made by a relay when processing a Teardown message MUST be identical to those that would be made if the relay had received an IGMP/MLD report that would cause the IGMP or MLD protocol to delete all existing group records in the group membership database associated with the endpoint. The processing of the Teardown message should trigger or mimic the normal interaction between IGMP or MLD and a multicast protocol to produce required changes in forwarding state and possibly send prune/leave messages towards upstream routers.
ティアダウンメッセージを処理するときにリレーによって行われる状態変更は、IGMPまたはMLDプロトコルがグループメンバーシップデータベース内のすべての既存のグループレコードを削除する原因となるIGMP / MLDレポートをリレーが受信した場合に行われるものと同じでなければなりませんエンドポイントに関連付けられています。 Teardownメッセージの処理は、IGMPまたはMLDとマルチキャストプロトコル間の通常の相互作用をトリガーまたは模倣して、転送状態に必要な変更を生成し、プルーニング/リーブメッセージを上流のルーターに送信する必要があります。
When a multicast IP datagram is forwarded to the relay pseudo-interface, the relay MUST, for each gateway that has expressed an interest in receiving the datagram, encapsulate the IP datagram into a Multicast Data message or messages and send that message or messages to the gateway. This process is highly implementation dependent but conceptually requires the following steps:
マルチキャストIPデータグラムがリレー疑似インターフェースに転送されると、リレーは、データグラムの受信に関心を示したゲートウェイごとに、IPデータグラムをマルチキャストデータメッセージにカプセル化し、そのメッセージをゲートウェイ。このプロセスは実装に大きく依存しますが、概念的には次の手順が必要です。
o Use the IP datagram source and destination address to look up the appropriate (*,G) or (S,G) entry in the endpoint forwarding table created for the pseudo-interface as a result of IGMP/MLD processing.
o IPデータグラムの送信元アドレスと宛先アドレスを使用して、IGMP / MLD処理の結果として疑似インターフェース用に作成されたエンドポイント転送テーブルで適切な（*、G）または（S、G）エントリを検索します。
o Possibly replicate the datagram for each gateway endpoint listed for that (*,G) or (S,G) entry.
o その（*、G）または（S、G）エントリに対してリストされている各ゲートウェイエンドポイントのデータグラムを複製する可能性があります。
o If the multicast IP datagram size exceeds the Tunnel MTU as determined according to the procedure described in Section 5.3.3.6.1, the relay must execute the procedure described in Section 5.3.3.6.2.
o マルチキャストIPデータグラムのサイズがセクション5.3.3.6.1で説明されている手順に従って決定されたトンネルMTUを超える場合、リレーはセクション5.3.3.6.2で説明されている手順を実行する必要があります。
o Encapsulate and transmit the IP datagram according to the procedure described in Section 5.3.3.6.3.
o セクション5.3.3.6.3で説明されている手順に従って、IPデータグラムをカプセル化して送信します。
The relay pseudo-interface MUST ignore any other IP datagrams forwarded to the pseudo-interface.
The relay pseudo-interface MUST ignore any other IP datagrams forwarded to the pseudo-interface.
A relay MUST compute a Tunnel MTU (TMTU) value for each AMT tunnel that originates on the relay. A relay will use the TMTU value to determine whether an incoming multicast IP datagram can be delivered downstream in a Membership Data message without fragmentation. A relay MUST compute the TMTU by subtracting the size of the Membership Data message headers (IP, UDP, and AMT) from the current Path MTU (PMTU) associated with each AMT tunnel. The relay MUST maintain a PMTU value on a per-tunnel or per-relay basis. A relay MUST support one or both of the following methods for determining the PMTU value:
リレーは、リレーを起点とする各AMTトンネルのトンネルMTU（TMTU）値を計算する必要があります。リレーは、TMTU値を使用して、着信マルチキャストIPデータグラムを断片化せずにメンバーシップデータメッセージでダウンストリームに配信できるかどうかを判断します。リレーは、各AMTトンネルに関連付けられている現在のパスMTU（PMTU）からメンバーシップデータメッセージヘッダー（IP、UDP、およびAMT）のサイズを減算することにより、TMTUを計算する必要があります。リレーは、トンネルごとまたはリレーごとにPMTU値を維持する必要があります。リレーは、PMTU値を決定するために次の方法の1つまたは両方をサポートする必要があります。
o The relay MAY provide a configuration option that establishes a fixed PMTU that will be applied to all AMT tunnels originating at the relay.
o リレーは、リレーを起点とするすべてのAMTトンネルに適用される固定PMTUを確立する構成オプションを提供する場合があります。
o The relay MAY dynamically adjust PMTU value(s) in response to receipt of ICMP/ICMPv6 Datagram Too Big messages as described in [RFC1191] and [RFC1981].
o [RFC1191]と[RFC1981]で説明されているように、リレーはICMP / ICMPv6データグラムが大きすぎるメッセージの受信に応じてPMTU値を動的に調整してもよい（MAY）。
If a relay supports dynamic adjustment of per-tunnel or per-relay PMTU values in response to ICMP messages, the relay MUST provide a configuration option that disables this feature and also provide a configuration option that establishes a minimum PMTU for all tunnels. These configuration options may be used to mitigate certain types of denial-of-service attacks (see Section 6). When dynamic PMTU adjustments are disabled, the PMTU for all tunnels MUST default to the Link MTU (first hop) on the downstream interface.
リレーがICMPメッセージに応じてトンネルごとまたはリレーごとのPMTU値の動的調整をサポートする場合、リレーはこの機能を無効にする構成オプションを提供し、すべてのトンネルの最小PMTUを確立する構成オプションも提供する必要があります。これらの構成オプションは、特定の種類のサービス拒否攻撃を軽減するために使用できます（セクション6を参照）。動的PMTU調整が無効になっている場合、すべてのトンネルのPMTUは、デフォルトでダウンストリームインターフェイスのリンクMTU（最初のホップ）に設定する必要があります。
This section defines procedures that a relay must execute when it receives a multicast datagram whose size is greater than the Tunnel MTU of the tunnel or tunnels through which it must be delivered.
このセクションでは、配信する必要のある1つまたは複数のトンネルのトンネルMTUより大きいサイズのマルチキャストデータグラムを受信したときに、リレーが実行する必要のある手順を定義します。
If the DF bit in the multicast datagram header is set to 1 (Don't Fragment), the relay MUST discard the packet and, if the datagram originated from an SSM source, send an ICMPv4 [RFC0792] Destination Unreachable message to the source, with code 4 (fragmentation needed and DF set). The ICMP Destination Unreachable message MUST contain a Next-Hop MTU (as specified by [RFC1191]), and the relay MUST set the Next-Hop MTU to the TMTU associated with the tunnel or tunnels. If the DF bit in the multicast datagram header is set to 0 (May Fragment), the relay MUST fragment the datagram and encapsulate each fragment within Multicast Data messages for transmission through the tunnel or tunnels. This ensures that gateways will receive complete, non-fragmented Multicast Data messages, containing fragmented multicast datagram payloads. The relay SHOULD avoid generating a separate ICMP message for each tunnel but instead send a single ICMP message with a Next-Hop MTU equal to the smallest TMTU of all tunnels to which the datagram was to be forwarded.
マルチキャストデータグラムヘッダーのDFビットが1（フラグメントしない）に設定されている場合、リレーはパケットを破棄する必要があり、データグラムがSSMソースから発信された場合は、ICMPv4 [RFC0792]宛先到達不能メッセージをソースに送信します。コード4（断片化が必要で、DFが設定されています）。 ICMP宛先到達不能メッセージには、[[RFC1191]で指定された）ネクストホップMTUが含まれている必要があり、リレーは、1つまたは複数のトンネルに関連付けられているTMTUにネクストホップMTUを設定する必要があります。マルチキャストデータグラムヘッダーのDFビットが0（5月のフラグメント）に設定されている場合、リレーは、データグラムをフラグメント化し、各フラグメントをマルチキャストデータメッセージ内にカプセル化して、1つまたは複数のトンネル経由で送信する必要があります。これにより、ゲートウェイはフラグメント化されたマルチキャストデータグラムペイロードを含む、フラグメント化されていない完全なマルチキャストデータメッセージを確実に受信します。リレーは、トンネルごとに個別のICMPメッセージを生成しないようにする必要があります（SHOULD）。代わりに、データグラムの転送先であるすべてのトンネルの最小TMTUに等しいネクストホップMTUを使用して単一のICMPメッセージを送信します。
The relay MUST discard the packet and, if the datagram originated from an SSM source, send an ICMPv6 [RFC4443] Packet Too Big message to the payload source. The MTU specified in the Packet Too Big message MUST be equal to the TMTU associated with the tunnel or tunnels. The relay SHOULD avoid generating a separate ICMPv6 message for each tunnel but instead send a single ICMPv6 message with a Next-Hop MTU equal to the smallest TMTU of all tunnels to which the datagram was to be forwarded.
リレーはパケットを破棄しなければならず、データグラムがSSMソースから発信された場合は、ICMPv6 [RFC4443]パケットビッグメッセージをペイロードソースに送信します。 Packet Too Bigメッセージで指定されたMTUは、1つまたは複数のトンネルに関連付けられたTMTUと等しくなければなりません。リレーは、トンネルごとに個別のICMPv6メッセージを生成することを回避する必要があります（SHOULD）。代わりに、データグラムの転送先であるすべてのトンネルの最小TMTUに等しいネクストホップMTUを含む単一のICMPv6メッセージを送信します。
A relay encapsulates a multicast IP datagram in a UDP/IP Membership Data message, using the tunnel endpoint UDP/IP address as the destination address and the unicast Relay Address and port number as the source UDP/IP address. To ensure successful NAT traversal, the source address and port MUST match the destination address and port carried by the Membership Update message sent by the gateway to create the forwarding table entry.
リレーは、トンネルエンドポイントのUDP / IPアドレスを宛先アドレスとして使用し、ユニキャストリレーアドレスとポート番号を送信元UDP / IPアドレスとして使用して、マルチキャストIPデータグラムをUDP / IPメンバーシップデータメッセージにカプセル化します。 NATトラバーサルを確実に成功させるには、転送元テーブルのエントリを作成するために、送信元アドレスとポートが、ゲートウェイから送信されたMembership Updateメッセージによって運ばれる宛先アドレスとポートと一致する必要があります。
If possible, the relay SHOULD compute a valid, non-zero checksum for the UDP datagram carrying the Multicast Data message. See Section 4.2.2.3.
可能であれば、リレーは、マルチキャストデータメッセージを伝送するUDPデータグラムの有効なゼロ以外のチェックサムを計算する必要があります（SHOULD）。 4.2.2.3項を参照してください。
The following sections describe additional requirements related to the IP protocol of the tunnel and that of the multicast IP datagram.
次のセクションでは、トンネルのIPプロトコルとマルチキャストIPデータグラムのIPプロトコルに関連する追加の要件について説明します。
When a relay delivers an IPv4 payload over an IPv4 tunnel and the DF bit in the payload header is set to 1 (Don't Fragment), the relay MUST set the DF bit in the Multicast Data IP header to 1. When a relay delivers an IPv4 payload over an IPv4 tunnel and the DF bit in the payload header is set to 0 (May Fragment), by default, the relay MUST set the DF bit in the Multicast Data IP header to 1. However, a relay MAY provide a configuration option that allows the DF bit to be copied from the payload header to the Multicast Data IP header to allow downstream fragmentation of the Multicast Data message. When a relay delivers an IPv6 payload over an IPv4 tunnel, the relay MUST set the DF bit in the Multicast Data IP header to 1. The relay MUST NOT transmit a Multicast Data message with an IP header in which the MF (More Fragments) bit is set to 1.
When a relay delivers an IPv4 payload over an IPv4 tunnel and the DF bit in the payload header is set to 1 (Don't Fragment), the relay MUST set the DF bit in the Multicast Data IP header to 1. When a relay delivers an IPv4 payload over an IPv4 tunnel and the DF bit in the payload header is set to 0 (May Fragment), by default, the relay MUST set the DF bit in the Multicast Data IP header to 1. However, a relay MAY provide a configuration option that allows the DF bit to be copied from the payload header to the Multicast Data IP header to allow downstream fragmentation of the Multicast Data message. When a relay delivers an IPv6 payload over an IPv4 tunnel, the relay MUST set the DF bit in the Multicast Data IP header to 1. The relay MUST NOT transmit a Multicast Data message with an IP header in which the MF (More Fragments) bit is set to 1.
When tunneling over IPv6, a relay MUST NOT emit a Multicast Data message datagram containing an IPv6 fragment header.
IPv6でトンネリングする場合、リレーはIPv6フラグメントヘッダーを含むマルチキャストデータメッセージデータグラムを送信してはなりません（MUST NOT）。
If a relay receives a sequence of ICMP or ICMPv6 Destination Unreachable messages (excluding ICMP code 4; see below) in response to transmission of a sequence of AMT Multicast Data messages to a gateway, the relay SHOULD discontinue sending messages to that gateway and shut down the tunnel for that gateway.
AMTマルチキャストデータメッセージのシーケンスのゲートウェイへの送信に応答して、リレーが一連のICMPまたはICMPv6 Destination Unreachableメッセージ（ICMPコード4を除く。下記参照）を受信した場合、リレーはそのゲートウェイへのメッセージの送信を中止してシャットダウンする必要があります（SHOULD）。そのゲートウェイのトンネル。
Handling of ICMP Destination Unreachable messages with code 4, "fragmentation needed and DF set" (i.e., "Datagram Too Big") is covered in Section 5.3.3.6.1. If a relay provides this capability, it MUST provide a configuration option that indicates what number of sequential Destination Unreachable messages can be received and ignored before the relay will automatically shut down a tunnel.
コード4、「フラグメンテーションが必要、DFが設定されている」（つまり、「データグラムが大きすぎます」）のICMP宛先到達不能メッセージの処理については、5.3.3.6.1で説明しています。リレーがこの機能を提供する場合、リレーが自動的にトンネルをシャットダウンする前に、受信および無視できる連続した宛先到達不能メッセージの数を示す構成オプションを提供する必要があります。
A relay MUST maintain a timer or timers whose expiration will trigger the removal of any group subscriptions and forwarding state previously created for a gateway endpoint should the gateway fail to refresh the group membership state within a specified time interval.
リレーは、指定された時間間隔内にゲートウェイがグループメンバーシップの状態を更新できなかった場合に、有効期限がグループサブスクリプションとゲートウェイエンドポイント用に以前に作成された転送状態の削除をトリガーするタイマーを維持する必要があります。
A relay MAY use a variant of the IGMPv3/MLDv2 state management protocol described in Section 6 of [RFC3376] or Section 7 of [RFC3810] or may maintain a per-endpoint timer to trigger the deletion of group membership state.
A relay MAY use a variant of the IGMPv3/MLDv2 state management protocol described in Section 6 of [RFC3376] or Section 7 of [RFC3810] or may maintain a per-endpoint timer to trigger the deletion of group membership state.
If a per-endpoint timer is used, the relay MUST restart this timer each time it receives a new Membership Update message from the gateway endpoint.
エンドポイントごとのタイマーが使用される場合、リレーはゲートウェイエンドポイントから新しいメンバーシップ更新メッセージを受信するたびにこのタイマーを再起動する必要があります。
The endpoint timer duration MAY be computed from tunable IGMP/MLD variables as follows:
エンドポイントタイマーの継続時間は、調整可能なIGMP / MLD変数から次のように計算できます。
((Robustness_Variable) * (Query_Interval)) + Query_Response_Interval
If IGMP/MLD default values are used for these variables, the gateway will time out after 125s * 2 + 10s = 260s. The timer duration MUST be greater than the query interval suggested in the last Membership Query message sent to the gateway endpoint.
これらの変数にIGMP / MLDのデフォルト値が使用されている場合、ゲートウェイは125秒* 2 + 10秒= 260秒後にタイムアウトします。タイマー期間は、ゲートウェイエンドポイントに送信された最後のメンバーシップクエリメッセージで提案されたクエリ間隔よりも長くなければなりません（MUST）。
Regardless of the timers used (IGMPv3/MLDv2 or endpoint), the Query_Response_Interval value SHOULD be greater than or equal to 10s to allow for packet loss and round-trip time in the Request/ Membership Query message exchange.
使用されるタイマー（IGMPv3 / MLDv2またはエンドポイント）に関係なく、Query_Response_Intervalの値は、リクエスト/メンバーシップクエリメッセージ交換でのパケット損失とラウンドトリップ時間を考慮して、10秒以上である必要があります（SHOULD）。
A relay may be configured with various service limits to ensure a minimum level of performance for gateways that connect to it.
リレーは、それに接続するゲートウェイのパフォーマンスの最小レベルを保証するために、さまざまなサービス制限で構成できます。
If a relay has determined that it has reached or exceeded maximum allowable capacity or has otherwise exhausted resources required to support additional gateways, it SHOULD withdraw any Relay Discovery Address Prefix it has advertised into the unicast internetwork and SHOULD set the L flag in any Membership Query messages it returns to gateways while in this state.
最大許容容量に達したか超えた、または追加のゲートウェイをサポートするために必要なリソースを使い果たしたとリレーが判断した場合、ユニキャストインターネットワークにアドバタイズしたリレー検出アドレスプレフィックスを取り除き、メンバーシップクエリでLフラグを設定する必要があります（SHOULD）。この状態のときにゲートウェイに戻るメッセージ。
If the relay receives an update from a gateway that adds group membership or forwarding state for an endpoint that has already reached maximum allowable state entries, the relay SHOULD continue to accept updates from the gateway but ignore any group membership/ forwarding state additions requested by that gateway.
リレーがゲートウェイから更新を受信すると、すでに最大許容状態エントリに達しているエンドポイントのグループメンバーシップまたは転送状態を追加します。リレーは、ゲートウェイからの更新を引き続き受け入れますが、それによって要求されたグループメンバーシップ/転送状態の追加を無視します（SHOULD）。ゲートウェイ。
If the relay receives an update from a gateway that would create a new tunnel endpoint for a source IP address that has already reached the maximum allowable number of endpoints (maximum UDP ports), it should simply ignore the Membership Update.
リレーがゲートウェイから更新を受信し、エンドポイントの最大許容数（最大UDPポート）に既に達している送信元IPアドレスの新しいトンネルエンドポイントを作成する場合は、メンバーシップ更新を単に無視する必要があります。
The following steps should be treated as an abstract description of the shutdown procedure for a relay:
次の手順は、リレーのシャットダウン手順の抽象的な説明として扱う必要があります。
o Withdraw the Relay Discovery Address Prefix advertisement (if used).
o リレー検出アドレスプレフィックスアドバタイズメントを撤回します（使用されている場合）。
o Stop listening for Relay Discovery messages.
o リレー検出メッセージの待機を停止します。
o Stop listening for control messages from gateways.
o ゲートウェイからの制御メッセージの待機を停止します。
o Stop sending data messages to gateways.
o ゲートウェイへのデータメッセージの送信を停止します。
o Delete all AMT group membership and forwarding state created on the relay, coordinating with the multicast routing protocol to update the group membership state on upstream interfaces as required.
o リレーで作成されたすべてのAMTグループメンバーシップと転送状態を削除し、マルチキャストルーティングプロトコルと連携して、必要に応じてアップストリームインターフェイスのグループメンバーシップ状態を更新します。
A Response MAC value is computed by the relay. A Response MAC computation is required in the following situations:
応答MAC値はリレーによって計算されます。以下の状況では、応答MAC計算が必要です。
o To generate a Response MAC value from a Request message for inclusion in a Membership Query message.
o メンバーシップクエリメッセージに含めるために、要求メッセージから応答MAC値を生成します。
o To generate a Response MAC value from a Membership Update message for use in authenticating the Response MAC carried within that message.
o メンバーシップ更新メッセージから応答MAC値を生成して、そのメッセージ内で伝達される応答MACの認証に使用します。
o To generate a Response MAC value from a Teardown message to authenticate the Response MAC carried within that message.
o To generate a Response MAC value from a Teardown message to authenticate the Response MAC carried within that message.
Gateways treat the Response MAC field as an opaque value, so a relay implementation may generate the MAC using any method available to it. The RECOMMENDED method for computing the Response MAC is to compute a cryptographically secure hash or keyed-hash digest from the following values:
ゲートウェイは応答MACフィールドを不透明な値として扱うため、リレー実装は、使用可能な任意の方法を使用してMACを生成できます。応答MACを計算するための推奨される方法は、次の値から暗号的に安全なハッシュまたはキー付きハッシュダイジェストを計算することです。
o The source IP address of the message (or Teardown Gateway IP Address field).
o メッセージの送信元IPアドレス（またはTeardown Gateway IP Addressフィールド）。
o The source UDP port of the message (or Teardown Gateway Port Number field).
o The source UDP port of the message (or Teardown Gateway Port Number field).
o The Request Nonce contained in the message.
o メッセージに含まれるリクエストナンス。
o A private secret or key known only to the relay.
o リレーだけが知っている秘密または秘密。
If the relay implementation uses a private secret (or key) to compute the Response MAC value, the relay SHOULD periodically compute a new private secret. The RECOMMENDED maximum interval is 2 hours. A relay MUST retain the prior secret for use in verifying MAC values that were sent to gateways just prior to the use of the new secret.
リレー実装がプライベートシークレット（またはキー）を使用して応答MAC値を計算する場合、リレーは新しいプライベートシークレットを定期的に計算する必要があります（SHOULD）。推奨される最大間隔は2時間です。リレーは、新しいシークレットを使用する直前にゲートウェイに送信されたMAC値の検証に使用するために、以前のシークレットを保持する必要があります。
AMT is not intended to be a strongly secure protocol. In general, the protocol provides the same level of security and robustness as is provided by the UDP, IGMP, and MLD protocols on which it relies. The lack of strong security features can be largely attributed to the desire to make the protocol lightweight by minimizing the state and computation required to service a single gateway, thereby allowing a relay to service a larger number of gateways.
AMTは、強力なセキュリティで保護されたプロトコルを意図したものではありません。一般的に、このプロトコルは、UDP、IGMP、およびMLDプロトコルが依存するのと同じレベルのセキュリティと堅牢性を提供します。強力なセキュリティ機能の欠如は、単一のゲートウェイにサービスを提供するために必要な状態と計算を最小限に抑え、それによりリレーがより多くのゲートウェイにサービスを提供できるようにすることでプロトコルを軽量にしたいという欲求に大きく起因します。
Many of the threats and vectors described in [RFC3552] may be employed against the protocol to launch various types of denial-of-service attacks that can affect the functioning of gateways or their ability to locate and communicate with a relay. These scenarios are described below.
[RFC3552]で説明されている脅威やベクターの多くは、プロトコルに対して使用され、ゲートウェイの機能や、リレーを見つけて通信する機能に影響を与える可能性のあるさまざまなタイプのサービス拒否攻撃を仕掛けます。これらのシナリオについて以下に説明します。
As is the case for UDP, IGMP, and MLD, the AMT protocol provides no mechanisms for ensuring message delivery or integrity. The protocol does not provide confidentiality -- multicast groups, sources, and streams requested by a gateway are sent in the clear.
UDP、IGMP、MLDの場合と同様に、AMTプロトコルはメッセージの配信または整合性を保証するメカニズムを提供しません。プロトコルは機密性を提供しません-ゲートウェイによって要求されたマルチキャストグループ、ソース、およびストリームは平文で送信されます。
The protocol does use a three-way handshake to provide trivial source authentication for state allocation and updates (see below). The protocol also requires gateways and relays to ignore malformed messages and those messages that do not carry expected address values, protocol payload types, or content.
このプロトコルは、3ウェイハンドシェイクを使用して、状態の割り当てと更新のための簡単なソース認証を提供します（以下を参照）。また、このプロトコルでは、ゲートウェイとリレーが、不正なメッセージと、予期されるアドレス値、プロトコルペイロードタイプ、またはコンテンツを含まないメッセージを無視することも必要です。
The three-way handshake provided by the membership update message sequence (see Section 4.2.1.2) provides a defense against source-spoofing-based resource-exhaustion attacks on a relay by requiring source authentication before state allocation. However, in an effort to consume computational resources, attackers may still attempt to flood a relay with Request and Membership Update messages to force the relay to make the MAC authentication computations. Implementations may choose to limit the frequency with which a relay responds to Request messages sent from a single IP address or IP address and UDP port pair, but support for this functionality is not required. The three-way handshake provides no defense against an eavesdropping or man-in-the-middle attacker.
メンバーシップ更新メッセージシーケンス（セクション4.2.1.2を参照）によって提供される3ウェイハンドシェイクは、状態割り当ての前にソース認証を要求することにより、リレーでのソーススプーフィングベースのリソース枯渇攻撃に対する防御を提供します。ただし、計算リソースを消費するために、攻撃者は依然として、リレーに強制的にMAC認証計算を行わせるために、要求およびメンバーシップ更新メッセージでリレーをフラッディングしようとする可能性があります。実装では、単一のIPアドレスまたはIPアドレスとUDPポートのペアから送信された要求メッセージにリレーが応答する頻度を制限することを選択できますが、この機能のサポートは必要ありません。 3ウェイハンドシェイクは、盗聴または中間者攻撃に対する防御を提供しません。
Attackers that execute the gateway protocol may consume relay resources by instantiating a large number of tunnels or joining a large number of multicast streams. A relay implementation should provide a mechanism for limiting the number of tunnels (Multicast Data message destinations) that can be created for a single gateway source address. Relays should also provide a means for limiting the number of joins per tunnel instance as a defense against these attacks.
ゲートウェイプロトコルを実行する攻撃者は、多数のトンネルをインスタンス化したり、多数のマルチキャストストリームに参加したりして、リレーリソースを消費する可能性があります。リレー実装は、単一のゲートウェイ送信元アドレスに対して作成できるトンネル（マルチキャストデータメッセージの宛先）の数を制限するメカニズムを提供する必要があります。リレーは、これらの攻撃に対する防御策として、トンネルインスタンスごとの結合数を制限する手段も提供する必要があります。
Relays may withdraw their AMT anycast prefix advertisement when they reach configured maximum capacity or exhaust required resources. This behavior allows gateways to use the relay discovery process to find the next topologically nearest relay that has advertised the prefix. This behavior also allows a successful resource-exhaustion attack to propagate from one relay to the next until all relays reachable using the anycast address have effectively been taken offline. This behavior may also be used to acquire the unicast addresses for individual relays that can then be used to launch a DDoS attack on all of the relays without using the relay discovery process. To prevent wider disruption of AMT-based distribution networks, relay anycast address advertisements can be limited to specific administrative routing domains. This will isolate such attacks to a single domain.
リレーは、設定された最大容量に達したとき、または必要なリソースを使い果たしたときに、AMTエニーキャストプレフィックスアドバタイズを取り消す場合があります。この動作により、ゲートウェイはリレー検出プロセスを使用して、プレフィックスをアドバタイズしたトポロジ的に最も近い次のリレーを見つけることができます。この動作により、エニーキャストアドレスを使用して到達可能なすべてのリレーが効果的にオフラインになるまで、リソース枯渇攻撃が1つのリレーから次のリレーに伝播することもできます。この動作は、個々のリレーのユニキャストアドレスを取得するためにも使用できます。これを使用して、リレー検出プロセスを使用せずにすべてのリレーに対してDDoS攻撃を開始できます。 AMTベースの配信ネットワークの広範な混乱を防ぐために、リレーエニーキャストアドレスアドバタイズメントを特定の管理ルーティングドメインに制限できます。これにより、このような攻撃が単一のドメインに隔離されます。
The Path and Tunnel MTU adjustment (discovery) procedure described in Section 5.3.3.6.1 is vulnerable to two denial-of-service attacks (see Section 8 of [RFC1191] for details). Both attacks are based on a malicious party sending forged ICMPv4 Destination Unreachable or ICMPv6 Packet Too Big messages to a host. In the first attack, the forged message indicates an inordinately small Path MTU. In the second attack, the forged message indicates an inordinately large Path MTU. In both cases, throughput is adversely affected. In order to mitigate such attacks, relay implementations MUST include a configuration option to disable Path MTU adjustments on AMT tunnels.
セクション5.3.3.6.1で説明されているパスとトンネルのMTU調整（検出）手順は、2つのサービス拒否攻撃に対して脆弱です（詳細については、[RFC1191]のセクション8をご覧ください）。どちらの攻撃も、偽造されたICMPv4 Destination UnreachableまたはICMPv6 Packet Too Bigメッセージをホストに送信する悪意のあるパーティに基づいています。最初の攻撃では、偽造されたメッセージが異常に小さいパスMTUを示しています。 2番目の攻撃では、偽造されたメッセージが異常に大きいパスMTUを示しています。どちらの場合も、スループットが低下します。このような攻撃を緩和するために、リレー実装には、AMTトンネルのパスMTU調整を無効にする構成オプションを含める必要があります。
A passive eavesdropper may launch a denial-of-service attack on a gateway by capturing a Membership Query or Membership Update message and using the Request Nonce and message authentication code carried by the captured message to send a spoofed Membership Update or Teardown message to the relay. The spoofed messages may be used to modify or destroy group membership state associated with the gateway, thereby changing or interrupting the multicast traffic flows.
パッシブ盗聴者は、Membership QueryまたはMembership Updateメッセージをキャプチャし、キャプチャされたメッセージに含まれるRequest Nonceおよびメッセージ認証コードを使用して、偽のMembership UpdateまたはTeardownメッセージをリレーに送信することにより、ゲートウェイにサービス拒否攻撃を仕掛けることがあります。 。スプーフィングされたメッセージを使用して、ゲートウェイに関連付けられたグループメンバーシップの状態を変更または破棄し、マルチキャストトラフィックフローを変更または中断することができます。
A passive eavesdropper may also spoof Multicast Data messages in an attempt to overload the gateway or to disrupt or supplant existing traffic flows. A properly implemented gateway will filter Multicast Data messages that do not originate from the expected Relay Address and should filter non-multicast packets and multicast IP packets whose group or source addresses are not included in the current reception state for the gateway pseudo-interface.
パッシブ盗聴者は、ゲートウェイに過負荷をかけたり、既存のトラフィックフローを妨害したり、取り替えたりする目的で、マルチキャストデータメッセージを偽装することもあります。適切に実装されたゲートウェイは、予想されるリレーアドレスから発信されていないマルチキャストデータメッセージをフィルタリングし、非マルチキャストパケットと、グループまたはソースアドレスがゲートウェイ疑似インターフェースの現在の受信状態に含まれていないマルチキャストIPパケットをフィルタリングする必要があります。
An active eavesdropper may launch a man-in-the-middle attack in which messages normally exchanged between a gateway and relay are intercepted, modified, spoofed, or discarded by the attacker. The attacker may deny access to, modify, or replace requested multicast traffic. The AMT protocol provides no means for detecting or defending against a man-in-the-middle attack -- any such functionality must be provided by multicast receiver applications through independent detection and validation of incoming multicast datagrams.
アクティブな盗聴者がman-in-the-middle攻撃を仕掛ける可能性があります。この攻撃では、通常、ゲートウェイとリレーの間で交換されるメッセージが、攻撃者によって傍受、変更、なりすまし、または破棄されます。攻撃者は、要求されたマルチキャストトラフィックへのアクセスを拒否、変更、または置き換える可能性があります。 AMTプロトコルは、man-in-the-middle攻撃を検出または防御する手段を提供しません。このような機能は、着信マルチキャストデータグラムの独立した検出と検証を通じて、マルチキャストレシーバーアプリケーションによって提供される必要があります。
The anycast discovery technique for finding relays (see Section 4.1.4) introduces a risk that a rogue router or a rogue Autonomous System (AS) could introduce a bogus route to a specific Relay Discovery Address Prefix and thus divert or absorb Relay Discovery messages sent by gateways. Network managers must guarantee the integrity of their routing to a particular Relay Discovery Address Prefix in much the same way that they guarantee the integrity of all other routes.
リレーを検出するためのエニーキャスト検出手法（セクション4.1.4を参照）は、不正なルーターまたは不正な自律システム（AS）が特定のリレー検出アドレスプレフィックスに偽のルートを導入し、送信されたリレー検出メッセージを迂回または吸収するリスクをもたらします。ゲートウェイによって。ネットワーク管理者は、他のすべてのルートの整合性を保証するのとほぼ同じ方法で、特定のリレー検出アドレスプレフィックスへのルーティングの整合性を保証する必要があります。
An attacker forging or modifying a Membership Query or Membership Update message may attempt to embed something other than an IGMP or MLD message within the encapsulated IP packet carried by these messages in an effort to introduce these into the recipient's IP stack. A properly implemented gateway or relay will ignore any such messages and may further choose to ignore Membership Query messages that do not contain IGMP/MLD General Query or Membership Update messages that do not contain IGMP/MLD membership reports.
An attacker forging or modifying a Membership Query or Membership Update message may attempt to embed something other than an IGMP or MLD message within the encapsulated IP packet carried by these messages in an effort to introduce these into the recipient's IP stack. A properly implemented gateway or relay will ignore any such messages and may further choose to ignore Membership Query messages that do not contain IGMP/MLD General Query or Membership Update messages that do not contain IGMP/MLD membership reports.
Properly implemented gateways and relays will also filter encapsulated IP packets that appear corrupted or truncated by verifying packet length and checksums.
適切に実装されたゲートウェイとリレーは、パケット長とチェックサムを確認することで、破損または切り詰められているように見えるカプセル化されたIPパケットもフィルタリングします。
The following unicast prefixes have been assigned to provide anycast routing of Relay Discovery messages to public AMT relays as described in Section 4.1.4. Address assignments within these prefixes are described in Section 4.1.5.2.
セクション4.1.4で説明されているように、リレー検出メッセージのパブリックAMTリレーへのエニーキャストルーティングを提供するために、次のユニキャストプレフィックスが割り当てられています。これらのプレフィックス内のアドレス割り当てについては、セクション4.1.5.2で説明しています。
IANA has assigned 192.52.193.0/24 from the "IANA IPv4 Special-Purpose Address Registry". The block has been registered as follows:
IANAは、「IANA IPv4 Special-Purpose Address Registry」から192.52.193.0/24を割り当てました。ブロックは次のように登録されています。
+----------------------+----------------+
| Attribute | Value |
+----------------------+----------------+
| Address Block |192.52.193.0/24 |
| Name | AMT |
| RFC | [RFC7450] |
| Allocation Date | 2014-12 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+----------------+
IANA has registered the following special-purpose address block for IPv6 anycast AMT relay discovery.
IANA has registered the following special-purpose address block for IPv6 anycast AMT relay discovery.
+----------------------+----------------+
| Attribute | Value |
+----------------------+----------------+
| Address Block | 2001:3::/32 |
| Name | AMT |
| RFC | [RFC7450] |
| Allocation Date | 2014-12 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+----------------+
The UDP port number 2268 has been reserved with IANA for use in the implementation and deployment of AMT. The protocol described by this document continues to use this port number according to the intent of the original request. IANA has updated the assignee, contact, and reference fields for this port number in accordance with this document.
The UDP port number 2268 has been reserved with IANA for use in the implementation and deployment of AMT. The protocol described by this document continues to use this port number according to the intent of the original request. IANA has updated the assignee, contact, and reference fields for this port number in accordance with this document.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002, <http://www.rfc-editor.org/info/rfc3376>.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、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, June 2004, <http://www.rfc-editor.org/info/rfc3810>.
[RFC3810]ビダ、R.、エド。、およびL.コスタ、エド。、 "IPv6のマルチキャストリスナ発見バージョン2（MLDv2の）"、RFC 3810、2004年6月、<http://www.rfc-editor.org / info / rfc3810>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6のアーキテクチャへの対応"、RFC 4291、2006年2月、<http://www.rfc-editor.org/info/rfc4291>。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006, <http://www.rfc-editor.org/info/rfc4607>.
[RFC4607] Holbrook、H.およびB. Cain、「Source-Specific Multicast for IP」、RFC 4607、2006年8月、<http://www.rfc-editor.org/info/rfc4607>。
[RFC4787] Audet, F., Ed., and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007, <http://www.rfc-editor.org/info/rfc4787>.
[RFC4787]オーデット、F。、エド、およびC.ジェニングス、「ユニキャストUDPのネットワークアドレス変換（NAT）動作要件」、BCP 127、RFC 4787、2007年1月、<http：//www.rfc-editor。 org / info / rfc4787>。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981, <http://www.rfc-editor.org/info/rfc0791>.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月、<http://www.rfc-editor.org/info/rfc0791>。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981, <http://www.rfc-editor.org/info/rfc0792>.
[RFC0792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月、<http://www.rfc-editor.org/info/rfc0792>。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989, <http://www.rfc-editor.org/info/rfc1112>.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月、<http://www.rfc-editor.org/info/rfc1112>。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990, <http://www.rfc-editor.org/info/rfc1191>.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU discovery」、RFC 1191、1990年11月、<http://www.rfc-editor.org/info/rfc1191>。
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993, <http://www.rfc-editor.org/info/rfc1546>.
[RFC1546] Partridge、C.、Mendez、T。、およびW. Milliken、「Host Anycasting Service」、RFC 1546、1993年11月、<http://www.rfc-editor.org/info/rfc1546>。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996, <http://www.rfc-editor.org/info/rfc1981>.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「Path MTU Discovery for IP version 6」、RFC 1981、1996年8月、<http://www.rfc-editor.org/info/rfc1981 >。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997, <http://www.rfc-editor.org/info/rfc2236>.
[RFC2236] Fenner、W。、「インターネットグループ管理プロトコル、バージョン2」、RFC 2236、1997年11月、<http://www.rfc-editor.org/info/rfc2236>。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999, <http://www.rfc-editor.org/info/rfc2663>.
[RFC2663] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス変換（NAT）の用語と考慮事項」、RFC 2663、1999年8月、<http://www.rfc-editor.org/info/rfc2663>。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999, <http://www.rfc-editor.org/info/rfc2710>.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999, <http://www.rfc-editor.org/info/rfc2710>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003, <http://www.rfc-editor.org/info/rfc3552>.
[RFC3552] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを作成するためのガイドライン」、BCP 72、RFC 3552、2003年7月、<http://www.rfc-editor.org/info/rfc3552>。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4271] Rekhter、Y。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月、<http：/ /www.rfc-editor.org/info/rfc4271>。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、編、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPv6）」、RFC 4443、2006年3月、<http： //www.rfc-editor.org/info/rfc4443>。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006, <http://www.rfc-editor.org/info/rfc4601>.
[RFC4601] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、「Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification（Revised）」、RFC 4601、2006年8月、< http://www.rfc-editor.org/info/rfc4601>。
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December 2006, <http://www.rfc-editor.org/info/rfc4786>.
[RFC4786] Abley、J。およびK. Lindqvist、「Operation of Anycast Services」、BCP 126、RFC 4786、2006年12月、<http://www.rfc-editor.org/info/rfc4786>。
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, April 2013, <http://www.rfc-editor.org/info/rfc6935>.
[RFC6935] Eubanks、M.、Chimento、P。、およびM. Westerlund、「トンネルパケットのIPv6およびUDPチェックサム」、RFC 6935、2013年4月、<http://www.rfc-editor.org/info/rfc6935 >。
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, April 2013, <http://www.rfc-editor.org/info/rfc6936>.
[RFC6936] Fairhurst、G。およびM. Westerlund、「ゼロチェックサムを使用したIPv6 UDPデータグラムの使用に関する適用性声明」、RFC 6936、2013年4月、<http://www.rfc-editor.org/info/rfc6936> 。
Acknowledgments
謝辞
The author would like to thank the following individuals for their suggestions, comments, and corrections:
著者は、以下の個人からの提案、コメント、および修正に感謝します。
Mark Altom Toerless Eckert Marshall Eubanks Gorry Fairhurst Dino Farinacci Lenny Giuliano Andy Huang Tom Imburgia Patricia McCrink Han Nguyen Doug Nortz Pekka Savola Robert Sayko Greg Shepherd Steve Simlo Mohit Talwar Lorenzo Vicisano Kurt Windisch John Zwiebel
マークアルトムテアレスエッカートマーシャルユーバンクスゴーリーフェアハーストディノファリナッチレニージュリアーノアンディフアントムインブルギアパトリシアマクリンクハングエンダグノーツペッカサヴォラロバートサイコグレッグシェパードスティーブシムロモヒトタルワールロレンツォヴィチサーノカートウィンディッシュジョンオニオン
The anycast discovery mechanism described in this document is based on similar work done by the NGTrans WG for obtaining automatic IPv6 connectivity without explicit tunnels ("6to4"). Tony Ballardie provided helpful discussion that inspired this document.
このドキュメントで説明されているエニーキャスト検出メカニズムは、明示的なトンネルなしの自動IPv6接続（ "6to4"）を取得するためにNGTrans WGが行った同様の作業に基づいています。 Tony Ballardieは、このドキュメントに影響を与えた有益なディスカッションを提供しました。
Juniper Networks was instrumental in funding several versions of this document as well as an open source implementation.
ジュニパーネットワークスは、このドキュメントのいくつかのバージョンだけでなく、オープンソースの実装への資金提供にも貢献しました。
Contributors
貢献者
The following people provided significant contributions to the design of the protocol and earlier versions of this specification:
以下の人々は、プロトコルの設計とこの仕様の以前のバージョンに多大な貢献をしました。
Amit Aggarwal Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 United States EMail: amitag@microsoft.com
Amit Aggarwalマイクロソフトコーポレーションワンマイクロソフトウェイレドモンド、ワシントン州98052-6399アメリカ合衆国メール：amitag@microsoft.com
Thomas Morin Orange 2, avenue Pierre Marzin Lannion 22300 France EMail: thomas.morin@orange.com
Thomas Morin Orange 2、avenue Pierre Marzin Lannion 22300 Franceメール：thomas.morin@orange.com
Dirk Ooms OneSparrow Robert Molsstraat 11; 2018 Antwerp Belgium EMail: dirk@onesparrow.com
Dirk Ooms OneSparrow Robert Molsstraat 11; 2018アントワープベルギーEメール：dirk@onesparrow.com
Tom Pusateri !j Wake Forest, NC United States EMail: pusateri@bangj.com
Tom Pusateri！Jウェイクフォレスト、ノースカロライナアメリカ合衆国メール：pusateri@bangj.com
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 United States EMail: dthaler@microsoft.com
Dave Thaler Microsoft Corporation One Microsoft Way Redmond、WA 98052-6399 United Statesメール：dthaler@microsoft.com
Author's Address
著者のアドレス
Gregory Bumgardner
グレゴリー・ブガードナー
Phone: +1 541 343 6790
EMail: gbumgard@gmail.com