[要約] RFC 8777は、DNS逆IP自動マルチキャストトンネリング（AMT）ディスカバリに関する仕様です。その目的は、AMTゲートウェイの自動検出と設定を可能にし、IPv4ネットワーク上でのAMTの展開を簡素化することです。
Internet Engineering Task Force (IETF) J. Holland
Request for Comments: 8777 Akamai Technologies, Inc.
Updates: 7450 April 2020
Category: Standards Track
ISSN: 2070-1721
DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery
DNSリバースIP自動マルチキャストトンネリング（AMT）検出
Abstract
概要
This document updates RFC 7450, "Automatic Multicast Tunneling" (or AMT), by modifying the relay discovery process. A new DNS resource record named AMTRELAY is defined for publishing AMT relays for source-specific multicast channels. The reverse IP DNS zone for a multicast sender's IP address is configured to use AMTRELAY resource records to advertise a set of AMT relays that can receive and forward multicast traffic from that sender over an AMT tunnel. Other extensions and clarifications to the relay discovery process are also defined.
このドキュメントは、リレー検出プロセスを変更することにより、RFC 7450「自動マルチキャストトンネリング」（またはAMT）を更新します。 AMTRELAYという名前の新しいDNSリソースレコードが、ソース固有のマルチキャストチャネルのAMTリレーを公開するために定義されています。マルチキャスト送信者のIPアドレスの逆IP DNSゾーンは、AMTRELAYリソースレコードを使用して、AMTトンネルを介してその送信者からマルチキャストトラフィックを受信および転送できる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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8777.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8777で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Background
1.2. Terminology
1.2.1. Relays and Gateways
1.2.2. Definitions
1.2.3. Requirements Language
2. Relay Discovery Overview
2.1. Basic Mechanics
2.2. Signaling and Discovery
2.3. Example Deployments
2.3.1. Example Receiving Networks
2.3.2. Example Sending Networks
3. Relay Discovery Operation
3.1. Optimal Relay Selection
3.1.1. Overview
3.1.2. Preference Ordering
3.1.3. Connecting to Multiple Relays
3.2. Happy Eyeballs
3.2.1. Overview
3.2.2. Algorithm Guidelines
3.2.3. Connection Definition
3.3. Guidelines for Restarting Discovery
3.3.1. Overview
3.3.2. Updates to Restarting Events
3.3.3. Tunnel Stability
3.3.4. Traffic Health
3.3.5. Relay Loaded or Shutting Down
3.3.6. Relay Discovery Messages vs. Restarting Discovery
3.3.7. Independent Discovery per Traffic Source
3.4. DNS Configuration
3.5. Waiting for DNS Resolution
4. AMTRELAY Resource Record Definition
4.1. AMTRELAY RRType
4.2. AMTRELAY RData Format
4.2.1. RData Format - Precedence
4.2.2. RData Format - Discovery Optional (D-bit)
4.2.3. RData Format - Type
4.2.4. RData Format - Relay
4.3. AMTRELAY Record Presentation Format
4.3.1. Representation of AMTRELAY RRs
4.3.2. Examples
5. IANA Considerations
6. Security Considerations
6.1. Use of AMT
6.2. Record-Spoofing
6.3. Congestion
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Unknown RRType Construction
Acknowledgements
Author's Address
This document defines DNS Reverse IP AMT Discovery (DRIAD), a mechanism for AMT gateways to discover AMT relays that are capable of forwarding multicast traffic from a known source IP address.
このドキュメントでは、DNS逆IP AMT検出（DRIAD）を定義します。これは、AMTゲートウェイが既知の送信元IPアドレスからマルチキャストトラフィックを転送できるAMTリレーを検出するためのメカニズムです。
AMT (Automatic Multicast Tunneling) is defined in [RFC7450] and provides a method to transport multicast traffic over a unicast tunnel in order to traverse network segments that are not multicast capable.
AMT（自動マルチキャストトンネリング）は[RFC7450]で定義されており、マルチキャストに対応していないネットワークセグメントを通過するために、ユニキャストトンネルを介してマルチキャストトラフィックを転送する方法を提供します。
Section 4.1.5 of [RFC7450] explains that the relay selection process for AMT is intended to be more flexible than the particular discovery method described in that document. That section further explains that the selection process might need to depend on the source of the multicast traffic in some deployments, since a relay must be able to receive multicast traffic from the desired source in order to forward it.
[RFC7450]のセクション4.1.5は、AMTのリレー選択プロセスが、そのドキュメントで説明されている特定の検出方法よりも柔軟であることを意図していることを説明しています。そのセクションでは、リレーが転送するために目的のソースからマルチキャストトラフィックを受信できる必要があるため、一部の展開では、選択プロセスがマルチキャストトラフィックのソースに依存する必要がある場合があることをさらに説明します。
Section 4.1.5 of [RFC7450] goes on to suggest DNS-based queries as a possible solution: DRIAD is DNS based. This solution also addresses the relay discovery issues in the "Disadvantages of this configuration" lists in Sections 3.3 and 3.4 of [RFC8313].
[RFC7450]のセクション4.1.5は、可能な解決策としてDNSベースのクエリを提案しています。DRIADはDNSベースです。このソリューションは、[RFC8313]のセクション3.3および3.4の「この構成の欠点」リストにあるリレー検出の問題にも対処します。
The goal for DRIAD is to enable multicast connectivity between separate multicast-enabled networks without preconfiguring any peering arrangements between the networks when neither the sending nor the receiving network is connected to a multicast-enabled backbone.
DRIADの目標は、送信ネットワークも受信ネットワークもマルチキャスト対応バックボーンに接続されていない場合、ネットワーク間のピアリング配置を事前に構成することなく、個別のマルチキャスト対応ネットワーク間のマルチキャスト接続を可能にすることです。
This document extends the relay discovery procedure described in Section 5.2.3.4 of [RFC7450].
このドキュメントは、[RFC7450]のセクション5.2.3.4で説明されているリレー検出手順を拡張したものです。
The reader is assumed to be familiar with the basic DNS concepts described in [RFC1034], [RFC1035], and the subsequent documents that update them, particularly [RFC2181].
読者は、[RFC1034]、[RFC1035]、およびそれらを更新する後続のドキュメント、特に[RFC2181]で説明されている基本的なDNSの概念に精通していることを前提としています。
The reader is also assumed to be familiar with the concepts and terminology regarding source-specific multicast as described in [RFC4607] and the use of Internet Group Management Protocol Version 3 (IGMPv3) [RFC3376] and Multicast Listener Discovery Version 2 (MLDv2) [RFC3810] for group management of source-specific multicast channels, as described in [RFC4604].
また、読者は、[RFC4607]で説明されているソース固有のマルチキャストの概念と用語、およびインターネットグループ管理プロトコルバージョン3（IGMPv3）[RFC3376]とマルチキャストリスナーディスカバリバージョン2（MLDv2）の使用に精通していることを前提としています。 [RFC4604]で説明されている、ソース固有のマルチキャストチャネルのグループ管理用のRFC3810]。
The reader should also be familiar with AMT, particularly the terminology listed in Sections 3.2 and 3.3 of [RFC7450].
読者は、AMT、特に[RFC7450]のセクション3.2および3.3にリストされている用語にも精通している必要があります。
When reading this document, it's especially helpful to recall that once an AMT tunnel is established, the relay receives native multicast traffic and sends unicast tunnel-encapsulated traffic to the gateway. The gateway receives the tunnel-encapsulated packets, decapsulates them, and forwards them as native multicast packets, as illustrated in Figure 1.
このドキュメントを読むとき、AMTトンネルが確立されると、リレーはネイティブマルチキャストトラフィックを受信し、ユニキャストトンネルカプセル化トラフィックをゲートウェイに送信することを思い出してください。図1に示すように、ゲートウェイはトンネルでカプセル化されたパケットを受信し、カプセル化を解除して、ネイティブマルチキャストパケットとして転送します。
Multicast +-----------+ Unicast +-------------+ Multicast
>---------> | AMT relay | >=======> | AMT gateway | >--------->
+-----------+ +-------------+
Figure 1: AMT Tunnel Illustration
図1：AMTトンネルの図
+------------+-------------------------------------------------+
| Term | Definition |
+============+=================================================+
| (S,G) | A source-specific multicast channel, as |
| | described in [RFC4607]. A pair of IP addresses |
| | with a source host IP and destination group IP. |
+------------+-------------------------------------------------+
| CMTS | Cable Modem Termination System |
+------------+-------------------------------------------------+
| discovery | A broker or load balancer for AMT relay |
| broker | discovery, as mentioned in Section 4.2.1.1 of |
| | [RFC7450]. |
+------------+-------------------------------------------------+
| downstream | Further from the source of traffic, as |
| | described in [RFC7450]. |
+------------+-------------------------------------------------+
| FQDN | Fully Qualified Domain Name, as described in |
| | [RFC8499]. |
+------------+-------------------------------------------------+
| gateway | An AMT gateway, as described in [RFC7450]. |
+------------+-------------------------------------------------+
| L flag | The "Limit" flag described in Section 5.1.4.4 |
| | of [RFC7450]. |
+------------+-------------------------------------------------+
| OLT | Optical Line Terminal |
+------------+-------------------------------------------------+
| relay | An AMT relay, as described in [RFC7450]. |
+------------+-------------------------------------------------+
| RPF | Reverse Path Forwarding, as described in |
| | [RFC5110]. |
+------------+-------------------------------------------------+
| RR | A DNS Resource Record, as described in |
| | [RFC1034]. |
+------------+-------------------------------------------------+
| RRType | A DNS Resource Record Type, as described in |
| | [RFC1034]. |
+------------+-------------------------------------------------+
| SSM | Source-specific multicast, as described in |
| | [RFC4607]. |
+------------+-------------------------------------------------+
| upstream | Closer to the source of traffic, as described |
| | in [RFC7450]. |
+------------+-------------------------------------------------+
Table 1: Definitions
表1：定義
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The AMTRELAY resource record (RR) defined in this document is used to publish the IP address or domain name of a set of AMT relays or discovery brokers that can receive, encapsulate, and forward multicast traffic from a particular sender.
このドキュメントで定義されているAMTRELAYリソースレコード（RR）は、特定の送信者からマルチキャストトラフィックを受信、カプセル化、および転送できる一連のAMTリレーまたは検出ブローカーのIPアドレスまたはドメイン名を公開するために使用されます。
The sender is the owner of the RR and configures the zone so that it contains a set of RRs that provide the addresses or domain names of AMT relays (or discovery brokers that advertise relays) that can receive multicast IP traffic from that sender.
送信者はRRの所有者であり、その送信者からマルチキャストIPトラフィックを受信できるAMTリレー（またはリレーをアドバタイズする検出ブローカー）のアドレスまたはドメイン名を提供する一連のRRが含まれるようにゾーンを構成します。
This enables AMT gateways in remote networks to discover an AMT relay that is capable of forwarding traffic from the sender. This, in turn, enables those AMT gateways to receive the multicast traffic tunneled over a unicast AMT tunnel from those relays and then pass the multicast packets into networks or applications that are using the gateway to subscribe to traffic from that sender.
これにより、リモートネットワークのAMTゲートウェイは、送信者からのトラフィックを転送できるAMTリレーを検出できます。これにより、これらのAMTゲートウェイは、ユニキャストAMTトンネルを介してトンネリングされたマルチキャストトラフィックをリレーから受信し、ゲートウェイを使用してその送信者からのトラフィックにサブスクライブするネットワークまたはアプリケーションにマルチキャストパケットを渡すことができます。
This mechanism only works for source-specific multicast (SSM) channels. The source address of the (S,G) is reversed and used as an index into one of the reverse mapping trees (in-addr.arpa for IPv4, as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, as described in Section 2.5 of [RFC3596]).
このメカニズムは、ソース固有のマルチキャスト（SSM）チャネルに対してのみ機能します。 （S、G）のソースアドレスは逆にされ、リバースマッピングツリーの1つへのインデックスとして使用されます（[RFC1035]のセクション3.5で説明されているIPv4の場合はindaddr.arpa、IPv6の場合はip6.arpa、 [RFC3596]のセクション2.5に記載されています）。
This mechanism should be treated as an extension of the AMT relay discovery procedure described in Section 5.2.3.4 of [RFC7450]. A gateway that supports this method of AMT relay discovery SHOULD use this method whenever it's performing the relay discovery procedure, the source IP addresses for desired (S,G)s are known to the gateway, and conditions match the requirements outlined in Section 3.1.
このメカニズムは、[RFC7450]のセクション5.2.3.4で説明されているAMTリレー検出手順の拡張として扱う必要があります。 AMTリレー検出のこのメソッドをサポートするゲートウェイは、リレー検出手順を実行している場合、このメソッドを使用する必要があります（SH。
Some detailed example use cases are provided in Section 2.3, and other applicable example topologies appear in Sections 3.3, 3.4, and 3.5 of [RFC8313].
いくつかの詳細な使用例はセクション2.3で提供され、他の適用可能なトポロジー例は[RFC8313]のセクション3.3、3.4、および3.5に記載されています。
This section describes a typical example of the end-to-end process for signaling a receiver's join of an SSM channel that relies on an AMTRELAY RR.
このセクションでは、AMTRELAY RRに依存するSSMチャネルの受信者の参加をシグナリングするエンドツーエンドプロセスの典型的な例について説明します。
The example in Figure 2 contains two multicast-enabled networks that are both connected to the internet with non-multicast-capable links and which have no direct association with each other.
図2の例には、マルチキャスト非対応のリンクでインターネットに接続され、互いに直接関連付けられていない、2つのマルチキャスト対応ネットワークが含まれています。
A content provider operates a sender, which is a source of multicast traffic inside a multicast-capable network.
コンテンツプロバイダーは、マルチキャスト対応ネットワーク内のマルチキャストトラフィックのソースである送信者を操作します。
An end user who is a customer of the content provider has a multicast-capable Internet Service Provider (ISP), which operates a receiving network that uses an AMT gateway. The AMT gateway is DRIAD capable.
コンテンツプロバイダーの顧客であるエンドユーザーは、AMTゲートウェイを使用する受信ネットワークを運用するマルチキャスト対応インターネットサービスプロバイダー（ISP）を持っています。 AMTゲートウェイはDRIAD対応です。
The content provider provides the user with a receiving application that tries to subscribe to at least one (S,G). This receiving application could, for example, be a file transfer system using File Delivery over Unidirectional Transport (FLUTE) [RFC6726], a live video stream using RTP [RFC3550], or any other application that might subscribe to an SSM channel.
コンテンツプロバイダーは、少なくとも1つの（S、G）にサブスクライブしようとする受信アプリケーションをユーザーに提供します。この受信アプリケーションは、たとえば、一方向トランスポート経由のファイル配信（FLUTE）[RFC6726]を使用したファイル転送システム、RTP [RFC3550]を使用したライブビデオストリーム、またはSSMチャネルにサブスクライブする可能性のあるその他のアプリケーションです。
+---------------+
| Sender |
| | | 2001:db8::a |
| | +---------------+
|Data| |
|Flow| Multicast |
\| |/ Network |
\ / | 5: Propagate RPF for Join(S,G)
\ / +---------------+
\/ | AMT relay |
| 2001:db8:c::f |
+---------------+
| 4: Gateway connects to Relay,
sends Join(S,G) over tunnel
|
Unicast
Tunnel | 3: --> DNS Query: type=AMTRELAY,
/ a.0.0.0.0.0.0.0.0.0.0.0.
^ | / 0.0.0.0.0.0.0.0.0.0.0.0.
| / 8.b.d.0.1.0.0.2.ip6.arpa
| | / <-- Response:
Join/Leave +-------------+ AMTRELAY=2001:db8:c::f
Signals | AMT gateway |
| +-------------+
| | 2: Propagate RPF for Join(S,G)
| Multicast |
Network |
| 1: Join(S=2001:db8::a,G=ff3e::8000:d)
+-------------+
| Receiver |
| (end user) |
+-------------+
Figure 2: DRIAD Messaging
図2：DRIADメッセージング
In this simple example, the sender IP is 2001:db8::a, which is sending traffic to the group address ff3e::8000:d, and the relay IP is 2001:db8::c:f.
この単純な例では、送信者IPは2001：db8 :: aで、トラフィックはグループアドレスff3e :: 8000：dに送信され、リレーIPは2001：db8 :: c：fです。
The content provider has previously configured the DNS zone that contains the reverse IP domain name for the sender's IP address so that it provides an AMTRELAY RR with the relay's IP address (see Section 4.3 for details about the AMTRELAY RR format and semantics). As described in Section 2.5 of [RFC3596], the reverse IP FQDN of the sender's address "2001:db8::a" is:
コンテンツプロバイダーは、リレーのIPアドレスをAMTRELAY RRに提供するように、送信者のIPアドレスの逆IPドメイン名を含むDNSゾーンを以前に構成しました（AMTRELAY RR形式とセマンティクスの詳細については、セクション4.3を参照してください）。 [RFC3596]のセクション2.5で説明されているように、送信者のアドレス「2001：db8 :: a」の逆IP FQDNは次のとおりです。
a.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6. arpa.
a.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6。ハープ。
The sequence of events depicted in Figure 2 is as follows:
図2に示すイベントのシーケンスは次のとおりです。
1. The end user starts the app, which issues a join to the (S,G): (2001:db8::a, ff3e::8000:d).
1. エンドユーザーが（S、G）への参加を発行するアプリを起動します：（2001：db8 :: a、ff3e :: 8000：d）。
2. The join propagates with RPF through the receiver's multicast-enabled network with PIM [RFC7761] or another multicast routing mechanism until the AMT gateway receives a signal to join the (S,G).
2. 参加は、AMTゲートウェイが（S、G）に参加する信号を受信するまで、PIM [RFC7761]または別のマルチキャストルーティングメカニズムを使用して、レシーバーのマルチキャスト対応ネットワークを介してRPFで伝播します。
3. The AMT gateway performs a reverse DNS lookup for the AMTRELAY RRType by sending an AMTRELAY RRType query for the reverse IP domain name for the sender's source IP address (the S from the (S,G)).
3. AMTゲートウェイは、送信者のソースIPアドレス（（S、G）からのS）の逆IPドメイン名のAMTRELAY RRTypeクエリを送信することにより、AMTRELAY RRTypeの逆DNSルックアップを実行します。
The DNS resolver for the AMT gateway uses ordinary DNS recursive resolution until it has the authoritative result that the content provider configured, which informs the AMT gateway that the relay address is 2001:db8::c:f.
AMTゲートウェイのDNSリゾルバーは、コンテンツプロバイダーが構成した信頼できる結果が得られるまで、通常のDNS再帰解決を使用し、リレーアドレスが2001：db8 :: c：fであることをAMTゲートウェイに通知します。
4. The AMT gateway performs AMT handshakes with the AMT relay as described in Section 4 of [RFC7450], then forwards a membership report to the relay, indicating subscription to the (S,G).
4. [RFC7450]のセクション4で説明されているように、AMTゲートウェイはAMTリレーでAMTハンドシェイクを実行し、（S、G）へのサブスクリプションを示すメンバーシップレポートをリレーに転送します。
5. The relay propagates the join through its network toward the sender and then forwards the appropriate AMT-encapsulated traffic to the gateway, which decapsulates and forwards it as a native multicast through its downstream network to the end user.
5. リレーは、ネットワークを介して結合を送信者に向けて伝播し、適切なAMTカプセル化トラフィックをゲートウェイに転送します。ゲートウェイは、カプセル化を解除し、それをネイティブマルチキャストとしてダウンストリームネットワーク経由でエンドユーザーに転送します。
In the case of an IPv4 (S,G), the only difference in the AMT relay discovery process is the use of the in-addr.arpa reverse IP domain name, as described in Section 3.5 of [RFC1035], instead of the in6.arpa domain name. For example, if the (S,G) is (198.51.100.12, 232.252.0.2), the reverse IP FQDN for the AMTRELAY query would be "12.100.51.198.in-addr.arpa.".
IPv4（S、G）の場合、AMTリレー検出プロセスの唯一の違いは、[RFC1035]のセクション3.5で説明されているように、in6ではなくin-addr.arpaリバースIPドメイン名を使用することです。 .arpaドメイン名。たとえば、（S、G）が（198.51.100.12、232.252.0.2）の場合、AMTRELAYクエリの逆IP FQDNは「12.100.51.198.in-addr.arpa。」になります。
Note that the address family of the AMT tunnel is independent of the address family for the multicast traffic.
AMTトンネルのアドレスファミリは、マルチキャストトラフィックのアドレスファミリから独立していることに注意してください。
One example of a receiving network is an Internet Service Provider (ISP) that offers multicast ingest services to its subscribers, illustrated in Figure 3.
受信ネットワークの一例は、図3に示すように、マルチキャストインジェストサービスを加入者に提供するインターネットサービスプロバイダー（ISP）です。
In the example network below, subscribers can join (S,G)s with MLDv2 or IGMPv3 as described in [RFC4604], and the AMT gateway in this ISP can receive and forward multicast traffic from one of the example sending networks in Section 2.3.2 by discovering the appropriate AMT relays with a DNS lookup for the AMTRELAY RR with the reverse IP of the source in the (S,G).
以下のネットワーク例では、加入者は[RFC4604]で説明されているようにMLDv2またはIGMPv3で（S、G）に参加でき、このISPのAMTゲートウェイはセクション2.3の送信ネットワーク例の1つからマルチキャストトラフィックを受信および転送できます。 2（S、G）のソースのリバースIPを使用してAMTRELAY RRのDNSルックアップで適切なAMTリレーを検出する。
Internet
^ ^ Multicast-enabled
| | Receiving Network
+------|------------|-------------------------+
| | | |
| +--------+ +--------+ +=========+ |
| | Border |---| Border | | AMT | |
| | Router | | Router | | gateway | |
| +--------+ +--------+ +=========+ |
| | | | |
| +-----+------+-----------+--+ |
| | | |
| +-------------+ +-------------+ |
| | Agg Routers | .. | Agg Routers | |
| +-------------+ +-------------+ |
| / \ \ / \ |
| +---------------+ +---------------+ |
| |Access Systems | ....... |Access Systems | |
| |(CMTS/OLT/etc.)| |(CMTS/OLT/etc.)| |
| +---------------+ +---------------+ |
| | | |
+--------|------------------------|-----------+
| |
+---+-+-+---+---+ +---+-+-+---+---+
| | | | | | | | | |
/-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\
|_| |_| |_| |_| |_| |_| |_| |_| |_| |_|
Subscribers
購読者
Figure 3: Receiving ISP Example
図3：ISPの受信例
Another example receiving network is a small branch office that regularly accesses some multicast content, illustrated in Figure 4.
受信ネットワークのもう1つの例は、図4に示すように、いくつかのマルチキャストコンテンツに定期的にアクセスする小さな支社です。
This office has desktop devices that need to receive some multicast traffic, so an AMT gateway runs on a LAN with these devices to pull traffic in through a non-multicast next hop.
このオフィスには、いくつかのマルチキャストトラフィックを受信する必要があるデスクトップデバイスがあるため、AMTゲートウェイはこれらのデバイスとLAN上で実行され、非マルチキャストネクストホップを介してトラフィックをプルします。
The office also hosts some mobile devices that have AMT gateway instances embedded inside apps in order to receive multicast traffic over their non-multicast wireless LAN. (Note that the "Legacy Router" is a simplification that's meant to describe a variety of possible conditions; for example, it could be a device providing a split-tunnel VPN as described in [RFC7359], deliberately excluding multicast traffic for a VPN tunnel, rather than a device that is incapable of multicast forwarding.)
また、オフィスは、非マルチキャストワイヤレスLAN経由でマルチキャストトラフィックを受信するために、アプリ内に埋め込まれたAMTゲートウェイインスタンスを持ついくつかのモバイルデバイスをホストしています。 （「レガシールータ」は、さまざまな可能な条件を説明するための簡略化であることに注意してください。たとえば、[RFC7359]で説明されているスプリットトンネルVPNを提供し、VPNトンネルのマルチキャストトラフィックを意図的に除外するデバイスである可能性があります、マルチキャスト転送に対応していないデバイスではありません）。
Internet
(non-multicast)
^
| Office Network
+----------|----------------------------------+
| | |
| +---------------+ (Wifi) Mobile apps |
| | Modem+ | Wifi | - - - - w/ embedded |
| | Router | AP | AMT gateways |
| +---------------+ |
| | |
| | |
| +----------------+ |
| | Legacy Router | |
| | (unicast) | |
| +----------------+ |
| / | \ |
| / | \ |
| +--------+ +--------+ +--------+=========+ |
| | Phones | | ConfRm | | Desks | AMT | |
| | subnet | | subnet | | subnet | gateway | |
| +--------+ +--------+ +--------+=========+ |
| |
+---------------------------------------------+
Figure 4: Small Office (No Multicast Up)
図4：小規模オフィス（マルチキャストなし）
By adding an AMT relay to this office network as in Figure 5, it's possible to make use of multicast services from the example multicast-capable ISP in Section 2.3.1.1.
図5のようにこのオフィスネットワークにAMTリレーを追加することで、セクション2.3.1.1のマルチキャスト対応ISPの例からのマルチキャストサービスを利用できます。
Multicast-capable ISP
^
| Office Network
+----------|----------------------------------+
| | |
| +---------------+ (Wifi) Mobile apps |
| | Modem+ | Wifi | - - - - w/ embedded |
| | Router | AP | AMT gateways |
| +---------------+ |
| | +=======+ |
| +---Wired LAN---| AMT | |
| | | relay | |
| +----------------+ +=======+ |
| | Legacy Router | |
| | (unicast) | |
| +----------------+ |
| / | \ |
| / | \ |
| +--------+ +--------+ +--------+=========+ |
| | Phones | | ConfRm | | Desks | AMT | |
| | subnet | | subnet | | subnet | gateway | |
| +--------+ +--------+ +--------+=========+ |
| |
+---------------------------------------------+
Figure 5: Small Office Example
図5：小規模オフィスの例
When multicast-capable networks are chained like this, with a network like the one in Figure 5 receiving Internet services from a multicast-capable network like the one in Figure 3, it's important for AMT gateways to reach the more local AMT relay in order to avoid accidentally tunneling multicast traffic from a more distant AMT relay with unicast and failing to utilize the multicast transport capabilities of the network in Figure 3.
マルチキャスト対応ネットワークがこのようにチェーン化されている場合、図5のようなネットワークが図3のようなマルチキャスト対応ネットワークからインターネットサービスを受信する場合、AMTゲートウェイがよりローカルなAMTリレーに到達することが重要です。図3のネットワークのマルチキャストトランスポート機能の利用に失敗したユニキャストを使用して、より遠くにあるAMTリレーからのマルチキャストトラフィックを誤ってトンネリングしないでください。
When a sender network is also operating AMT relays to distribute multicast traffic, as in Figure 6, each address could appear as an AMTRELAY RR for the reverse IP of the sender. Alternately, one or more domain names could appear in AMTRELAY RRs, and the AMT relay addresses can be discovered by finding A or AAAA records from those domain names.
図6に示すように、送信側ネットワークがマルチキャストトラフィックを配信するためにAMTリレーも動作している場合、各アドレスは送信側の逆IPのAMTRELAY RRとして表示される可能性があります。または、1つ以上のドメイン名がAMTRELAY RRに表示され、それらのドメイン名からAまたはAAAAレコードを検索することにより、AMTリレーアドレスを検出できます。
Sender Network
+-----------------------------------+
| |
| +--------+ +=======+ +=======+ |
| | Sender | | AMT | | AMT | |
| +--------+ | relay | | relay | |
| | +=======+ +=======+ |
| | | | |
| +-----+------+----------+ |
| | |
+-----------|-----------------------+
v
Internet
(non-multicast)
Figure 6: Small Office Example
図6：小規模オフィスの例
When an ISP offers a service to transmit outbound multicast traffic through a forwarding network, it might also offer AMT relays in order to reach receivers without multicast connectivity to the forwarding network, as in Figure 7. In this case, it's recommended that the ISP also provide at least one domain name for the AMT relays for use with the AMTRELAY RR.
ISPが転送ネットワークを介して送信マルチキャストトラフィックを送信するサービスを提供する場合、図7に示すように、転送ネットワークへのマルチキャスト接続なしで受信者に到達するためにAMTリレーも提供する場合があります。この場合、ISPも推奨するAMTRELAY RRで使用するAMTリレーに少なくとも1つのドメイン名を提供します。
When the sender wishes to use the relays provided by the ISP for forwarding multicast traffic, an AMTRELAY RR should be configured to use the domain name provided by the ISP to allow for address reassignment of the relays without forcing the sender to reconfigure the corresponding AMTRELAY RRs.
送信者がISPから提供されたリレーをマルチキャストトラフィックの転送に使用したい場合は、ISPから提供されたドメイン名を使用してAMTRELAY RRを構成し、送信者に対応するAMTRELAY RRを再構成させずに、リレーのアドレス再割り当てを許可する必要があります。 。
+--------+
| Sender |
+---+----+ Multicast-enabled
| Sending Network
+-----------|-------------------------------+
| v |
| +------------+ +=======+ +=======+ |
| | Agg Router | | AMT | | AMT | |
| +------------+ | relay | | relay | |
| | +=======+ +=======+ |
| | | | |
| +-----+------+--------+---------+ |
| | | |
| +--------+ +--------+ |
| | Border |---| Border | |
| | Router | | Router | |
| +--------+ +--------+ |
+-----|------------|------------------------+
| |
v v
Internet
(non-multicast)
Figure 7: Sending ISP Example
図7：ISPの送信例
The reverse source IP DNS query of an AMTRELAY RR is a good way for a gateway to discover a relay that is known to the sender.
AMTRELAY RRの逆ソースIP DNSクエリは、ゲートウェイが送信者に既知のリレーを発見するための良い方法です。
However, it is *not* necessarily a good way to discover the best relay for that gateway to use, because the RR will only provide information about relays known to the source.
ただし、RRは送信元に既知のリレーに関する情報しか提供しないため、そのゲートウェイが使用する最適なリレーを見つけるのに必ずしも良い方法とは限りません。
If there is an upstream relay in a network that is topologically closer to the gateway and is able to receive and forward multicast traffic from the sender, that relay is better for the gateway to use since more of the network path uses native multicast, allowing more chances for packet replication. But since that relay is not known to the sender, it won't be advertised in the sender's reverse IP DNS record. An example network that illustrates this scenario is outlined in Figure 5 from Section 2.3.1.2.
トポロジー的にゲートウェイに近いネットワークにアップストリームリレーがあり、送信者からマルチキャストトラフィックを受信および転送できる場合、より多くのネットワークパスがネイティブマルチキャストを使用するため、ゲートウェイはそのリレーを使用する方が適しています。パケット複製のチャンス。ただし、そのリレーは送信者に認識されていないため、送信者の逆IP DNSレコードではアドバタイズされません。このシナリオを示すネットワークの例は、セクション2.3.1.2の図5に概説されています。
It's only appropriate for an AMT gateway to discover an AMT relay by querying an AMTRELAY RR owned by a sender when all of these conditions are met:
これらの条件がすべて満たされた場合に、AMTゲートウェイが送信者が所有するAMTRELAY RRを照会することによってAMTリレーを検出することのみが適切です。
1. The gateway needs to propagate a join of an (S,G) over AMT because in the gateway's network, no RPF next hop toward the source can propagate a native multicast join of the (S,G);
1. ゲートウェイのネットワークでは、ソースへのRPFネクストホップが（S、G）のネイティブマルチキャスト結合を伝播できないため、ゲートウェイはAMTを介して（S、G）の結合を伝播する必要があります。
2. The gateway is not already connected to a relay that forwards multicast traffic from the source of the (S,G);
2. ゲートウェイは、（S、G）のソースからマルチキャストトラフィックを転送するリレーにまだ接続されていません。
3. The gateway is not configured to use a particular IP address for AMT discovery, or a relay discovered with that IP is not able to forward traffic from the source of the (S,G);
3. ゲートウェイがAMT検出に特定のIPアドレスを使用するように構成されていないか、そのIPで検出されたリレーが（S、G）のソースからトラフィックを転送できません。
4. The gateway is not able to find an upstream AMT relay with DNS-based Service Discovery (DNS-SD) [RFC6763] using "_amt._udp" as the Service section of the queries, or a relay discovered this way is not able to forward traffic from the source of the (S,G) (as described in Section 3.3.4.1 and 3.3.5); and
4. ゲートウェイは、クエリのサービスセクションとして "_amt._udp"を使用して、DNSベースのサービス検出（DNS-SD）[RFC6763]でアップストリームAMTリレーを見つけることができません。または、この方法で検出されたリレーは転送できません。 （S、G）のソースからのトラフィック（セクション3.3.4.1および3.3.5で説明）。そして
5. The gateway is not able to find an upstream AMT relay with the well-known anycast addresses from Section 7 of [RFC7450].
5. ゲートウェイは、[RFC7450]のセクション7の既知のエニーキャストアドレスを持つアップストリームAMTリレーを見つけることができません。
When all of the above conditions are met, the gateway has no path within its local network that can receive multicast traffic from the source IP of the (S,G).
上記の条件がすべて満たされた場合、ゲートウェイのローカルネットワーク内には、（S、G）のソースIPからマルチキャストトラフィックを受信できるパスがありません。
In this situation, the best way to find a relay that can forward the required traffic is to use information that comes from the operator of the sender. When the sender has configured an AMTRELAY RR, gateways can use the DRIAD mechanism defined in this document to discover the relay information provided by the sender.
この状況で、必要なトラフィックを転送できるリレーを見つける最善の方法は、送信者のオペレーターからの情報を使用することです。送信者がAMTRELAY RRを構成すると、ゲートウェイはこのドキュメントで定義されているDRIADメカニズムを使用して、送信者から提供されたリレー情報を検出できます。
Note that the above conditions are designed to prefer the use of a local AMT relay if one can be discovered. However, note also that the network upstream of the locally discovered relay would still need to receive traffic from the sender of the (S,G) in order to forward it. Therefore, unless the upstream network contains the sender or has a multicast-capable peering with a network that can forward traffic from the sender, the upstream network might still use AMT to ingest the traffic from a network that can receive traffic from the sender. If this is the case, the upstream AMT gateway could still rely on the AMTRELAY RR provided by the sender, even though the AMTRELAY RR is not directly used by gateways topologically closer to the receivers. For a concrete example of such a situation, consider the network in Figure 5 connected as one of the customers to the network in Figure 3.
上記の条件は、ローカルAMTリレーが検出された場合にそれを使用するように設計されていることに注意してください。ただし、ローカルで検出されたリレーの上流のネットワークは、（S、G）の送信者からトラフィックを受信して転送する必要があることにも注意してください。したがって、上流ネットワークに送信者が含まれているか、送信者からのトラフィックを転送できるネットワークとのマルチキャスト対応ピアリングがない限り、上流ネットワークは引き続きAMTを使用して、送信者からのトラフィックを受信できるネットワークからトラフィックを取り込むことができます。これが事実である場合、AMTRELAY RRがトポロジー的にレシーバーに近いゲートウェイによって直接使用されていなくても、アップストリームAMTゲートウェイは、センダーによって提供されるAMTRELAY RRに依拠する可能性があります。このような状況の具体的な例として、図3のネットワークに顧客の1つとして接続されている図5のネットワークを考えます。
This section defines a preference ordering for relay addresses during the relay discovery process. Gateways are encouraged to implement a Happy Eyeballs [RFC8305] algorithm to try candidate relays concurrently (see Section 3.2), but even gateways that do not implement a Happy Eyeballs algorithm SHOULD use this ordering, except as noted.
このセクションでは、リレー検出プロセス中のリレーアドレスの優先順位を定義します。ゲートウェイは、Happy Eyeballs [RFC8305]アルゴリズムを実装して候補リレーを同時に試行することをお勧めします（セクション3.2を参照）。ただし、注記がない限り、Happy Eyeballsアルゴリズムを実装していないゲートウェイでもこの順序を使用する必要があります。
When establishing an AMT tunnel to forward multicast data, it's very important for the discovery process to prioritize network topology considerations ahead of address selection considerations in order to gain the packet replication benefits from using multicast instead of unicast tunneling in the multicast-capable portions of the network path.
マルチキャストデータを転送するためのAMTトンネルを確立するときは、アドレス選択の考慮事項よりもネットワークトポロジの考慮事項を優先することが発見プロセスにとって非常に重要です。これにより、のマルチキャスト対応部分でユニキャストトンネリングではなくマルチキャストを使用することでパケットレプリケーションの利点を得ることができます。ネットワークパス。
The intent of the advice and requirements in this section is to describe how a gateway should make use of the concurrency provided by a Happy Eyeballs algorithm to reduce the join latency while still prioritizing network efficiency considerations over address selection considerations.
このセクションのアドバイスと要件の目的は、Happy Eyeballsアルゴリズムが提供する同時実行性をゲートウェイがどのように利用して、結合遅延を削減しながら、アドレス選択の考慮事項よりもネットワーク効率の考慮事項を優先するかを説明することです。
Section 4 of [RFC8305] requires a Happy Eyeballs algorithm to sort the addresses with the Destination Address Selection defined in Section 6 of [RFC6724], but for the above reasons, that requirement is superseded in the AMT discovery use case by the following considerations:
[RFC8305]のセクション4では、[RFC6724]のセクション6で定義された宛先アドレス選択を使用してアドレスをソートするためにHappy Eyeballsアルゴリズムが必要ですが、上記の理由により、その要件は次の考慮事項によってAMTディスカバリユースケースで置き換えられます。
* Prefer Local Relays
* ローカルリレーを優先
Figure 5 and Section 2.3.1.2 provide a motivating example to prefer DNS-SD [RFC6763] for discovery strictly ahead of using the AMTRELAY RR controlled by the sender for AMT discovery.
図5およびセクション2.3.1.2は、AMTディスカバリーのために送信側によって制御されるAMTRELAY RRを使用する前に、ディスカバリーにDNS-SD [RFC6763]を優先する動機付けの例を提供します。
For this reason, it's RECOMMENDED that AMT gateways by default perform service discovery using DNS Service Discovery (DNS-SD) [RFC6763] for _amt._udp.<domain> (with <domain> chosen as described in Section 11 of [RFC6763]) and use the AMT relays discovered that way in preference to AMT relays discoverable via the mechanism defined in this document (DRIAD).
このため、AMTゲートウェイは、デフォルトで_amt._udp。<domain>のDNSサービス検出（DNS-SD）[RFC6763]を使用してサービス検出を実行することをお勧めします（<domain>は[RFC6763]のセクション11で説明されているように選択されています）。このドキュメントで定義されているメカニズム（DRIAD）を介して検出可能なAMTリレーよりも、その方法で検出されたAMTリレーを使用します。
* Prefer Relays Managed by the Containing Network
* 包含ネットワークによって管理されるリレーを優先する
When no local relay is discoverable with DNS-SD, it still may be the case that a relay local to the receiver is operated by the network providing transit services to the receiver.
DNS-SDでローカルリレーが検出されない場合でも、レシーバーにローカルなリレーが、レシーバーにトランジットサービスを提供するネットワークによって運用されている可能性があります。
In this case, when the network cannot make the relay discoverable via DNS-SD, the network SHOULD use the well-known anycast addresses from Section 7 of [RFC7450] to route discovery traffic to the relay most appropriate to the receiver's gateway.
この場合、ネットワークがDNS-SD経由でリレーを検出できないようにする場合、ネットワークは[RFC7450]のセクション7の既知のエニーキャストアドレスを使用して、検出トラフィックを受信者のゲートウェイに最も適したリレーにルーティングする必要があります。
Accordingly, the gateway SHOULD by default discover a relay with the well-known AMT anycast addresses as the next-best option after DNS-SD when searching for a local relay.
したがって、ゲートウェイは、デフォルトで、ローカルリレーを検索するときにDNS-SDの次に最適なオプションとして、既知のAMTエニーキャストアドレスを使用してリレーを検出する必要があります。
* Let Sender Manage Relay Provisioning
* 送信者にリレープロビジョニングを管理させる
A related motivating example is provided by considering a sender whose traffic can be forwarded by relays in a sender-controlled network like Figure 6 in Section 2.3.2.1 and by relays in a provider-controlled network like Figure 7 in Section 2.3.2.2, with different cost and scalability profiles for the different options.
関連する動機付けの例は、セクション2.3.2.1の図6のような送信者制御ネットワークのリレーおよびセクション2.3.2.2の図7のようなプロバイダー制御ネットワークのリレーによってトラフィックを転送できる送信者を検討することによって提供されます。オプションごとに異なるコストとスケーラビリティプロファイル。
In this example about the sending-side network, the precedence field described in Section 4.2.1 is a critical method of control so that senders can provide the appropriate guidance to gateways during the discovery process in order to manage load and failover scenarios in a manner that operates well with the sender's provisioning strategy for horizontal scaling of AMT relays.
送信側ネットワークに関するこの例では、セクション4.2.1で説明されている優先順位フィールドが重要な制御方法であるため、送信者は、負荷とフェイルオーバーのシナリオをある方法で管理するために、検出プロセス中にゲートウェイに適切なガイダンスを提供できます。これは、AMTリレーの水平スケーリングのための送信側のプロビジョニング戦略とうまく連動します。
Therefore, after DNS-SD, the precedence from the RR MUST be used for sorting preference ahead of the Destination Address Selection ordering from Section 6 of [RFC6724] so that only relay IPs with the same precedence are directly compared according to the Destination Address Selection ordering.
そのため、DNS-SDの後、RRからの優先順位を使用して、[RFC6724]のセクション6からの宛先アドレス選択の順序よりも優先順位を並べ替え、同じ優先順位のリレーIPのみが宛先アドレス選択に従って直接比較されるようにする必要があります。注文。
Accordingly, AMT gateways SHOULD by default prefer relays in this order:
したがって、AMTゲートウェイはデフォルトで次の順序でリレーを優先する必要があります。
1. DNS-SD
1. DNS-SD
2. Anycast addresses from Section 7 of [RFC7450]
2. [RFC7450]のセクション7のエニーキャストアドレス
3. DRIAD
3. 番号
This default behavior MAY be overridden by administrative configuration where other behavior is more appropriate for the gateway within its network.
このデフォルトの動作は、他の動作がネットワーク内のゲートウェイにより適している管理構成によってオーバーライドされる場合があります。
Among relay addresses that have an equivalent preference as described above, a Happy Eyeballs algorithm for AMT SHOULD use the Destination Address Selection defined in Section 6 of [RFC6724].
上記と同等の優先度を持つリレーアドレスの中で、AMTのHappy Eyeballsアルゴリズムは、[RFC6724]のセクション6で定義されている宛先アドレス選択を使用する必要があります（SHOULD）。
Among relay addresses that still have an equivalent preference after the above orderings, a gateway SHOULD make a non-deterministic choice (such as a pseudorandom selection) for relay preference ordering in order to support load balancing by DNS configurations that provide many relay options.
上記の順序の後も同等の優先順位を持つリレーアドレスの中で、ゲートウェイは、多くの中継オプションを提供するDNS構成によるロードバランシングをサポートするために、リレー優先順位の順序に対して非決定的な選択（疑似ランダム選択など）を行う必要があります（SHOULD）。
The gateway MAY introduce a bias in the non-deterministic choice according to information that indicates expected benefits from selecting some relays in preference to others. Details about the structure and collection of this information are out of scope for this document but could, for example, be obtained by out-of-band methods or from a historical record about network topology, timing information, or the response to a probing mechanism. A gateway in possession of such information MAY use it to prefer topologically closer relays.
ゲートウェイは、一部のリレーを他のリレーよりも優先して選択することで期待される利点を示す情報に従って、非決定論的な選択にバイアスを導入する場合があります。この情報の構造と収集に関する詳細は、このドキュメントの範囲外ですが、たとえば、帯域外の方法によって、またはネットワークトポロジ、タイミング情報、または調査メカニズムへの応答に関する履歴レコードから取得できます。 。そのような情報を保持しているゲートウェイは、トポロジー的に近いリレーを優先するためにそれを使用してもよい（MAY）。
Within the above constraints, gateways MAY make use of other considerations from Section 4 of [RFC8305], such as the address family interleaving strategies, to produce a final ordering of candidate relay addresses.
上記の制約内で、ゲートウェイは、[RFC8305]のセクション4にある他の考慮事項（アドレスファミリインターリービング戦略など）を使用して、候補のリレーアドレスの最終的な順序を作成できます（MAY）。
Note also that certain relay addresses might be excluded from consideration by the hold-down timers described in Section 3.3.4.1 or 3.3.5. These relays constitute "unusable destinations" under Rule 1 of the Destination Address Selection and are also not part of the superseding considerations described above.
セクション3.3.4.1または3.3.5で説明されているホールドダウンタイマーによって、特定のリレーアドレスが考慮から除外される場合があることにも注意してください。これらのリレーは、宛先アドレス選択のルール1に基づく「使用できない宛先」を構成し、上記の優先される考慮事項の一部でもありません。
The discovery and connection process for the relay addresses in the above described ordering MAY operate in parallel, subject to delays prescribed by the Happy Eyeballs requirements described in Section 5 of [RFC8305] for successively launched concurrent connection attempts.
上記の順序でのリレーアドレスの検出と接続のプロセスは、[RFC8305]のセクション5で説明されているHappy Eyeballsの要件で規定されている遅延に従って、並行して動作する場合があります。
In some deployments, it may be useful for a gateway to connect to multiple upstream relays and subscribe to the same traffic in order to support an active/active failover model. A gateway SHOULD NOT be configured to do so without guaranteeing that adequate bandwidth is available.
一部の展開では、アクティブ/アクティブフェールオーバーモデルをサポートするために、ゲートウェイが複数のアップストリームリレーに接続し、同じトラフィックにサブスクライブすることが役立つ場合があります。ゲートウェイは、十分な帯域幅が利用可能であることを保証せずに、そのように構成するべきではありません。
A gateway configured to do this SHOULD still use the same preference-ordering logic from Section 3.1.2 for each connection. (Note that this ordering allows for overriding by explicit administrative configuration where required.)
これを行うように構成されたゲートウェイは、各接続に対してセクション3.1.2の同じ優先順位順序ロジックを使用する必要があります（SHOULD）。 （この順序付けにより、必要に応じて明示的な管理構成によるオーバーライドが可能になることに注意してください。）
Often, multiple choices of relay will exist for a gateway using DRIAD for relay discovery. Happy Eyeballs [RFC8305] provides a widely deployed and generalizable strategy for probing multiple possible connections in parallel. Therefore, it is RECOMMENDED that DRIAD-capable gateways implement a Happy Eyeballs algorithm to support fast discovery of the most preferred available relay by probing multiple relays concurrently.
多くの場合、リレーの検出にDRIADを使用するゲートウェイには、リレーの複数の選択肢が存在します。 Happy Eyeballs [RFC8305]は、複数の可能な接続を並行してプローブするための広く展開された一般化可能な戦略を提供します。したがって、DRIAD対応ゲートウェイがHappy Eyeballsアルゴリズムを実装して、複数のリレーを同時にプローブすることにより、最も優先される使用可能なリレーの高速検出をサポートすることをお勧めします。
The parallel discovery logic of a Happy Eyeballs algorithm serves to reduce join latency for the initial join of an SSM channel. This section and the preference ordering of relays defined in Section 3.1.2 together provide guidance on use of a Happy Eyeballs algorithm for the case of establishing AMT connections.
Happy Eyeballsアルゴリズムの並列ディスカバリロジックは、SSMチャネルの最初の参加の参加レイテンシを削減するのに役立ちます。このセクションとセクション3.1.2で定義されたリレーの優先順位は、AMT接続を確立する場合のHappy Eyeballsアルゴリズムの使用に関するガイダンスを提供します。
Note that according to the definition in Section 3.2.3 of this document, establishing the connection occurs before sending a membership report. As described in Section 5 of [RFC8305], only one of the successful connections will be used, and the others are all canceled or ignored. In the context of an AMT connection, this means the gateway will send the membership reports that subscribe to traffic only for the chosen connection after the Happy Eyeballs algorithm resolves.
このドキュメントのセクション3.2.3の定義に従って、メンバーシップレポートを送信する前に接続の確立が行われることに注意してください。 [RFC8305]のセクション5で説明されているように、成功した接続の1つだけが使用され、その他はすべてキャンセルされるか無視されます。 AMT接続のコンテキストでは、Happy Eyeballsアルゴリズムが解決された後、ゲートウェイは選択された接続のトラフィックのみをサブスクライブするメンバーシップレポートを送信します。
During the "Initiation of asynchronous DNS queries" phase described in Section 3 of [RFC8305], a gateway attempts to resolve the domain names listed in Section 3.1. This consists of resolving the SRV queries for DNS-SD domains for the AMT service, as well as the AMTRELAY query for the reverse IP domain defined in this document.
[RFC8305]のセクション3で説明されている「非同期DNSクエリの開始」フェーズ中に、ゲートウェイはセクション3.1に記載されているドメイン名を解決しようとします。これは、AMTサービスのDNS-SDドメインのSRVクエリの解決と、このドキュメントで定義されている逆IPドメインのAMTRELAYクエリの解決で構成されています。
Each of the SRV and AMTRELAY responses might contain:
SRV応答とAMTRELAY応答のそれぞれに、次のものが含まれる場合があります。
* one or more IP addresses (as with type 1 or type 2 AMTRELAY responses or when the SRV Additional Data section of the SRV response contains the address records for the target, as urged by [RFC2782]), or
* 1つ以上のIPアドレス（タイプ1またはタイプ2のAMTRELAY応答の場合、または[RFC2782]によって促された、SRV応答のSRV追加データセクションにターゲットのアドレスレコードが含まれている場合）、または
* only domain names (as with type 3 responses from Section 4.2.3 or an SRV response without an additional data section).
* ドメイン名のみ（セクション4.2.3からのタイプ3応答または追加のデータセクションなしのSRV応答と同様）。
When present, IP addresses in the initial response provide resolved destination address candidates for the "Sorting of resolved destination addresses" phase described in Section 4 of [RFC8305]), whereas domain names without IP addresses in the initial response result in another set of queries for AAAA and A records, whose responses provide the candidate resolved destination addresses.
存在する場合、初期応答のIPアドレスは、[RFC8305]のセクション4で説明されている「解決済み宛先アドレスのソート」フェーズの解決済み宛先アドレス候補を提供しますが、初期応答にIPアドレスのないドメイン名は、別の一連のクエリになりますAAAAおよびAレコードの場合、その応答は候補解決された宛先アドレスを提供します。
Since the SRV or AMTRELAY responses don't have a bound on the count of queries that might be generated aside from the bounds imposed by the DNS resolver, it's important for the gateway to provide a rate limit on the DNS queries. The DNS query functionality is expected to follow ordinary standards and best practices for DNS clients. A gateway MAY use an existing DNS client implementation that does so and MAY rely on that client's rate-limiting logic to avoid issuing excessive queries. Otherwise, a gateway MUST provide a rate limit for the DNS queries, and its default settings SHOULD NOT permit more than 10 queries for any 100-millisecond period (though this MAY be overridable by the administrative configuration).
SRVまたはAMTRELAY応答には、DNSリゾルバーによって課された境界以外に生成される可能性のあるクエリの数に対する制限がないため、ゲートウェイがDNSクエリにレート制限を提供することが重要です。 DNSクエリ機能は、DNSクライアントの通常の標準とベストプラクティスに従うことが期待されています。ゲートウェイは、そうする既存のDNSクライアント実装を使用してもよく（MAY）、過剰なクエリの発行を回避するためにそのクライアントのレート制限ロジックに依存してもよい（MAY）。それ以外の場合、ゲートウェイはDNSクエリのレート制限を提供する必要があり、そのデフォルト設定では、100ミリ秒の期間に10を超えるクエリを許可してはなりません（ただし、これは管理構成によってオーバーライドできます）。
As the resolved IP addresses arrive, the Happy Eyeballs algorithm sorts them according to the requirements and recommendations given in Section 3.1.2 and attempts connections with the corresponding relays under the algorithm restrictions and guidelines given in [RFC8305] for the "Establishment of one connection, which cancels all other attempts" phase. As described in Section 3 of [RFC8305], DNS resolution is treated as asynchronous, and connection initiation does not wait for lagging DNS responses.
解決されたIPアドレスが到着すると、ハッピーアイボールアルゴリズムは、セクション3.1.2で指定された要件と推奨事項に従ってそれらを並べ替え、[RFC8305]で指定されたアルゴリズムの制限とガイドラインに基づいて、対応するリレーとの接続を試みます。 、他のすべての試行をキャンセルします」フェーズ。 [RFC8305]のセクション3で説明されているように、DNS解決は非同期として扱われ、接続の開始は遅延DNS応答を待ちません。
Section 5 of [RFC8305] non-normatively describes a successful connection attempt as "generally when the TCP handshake completes".
[RFC8305]のセクション5は、正常な接続試行を「通常はTCPハンドシェイクが完了したとき」と非規範的に説明しています。
There is no normative definition of a connection in the AMT specification [RFC7450], and there is no TCP connection involved in an AMT tunnel.
AMT仕様[RFC7450]には、接続の規範的な定義はなく、AMTトンネルに含まれるTCP接続はありません。
However, the concept of an AMT connection in the context of a Happy Eyeballs algorithm is a useful one, and so this section provides the following normative definition:
ただし、Happy EyeballsアルゴリズムのコンテキストでのAMT接続の概念は有用なものであるため、このセクションでは次の規範的な定義を提供します。
* An AMT connection is established successfully when the gateway receives from a newly discovered relay a valid Membership Query message (Section 5.1.4 of [RFC7450]) that does not have the L flag set.
* ゲートウェイが新しく検出されたリレーから、Lフラグが設定されていない有効なメンバーシップクエリメッセージ（[RFC7450]のセクション5.1.4）を受信すると、AMT接続が正常に確立されます。
See Section 3.3.5 of this document for further information about the relevance of the L flag to the establishment of a Happy Eyeballs connection. See Section 3.3.4 for an overview of how to respond if the connection does not provide multicast connectivity to the source.
Happy Eyeballs接続の確立に対するLフラグの関連性の詳細については、このドキュメントのセクション3.3.5を参照してください。接続がソースへのマルチキャスト接続を提供しない場合の応答方法の概要については、セクション3.3.4を参照してください。
To "cancel" this kind of AMT connection for the Happy Eyeballs algorithm, a gateway that has not sent a membership report with a subscription would simply stop sending AMT packets for that connection. A gateway only sends a membership report to a connection it has chosen as the most preferred available connection.
Happy Eyeballsアルゴリズムのこの種のAMT接続を「キャンセル」するには、サブスクリプションのメンバーシップレポートを送信していないゲートウェイは、その接続のAMTパケットの送信を停止するだけです。ゲートウェイは、最も優先される使用可能な接続として選択した接続にのみメンバーシップレポートを送信します。
It's expected that gateways deployed in different environments will use a variety of heuristics to decide when it's appropriate to restart the relay discovery process in order to meet different performance goals (for example, to fulfill different kinds of service level agreements).
さまざまな環境に展開されたゲートウェイは、さまざまなヒューリスティックを使用して、さまざまなパフォーマンス目標を満たすために（たとえば、さまざまな種類のサービスレベル契約を満たすために）リレー検出プロセスを再開するのが適切である場合を判断することが期待されます。
In general, restarting the discovery process is always safe for the gateway and relay during any of the events listed in this section but may cause a disruption in the forwarded traffic if the discovery process results in choosing a different relay because this changes the RPF forwarding tree for the multicast traffic upstream of the gateway. This is likely to result in some dropped or duplicated packets from channels actively being tunneled from the old relay to the gateway.
一般に、このセクションにリストされているイベントのいずれかの間、ゲートウェイとリレーにとってディスカバリプロセスの再起動は常に安全ですが、RPFフォワーディングツリーが変更されるため、ディスカバリプロセスが別のリレーを選択した場合、転送されたトラフィックが中断する可能性があります。ゲートウェイの上流のマルチキャストトラフィック用。これにより、チャネルからの一部のドロップまたは複製されたパケットが古いリレーからゲートウェイにアクティブにトンネリングされる可能性があります。
The degree of impact on the traffic from choosing a different relay may depend on network conditions between the gateway and the new relay, as well as the network conditions and topology between the sender and the new relay, as this may cause the relay to propagate a new RPF join toward the sender.
別のリレーの選択がトラフィックに与える影響の程度は、ゲートウェイと新しいリレーの間のネットワーク状態、および送信者と新しいリレーの間のネットワーク状態によって異なります。これにより、リレーが送信者への新しいRPF参加。
Balancing the expected impact on the tunneled traffic against likely or observed problems with an existing connection to the relay is the goal of the heuristics that gateways use to determine when to restart the discovery process.
トンネルへの予想される影響と、リレーへの既存の接続で起こりそうな問題または観測された問題とのバランスをとることが、ゲートウェイが発見プロセスを再開するタイミングを決定するために使用するヒューリスティックの目標です。
The non-normative advice in this section should be treated as guidelines to operators and implementors working with AMT systems that can use DRIAD as part of the relay discovery process.
このセクションの非規範的アドバイスは、リレー検出プロセスの一部としてDRIADを使用できるAMTシステムを操作するオペレーターと実装者へのガイドラインとして扱う必要があります。
Section 5.2.3.4.1 of [RFC7450] lists several events that may cause a gateway to start or restart the discovery procedure.
[RFC7450]のセクション5.2.3.4.1は、ゲートウェイが検出手順を開始または再開する原因となるいくつかのイベントを示しています。
This document provides some updates and recommendations regarding the handling of these and similar events. The first five events are copied here and numbered for easier reference, and the remaining four events are newly added for consideration in this document:
このドキュメントでは、これらのイベントおよび類似のイベントの処理に関するいくつかの更新と推奨事項を提供します。最初の5つのイベントはここにコピーされ、参照しやすいように番号が付けられています。残りの4つのイベントは、このドキュメントでの検討のために新しく追加されています。
1. When a gateway pseudo-interface is started (enabled).
1. ゲートウェイ疑似インターフェースが開始された（有効にされた）とき。
2. When the gateway wishes to report a group subscription when none currently exists.
2. 現在何も存在しないときに、ゲートウェイがグループサブスクリプションを報告する場合。
3. Before sending the next Request message in a membership update cycle.
3. メンバーシップ更新サイクルで次のリクエストメッセージを送信する前。
4. After the gateway fails to receive a response to a Request message.
4. ゲートウェイが要求メッセージへの応答の受信に失敗した後。
5. After the gateway receives a Membership Query message with the L flag set to 1.
5. ゲートウェイがLフラグが1に設定されたMembership Queryメッセージを受信した後。
6. When the gateway wishes to report an (S,G) subscription with a source address that does not currently have other group subscriptions.
6. ゲートウェイが、現在他のグループサブスクリプションを持たないソースアドレスを持つ（S、G）サブスクリプションを報告する場合。
7. When there is a network change detected; for example, when a gateway is operating inside an end user device or application and the device joins a different network or when the domain portion of a DNS-SD domain name changes in response to a DHCP message or administrative configuration.
7. ネットワークの変更が検出された場合。たとえば、ゲートウェイがエンドユーザーのデバイスまたはアプリケーション内で動作しており、デバイスが別のネットワークに参加している場合や、DHCPメッセージまたは管理構成に応答してDNS-SDドメイン名のドメイン部分が変更された場合などです。
8. When substantial loss, persistent congestion, or network overload is detected in the stream of AMT packets from a relay.
8. リレーからのAMTパケットのストリームで実質的な損失、永続的な輻輳、またはネットワークの過負荷が検出された場合。
9. When the gateway has reported one or more (S,G) subscriptions but no traffic is received from the source for some timeout (see Section 3.3.4.1).
9. ゲートウェイが1つ以上の（S、G）サブスクリプションを報告したが、タイムアウトのためにソースからトラフィックを受信しなかった場合（セクション3.3.4.1を参照）。
This list is not exhaustive, nor are any of the listed events strictly required to always force a restart of the discovery process.
このリストは完全なものではなく、リストされたイベントのいずれも、検出プロセスを常に強制的に再起動するために厳密に必要なものではありません。
Note that during event #1, a gateway may use DNS-SD but does not have sufficient information to use DRIAD, since no source is known.
イベント＃1の間、ゲートウェイはDNS-SDを使用できますが、ソースが不明であるため、DRIADを使用するための十分な情報がないことに注意してください。
In general, subscribers to active traffic flows that are being forwarded by an AMT gateway are less likely to experience a degradation in service (for example, from missing or duplicated packets) when the gateway continues using the same relay as long as the relay is not overloaded and the network conditions remain stable.
一般に、AMTゲートウェイによって転送されているアクティブなトラフィックフローのサブスクライバーは、ゲートウェイがリレーを使用しない限り、ゲートウェイが同じリレーを使用し続けると、サービスの低下（パケットの欠落や重複など）を経験する可能性が低くなります。過負荷状態になり、ネットワーク状態は安定したままです。
Therefore, gateways SHOULD avoid performing a full restart of the discovery process during routine cases of event #3 (sending a new Request message), since it occurs frequently in normal operation.
したがって、ゲートウェイは通常の操作で頻繁に発生するため、イベント＃3（新しいリクエストメッセージの送信）のルーチンケースの間にディスカバリプロセスの完全な再起動を実行しないでください。
However, see Sections 3.3.4, 3.3.6, and 3.3.4.3 for more information about exceptional cases when it may be appropriate to use event #3.
ただし、イベント＃3を使用するのが適切な場合がある例外的なケースの詳細については、セクション3.3.4、3.3.6、および3.3.4.3を参照してください。
If a gateway indicates one or more (S,G) subscriptions in a Membership Update message but no traffic for any of the (S,G)s is received in a reasonable time, it's appropriate for the gateway to restart the discovery process.
ゲートウェイがメンバーシップ更新メッセージで1つ以上の（S、G）サブスクリプションを示しているが、どの（S、G）のトラフィックも妥当な時間内に受信されない場合、ゲートウェイが検出プロセスを再開するのが適切です。
If the gateway restarts the discovery process multiple times consecutively for this reason, the timeout period SHOULD be adjusted to provide a random exponential back-off.
この理由により、ゲートウェイが連続して複数回ディスカバリプロセスを再起動する場合、ランダムな指数バックオフを提供するようにタイムアウト期間を調整する必要があります（SHOULD）。
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 4 seconds and a RECOMMENDED maximum_timeout of 120 seconds (which is the recommended minimum NAT mapping timeout described in [RFC4787]).
RECOMMENDEDタイムアウトは、[initial_timeout、MIN（initial_timeout * 2 ^ retry_count、maximum_timeout）]の範囲のランダムな値であり、RECOMMENDED initial_timeoutは4秒、RECOMMENDED maximum_timeoutは120秒（推奨される最小NATマッピングタイムアウトです） [RFC4787]）。
Note that the recommended initial_timeout is larger than the initial timeout recommended in the similar algorithm from Section 5.2.3.4.3 of [RFC7450]. This is to provide time for RPF Join propagation in the sending network. Although the timeout values may be administratively adjusted to support performance requirements, operators are advised to consider the possibility of join propagation delays between the sender and the relay when choosing an appropriate timeout value.
推奨されるinitial_timeoutは、[RFC7450]のセクション5.2.3.4.3にある同様のアルゴリズムで推奨される初期タイムアウトよりも大きいことに注意してください。これは、送信ネットワークでのRPF結合の伝播に時間を提供するためです。タイムアウト値はパフォーマンス要件をサポートするために管理上調整される場合がありますが、適切なタイムアウト値を選択するときは、送信者とリレーの間の結合伝播遅延の可能性を考慮することをお勧めします。
Gateways restarting the discovery process because of an absence of traffic MUST use a hold-down timer that removes this relay from consideration during subsequent rounds of discovery while active. The hold-down SHOULD last for no less than 3 minutes and no more than 10 minutes.
トラフィックがないためにディスカバリプロセスを再起動するゲートウェイは、アクティブな間、以降のディスカバリーのラウンドでこのリレーを考慮から除外するホールドダウンタイマーを使用する必要があります。ホールドダウンは3分以上10分以下持続する必要があります。
In some gateway deployments, it is also feasible to monitor the health of traffic flows through the gateway -- for example, by detecting the rate of packet loss by communicating out of band with receivers or monitoring the packets of known protocols with sequence numbers. Where feasible, it's encouraged for gateways to use such traffic health information to trigger a restart of the discovery process during event #3 (before sending a new Request message).
一部のゲートウェイ配置では、ゲートウェイを通過するトラフィックフローの状態を監視することもできます。たとえば、受信機と帯域外で通信したり、シーケンス番号を使用して既知のプロトコルのパケットを監視したりすることにより、パケット損失率を検出します。可能であれば、ゲートウェイがそのようなトラフィックヘルス情報を使用して、イベント＃3の間に（新しいリクエストメッセージを送信する前に）検出プロセスの再起動をトリガーすることをお勧めします。
However, if a transient network event that affects the tunneled multicast stream -- as opposed to an event that affects the tunnel connection between the relay and gateway -- occurs, poor health detection could be triggered for many gateways simultaneously. In this situation, adding a random delay to avoid synchronized rediscovery by many gateways is recommended.
ただし、リレーとゲートウェイ間のトンネル接続に影響を与えるイベントではなく、トンネル化マルチキャストストリームに影響を与える一時的なネットワークイベントが発生した場合、多くのゲートウェイで正常性の検出が不十分になる可能性があります。この状況では、ランダムな遅延を追加して、多くのゲートウェイによる再検出の同期を回避することをお勧めします。
The span of the random portion of the delay should be no less than 10 seconds by default but may be administratively configured to support different performance requirements.
遅延のランダムな部分のスパンは、デフォルトで10秒以上にする必要がありますが、さまざまなパフォーマンス要件をサポートするように管理者が設定できます。
In most cases, a gateway actively receiving healthy traffic from a relay that has not indicated load with the L flag should prefer to remain connected to the same relay, as described in Section 3.3.3.
ほとんどの場合、Lフラグで負荷を示さないリレーから正常なトラフィックをアクティブに受信するゲートウェイは、セクション3.3.3で説明されているように、同じリレーに接続されたままにすることを好むはずです。
However, a relay that appears healthy but has been forwarding traffic for days or weeks may have an increased chance of becoming unstable. Gateways may benefit from restarting the discovery process during event #3 (before sending a Request message) after the expiration of a long-term timeout on the order of multiple hours or even days in some deployments.
ただし、正常に見えても数日または数週間トラフィックを転送しているリレーは、不安定になる可能性が高くなります。一部の展開では、数時間または数日程度の長期タイムアウトが満了した後、イベント＃3の間に（要求メッセージを送信する前に）検出プロセスを再開することで、ゲートウェイにメリットがもたらされる場合があります。
It may be beneficial for such timers to consider the amount of traffic currently being forwarded and to give a higher probability of restarting discovery during periods with an unusually low data rate to reduce the impact on active traffic while still avoiding relying on the results of a very old discovery.
このようなタイマーは、現在転送されているトラフィックの量を考慮し、非常に低いデータレートの期間中に検出を再開する可能性を高くして、アクティブトラフィックへの影響を減らしながら、非常に高い古い発見。
Other issues may also be worth considering as part of this heuristic; for example, if the DNS expiry time of the record that was used to discover the current relay has not passed, the long-term timer might be restarted without restarting the discovery process.
他の問題も、このヒューリスティックの一部として検討する価値があります。たとえば、現在のリレーを検出するために使用されたレコードのDNS有効期限が経過していない場合、検出プロセスを再起動せずに長期タイマーが再起動される可能性があります。
The L flag (see Section 5.1.4.4 of [RFC7450]) is the preferred mechanism for a relay to signal overloading or a graceful shutdown to gateways.
Lフラグ（[RFC7450]のセクション5.1.4.4を参照）は、リレーが過負荷または正常なシャットダウンをゲートウェイに通知するための推奨メカニズムです。
A gateway that supports handling of the L flag should generally restart the discovery process when it processes a Membership Query packet with the L flag set. If an L flag is received while a concurrent Happy Eyeballs discovery process is underway for multiple candidate relays (Section 3.2), the relay sending the L flag SHOULD NOT be considered for the relay selection.
Lフラグの処理をサポートするゲートウェイは、通常、Lフラグが設定されたメンバーシップクエリパケットを処理するときに、検出プロセスを再開する必要があります。複数の候補リレーの同時Happy Eyeballsディスカバリープロセスが進行中に（セクション3.2）Lフラグが受信された場合、Lフラグを送信するリレーは、リレー選択のために考慮されるべきではありません（SHOULD NOT）。
It is also RECOMMENDED that gateways avoid choosing a relay that has recently sent an L flag, with approximately a 10-minute hold-down. Gateways SHOULD treat this hold-down timer in the same way as the hold-down in Section 3.3.4.1 so that the relay is removed from consideration for subsequent short-term rounds of discovery.
また、ゲートウェイは、約10分のホールドダウンでLフラグを最近送信したリレーを選択しないことをお勧めします。ゲートウェイは、このホールドダウンタイマーをセクション3.3.4.1のホールドダウンと同じ方法で処理する必要があります（SHOULD）。これにより、後続の短期間のディスカバリーの考慮からリレーが削除されます。
All AMT relays are required by [RFC7450] to support handling of Relay Discovery messages (e.g., in Section 5.3.3.2 of [RFC7450]).
[RFC7450]では、リレー検出メッセージの処理をサポートするためにすべてのAMTリレーが必要です（たとえば、[RFC7450]のセクション5.3.3.2）。
So a gateway with an existing connection to a relay can send a Relay Discovery message to the unicast address of that AMT relay. Under stable conditions with an unloaded relay, it's expected that the relay will return its own unicast address in the Relay Advertisement in response to such a Relay Discovery message. Since this will not result in the gateway changing to another relay unless the relay directs the gateway away, this is a reasonable exception to the advice against handling event #3 described in Section 3.3.3.
したがって、リレーへの既存の接続を持つゲートウェイは、そのAMTリレーのユニキャストアドレスにリレー検出メッセージを送信できます。アンロードされたリレーの安定した状態では、リレーは、そのようなリレー検出メッセージに応答して、リレーアドバタイズメントで独自のユニキャストアドレスを返すことが期待されます。リレーがゲートウェイを離れるように指示しない限り、これによってゲートウェイが別のリレーに変更されることはないため、これは、セクション3.3.3で説明されているイベント＃3の処理に対するアドバイスの妥当な例外です。
This behavior is discouraged for gateways that do support the L flag to avoid sending unnecessary packets over the network.
この動作は、Lフラグをサポートしていないゲートウェイでは、ネットワーク経由で不要なパケットを送信しないようにすることをお勧めします。
However, gateways that do not support the L flag may be able to avoid a disruption in the forwarded traffic by sending such Relay Discovery messages regularly. When a relay is under load or has started a graceful shutdown, it may respond with a different relay address, which the gateway can use to connect to a different relay. This kind of coordinated handoff will likely result in a smaller disruption to the traffic than if the relay simply stops responding to Request messages and stops forwarding traffic.
ただし、Lフラグをサポートしないゲートウェイは、このようなリレー検出メッセージを定期的に送信することで、転送されたトラフィックの中断を回避できる場合があります。リレーに負荷がかかっているか、正常なシャットダウンが開始されている場合、リレーは別のリレーアドレスで応答する場合があり、ゲートウェイはこのアドレスを使用して別のリレーに接続できます。この種の協調ハンドオフにより、リレーが要求メッセージへの応答を停止してトラフィックの転送を停止する場合よりも、トラフィックの中断が少なくなる可能性があります。
This style of Relay Discovery message (one sent to the unicast address of a relay that's already forwarding traffic to this gateway) SHOULD NOT be considered a full restart of the relay discovery process. It is RECOMMENDED that gateways support the L flag, but for gateways that do not support the L flag, sending this message during event #3 may help mitigate service degradation when relays become unstable.
このスタイルのリレー検出メッセージ（すでにこのゲートウェイにトラフィックを転送しているリレーのユニキャストアドレスに送信されるメッセージ）は、リレー検出プロセスの完全な再起動と見なしてはなりません。ゲートウェイがLフラグをサポートすることをお勧めしますが、Lフラグをサポートしないゲートウェイでは、イベント＃3の間にこのメッセージを送信すると、リレーが不安定になったときにサービスの低下を軽減できる場合があります。
Relays discovered via the AMTRELAY RR are source-specific relay addresses and may use different pseudo-interfaces from each other and from relays discovered via DNS-SD or via a non-source-specific address, as described in Section 4.1.2.1 of [RFC7450].
[RFC7450のセクション4.1.2.1で説明されているように、AMTRELAY RRを介して検出されたリレーはソース固有のリレーアドレスであり、互いに、およびDNS-SDを介して、または非ソース固有のアドレスを介して検出されたリレーから、異なる擬似インターフェースを使用する場合があります。 ]。
Restarting the discovery process for one pseudo-interface does not require restarting the discovery process for other pseudo-interfaces. Gateway heuristics about restarting the discovery process should operate independently for different tunnels to relays when responding to events that are specific to the different tunnels.
1つの疑似インターフェースのディスカバリー・プロセスを再始動するために、他の疑似インターフェースのディスカバリー・プロセスを再始動する必要はありません。異なるトンネルに固有のイベントに応答する場合、検出プロセスの再開に関するゲートウェイのヒューリスティックは、異なるトンネルがリレーに独立して動作する必要があります。
Often, an AMT gateway will only have access to the source and group IP addresses of the desired traffic and will not know any other name for the source of the traffic. Because of this, typically, the best way of looking up AMTRELAY RRs will be by using the source IP address as an index into one of the reverse mapping trees (in-addr.arpa for IPv4, as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, as described in Section 2.5 of [RFC3596]).
多くの場合、AMTゲートウェイは、目的のトラフィックの送信元とグループのIPアドレスにのみアクセスでき、トラフィックの送信元の他の名前を知りません。このため、通常、AMTRELAY RRを検索する最良の方法は、[RFC1035]のセクション3.5で説明されているように、ソースIPアドレスをリバースマッピングツリーの1つへのインデックスとして使用することです（IPv4のin-addr.arpa。 、または[RFC3596]のセクション2.5で説明されているように、IPv6の場合はip6.arpa）。
Therefore, it is RECOMMENDED that AMTRELAY RRs be added to reverse IP zones as appropriate. AMTRELAY records MAY also appear in other zones, since this may be necessary to perform delegation from the reverse zones (see, for example, Section 5.2 of [RFC2317]), but the use case enabled by this document requires a reverse IP mapping for the source from an (S,G) in order to be useful to most AMT gateways. This document does not define semantics for the use of AMTRELAY records obtained in a way other than by a reverse IP lookup.
したがって、必要に応じてAMTRELAY RRをリバースIPゾーンに追加することをお勧めします。 AMTRELAYレコードは他のゾーンにも表示される場合があります。これは、逆ゾーンからの委任を実行するために必要になる場合があるためです（たとえば、[RFC2317]のセクション5.2を参照）。このドキュメントで有効にされているユースケースでは、ほとんどのAMTゲートウェイで役立つように、（S、G）からのソース。このドキュメントでは、逆IPルックアップ以外の方法で取得されたAMTRELAYレコードの使用に関するセマンティクスを定義していません。
When performing the AMTRELAY RR lookup, any CNAMEs or DNAMEs found MUST be followed. This is necessary to support zone delegation. Some examples outlining this need are described in [RFC2317].
AMTRELAY RRルックアップを実行するときは、見つかったCNAMEまたはDNAMEを追跡する必要があります。これは、ゾーンの委任をサポートするために必要です。この必要性を概説するいくつかの例は[RFC2317]で説明されています。
See Sections 4 and 4.3 for a detailed explanation of the contents of a DNS zone file.
DNSゾーンファイルの内容の詳細については、セクション4および4.3を参照してください。
DNS query functionality is expected to follow ordinary standards and best practices for DNS clients. A gateway MAY use an existing DNS client implementation that does so and MAY rely on that client's retry logic to determine the timeouts between retries.
DNSクエリ機能は、DNSクライアントの通常の標準とベストプラクティスに従うことが期待されています。ゲートウェイは、既存のDNSクライアント実装を使用してもよい（MAY）、そのクライアントの再試行ロジックに依存して、再試行間のタイムアウトを決定してもよい（MAY）。
Otherwise, a gateway MAY resend a DNS query if it does not receive an appropriate DNS response within some timeout period. If the gateway retries multiple times, the timeout period SHOULD be adjusted to provide a random exponential back-off.
それ以外の場合、ゲートウェイは、タイムアウト期間内に適切なDNS応答を受信しない場合、DNSクエリを再送信できます。ゲートウェイが複数回再試行する場合、ランダムな指数バックオフを提供するようにタイムアウト期間を調整する必要があります（SHOULD）。
As with the waiting process for the Relay Advertisement message from Section 5.2.3.4.3 of [RFC7450], 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.
[RFC7450]のセクション5.2.3.4.3のリレーアドバタイズメントメッセージの待機プロセスと同様に、RECOMMENDEDタイムアウトは、RECOMMENDEDを伴う[initial_timeout、MIN（initial_timeout * 2 ^ retry_count、maximum_timeout）]の範囲のランダムな値です。 initial_timeoutは1秒、RECOMMENDED maximum_timeoutは120秒。
The AMTRELAY RRType has the mnemonic AMTRELAY and type code 260 (decimal).
AMTRELAY RRTypeには、ニーモニックAMTRELAYとタイプコード260（10進数）があります。
The AMTRELAY RR is class independent.
AMTRELAY RRはクラスに依存しません。
The AMTRELAY RData consists of an 8-bit precedence field, a 1-bit "Discovery Optional" field, a 7-bit type field, and a variable length relay field.
AMTRELAY RDataは、8ビットの優先フィールド、1ビットの「Discovery Optional」フィールド、7ビットのタイプフィールド、および可変長リレーフィールドで構成されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| precedence |D| type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ relay ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is an 8-bit precedence for this record. It is interpreted in the same way as the PREFERENCE field described in Section 3.3.9 of [RFC1035].
これは、このレコードの8ビットの優先順位です。 [RFC1035]のセクション3.3.9で説明されているPREFERENCEフィールドと同じように解釈されます。
Relays listed in AMTRELAY records with a lower value for precedence are to be attempted first.
優先順位の値が小さいAMTRELAYレコードにリストされているリレーが最初に試行されます。
The D-bit is a "Discovery Optional" flag.
Dビットは「検出オプション」フラグです。
If the D-bit is set to 0, a gateway using this RR MUST perform AMT relay discovery as described in Section 4.2.1.1 of [RFC7450] rather than directly sending an AMT Request message to the relay.
Dビットが0に設定されている場合、このRRを使用するゲートウェイは、AMTリクエストメッセージをリレーに直接送信するのではなく、[RFC7450]のセクション4.2.1.1で説明されているようにAMTリレーディスカバリを実行する必要があります。
That is, the gateway MUST receive an AMT Relay Advertisement message (Section 5.1.2 of [RFC7450]) for an address before sending an AMT Request message (Section 5.1.3 of [RFC7450]) to that address. Before receiving the Relay Advertisement message, this record has only indicated that the address can be used for AMT relay discovery, not for a Request message. This is necessary for devices that are not fully functional AMT relays but rather load balancers or brokers, as mentioned in Section 4.2.1.1 of [RFC7450].
つまり、ゲートウェイは、そのアドレスにAMTリクエストメッセージ（[RFC7450]のセクション5.1.3）を送信する前に、そのアドレスのAMTリレーアドバタイズメントメッセージ（[RFC7450]のセクション5.1.2）を受信する必要があります。リレーアドバタイズメッセージを受信する前に、このレコードは、アドレスがリクエストメッセージではなく、AMTリレーディスカバリに使用できることのみを示しています。これは、[RFC7450]のセクション4.2.1.1で説明されているように、完全に機能するAMTリレーではなく、ロードバランサーまたはブローカーであるデバイスに必要です。
If the D-bit is set to 1, the gateway MAY send an AMT Request message directly to the discovered relay address without first sending an AMT Discovery message.
Dビットが1に設定されている場合、ゲートウェイは、最初にAMT検出メッセージを送信せずに、検出されたリレーアドレスに直接AMT要求メッセージを送信できます（MAY）。
This bit should be set according to advice from the AMT relay operator. The D-bit MUST be set to zero when no information is available from the AMT relay operator about its suitability.
このビットは、AMTリレーオペレーターからのアドバイスに従って設定する必要があります。 AMTリレーオペレーターからその適合性に関する情報が得られない場合、Dビットをゼロに設定する必要があります。
The type field indicates the format of the information that is stored in the relay field.
タイプフィールドは、リレーフィールドに格納される情報の形式を示します。
The following values are defined:
以下の値が定義されています。
* type = 0: The relay field is empty (0 bytes).
* type = 0：リレーフィールドは空です（0バイト）。
* type = 1: The relay field contains a 4-octet IPv4 address.
* タイプ= 1：リレーフィールドには4オクテットのIPv4アドレスが含まれます。
* type = 2: The relay field contains a 16-octet IPv6 address.
* type = 2：リレーフィールドには、16オクテットのIPv6アドレスが含まれます。
* type = 3: The relay field contains a wire-encoded domain name. The wire-encoded format is self-describing, so the length is implicit. The domain name MUST NOT be compressed (see Section 3.3 of [RFC1035] and Section 4 of [RFC3597]).
* type = 3：relayフィールドには、ワイヤーでエンコードされたドメイン名が含まれています。ワイヤーエンコード形式は自己記述型であるため、長さは暗黙的です。ドメイン名は圧縮してはなりません（[RFC1035]のセクション3.3および[RFC3597]のセクション4を参照）。
RRs with an undefined value in the Type field SHOULD NOT be considered by receiving gateways for AMT relay discovery.
Typeフィールドに未定義の値があるRRは、AMTリレー検出の受信ゲートウェイでは考慮されるべきではありません（SHOULD NOT）。
The relay field is the address or domain name of the AMT relay. It is formatted according to the type field.
リレーフィールドは、AMTリレーのアドレスまたはドメイン名です。タイプフィールドに従ってフォーマットされます。
When the type field is 0, the length of the relay field is 0, and it indicates that no AMT relay should be used for multicast traffic from this source.
タイプフィールドが0の場合、リレーフィールドの長さは0であり、このソースからのマルチキャストトラフィックにAMTリレーを使用しないことを示します。
When the type field is 1, the length of the relay field is 4 octets, and a 32-bit IPv4 address is present. This is an IPv4 address as described in Section 3.4.1 of [RFC1035]. This is a 32-bit number in network byte order.
タイプフィールドが1の場合、リレーフィールドの長さは4オクテットであり、32ビットのIPv4アドレスが存在します。これは、[RFC1035]のセクション3.4.1で説明されているIPv4アドレスです。これは、ネットワークバイト順の32ビットの数値です。
When the type field is 2, the length of the relay field is 16 octets, and a 128-bit IPv6 address is present. This is an IPv6 address as described in Section 2.2 of [RFC3596]. This is a 128-bit number in network byte order.
タイプフィールドが2の場合、リレーフィールドの長さは16オクテットで、128ビットのIPv6アドレスが存在します。これは[RFC3596]のセクション2.2で説明されているIPv6アドレスです。これは、ネットワークバイトオーダーの128ビットの数値です。
When the type field is 3, the relay field is a normal wire-encoded domain name, as described in Section 3.3 of [RFC1035]. For the reasons given in Section 4 of [RFC3597], compression MUST NOT be used.
タイプフィールドが3の場合、リレーフィールドは、[RFC1035]のセクション3.3で説明されているように、通常のワイヤーエンコードされたドメイン名です。 [RFC3597]のセクション4に記載されている理由により、圧縮を使用してはなりません。
For a type 3 record, the D-bit and preference fields carry over to all A or AAAA records for the domain name. There is no difference in the result of the discovery process when it's obtained by type 1 or type 2 AMTRELAY records with identical D-bit and preference fields vs. when the result is obtained by a type 3 AMTRELAY record that resolves to the same set of IPv4 and IPv6 addresses via A and AAAA lookups.
タイプ3レコードの場合、Dビットと設定フィールドは、ドメイン名のすべてのAまたはAAAAレコードに引き継がれます。タイプ1またはタイプ2のAMTRELAYレコードが同一のDビットと設定フィールドで取得された場合と、同じセットに解決されるタイプ3 AMTRELAYレコードで結果が取得された場合の検出プロセスの結果に違いはありません。 AおよびAAAAルックアップを介したIPv4およびIPv6アドレス。
AMTRELAY RRs may appear in a zone data master file. The precedence, D-bit, relay type, and relay fields are REQUIRED.
AMTRELAY RRは、ゾーンデータマスターファイルに表示される場合があります。優先順位、Dビット、リレータイプ、およびリレーフィールドが必要です。
If the relay type field is 0, the relay field MUST be ".".
リレータイプフィールドが0の場合、リレーフィールドは「。」でなければなりません。
The presentation for the record is as follows:
レコードのプレゼンテーションは次のとおりです。
IN AMTRELAY precedence D-bit type relay
IN AMTRELAY優先Dビットタイプリレー
In a DNS authoritative nameserver that understands the AMTRELAY type, the zone might contain a set of entries like this:
AMTRELAYタイプを理解するDNS権威ネームサーバーでは、ゾーンに次のようなエントリのセットが含まれる場合があります。
$ORIGIN 100.51.198.in-addr.arpa. 12 IN AMTRELAY 10 0 1 203.0.113.15 12 IN AMTRELAY 10 0 2 2001:db8::15 12 IN AMTRELAY 128 1 3 amtrelays.example.com.
$ ORIGIN 100.51.198.in-addr.arpa。 12 IN AMTRELAY 10 0 1 203.0.113.15 12 IN AMTRELAY 10 0 2 2001：db8 :: 15 12 IN AMTRELAY 128 1 3 amtrelays.example.com。
This configuration advertises an IPv4 discovery address, an IPv6 discovery address, and a domain name for AMT relays that can receive traffic from the source 198.51.100.12. The IPv4 and IPv6 addresses are configured with a D-bit of 0 (meaning discovery is mandatory, as described in Section 4.2.2) and a precedence 10 (meaning they're preferred ahead of the last entry, which has precedence 128).
この構成は、ソース198.51.100.12からトラフィックを受信できるAMTリレーのIPv4検出アドレス、IPv6検出アドレス、およびドメイン名をアドバタイズします。 IPv4およびIPv6アドレスは、Dビット0（4.2.2で説明されているように、検出が必須であることを意味します）および優先順位10（128の優先順位を持つ最後のエントリよりも優先されることを意味します）で構成されます。
For zone files in name servers that don't support the AMTRELAY RRType natively, it's possible to use the format for unknown RR types, as described in [RFC3597]. This approach would replace the AMTRELAY entries in the example above with the entries below:
AMTRELAY RRTypeをネイティブにサポートしていないネームサーバーのゾーンファイルの場合、[RFC3597]で説明されているように、不明なRRタイプの形式を使用することが可能です。このアプローチは、上記の例のAMTRELAYエントリを以下のエントリに置き換えます。
10 IN TYPE260 \# (
6 ; length
0a ; precedence=10
01 ; D=0, relay type=1, an IPv4 address
cb00710f ) ; 203.0.113.15
10 IN TYPE260 \# (
18 ; length
0a ; precedence=10
02 ; D=0, relay type=2, an IPv6 address
20010db800000000000000000000000f ) ; 2001:db8::15
10 IN TYPE260 \# (
24 ; length
80 ; precedence=128
83 ; D=1, relay type=3, a wire-encoded domain name
09616d7472656c617973076578616d706c6503636f6d ) ; domain name
See Appendix A for more details.
詳細については、付録Aを参照してください。
This document updates the DNS "Resource Record (RR) TYPEs" registry by assigning type 260 to the AMTRELAY record.
このドキュメントでは、AMTRELAYレコードにタイプ260を割り当てることにより、DNSの「リソースレコード（RR）タイプ」レジストリを更新します。
This document creates a new registry named "AMTRELAY Resource Record Parameters" with a subregistry for the "Relay Type Field". The initial values in the subregistry are:
このドキュメントでは、「リレータイプフィールド」のサブレジストリを持つ「AMTRELAYリソースレコードパラメータ」という名前の新しいレジストリを作成します。サブレジストリの初期値は次のとおりです。
+-------+---------------------------------------+
| Value | Description |
+=======+=======================================+
| 0 | No relay is present |
+-------+---------------------------------------+
| 1 | A 4-byte IPv4 address is present |
+-------+---------------------------------------+
| 2 | A 16-byte IPv6 address is present |
+-------+---------------------------------------+
| 3 | A wire-encoded domain name is present |
+-------+---------------------------------------+
| 4-255 | Unassigned |
+-------+---------------------------------------+
Table 2: Initial Contents of the "Relay Type Field" Registry
表2：「リレータイプフィールド」レジストリの初期内容
Values 0, 1, 2, and 3 are further explained in Sections 4.2.3 and 4.2.4. Relay type numbers 4 through 255 can be assigned with a policy of Specification Required (as described in [RFC8126]).
値0、1、2、および3については、セクション4.2.3および4.2.4でさらに説明します。リレータイプ番号4〜255は、[RFC8126]で説明されているように、Specification Requiredのポリシーで割り当てることができます。
This document defines a mechanism that enables a more widespread and automated use of AMT, even without access to a multicast backbone. Operators of networks and applications that include a DRIAD-capable AMT gateway are advised to carefully consider the security considerations in Section 6 of [RFC7450].
このドキュメントでは、マルチキャストバックボーンにアクセスしなくても、AMTをより広く自動化して使用できるようにするメカニズムを定義しています。 DRIAD対応のAMTゲートウェイを含むネットワークおよびアプリケーションの運営者は、[RFC7450]のセクション6のセキュリティに関する考慮事項を慎重に検討することをお勧めします。
AMT gateway operators also are encouraged to take appropriate steps to ensure the integrity of the data received via AMT, for example, by the opportunistic use of IPsec [RFC4301] to secure traffic received from AMT relays when IPSECKEY records [RFC4025] are available or when a trust relationship with the AMT relays can be otherwise established and secured.
AMTゲートウェイオペレーターは、IPseckeyレコード[RFC4025]が利用可能な場合、またはIPSecKEYレコード[RFC4025]が利用可能な場合、AMTリレーから受信したトラフィックを保護するIPsec [RFC4301]の日和見的な使用など、AMTを介して受信したデータの整合性を確保するために適切な手順を実行することも推奨されます。 AMTリレーとの信頼関係は、他の方法で確立および保護できます。
Note that AMT does not itself provide any integrity protection for Multicast Data packets (Section 5.1.6 of [RFC7450]), so absent protections like those mentioned above, even an off-path attacker who discovers the gateway IP, the relay IP, and the relay source port for an active AMT connection can inject multicast data packets for a joined (S,G) into the data stream if he can get data packets delivered to the gateway IP that spoof the relay as the source.
AMT自体はマルチキャストデータパケットの整合性保護を提供しないことに注意してください（[RFC7450]のセクション5.1.6）。そのため、上記のような保護が存在しないため、ゲートウェイIP、リレーIP、およびアクティブなAMT接続のリレー送信元ポートは、リレーを送信元として偽装しているゲートウェイIPにデータパケットを配信できる場合、結合された（S、G）のマルチキャストデータパケットをデータストリームに挿入できます。
The AMTRELAY resource record contains information that SHOULD be communicated to the DNS client without being modified. The method used to ensure the result was unmodified is up to the client.
AMTRELAYリソースレコードには、変更せずにDNSクライアントに通信する必要がある情報が含まれています。結果が変更されていないことを確認するために使用される方法は、クライアント次第です。
There must be a trust relationship between the end consumer of this resource record and the DNS server. This relationship may be end-to-end DNSSEC validation or a secure connection to a trusted DNS server that provides end-to-end safety to prevent record-spoofing of the response from the trusted server. The connection to the trusted server can use any secure channel, such as with a TSIG [RFC2845] or SIG(0) [RFC2931] channel, a secure local channel on the host, DNS over TLS [RFC7858], DNS over HTTPS [RFC8484], or some other mechanism that provides authentication of the RR.
このリソースレコードのエンドコンシューマとDNSサーバーの間には信頼関係が必要です。この関係は、エンドツーエンドのDNSSEC検証、またはエンドツーエンドの安全性を提供して信頼されたサーバーからの応答のなりすましを防ぐ信頼されたDNSサーバーへの安全な接続である場合があります。信頼されたサーバーへの接続では、TSIG [RFC2845]またはSIG（0）[RFC2931]チャネル、ホスト上の安全なローカルチャネル、DNS over TLS [RFC7858]、DNS over HTTPS [RFC8484などの安全なチャネルを使用できます。 ]、またはRRの認証を提供するその他のメカニズム。
If an AMT gateway accepts a maliciously crafted AMTRELAY record, the result could be a Denial of Service or receivers processing multicast traffic from a source under the attacker's control.
AMTゲートウェイが悪意を持って作成されたAMTRELAYレコードを受け入れると、結果としてサービス拒否や、攻撃者の制御下にあるソースからのマルチキャストトラフィックを受信者が処理する可能性があります。
Multicast traffic, particularly interdomain multicast traffic, carries some congestion risks, as described in Section 4 of [RFC8085].
[RFC8085]のセクション4で説明されているように、マルチキャストトラフィック、特にドメイン間マルチキャストトラフィックは、いくつかの輻輳リスクを伴います。
Application implementors and network operators that use AMT gateways are advised to take precautions, including monitoring of application traffic behavior, traffic authentication at ingest, rate-limiting of multicast traffic, and the use of circuit-breaker techniques such as those described in Section 3.1.10 of [RFC8085] and similar protections at the network level in order to ensure network health in the event of misconfiguration, poorly written applications that don't follow UDP congestion control principles, or a deliberate attack.
AMTゲートウェイを使用するアプリケーションの実装者とネットワークオペレーターは、アプリケーショントラフィックの動作の監視、取り込み時のトラフィック認証、マルチキャストトラフィックのレート制限、セクション3.1で説明されているような回路ブレーカー技術の使用などの予防策を講じることをお勧めします。 [RFC8085]の10およびネットワークレベルでの同様の保護により、設定ミス、UDP輻輳制御の原則に従わない不適切に記述されたアプリケーション、または意図的な攻撃が発生した場合にネットワークの正常性を確保します。
Section 4.1.4.2 of [RFC7450] and Section 6.1 of [RFC7450] provide some further considerations and advice about mitigating congestion risk.
[RFC7450]のセクション4.1.4.2および[RFC7450]のセクション6.1は、輻輳リスクの軽減に関するいくつかの追加の考慮事項とアドバイスを提供します。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<https://www.rfc-editor.org/info/rfc1034>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<https://www.rfc-editor.org/info/rfc1035>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <https://www.rfc-editor.org/info/rfc2181>.
[RFC2181] Elz、R。およびR. Bush、「Clarifications to the DNS Specification」、RFC 2181、DOI 10.17487 / RFC2181、1997年7月、<https://www.rfc-editor.org/info/rfc2181>。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc2782>.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、DOI 10.17487 / RFC2782、2000年2月、<https：// www.rfc-editor.org/info/rfc2782>。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, <https://www.rfc-editor.org/info/rfc3376>.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、DOI 10.17487 / RFC3376、2002年10月、< https://www.rfc-editor.org/info/rfc3376>。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", STD 88, RFC 3596, DOI 10.17487/RFC3596, October 2003, <https://www.rfc-editor.org/info/rfc3596>.
[RFC3596] Thomson、S.、Huitema、C.、Ksinant、V。、およびM. Souissi、「IPバージョン6をサポートするDNS拡張機能」、STD 88、RFC 3596、DOI 10.17487 / RFC3596、2003年10月、<https： //www.rfc-editor.org/info/rfc3596>。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 2003, <https://www.rfc-editor.org/info/rfc3597>.
[RFC3597] Gustafsson、A。、「Handling of Unknown DNS Resource Record（RR）Types」、RFC 3597、DOI 10.17487 / RFC3597、2003年9月、<https://www.rfc-editor.org/info/rfc3597>。
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <https://www.rfc-editor.org/info/rfc3810>.
[RFC3810] Vida、R.、Ed。 L.コスタ編、「IPv6のマルチキャストリスナーディスカバリバージョン2（MLDv2）」、RFC 3810、DOI 10.17487 / RFC3810、2004年6月、<https://www.rfc-editor.org/info/rfc3810>。
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, August 2006, <https://www.rfc-editor.org/info/rfc4604>.
[RFC4604] Holbrook、H.、Cain、B。、およびB. Haberman、「Source-Specific MulticastでのInternet Group Management Protocolバージョン3（IGMPv3）およびMulticast Listener Discovery Protocolバージョン2（MLDv2）の使用」、RFC 4604、DOI 10.17487 / RFC4604、2006年8月、<https://www.rfc-editor.org/info/rfc4604>。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, <https://www.rfc-editor.org/info/rfc4607>.
[RFC4607] Holbrook、H.およびB. Cain、「Source-Specific Multicast for IP」、RFC 4607、DOI 10.17487 / RFC4607、2006年8月、<https://www.rfc-editor.org/info/rfc4607>。
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <https://www.rfc-editor.org/info/rfc6724>.
[RFC6724] Thaler、D.、Ed。、Draves、R.、Matsumoto、A。、およびT. Chown、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 6724、DOI 10.17487 / RFC6724、2012年9月、<https://www.rfc-editor.org/info/rfc6724>。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.
[RFC6763] Cheshire、S。およびM. Krochmal、「DNSベースのサービスディスカバリ」、RFC 6763、DOI 10.17487 / RFC6763、2013年2月、<https://www.rfc-editor.org/info/rfc6763>。
[RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, DOI 10.17487/RFC7450, February 2015, <https://www.rfc-editor.org/info/rfc7450>.
[RFC7450] Bumgardner、G。、「Automatic Multicast Tunneling」、RFC 7450、DOI 10.17487 / RFC7450、2015年2月、<https://www.rfc-editor.org/info/rfc7450>。
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8085] Eggert、L.、Fairhurst、G。、およびG. Shepherd、「UDP使用ガイドライン」、BCP 145、RFC 8085、DOI 10.17487 / RFC8085、2017年3月、<https://www.rfc-editor.org / info / rfc8085>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, <https://www.rfc-editor.org/info/rfc8305>.
[RFC8305] Schinazi、D。およびT. Pauly、「Happy Eyeballs Version 2：Better Connectivity Using Concurrency」、RFC 8305、DOI 10.17487 / RFC8305、2017年12月、<https://www.rfc-editor.org/info/ rfc8305>。
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8499]ホフマン、P。、サリバン、A。、およびK.藤原、「DNS用語」、BCP 219、RFC 8499、DOI 10.17487 / RFC8499、2019年1月、<https://www.rfc-editor.org/ info / rfc8499>。
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/RFC2317, March 1998, <https://www.rfc-editor.org/info/rfc2317>.
[RFC2317] Eidnes、H.、de Groot、G。、およびP. Vixie、「Classless IN-ADDR.ARPA delegation」、BCP 20、RFC 2317、DOI 10.17487 / RFC2317、1998年3月、<https：// www。 rfc-editor.org/info/rfc2317>。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, <https://www.rfc-editor.org/info/rfc2845>.
[RFC2845] Vixie、P.、Gudmundsson、O.、Eastlake 3rd、D。、およびB. Wellington、「DNSの秘密鍵トランザクション認証（TSIG）」、RFC 2845、DOI 10.17487 / RFC2845、2000年5月、<https： //www.rfc-editor.org/info/rfc2845>。
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 2000, <https://www.rfc-editor.org/info/rfc2931>.
[RFC2931] Eastlake 3rd、D。、「DNS Request and Transaction Signatures（SIG（0）s）」、RFC 2931、DOI 10.17487 / RFC2931、2000年9月、<https://www.rfc-editor.org/info/ rfc2931>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <https://www.rfc-editor.org/info/rfc3550>。
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March 2005, <https://www.rfc-editor.org/info/rfc4025>.
[RFC4025] Richardson、M。、「A Method for Storing IPsec Keying Material in DNS」、RFC 4025、DOI 10.17487 / RFC4025、2005年3月、<https://www.rfc-editor.org/info/rfc4025>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<https://www.rfc-editor.org/info/rfc4301>。
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC4787]オーデ、F、エド。およびC.ジェニングス、「ユニキャストUDPのネットワークアドレス変換（NAT）動作要件」、BCP 127、RFC 4787、DOI 10.17487 / RFC4787、2007年1月、<https://www.rfc-editor.org/info/rfc4787> 。
[RFC5110] Savola, P., "Overview of the Internet Multicast Routing Architecture", RFC 5110, DOI 10.17487/RFC5110, January 2008, <https://www.rfc-editor.org/info/rfc5110>.
[RFC5110] Savola、P。、「Overview of the Internet Multicast Routing Architecture」、RFC 5110、DOI 10.17487 / RFC5110、2008年1月、<https://www.rfc-editor.org/info/rfc5110>。
[RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, "FLUTE - File Delivery over Unidirectional Transport", RFC 6726, DOI 10.17487/RFC6726, November 2012, <https://www.rfc-editor.org/info/rfc6726>.
[RFC6726] Paila、T.、Walsh、R.、Luby、M.、Roca、V。、およびR. Lehtonen、「FLUTE-単一方向トランスポートを介したファイル配信」、RFC 6726、DOI 10.17487 / RFC6726、2012年11月、< https://www.rfc-editor.org/info/rfc6726>。
[RFC7359] Gont, F., "Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks", RFC 7359, DOI 10.17487/RFC7359, August 2014, <https://www.rfc-editor.org/info/rfc7359>.
[RFC7359] Gont、F。、「デュアルスタックホスト/ネットワークにおけるレイヤ3仮想プライベートネットワーク（VPN）トンネルトラフィックリーケージ」、RFC 7359、DOI 10.17487 / RFC7359、2014年8月、<https：//www.rfc-editor .org / info / rfc7359>。
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC7761] Fenner、B.、Handley、M.、Holbrook、H.、Kouvelas、I.、Parekh、R.、Zhang、Z。、およびL. Zheng、「Protocol Independent Multicast-Sparse Mode（PIM-SM） ：プロトコル仕様（改訂）」、STD 83、RFC 7761、DOI 10.17487 / RFC7761、2016年3月、<https://www.rfc-editor.org/info/rfc7761>。
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7858] Hu、Z.、Zhu、L.、Heidemann、J.、Mankin、A.、Wessels、D。、およびP. Hoffman、「DNS over Transport Layer Security（TLS）の仕様」、RFC 7858、DOI 10.17487 / RFC7858、2016年5月、<https://www.rfc-editor.org/info/rfc7858>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T., Ed., and R. Krishnan, "Use of Multicast across Inter-domain Peering Points", BCP 213, RFC 8313, DOI 10.17487/RFC8313, January 2018, <https://www.rfc-editor.org/info/rfc8313>.
[RFC8313]タラポア、P。、編、セイコ、R。、シェパード、G。、エッカート、T。、編、およびR.クリシュナン、「ドメイン間ピアリングポイントでのマルチキャストの使用」、BCP 213、RFC 8313、DOI 10.17487 / RFC8313、2018年1月、<https://www.rfc-editor.org/info/rfc8313>。
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.
[RFC8484] Hoffman、P。およびP. McManus、「HTTPS（DoH）を介したDNSクエリ」、RFC 8484、DOI 10.17487 / RFC8484、2018年10月、<https://www.rfc-editor.org/info/rfc8484> 。
In a DNS resolver that understands the AMTRELAY type, the zone file might contain this line:
AMTRELAYタイプを理解するDNSリゾルバーでは、ゾーンファイルに次の行が含まれる場合があります。
IN AMTRELAY 128 0 3 amtrelays.example.com.
AMTRELAY 128 0 3 amtrelays.example.com。
In order to translate this example to appear as an unknown RRType as defined in [RFC3597], one could run the following program:
[RFC3597]で定義されているように、この例を翻訳して未知のRRTypeとして表示するには、次のプログラムを実行します。
<CODE BEGINS>
$ cat translate.py
#!/usr/bin/env python3
import sys
name=sys.argv[1]
wire=''
for dn in name.split('.'):
if len(dn) > 0:
wire += ('%02x' % len(dn))
wire += (''.join('%02x'%ord(x) for x in dn))
print(len(wire)//2) + 2
print(wire)
$ ./translate.py amtrelays.example.com 24 09616d7472656c617973076578616d706c6503636f6d <CODE ENDS>
$ ./translate.py amtrelays.example.com 24 09616d7472656c617973076578616d706c6503636f6d <コード終了>
The length of the RData and the hex string for the domain name "amtrelays.example.com" are the outputs of this program.
RDataの長さとドメイン名「amtrelays.example.com」の16進文字列は、このプログラムの出力です。
The length of the wire-encoded domain name is 22, so 2 was added to that value (1 for the precedence field and 1 for the combined D-bit and relay type fields) to get the full length 24 of the RData. For the 2 octets ahead of the domain name, we encode the precedence, D-bit, and relay type fields, as described in Section 4.
ワイヤーエンコードされたドメイン名の長さは22であるため、RDataの全長24を取得するために、2がその値に追加されました（優先フィールド用に1、Dビットとリレータイプのフィールドの組み合わせ用に1）。ドメイン名の前の2オクテットについては、セクション4で説明されているように、優先順位、Dビット、およびリレータイプのフィールドをエンコードします。
This results in a zone file entry like this:
これにより、次のようなゾーンファイルエントリが生成されます。
IN TYPE260 \# ( 24 ; length
80 ; precedence = 128
03 ; D-bit=0, relay type=3 (wire-encoded domain name)
09616d7472656c617973076578616d706c6503636f6d ) ; domain name
Acknowledgements
謝辞
This specification was inspired by the previous work of Doug Nortz, Robert Sayko, David Segelstein, and Percy Tarapore, presented in the MBONED Working Group at IETF 93.
この仕様は、IETF 93のMBONEDワーキンググループで発表された、Doug Nortz、Robert Sayko、David Segelstein、およびPercy Taraporeの以前の研究に触発されました。
Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, Ben Kaduk, Bill Atwood, Tim Chown, Christian Worm Mortensen, Warren Kumari, Dan Romanescu, Bernard Aboba, Carlos Pignataro, Niclas Comstedt, Mirja Kühlewind, Henning Rogge, Eric Vyncke, Barry Lieba, Roman Danyliw, Alissa Cooper, Suresh Krishnan, Adam Roach, and Daniel Franke for their very helpful reviews and comments.
Jeff Goldsmith、Toerless Eckert、Mikael Abrahamsson、Lenny Giuliano、Mark Andrews、Sandy Zheng、Kyle Rose、Ben Kaduk、Bill Atwood、Tim Chown、Christian Worm Mortensen、Warren Kumari、Dan Romanescu、Bernard Aboba、Carlos Pignataro、Niclas Comstedtに感謝、MirjaKühlewind、Henning Rogge、Eric Vyncke、Barry Lieba、Roman Danyliw、Alissa Cooper、Suresh Krishnan、Adam Roach、Daniel Frankeの非常に役立つレビューとコメント。
Author's Address
著者のアドレス
Jake Holland Akamai Technologies, Inc. 150 Broadway Cambridge, MA 02144 United States of America
Jake Holland Akamai Technologies、Inc. 150 Broadway Cambridge、MA 02144アメリカ合衆国
Email: jakeholland.net@gmail.com