Mboned                                                        J. Holland
Internet-Draft                                 Akamai Technologies, Inc.
Updates: 7450 (if approved)                            December 19, 20, 2019
Intended status: Standards Track
Expires: June 21, 22, 2020

      DNS Reverse IP AMT (Automatic Multicast Tunneling) Discovery
                draft-ietf-mboned-driad-amt-discovery-12
                draft-ietf-mboned-driad-amt-discovery-13

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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 21, 22, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   4   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
       1.2.1.  Relays and Gateways . . . . . . . . . . . . . . . . .   4
       1.2.2.  Definitions . . . . . . . . . . . . . . . . . . . . .   4
   2.  Relay Discovery Operation Overview  . . . . . . . . . . . . . . . . . .   6
     2.1.  Overview  . . .  Basic Mechanics . . . . . . . . . . . . . . . . . . . . .   6
     2.2.  Signaling and Discovery . . . . . . . . . . . . . . . . .   6
     2.3.  Optimal Relay Selection . . . . . . .  Example Deployments . . . . . . . . . .   9
       2.3.1.  Overview . . . . . . . . .   9
       2.3.1.  Example Receiving Networks  . . . . . . . . . . . . .   9
       2.3.2.  Preference Ordering .  Example Sending Networks  . . . . . . . . . . . . . .  12
   3.  Relay Discovery Operation . .  10
       2.3.3.  Connecting to Multiple Relays . . . . . . . . . . . .  13
     2.4.  Happy Eyeballs . . . .  14
     3.1.  Optimal Relay Selection . . . . . . . . . . . . . . . . .  13
       2.4.1.  14
       3.1.1.  Overview  . . . . . . . . . . . . . . . . . . . . . .  13
       2.4.2.  Algorithm Guidelines  . . . . . . . . . . . . . . . .  13
       2.4.3.  Connection Definition . . . . . . . . . . . . . . . .  14
     2.5.  Guidelines for Restarting Discovery . . . . . .
       3.1.2.  Preference Ordering . . . . .  15
       2.5.1.  Overview . . . . . . . . . . . .  15
       3.1.3.  Connecting to Multiple Relays . . . . . . . . . .  15
       2.5.2.  Updates to Restarting Events . .  18
     3.2.  Happy Eyeballs  . . . . . . . . . .  16
       2.5.3.  Tunnel Stability . . . . . . . . . . .  18
       3.2.1.  Overview  . . . . . . .  17
       2.5.4.  Traffic Health . . . . . . . . . . . . . . .  18
       3.2.2.  Algorithm Guidelines  . . . .  17
       2.5.5.  Relay Loaded or Shutting Down . . . . . . . . . . . .  19
       2.5.6.  Relay Discovery Messages vs. Restarting Discovery .
       3.2.3.  Connection Definition .  19
       2.5.7.  Independent Discovery Per Traffic Source . . . . . .  20
     2.6.  DNS Configuration . . . . . . . . .  20
     3.3.  Guidelines for Restarting Discovery . . . . . . . . . . .  20
     2.7.  Waiting for DNS resolution  . .
       3.3.1.  Overview  . . . . . . . . . . . . .  21
   3.  Example Deployments . . . . . . . . .  20
       3.3.2.  Updates to Restarting Events  . . . . . . . . . . . .  21
     3.1.  Example Receiving Networks
       3.3.3.  Tunnel Stability  . . . . . . . . . . . . . . .  21
       3.1.1.  Internet Service Provider . . .  22
       3.3.4.  Traffic Health  . . . . . . . . . . .  21
       3.1.2.  Small Office . . . . . . . .  22
       3.3.5.  Relay Loaded or Shutting Down . . . . . . . . . . . .  22
     3.2.  Example Sending Networks  24
       3.3.6.  Relay Discovery Messages vs. Restarting Discovery . .  24
       3.3.7.  Independent Discovery Per Traffic Source  . . . . . .  25
     3.4.  DNS Configuration . . . . . . . .  24
       3.2.1.  Sender-controlled Relays . . . . . . . . . . . .  25
     3.5.  Waiting for DNS resolution  . .  24
       3.2.2.  Provider-controlled Relays . . . . . . . . . . . . .  25  26
   4.  AMTRELAY Resource Record Definition . . . . . . . . . . . . .  26
     4.1.  AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . .  26
     4.2.  AMTRELAY RData Format . . . . . . . . . . . . . . . . . .  26  27
       4.2.1.  RData Format - Precedence . . . . . . . . . . . . . .  27
       4.2.2.  RData Format - Discovery Optional (D-bit) . . . . . .  27
       4.2.3.  RData Format - Type . . . . . . . . . . . . . . . . .  27  28
       4.2.4.  RData Format - Relay  . . . . . . . . . . . . . . . .  28
     4.3.  AMTRELAY Record Presentation Format . . . . . . . . . . .  28  29
       4.3.1.  Representation of AMTRELAY RRs  . . . . . . . . . . .  28  29
       4.3.2.  Examples  . . . . . . . . . . . . . . . . . . . . . .  29

   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  30
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  30
     6.1.  Use of AMT  . . . . . . . . . . . . . . . . . . . . . . .  30
     6.2.  Record-spoofing . . . . . . . . . . . . . . . . . . . . .  30  31
     6.3.  Congestion  . . . . . . . . . . . . . . . . . . . . . . .  31
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  31  32
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  32
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  32
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  33  34
   Appendix A.  Unknown RRType construction  . . . . . . . . . . . .  35
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  36

1.  Introduction

   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.

   AMT (Automatic Multicast Tunneling) is defined in [RFC7450], and
   provides a method to transport multicast traffic over a unicast
   tunnel, in order to traverse non-multicast-capable network segments.

   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, and 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.

   That section goes on to suggest DNS-based queries as a possible
   solution.  DRIAD is a DNS-based solution, as suggested there.  This
   solution also addresses the relay discovery issues in the
   "Disadvantages" lists in Section 3.3 of [RFC8313] and Section 3.4 of
   [RFC8313].

   The goal for DRIAD is to enable multicast connectivity between
   separate multicast-enabled networks when neither the sending nor the
   receiving network is connected to a multicast-enabled backbone,
   without pre-configuring any peering arrangement between the networks.

   This document extends the relay discovery procedure described in
   Section 5.2.3.4 of [RFC7450].

1.1.  Background

   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].

   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 IGMPv3 [RFC3376] and MLDv2 [RFC3810] for
   group management of source-specific multicast channels, as described
   in [RFC4604].

   The reader should also be familiar with AMT, particularly the
   terminology listed in Section 3.2 of [RFC7450] and Section 3.3 of
   [RFC7450].

1.2.  Terminology

1.2.1.  Relays and Gateways

   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, and the gateway receives the tunnel-encapsulated
   packets, decapsulates them, and forwards them as native multicast
   packets, as illustrated in Figure 1.

    Multicast  +-----------+  Unicast  +-------------+  Multicast
   >---------> | AMT relay | >=======> | AMT gateway | >--------->
               +-----------+           +-------------+

                     Figure 1: AMT Tunnel Illustration

1.2.2.  Definitions
   +------------+------------------------------------------------------+
   |       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.                         |
   |            |                                                      |
   |  discovery | A broker or load balancer for AMT relay discovery,   |
   |     broker | 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]                                            |
   |            |                                                      |
   |      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].                                           |
   |            |                                                      |
   |       CMTS | Cable Modem Termination System                       |
   |            |                                                      |
   |        OLT | Optical Line Terminal                                |
   +------------+------------------------------------------------------+

   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.

2.  Relay Discovery Operation

2.1. Overview

2.1.  Basic Mechanics

   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.

   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.

   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 to pass the
   multicast packets into networks or applications that are using the
   gateway to subscribe to traffic from that sender.

   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]).

   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,
   and the source IP addresses for desired (S,G)s are known to the
   gateway, and conditions match the requirements outlined in
   Section 2.3. 3.1.

   Some detailed example use cases are provided in Section 3, 2.3, and
   other applicable example topologies appear in Section 3.3 of
   [RFC8313], Section 3.4 of [RFC8313], and Section 3.5 of [RFC8313].

2.2.  Signaling and Discovery

   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.

   The example in Figure 2 contains 2 multicast-enabled networks that
   are both connected to the internet with non-multicast-capable links,
   and which have no direct association with each other.

   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, which operates a
   receiving network that uses an AMT gateway.  The AMT gateway is
   DRIAD-capable.

   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 FLUTE
   [RFC6726] or a live video stream using RTP [RFC3550], or any other
   application that might subscribe to an SSM channel.

                  +---------------+
                  |    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,
                  Tunnel  |
                                  /        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         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

   In this simple example, the sender IP is 2001:db8::a, it is sending
   traffic to the group address ff3e::8000:d, and the relay IP is
   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:

   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.

   The sequence of events depicted in Figure 2 is as follows:

   1.  The end user starts the app, which issues a join to the (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).

   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)).

       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.

   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).

   5.  The relay propagates the join through its network toward the
       sender, then forwards the appropriate AMT-encapsulated traffic to
       the gateway, which decapsulates and forwards it as native
       multicast through its downstream network to the end user.

   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.".

   Note that the address family of the AMT tunnel is independent of the
   address family for the multicast traffic.

2.3.  Optimal Relay Selection  Example Deployments

2.3.1.  Overview

   The reverse source IP DNS query  Example Receiving Networks

2.3.1.1.  Internet Service Provider

   One example of an AMTRELAY RR is a good way for a
   gateway to discover a relay that is known to the sender.

   However, it receiving network is NOT necessarily a good way to discover the best relay
   for an Internet Service Provider
   (ISP) that gateway to use, because the RR will only provide information
   about relays known offers multicast ingest services to the source.

   If there is an upstream relay its subscribers,
   illustrated in a Figure 3.

   In the example network that is topologically
   closer to below, subscribers can join (S,G)s with MLDv2
   or IGMPv3 as described in [RFC4604], and the AMT gateway and able to in this ISP
   can receive and forward multicast traffic from the sender, that relay is better for the gateway to use,
   since more one 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
   sending networks in Section 3.1.2.

   It's only 2.3.2 by discovering the appropriate for an AMT gateway to discover an AMT relay by
   querying an
   relays with a DNS lookup for the AMTRELAY RR owned by a sender when all of these
   conditions are met:

   1.  The gateway needs to propagate a join of an (S,G) over AMT,
       because in with the gateway's network, no RPF next hop toward reverse IP of
   the source can propagate a native multicast join of in the (S,G); and

   2.  The gateway (S,G).

                       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

2.3.1.2.  Small Office

   Another example receiving network is not already connected to a relay small branch office that forwards
   regularly accesses some multicast traffic from the source of the (S,G); and

   3.  The gateway is not configured content, illustrated in Figure 4.

   This office has desktop devices that need to use a particular IP address for receive some multicast
   traffic, so an AMT discovery, or gateway runs on a relay discovered LAN with that IP is not able these devices, to
       forward pull
   traffic from the source of the (S,G); and

   4. in through a non-multicast next-hop.

   The office also hosts some mobile devices that have AMT gateway is not able
   instances embedded inside apps, in order to find an upstream AMT relay with 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 2.5.4.1 or Section 2.5.5); and

   5.  The gateway is not able to find an upstream AMT relay with the
       well-known anycast addresses from Section 7 of [RFC7450].

   When 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).

   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.

   Note
   over their non-multicast wireless LAN.  (Note that the DNS-SD service "Legacy
   Router" is not source-specific, so even though
   several methods of finding a more local source of multicast traffic
   connectivity are preferred where available simplification that's meant to using a relay provided
   by an AMTRELAY RR, describe a gateway further upstream would still variety of
   possible conditions; for example it could be using
   the AMTRELAY RR unless the upstream network has a peering or direct
   connectivity that provides an alternative end-to-end device providing a
   split-tunnel VPN as described in [RFC7359], deliberately excluding
   multicast
   transport path traffic for the (S,G)'s traffic.

2.3.2.  Preference Ordering

   This section defines a preference ordering for relay addresses during
   the relay discovery process.  Gateways are encouraged to implement VPN tunnel, rather than a
   Happy Eyeballs algorithm to try candidate relays concurrently, but
   even device which is
   incapable of multicast forwarding.)

                    Internet
                 (non-multicast)
                        ^
                        |                  Office Network
             +----------|----------------------------------+
             |          |                                  |
             |    +---------------+ (Wifi)   Mobile apps   |
             |    | Modem+ | Wifi | - - - -  w/ embedded   |
             |    | Router |  AP  |          AMT gateways that do not implement a Happy Eyeballs algorithm SHOULD
   use this ordering, except as noted.

   When establishing an  |
             |    +---------------+                        |
             |          |                                  |
             |          |                                  |
             |     +----------------+                      |
             |     | Legacy Router  |                      |
             |     |   (unicast)    |                      |
             |     +----------------+                      |
             |      /        |      \                      |
             |     /         |       \                     |
             | +--------+ +--------+ +--------+=========+  |
             | | Phones | | ConfRm | | Desks  |   AMT tunnel to forward   |  |
             | | subnet | | subnet | | subnet | gateway |  |
             | +--------+ +--------+ +--------+=========+  |
             |                                             |
             +---------------------------------------------+

                 Figure 4: Small Office (no multicast data, it's very
   important for the discovery process to prioritize the network
   topology considerations ahead of address selection considerations, in
   order up)

   By adding an AMT relay to gain the packet replication benefits from using multicast
   instead of unicast tunneling in the multicast-capable portions of the this office network path.

   The intent of the advice and requirements as in this section is Figure 5, it's
   possible to
   describe how a gateway should make use of multicast services from the concurrency provided by
   a Happy Eyeballs algorithm to reduce the join latency, while still
   prioritizing network efficiency considerations over Address Selection
   considerations. example
   multicast-capable ISP in Section 4 of [RFC8305] requires a Happy Eyeballs algorithm to sort
   the addresses 2.3.1.1.

              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

   When multicast-capable networks are chained like this, with a network
   like the Destination Address Selection defined in
   Section 6 of [RFC6724], but for the above reasons, that requirement
   is superseded one in the AMT discovery use case by the following
   considerations:

   o  Prefer Local Relays Figure 5 and Section 3.1.2 provide receiving internet services from a motivating example to prefer
      DNS-SD [RFC6763] for discovery strictly ahead of using the
      AMTRELAY RR controlled by
   multicast-capable network like the sender for AMT discovery.

      For this reason, one in Figure 3, it's RECOMMENDED that important
   for 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 to reach the more local AMT relays
      discovered that way relay, in preference order to avoid
   accidentally tunneling multicast traffic from a more distant AMT relays discoverable via
      the mechanism defined in this document (DRIAD).

   o  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 unicast, and failing to utilize the receiver.

      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 multicast transport
   capabilities of [RFC7450] to route discovery traffic
      to the relay most appropriate to the receiver's gateway.

      Accordingly, the gateway SHOULD by default discover a relay with
      the well-known AMT anycast addresses as the second preference
      after DNS-SD when searching for a local relay.

   o  Let Sender Manage Relay Provisioning

      A related motivating example is provided by considering a sender
      whose traffic can be forwarded by relays network in Figure 3.

2.3.2.  Example Sending Networks

2.3.2.1.  Sender-controlled Relays

   When a sender-controlled sender network like Figure 6 in Section 3.2.1, and is also by operating AMT relays to distribute
   multicast traffic, as in a
      provider-controlled network like Figure 7 in Section 3.2.2, with
      different cost and scalability profiles 6, each address could appear as an
   AMTRELAY RR for the different options.

      In this example about the sending-side network, the precedence
      field described in Section 4.2.1 is a critical method reverse IP of control
      so that senders can provide the appropriate guidance to gateways
      during the discovery process, sender, or one or more domain
   names could appear in order to manage load AMTRELAY RRs, and failover
      scenarios in a manner that operates well with the sender's
      provisioning strategy for horizontal scaling of AMT relays.

      Therefore, after DNS-SD, the precedence from the RR MUST relay addresses can
   be used
      for sorting preference ahead of the Destination Address Selection
      ordering discovered by finding A or AAAA records from Section 6 of [RFC6724], so that only those domain names.

                                         Sender Network
                   +-----------------------------------+
                   |                                   |
                   | +--------+   +=======+  +=======+ |
                   | | Sender |   |  AMT  |  |  AMT  | |
                   | +--------+   | relay IPs with
      the same precedence are directly compared according |  | relay | |
                   |     |        +=======+  +=======+ |
                   |     |            |          |     |
                   |     +-----+------+----------+     |
                   |           |                       |
                   +-----------|-----------------------+
                               v
                            Internet
                         (non-multicast)

                      Figure 6: Small Office Example

2.3.2.2.  Provider-controlled Relays

   When an ISP offers a service to the
      Destination Address Selection ordering.

   Accordingly, transmit outbound multicast traffic
   through a forwarding network, it might also offer AMT gateways SHOULD by default prefer relays in this
   order:

      1. DNS-SD
      2. Anycast addresses from Section 7 of [RFC7450]
      3. DRIAD

   This default behavior MAY be overridden by administrative
   configuration where other behavior is more appropriate for order
   to reach receivers without multicast connectivity to the
   gateway within its network.

   Among relay addresses that have an equivalent preference forwarding
   network, as described
   above, a Happy Eyeballs algorithm in Figure 7.  In this case it's recommended that the ISP
   also provide at least one domain name for the AMT SHOULD relays for use with
   the Destination
   Address Selection defined in Section 6 of [RFC6724].

   Among relay addresses that still have an equivalent preference after AMTRELAY RR.

   When the above orderings, a gateway SHOULD make a non-deterministic choice
   (such as a pseudorandom selection) sender wishes to use the relays provided by the ISP for relay preference ordering, in
   order
   forwarding multicast traffic, an AMTRELAY RR should be configured to support load balancing
   use the domain name provided by DNS configurations that provide
   many relay options.

   The gateway MAY introduce a bias in the non-deterministic choice
   according ISP, to information obtained out allow for address
   reassignment of band or from a historical
   record about network topology, timing information, or the response to
   a probing mechanism, that indicates some expected benefits from
   selecting some relays in preference without forcing the sender to others.  Details about reconfigure
   the
   structure and collection of this information are out corresponding AMTRELAY RRs.

                     +--------+
                     | 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

3.  Relay Discovery Operation

3.1.  Optimal Relay Selection

3.1.1.  Overview

   The reverse source IP DNS query of scope an AMTRELAY RR is a good way for
   this document, but a
   gateway in possession of such information MAY
   use it to prefer topologically closer relays.

   Within discover a relay that is known to the above constraints, gateways MAY make use of other
   considerations from Section 4 of [RFC8305], such as the address
   family interleaving strategies, to produce sender.

   However, it is NOT necessarily a final ordering of
   candidate good way to discover the best relay addresses.

   Note also
   for that certain relay addresses might be excluded from
   consideration by gateway to use, because the hold-down timers described in Section 2.5.4.1 or
   Section 2.5.5.  These RR will only provide information
   about relays constitute "unusable destinations" under
   Rule 1 of the Destination Address Selection, and are also not part of
   the superseding considerations described above.

   The discovery and connection process for known to the source.

   If there is an upstream relay addresses in the
   above described ordering MAY operate in parallel, subject a network that is topologically
   closer to delays
   prescribed by the Happy Eyeballs requirements described in Section 5
   of [RFC8305] for successively launched concurrent connection
   attempts.

2.3.3.  Connecting to Multiple Relays

   In some deployments, it may be useful for a gateway to connect to
   multiple upstream relays and subscribe able to receive and forward multicast
   traffic from the same traffic, in order
   to support an active/active failover model.  A gateway SHOULD NOT be
   configured to do so without guaranteeing sender, that adequate bandwidth relay is
   available.

   A better for the gateway configured to do this SHOULD still use use,
   since more of the same preference
   ordering logic from Section 2.3.2 network path uses native multicast, allowing more
   chances for each connection.  (Note 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 ordering allows scenario is
   outlined in Figure 5 from Section 2.3.1.2.

   It's only appropriate for overriding by explicit administrative
   configuration where required.)

2.4.  Happy Eyeballs

2.4.1.  Overview

   Often, multiple choices of relay will exist for a an AMT gateway using DRIAD
   for to discover an AMT 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 by
   querying an AMTRELAY RR owned by a Happy Eyeballs algorithm to support fast
   discovery sender when all of the most preferred available relay, by probing multiple
   relays concurrently. these
   conditions are met:

   1.  The parallel discovery logic of a Happy Eyeballs algorithm serves gateway needs to
   reduce propagate a join latency for of an (S,G) over AMT,
       because in the initial gateway's network, no RPF next hop toward the
       source can propagate a native multicast join of an SSM channel.  This
   section the (S,G); and

   2.  The gateway is not already connected to a relay that forwards
       multicast traffic from the preference ordering source of relays defined in
   Section 2.3.2 taken together provide guidance on the (S,G); and

   3.  The gateway is not configured to use of a Happy
   Eyeballs algorithm particular IP address for the case of establishing
       AMT connections.

   Note discovery, or a relay discovered with that according IP is not able to
       forward traffic from the definition in Section 2.4.3 source of this
   document, establishing the connection occurs before sending (S,G); and

   4.  The gateway is not able to find an upstream AMT relay with DNS-SD
       [RFC6763], using "_amt._udp" as the Service section of the
       queries, or a
   membership report.  As relay discovered this way is not able to forward
       traffic from the source of the (S,G) (as described in
       Section 5 of [RFC8305], only one
   of the successful connections will be used, and the others are all
   canceled 3.3.4.1 or ignored.  In the context of Section 3.3.5); and

   5.  The gateway is not able to find an upstream AMT connection, this means relay with the gateway will send
       well-known anycast addresses from Section 7 of [RFC7450].

   When the membership reports above conditions are met, the gateway has no path within its
   local network that subscribe to can receive multicast traffic only for from the chosen connection, after source IP
   of the Happy Eyeballs
   algorithm resolves.

2.4.2.  Algorithm Guidelines

   During (S,G).

   In this situation, the "Initiation of asynchronous DNS queries" phase described
   in Section 3 of [RFC8305]), best way to find a gateway attempts relay that can forward the
   required traffic is to resolve use information that comes from the domain
   names listed in Section 2.3.  This consists operator
   of resolving the SRV
   queries for DNS-SD domains for the AMT service, as well as sender.  When the sender has configured an AMTRELAY query for RR,
   gateways can use the reverse IP domain DRIAD mechanism defined in this document.

   Each of document to
   discover the SRV and AMTRELAY responses might contain one or more IP
   addresses, (as with type 1 or type 2 AMTRELAY responses, or when relay information provided by the
   SRV Additional Data section of sender.

   Note that the SRV response contains DNS-SD service is not source-specific, so even though
   when available, several methods of finding a more local source of
   multicast traffic connectivity are preferred to using a relay
   provided by an AMTRELAY RR, a gateway further upstream would still be
   using the address
   records for AMTRELAY RR unless the target, as urged by [RFC2782]), or they might contain
   only domain names (as with type 3 responses from Section 4.2.3, or an
   SRV response without upstream network has a peering that
   provides an additional data section).

   When present, IP alternative end-to-end multicast transport path for the
   (S,G)'s traffic.

3.1.2.  Preference Ordering

   This section defines a preference ordering for relay addresses in during
   the initial response provide resolved
   destination address candidates relay discovery process.  Gateways are encouraged to implement a
   Happy Eyeballs algorithm to try candidate relays concurrently, but
   even gateways that do not implement a Happy Eyeballs algorithm SHOULD
   use this ordering, except as noted.

   When establishing an AMT tunnel to forward multicast data, it's very
   important for the "Sorting discovery process to prioritize the network
   topology considerations ahead of resolved
   destination addresses" phase described address selection considerations, in Section 4
   order to gain the packet replication benefits from using multicast
   instead of [RFC8305]),
   whereas domain names without IP addresses unicast tunneling in the initial response
   result in another set multicast-capable portions of queries for AAAA and A records, whose
   responses provide the candidate resolved destination addresses.

   Since
   network path.

   The intent of the SRV or AMTRELAY responses don't have advice and requirements in this section is to
   describe how a bound on the count gateway should make use of queries that might be generated aside from the bounds imposed concurrency provided by
   the DNS resolver, it's important for the gateway
   a Happy Eyeballs algorithm to provide reduce the join latency, while still
   prioritizing network efficiency considerations over Address Selection
   considerations.

   Section 4 of [RFC8305] requires a rate
   limit on Happy Eyeballs algorithm to sort
   the DNS queries.  The DNS query functionality is expected to
   follow ordinary standards and best practices addresses with the Destination Address Selection defined in
   Section 6 of [RFC6724], but for DNS clients.  A
   gateway MAY use an existing DNS client implementation the above reasons, that does so, requirement
   is superseded in the AMT discovery use case by the following
   considerations:

   o  Prefer Local Relays

      Figure 5 and MAY rely on that client's rate limiting logic to avoid issuing
   excessive queries.  Otherwise, a gateway MUST Section 2.3.1.2 provide a rate limit motivating example to
      prefer DNS-SD [RFC6763] for discovery strictly ahead of using the DNS queries, and its default settings SHOULD NOT permit more
   than 10 queries
      AMTRELAY RR controlled by the sender for any 100-millisecond period (though AMT discovery.

      For this MAY be
   overridable reason, it's RECOMMENDED that AMT gateways by administrative configuration).

   As the resolved IP addresses arrive, the Happy Eyeballs algorithm
   sorts them according to the requirements and recommendations given in
   Section 2.3.2, and attempts connections with the corresponding relays
   under the algorithm restrictions and guidelines given in [RFC8305] default
      perform service discovery using DNS Service Discovery (DNS-SD)
      [RFC6763] for the "Establishment of one connection, which cancels all other
   attempts" phase.  As _amt._udp.<domain> (with <domain> chosen as
      described in Section 3 11 of [RFC8305], DNS
   resolution is treated as asynchronous, [RFC6763]) and connection initiation does
   not wait for lagging DNS responses.

2.4.3.  Connection Definition

   Section 5 of [RFC8305] non-normatively describes success at a
   connection attempt as "generally when the TCP handshake completes".

   There is no normative definition of a connection in use the AMT
   specification [RFC7450], and there is no TCP connection involved relays
      discovered that way in
   an preference to AMT tunnel.

   However, relays discoverable via
      the concept of an AMT connection mechanism defined in the context of a Happy
   Eyeballs algorithm is a useful one, and so this section provides the
   following normative definition: document (DRIAD).

   o  An AMT connection  Prefer Relays Managed by the Containing Network

      When no local relay is established successfully when discoverable with DNS-SD, it still may be
      the gateway
      receives from case that a newly discovered relay a valid Membership Query
      message (Section 5.1.4 of [RFC7450]) that does not have local to the L flag
      set.

   See Section 2.5.5 of receiver is operated by the
      network providing transit services to the receiver.

      In this document for further information about case, when the
   relevance of network cannot make the L flag to relay discoverable
      via DNS-SD, the establishment of a Happy Eyeballs
   connection.  See network SHOULD use the well-known anycast
      addresses from Section 2.5.4 for an overview 7 of how [RFC7450] to route discovery traffic
      to respond if the connection does not provide multicast connectivity relay most appropriate to the source.

   To "cancel" this kind of AMT connection for receiver's gateway.

      Accordingly, the Happy Eyeballs
   algorithm, a gateway that has not sent SHOULD by default discover a membership report relay with a
   subscription would simply stop sending
      the well-known AMT packets for that
   connection.  A gateway only sends a membership report to a connection
   it has chosen anycast addresses as the most preferred available connection.

2.5.  Guidelines second preference
      after DNS-SD when searching for Restarting Discovery

2.5.1.  Overview

   It's expected that gateways deployed a local relay.

   o  Let Sender Manage Relay Provisioning

      A related motivating example is provided by considering a sender
      whose traffic can be forwarded by relays in different environments will
   use a variety of heuristics to decide when it's appropriate to
   restart the relay discovery process, sender-controlled
      network like Figure 6 in order to meet Section 2.3.2.1, and also by relays in a
      provider-controlled network like Figure 7 in Section 2.3.2.2, with
      different
   performance goals (for example, to fulfill cost and scalability profiles for the different kinds of service
   level agreements). options.

      In general, restarting the discovery process is always safe for this example about the
   gateway and relay during any of sending-side network, the events listed precedence
      field described in this section,
   but may cause Section 4.2.1 is a disruption in critical method of control
      so that senders can provide the forwarded traffic if appropriate guidance to gateways
      during the discovery
   process results process, in order to manage load and failover
      scenarios in choosing a different relay, because this changes manner that operates well with the RPF forwarding tree sender's
      provisioning strategy for the multicast traffic upstream horizontal scaling of AMT relays.

      Therefore, after DNS-SD, the
   gateway.  This is likely to result in some dropped or duplicated
   packets from channels actively being tunneled precedence from the old relay to
   the gateway.

   The degree RR MUST be used
      for sorting preference ahead of impact on the traffic Destination Address Selection
      ordering from choosing a different Section 6 of [RFC6724], so that only 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 IPs with
      the relay same precedence are directly compared according to propagate a
   new RPF join toward the sender.

   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
      Destination Address Selection ordering.

   Accordingly, AMT gateways use to determine when to restart
   the discovery process.

   The non-normative advice SHOULD by default prefer relays in this section should
   order:

      1. DNS-SD
      2. Anycast addresses from Section 7 of [RFC7450]
      3. DRIAD

   This default behavior MAY be treated 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
   guidelines to operators and implementors working with described
   above, a Happy Eyeballs algorithm for AMT systems
   that can SHOULD use DRIAD as part of the relay discovery process.

2.5.2.  Updates to Restarting Events Destination
   Address Selection defined in Section 5.2.3.4.1 6 of [RFC7450] lists several events [RFC6724].

   Among relay addresses that may cause 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 start support load balancing by DNS configurations that provide
   many relay options.

   The gateway MAY introduce a bias in the non-deterministic choice
   according to information obtained out of band or from a historical
   record about network topology, timing information, or restart the discovery procedure.

   This document provides response to
   a probing mechanism, that indicates some updates and recommendations regarding expected benefits from
   selecting some relays in preference to others.  Details about the
   handling of these and similar events.  The first 5 events are copied
   here and numbered for easier reference,
   structure and the remaining 4 events collection of this information are newly added out of scope for consideration in
   this document:

   1.  When a document, but a gateway pseudo-interface is started (enabled).

   2.  When in possession of such information MAY
   use it to prefer topologically closer relays.

   Within the gateway wishes above constraints, gateways MAY make use of other
   considerations from Section 4 of [RFC8305], such as the address
   family interleaving strategies, to report produce a group subscription when none
       currently exist.

   3.  Before sending final ordering of
   candidate relay addresses.

   Note also that certain relay addresses might be excluded from
   consideration by the next Request message hold-down timers described in a membership update
       cycle.

   4.  After Section 3.3.4.1 or
   Section 3.3.5.  These relays constitute "unusable destinations" under
   Rule 1 of the gateway fails to receive a response to a Request
       message.

   5.  After Destination Address Selection, and are also not part of
   the gateway receives a Membership Query message with superseding considerations described above.

   The discovery and connection process for the L
       flag set relay addresses in the
   above described ordering MAY operate in parallel, subject to 1.

   6.  When delays
   prescribed by the gateway wishes Happy Eyeballs requirements described in Section 5
   of [RFC8305] for successively launched concurrent connection
   attempts.

3.1.3.  Connecting to report an (S,G) subscription with a
       source address that does not currently have other group
       subscriptions.

   7.  When there is a network change detected, Multiple Relays

   In some deployments, it may be useful for example when a gateway is operating inside an end user device or application, to connect to
   multiple upstream relays and subscribe to the device joins a different network, or when the domain
       portion of a DNS-SD domain name changes same traffic, in response order
   to a DHCP
       message or administrative configuration.

   8.  When substantial loss, persistent congestion, or network overload
       is detected in the stream of AMT packets from a relay.

   9.  When the support an active/active failover model.  A gateway has reported one or more (S,G) subscriptions,
       but no traffic is received from the source for some timeout.
       (See Section 2.5.4.1).

   This list is not exhaustive, nor are any of the listed events
   strictly required SHOULD NOT be
   configured to always force a restart of the discovery process.

   Note do so without guaranteeing that during event #1, a adequate bandwidth is
   available.

   A gateway may use DNS-SD, but does not
   have sufficient information configured to do this SHOULD still use DRIAD, since no source is known.

2.5.3.  Tunnel Stability

   In general, subscribers to active traffic flows the same preference
   ordering logic from Section 3.1.2 for each connection.  (Note that are being
   forwarded
   this ordering allows for overriding by an AMT gateway are less likely to experience explicit administrative
   configuration where required.)

3.2.  Happy Eyeballs

3.2.1.  Overview

   Often, multiple choices of relay will exist for a
   degradation in service (for example, from missing or duplicated
   packets) when the gateway continues using the same relay, as long as
   the DRIAD
   for relay is not overloaded discovery.  Happy Eyeballs [RFC8305] provides a widely
   deployed and the network conditions remain stable.

   Therefore, generalizable strategy for probing multiple possible
   connections in parallel, therefore it is RECOMMENDED that DRIAD-
   capable gateways SHOULD avoid performing implement a full restart Happy Eyeballs algorithm to support fast
   discovery of the most preferred available relay, by probing multiple
   relays concurrently.

   The parallel discovery process during routine cases logic of event #3 (sending a new
   Request message), since it occurs frequently in normal operation.

   However, see Section 2.5.4, Section 2.5.6, and Section 2.5.4.3 for
   more information about exceptional cases when it may be appropriate Happy Eyeballs algorithm serves to use event #3.

2.5.4.  Traffic Health

2.5.4.1.  Absence of Traffic

   If a gateway indicates one or more (S,G) subscriptions in a
   Membership Update message, but no traffic
   reduce join latency for any the initial join of an SSM channel.  This
   section and the (S,G)s is
   received preference ordering of relays defined in
   Section 3.1.2 taken together provide guidance on use of a reasonable time, it's appropriate Happy
   Eyeballs algorithm for the gateway case of establishing AMT connections.

   Note that according to
   restart the discovery process.

   If the gateway restarts the discovery process multiple times
   consecutively for definition in Section 3.2.3 of this reason,
   document, establishing the timeout period SHOULD be adjusted
   to provide a random exponential back-off.

   The RECOMMENDED timeout is connection occurs before sending a random value
   membership report.  As described in the range
   [initial_timeout, MIN(initial_timeout * 2^retry_count,
   maximum_timeout)], with a RECOMMENDED initial_timeout Section 5 of 4 seconds [RFC8305], only one
   of the successful connections will be used, and a RECOMMENDED maximum_timeout the others are all
   canceled or ignored.  In the context of 120 seconds (which is an AMT connection, this means
   the
   recommended minimum NAT mapping timeout described in [RFC4787]).

   Note that gateway will send the recommended initial_timeout is larger than membership reports that subscribe to
   traffic only for the initial
   timout recommended in chosen connection, after the similar Happy Eyeballs
   algorithm from resolves.

3.2.2.  Algorithm Guidelines

   During the "Initiation of asynchronous DNS queries" phase described
   in Section 5.2.3.4.3 3 of
   [RFC7450].  This is [RFC8305]), a gateway attempts to provide time for RPF Join propagation in resolve the
   sending network.  Although the timeout values may be administratively
   adjusted to support performance requirements, operators are advised
   to consider the possibility domain
   names listed in Section 3.1.  This consists of join propagation delays between resolving the
   sender and SRV
   queries for DNS-SD domains for the relay when choosing an appropriate timeout value.

   Gateways restarting AMT service, as well as the discovery process because of an absence of
   traffic MUST use a hold-down timer that removes
   AMTRELAY query for the reverse IP domain defined in this relay from
   consideration during subsequent rounds document.

   Each of discovery while active.
   The hold-down SHOULD last for no less than 3 minutes the SRV and no AMTRELAY responses might contain one or more than
   10 minutes.

2.5.4.2.  Loss and Congestion

   In some gateway deployments, it is also feasible to monitor IP
   addresses, (as with type 1 or type 2 AMTRELAY responses, or when the
   health
   SRV Additional Data section of traffic flows through the gateway, SRV response contains the address
   records for example by detecting the rate of packet loss target, as urged by communicating out of band [RFC2782]), or they might contain
   only domain names (as with receivers, type 3 responses from Section 4.2.3, or monitoring an
   SRV response without an additional data section).

   When present, IP addresses in the packets of known protocols with sequence numbers.
   Where feasible, it's encouraged initial response provide resolved
   destination address candidates 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).

   However, to avoid synchronized rediscovery by many gateways
   simultaneously after a transient network event upstream "Sorting of a relay
   results in many receivers detecting poor flow health at the same
   time, it's recommended to add a random delay before restarting the
   discovery process resolved
   destination addresses" phase described in this case.

   The span Section 4 of [RFC8305]),
   whereas domain names without IP addresses in the random portion initial response
   result in another set of queries for AAAA and A records, whose
   responses provide the delay should be no less than 10
   seconds by default, but may be administratively configured to support
   different performance requirements.

2.5.4.3.  Ancient Discovery Information

   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 candidate resolved destination addresses.

   Since the same relay, as described in Section 2.5.3.

   However, a relay that appears healthy but has been forwarding traffic
   for days SRV or weeks may AMTRELAY responses don't 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, bound on the order count
   of multiple hours, or even days in
   some deployments.

   It may queries that might be beneficial generated aside from the bounds imposed by
   the DNS resolver, it's important for such timers to consider the amount of
   traffic currently being forwarded, and gateway to give provide 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 rate
   limit 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.

2.5.5.  Relay Loaded or Shutting Down queries.  The L flag (see Section 5.1.4.4 of [RFC7450]) DNS query functionality is the preferred
   mechanism for a relay to signal overloading or a graceful shutdown expected to
   gateways.
   follow ordinary standards and best practices for DNS clients.  A
   gateway MAY use an existing DNS client implementation that supports handling of the L flag should generally
   restart the discovery process when it processes does so,
   and MAY rely on that client's rate limiting logic to avoid issuing
   excessive queries.  Otherwise, a Membership Query
   packet with the L flag set.  If an L flag is received while gateway MUST provide a
   concurrent Happy Eyeballs discovery process is under way rate limit
   for multiple
   candidate relays (Section 2.4), the relay sending the L flag DNS queries, and its default settings SHOULD NOT be considered permit more
   than 10 queries for the relay selection.

   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 any 100-millisecond period (though this hold-down timer in MAY be
   overridable by administrative configuration).

   As the same way as resolved IP addresses arrive, the
   hold-down Happy Eyeballs algorithm
   sorts them according to the requirements and recommendations given in
   Section 2.5.4.1, so that 3.1.2, and attempts connections with the relay is removed from
   consideration corresponding relays
   under the algorithm restrictions and guidelines given in [RFC8305]
   for short-term subsequent rounds the "Establishment of discovery.

2.5.6.  Relay Discovery Messages vs. Restarting Discovery

   All AMT relays are required by [RFC7450] to support handling of Relay
   Discovery messages (e.g. one connection, which cancels all other
   attempts" phase.  As described in Section 5.3.3.2 3 of [RFC7450]).

   So a gateway with an existing [RFC8305], DNS
   resolution is treated as asynchronous, and connection to a relay can send initiation does
   not wait for lagging DNS responses.

3.2.3.  Connection Definition

   Section 5 of [RFC8305] non-normatively describes success at a Relay
   Discovery message to
   connection attempt as "generally when the unicast address TCP handshake completes".

   There is no normative definition of that a connection in the AMT relay.  Under
   stable conditions with
   specification [RFC7450], and there is no TCP connection involved in
   an unloaded relay, it's expected that AMT tunnel.

   However, the
   relay will return its own unicast address concept of an AMT connection in the Relay Advertisement,
   in response to such context of a Relay Discovery message.  Since Happy
   Eyeballs algorithm is a useful one, and so this will not
   result in the gateway changing to another relay unless section provides the relay
   directs
   following normative definition:

   o  An AMT connection is established successfully when the gateway away, this is
      receives from a reasonable exception to the
   advice against handling event #3 described in Section 2.5.3.

   This behavior is discouraged for gateways newly discovered relay a valid Membership Query
      message (Section 5.1.4 of [RFC7450]) that do support does not have the L flag,
   to avoid sending unnecessary packets over flag
      set.

   See Section 3.3.5 of this document for further information about the network.

   However, gateways that do not support
   relevance of the L flag may be able to avoid
   a disruption in the forwarded traffic by sending such Relay Discovery
   messages regularly.  When establishment of a relay is under load or 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.

   To "cancel" this kind of AMT connection for the Happy Eyeballs
   algorithm, a gateway that has started not sent a
   graceful shutdown, it may respond membership report with a different relay address,
   which the
   subscription would simply stop sending AMT packets for that
   connection.  A gateway can only sends a membership report to a connection
   it has chosen as the most preferred available connection.

3.3.  Guidelines for Restarting Discovery

3.3.1.  Overview

   It's expected that gateways deployed in different environments will
   use a variety of heuristics to connect decide when it's appropriate to a
   restart the relay discovery process, in order to meet different relay.  This kind
   performance goals (for example, to fulfill different kinds of coordinated handoff will likely result 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 smaller disruption to in the forwarded traffic than if the relay simply stops responding to Request
   messages, and stops discovery
   process results in choosing a different relay, because this changes
   the RPF forwarding traffic.

   This style tree for the multicast traffic upstream of Relay Discovery message (one sent the
   gateway.  This is likely to result in some dropped or duplicated
   packets from channels actively being tunneled from the unicast
   address of a old relay that's already forwarding traffic to this gateway)
   SHOULD NOT be considered a full restart
   the gateway.

   The degree of impact on the traffic from choosing a different relay discovery
   process.  It is RECOMMENDED for gateways to support
   may depend on network conditions between the L flag, but
   for gateways that do not support gateway and the L flag, sending new
   relay, as well as the network conditions and topology between the
   sender and the new relay, as this message
   during event #3 may help mitigate service degradation when relays
   become unstable.

2.5.7.  Independent Discovery Per Traffic Source

   Relays discovered via cause 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 to propagate a non-source-specific
   address, as described in Section 4.1.2.1 of [RFC7450].

   Restarting
   new RPF join toward the discovery process for one pseudo-interface does not
   require restarting sender.

   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 discovery process for other pseudo-interfaces.
   Gateway heuristics about restarting that gateways use to determine when to restart
   the discovery process process.

   The non-normative advice in this section should
   operate independently for different tunnels be treated as
   guidelines to relays, when
   responding operators and implementors working with AMT systems
   that can use DRIAD as part of the relay discovery process.

3.3.2.  Updates to Restarting Events

   Section 5.2.3.4.1 of [RFC7450] lists several events that are specific to the different tunnels.

2.6.  DNS Configuration

   Often an AMT may cause a
   gateway will only have access to start or restart the source discovery procedure.

   This document provides some updates and group IP
   addresses of recommendations regarding the desired traffic,
   handling of these and will not know any other name similar events.  The first 5 events are copied
   here and numbered for easier reference, and 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 remaining 4 events
   are newly added for IPv6,
   as described consideration in Section 2.5 of [RFC3596]).

   Therefore, it this document:

   1.  When a gateway pseudo-interface is RECOMMENDED that AMTRELAY RRs be added started (enabled).

   2.  When the gateway wishes to reverse IP
   zones as appropriate.  AMTRELAY records MAY also appear report a group subscription when none
       currently exist.

   3.  Before sending the next Request message in other
   zones, since this may be necessary to perform delegation from a membership update
       cycle.

   4.  After the
   reverse zones (see for example Section 5.2 of [RFC2317]), but gateway fails to receive a response to a Request
       message.

   5.  After the use
   case enabled by this document requires gateway receives a reverse IP mapping for Membership Query message with the
   source from an (S,G) in order L
       flag set to be useful 1.

   6.  When the gateway wishes to most AMT gateways.
   This document report an (S,G) subscription with a
       source address that does not define semantics currently have other group
       subscriptions.

   7.  When there is a network change detected, for example when a
       gateway is operating inside an end user device or application,
       and the use device joins a different network, or when the domain
       portion of AMTRELAY
   records obtained in a way other than by DNS-SD domain name changes in response to a reverse IP lookup.

   When performing DHCP
       message or administrative configuration.

   8.  When substantial loss, persistent congestion, or network overload
       is detected in the AMTRELAY RR lookup, any CNAMEs stream of AMT packets from a relay.

   9.  When the gateway has reported one or DNAMEs found
   MUST be followed. more (S,G) subscriptions,
       but no traffic is received from the source for some timeout.
       (See Section 3.3.4.1).

   This list is necessary to support zone delegation.
   Some examples outlining this need not exhaustive, nor are described in [RFC2317].

   See Section 4 and Section 4.3 for any of the listed events
   strictly required to always force a detailed explanation restart of the
   contents for discovery process.

   Note that during event #1, a DNS Zone file.

2.7.  Waiting for DNS resolution

   The DNS query functionality is expected to follow ordinary standards
   and best practices for DNS clients.  A gateway MAY may use an existing
   DNS client implementation that DNS-SD, but does so, and MAY rely on that client's
   retry logic not
   have sufficient information to determine the timeouts between retries.

   Otherwise, a use DRIAD, since no source is known.

3.3.3.  Tunnel Stability

   In general, subscribers to active traffic flows that are being
   forwarded by an AMT gateway MAY re-send are less likely to experience a DNS query if it does not receive
   an appropriate DNS response within some timeout period.  If
   degradation in service (for example, from missing or duplicated
   packets) when the gateway retries multiple times, continues using the timeout period same relay, as long as
   the relay is not overloaded and the network conditions remain stable.

   Therefore, gateways SHOULD be adjusted
   to provide avoid performing a random exponential back-off.

   As with full restart of the waiting
   discovery process for the Relay Advertisement message from during routine cases of event #3 (sending a new
   Request message), since it occurs frequently in normal operation.

   However, see Section 5.2.3.4.3 3.3.4, Section 3.3.6, and Section 3.3.4.3 for
   more information about exceptional cases when it may be appropriate
   to use event #3.

3.3.4.  Traffic Health

3.3.4.1.  Absence of [RFC7450], Traffic

   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.

   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.

   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 4 seconds
   and a RECOMMENDED maximum_timeout of 120 seconds.

3.  Example Deployments

3.1.  Example Receiving Networks

3.1.1.  Internet Service Provider

   One example of a receiving network seconds (which is an Internet Service Provider
   (ISP) that offers multicast ingest services to its subscribers,
   illustrated in Figure 3.

   In the example network below, subscribers can join (S,G)s with MLDv2
   or IGMPv3 as
   recommended minimum NAT mapping timeout described in [RFC4604], and [RFC4787]).

   Note that the AMT gateway recommended initial_timeout is larger than the initial
   timout recommended in this ISP
   can receive and forward multicast traffic the similar algorithm from one Section 5.2.3.4.3 of the example
   sending networks
   [RFC7450].  This is to provide time for RPF Join propagation in Section 3.2 by discovering the appropriate AMT
   relays with a DNS lookup for
   sending network.  Although the AMTRELAY RR with timeout values may be administratively
   adjusted to support performance requirements, operators are advised
   to consider the reverse IP possibility of join propagation delays between the source in
   sender and the (S,G).

                       Internet
                    ^            ^      Multicast-enabled
                    |            |      Receiving Network
             +------|------------|-------------------------+
             |      |            |                         |
             |  +--------+   +--------+    +=========+     |
             |  | Border |---| Border |    |   AMT   |     |
             |  | Router |   | Router |    | relay when choosing an appropriate timeout value.

   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.3.4.2.  Loss and Congestion

   In some gateway |     |
             |  +--------+   +--------+    +=========+     |
             |      |            |              |          |
             |      +-----+------+-----------+--+          |
             |            |                  |             |
             |      +-------------+    +-------------+     |
             |      | Agg Routers | .. | Agg Routers |     |
             |      +-------------+    +-------------+     |
             |            /     \ \     /         \        |
             | +---------------+         +---------------+ |
             | |Access Systems | ....... |Access Systems | |
             | |(CMTS/OLT/etc.)|         |(CMTS/OLT/etc.)| |
             | +---------------+         +---------------+ |
             |        |                        |           |
             +--------|------------------------|-----------+
                      |                        |
                +---+-+-+---+---+        +---+-+-+---+---+
                |   |   |   |   |        |   |   |   |   |
               /-\ /-\ /-\ /-\ /-\      /-\ /-\ /-\ /-\ /-\
               |_| |_| |_| |_| |_|      |_| |_| |_| |_| |_|

                              Subscribers

                      Figure 3: Receiving ISP Example

3.1.2.  Small Office

   Another deployments, it is also feasible to monitor the
   health of traffic flows through the gateway, for example receiving network 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).

   However, to avoid synchronized rediscovery by many gateways
   simultaneously after a transient network event upstream of a relay
   results in many receivers detecting poor flow health at the same
   time, it's recommended to add a random delay before restarting the
   discovery process in this case.

   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.

3.3.4.3.  Ancient Discovery Information

   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.

   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.

   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.

3.3.5.  Relay Loaded or Shutting Down

   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.

   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 small branch office
   concurrent Happy Eyeballs discovery process is under way for multiple
   candidate relays (Section 3.2), the relay sending the L flag SHOULD
   NOT be considered for the relay selection.

   It is also RECOMMENDED that
   regularly accesses some multicast content, illustrated in Figure 4.

   This office has desktop devices gateways avoid choosing a relay that need to receive some multicast
   traffic, so 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 short-term subsequent rounds of discovery.

3.3.6.  Relay Discovery Messages vs. Restarting Discovery

   All AMT gateway runs on relays are required by [RFC7450] to support handling of Relay
   Discovery messages (e.g. in Section 5.3.3.2 of [RFC7450]).

   So a LAN gateway with these devices, an existing connection to pull
   traffic in through a non-multicast next-hop.

   The office also hosts some mobile devices relay can send a Relay
   Discovery message to the unicast address of that have 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
   instances embedded inside apps, 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 order Section 3.3.3.

   This behavior is discouraged for gateways that do support the L flag,
   to receive multicast traffic avoid sending unnecessary packets over their non-multicast wireless LAN.  (Note the network.

   However, gateways that do not support the "Legacy
   Router" is a simplification that's meant to describe a variety of
   possible conditions; for example it could L flag may be able to avoid
   a device providing a
   split-tunnel VPN as described disruption in [RFC7359], deliberately excluding
   multicast the forwarded traffic for by sending such Relay Discovery
   messages regularly.  When a VPN tunnel, rather than relay is under load or has started a device
   graceful shutdown, it may respond with a different relay address,
   which is
   incapable of multicast forwarding.)

                    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 | the gateway |  |
             | +--------+ +--------+ +--------+=========+  |
             |                                             |
             +---------------------------------------------+

                 Figure 4: Small Office (no multicast up)

   By adding an AMT 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.

   This style of Relay Discovery message (one sent to the unicast
   address of a relay that's already forwarding traffic to this office network as in Figure 5, it's
   possible to make use gateway)
   SHOULD NOT be considered a full restart of multicast services from the example
   multicast-capable ISP in Section 3.1.1.

              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

   When multicast-capable networks are chained like this, with a network
   like discovery
   process.  It is RECOMMENDED for gateways to support the one in Figure 5 receiving internet services 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.

3.3.7.  Independent Discovery Per Traffic Source

   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 a
   multicast-capable network like non-source-specific
   address, as described in Section 4.1.2.1 of [RFC7450].

   Restarting the discovery process for one in Figure 3, it's important pseudo-interface does not
   require restarting the discovery process for AMT gateways to reach other pseudo-interfaces.
   Gateway heuristics about restarting the more local AMT relay, in order discovery process should
   operate independently for different tunnels to avoid
   accidentally tunneling multicast traffic from a more distant relays, when
   responding to events that are specific to the different tunnels.

3.4.  DNS Configuration

   Often an AMT
   relay with unicast, and failing gateway will only have access to utilize the multicast transport
   capabilities source and group IP
   addresses of the network in Figure 3.

3.2.  Example Sending Networks

3.2.1.  Sender-controlled Relays

   When a sender network is also operating AMT relays to distribute
   multicast desired traffic, as in Figure 6, each address could appear as an
   AMTRELAY RR and will not know any other name
   for the reverse IP source of the sender, or one or more domain
   names could appear in AMTRELAY RRs, and traffic.  Because of this, typically the AMT relay addresses can best
   way of looking up AMTRELAY RRs will be discovered by finding A or AAAA records from those domain names.

                                         Sender Network
                   +-----------------------------------+
                   |                                   |
                   | +--------+   +=======+  +=======+ |
                   | | Sender |   |  AMT  |  |  AMT  | |
                   | +--------+   | relay |  | relay | |
                   |     |        +=======+  +=======+ |
                   |     |            |          |     |
                   |     +-----+------+----------+     |
                   |           |                       |
                   +-----------|-----------------------+
                               v
                            Internet
                         (non-multicast)

                      Figure 6: Small Office Example

3.2.2.  Provider-controlled Relays

   When using the source IP address
   as an ISP offers a service to transmit outbound multicast traffic
   through a forwarding network, it might also offer AMT relays index into one of the reverse mapping trees (in-addr.arpa for
   IPv4, as described in order
   to reach receivers without multicast connectivity Section 3.5 of [RFC1035], or ip6.arpa for IPv6,
   as described in Section 2.5 of [RFC3596]).

   Therefore, it is RECOMMENDED that AMTRELAY RRs be added to the forwarding
   network, reverse IP
   zones as appropriate.  AMTRELAY records MAY also appear in Figure 7.  In other
   zones, since this case it's recommended that may be necessary to perform delegation from the ISP
   also provide at least one domain name
   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 relays gateways.
   This document does not define semantics for use with the use of AMTRELAY RR.
   records obtained in a way other than by a reverse IP lookup.

   When performing the sender wishes 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].

   See Section 4 and Section 4.3 for a detailed explanation of the
   contents for a DNS Zone file.

3.5.  Waiting for DNS resolution

   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
   retry logic to determine the timeouts between retries.

   Otherwise, a gateway MAY re-send a DNS query if it does not receive
   an appropriate DNS response within some timeout period.  If the relays provided by
   gateway retries multiple times, the ISP for
   forwarding multicast traffic, an AMTRELAY RR should timeout period SHOULD be configured adjusted
   to
   use the domain name provided by provide a random exponential back-off.

   As with the ISP, to allow waiting process for address
   reassignment of the relays without forcing Relay Advertisement message from
   Section 5.2.3.4.3 of [RFC7450], the sender to reconfigure RECOMMENDED timeout is a random
   value in the corresponding AMTRELAY RRs.

                     +--------+
                     | 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 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.

4.  AMTRELAY Resource Record Definition

4.1.  AMTRELAY RRType

   The AMTRELAY RRType has the mnemonic AMTRELAY and type code 260
   (decimal).

   The AMTRELAY RR is class independent.

4.2.  AMTRELAY RData Format

   The AMTRELAY RData consists of a 8-bit precedence field, a 1-bit
   "Discovery Optional" field, a 7-bit type field, and a variable length
   relay field.

    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                              ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2.1.  RData Format - Precedence

   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].

   Relays listed in AMTRELAY records with a lower value for precedence
   are to be attempted first.

4.2.2.  RData Format - Discovery Optional (D-bit)

   The D bit is a "Discovery Optional" flag.

   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.

   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].

   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.

   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.

4.2.3.  RData Format - Type

   The type field indicates the format of the information that is stored
   in the relay field.

   The following values are defined:

   o  type = 0: The relay field is empty (0 bytes).

   o  type = 1: The relay field contains a 4-octet IPv4 address.

   o  type = 2: The relay field contains a 16-octet IPv6 address.

   o  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].)

   RRs with an undefined value in the Type field SHOULD NOT be
   considered by receiving gateways for AMT relay discovery.

4.2.4.  RData Format - Relay

   The relay field is the address or domain name of the AMT relay.  It
   is formatted according to the type field.

   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.

   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.

   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.

   When the type field is 3, the relay field is a normal wire-encoded
   domain name, as described in Section 3.3 of [RFC1035].  Compression
   MUST NOT be used, for the reasons given in Section 4 of [RFC3597].

   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.

4.3.  AMTRELAY Record Presentation Format

4.3.1.  Representation of AMTRELAY RRs

   AMTRELAY RRs may appear in a zone data master file.  The precedence,
   D-bit, relay type, and relay fields are REQUIRED.

   If the relay type field is 0, the relay field MUST be ".".

   The presentation for the record is as follows:

     IN AMTRELAY precedence D-bit type relay

4.3.2.  Examples

   In a DNS authoritative nameserver that understands the AMTRELAY type,
   the zone might contain a set of entries like this:

       $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 which 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).

   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:

     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.

5.  IANA Considerations

   This document updates the IANA Registry for DNS Resource Record Types
   by assigning type 260 to the AMTRELAY record.

   This document creates a new registry named "AMTRELAY Resource Record
   Parameters", with a sub-registry for the "Relay Type Field".  The
   initial values in the sub-registry are:

            +-------+---------------------------------------+
            | 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                            |
            +-------+---------------------------------------+

   Values 0, 1, 2, and 3 are further explained in Section 4.2.3 and
   Section 4.2.4.  Relay type numbers 4 through 255 can be assigned with
   a policy of Specification Required (as described in [RFC8126]).

6.  Security Considerations

6.1.  Use of AMT

   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 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.

   Note that AMT does not itself provide any integrity protection on
   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.

6.2.  Record-spoofing

   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.

   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.

   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.

6.3.  Congestion

   Multicast traffic, particularly interdomain multicast traffic,
   carries some congestion risks, as described in Section 4 of
   [RFC8085].

   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 deliberate attack.

   Section 4.1.4.2 of [RFC7450] and Section 6.1 of [RFC7450] provide
   some further considerations and advice about mitigating congestion
   risk.

7.  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.

   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
   Kuehlewind, Henning Rogge, Eric Vyncke, Barry Lieba, Roman Danyliw,
   Alissa Cooper, Suresh Krishnan, Adam Roach, and Daniel Franke for
   their very helpful reviews and comments.

8.  References

8.1.  Normative References

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [RFC7450]  Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450,
              DOI 10.17487/RFC7450, February 2015,
              <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>.

   [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>.

   [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>.

   [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>.

8.2.  Informative References

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

Appendix A.  Unknown RRType construction

   In a DNS resolver that understands the AMTRELAY type, the zone file
   might contain this line:

     IN 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:

   <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>

   The length of the RData and the hex string for the domain name
   "amtrelays.example.com" are the outputs of this program.

   22 is the length of the wire-encoded domain name, 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.

   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

Author's Address

   Jake Holland
   Akamai Technologies, Inc.
   150 Broadway
   Cambridge, MA 02144
   United States of America

   Email: jakeholland.net@gmail.com