doc: Add RFC documents

1 files changed, 1664 insertions, 0 deletions

diff --git a/doc/rfc/rfc8777.txt b/doc/rfc/rfc8777.txt
new file mode 100644
index 0000000..fc40330
--- /dev/null
+++ b/doc/rfc/rfc8777.txt
@@ -0,0 +1,1664 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                        J. Holland
+Request for Comments: 8777                     Akamai Technologies, Inc.
+Updates: 7450                                                 April 2020
+Category: Standards Track                                               
+ISSN: 2070-1721
+
+
+      DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery
+
+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 is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8777.
+
+Copyright Notice
+
+   Copyright (c) 2020 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
+     1.1.  Background
+     1.2.  Terminology
+       1.2.1.  Relays and Gateways
+       1.2.2.  Definitions
+       1.2.3.  Requirements Language
+   2.  Relay Discovery Overview
+     2.1.  Basic Mechanics
+     2.2.  Signaling and Discovery
+     2.3.  Example Deployments
+       2.3.1.  Example Receiving Networks
+       2.3.2.  Example Sending Networks
+   3.  Relay Discovery Operation
+     3.1.  Optimal Relay Selection
+       3.1.1.  Overview
+       3.1.2.  Preference Ordering
+       3.1.3.  Connecting to Multiple Relays
+     3.2.  Happy Eyeballs
+       3.2.1.  Overview
+       3.2.2.  Algorithm Guidelines
+       3.2.3.  Connection Definition
+     3.3.  Guidelines for Restarting Discovery
+       3.3.1.  Overview
+       3.3.2.  Updates to Restarting Events
+       3.3.3.  Tunnel Stability
+       3.3.4.  Traffic Health
+       3.3.5.  Relay Loaded or Shutting Down
+       3.3.6.  Relay Discovery Messages vs. Restarting Discovery
+       3.3.7.  Independent Discovery per Traffic Source
+     3.4.  DNS Configuration
+     3.5.  Waiting for DNS Resolution
+   4.  AMTRELAY Resource Record Definition
+     4.1.  AMTRELAY RRType
+     4.2.  AMTRELAY RData Format
+       4.2.1.  RData Format - Precedence
+       4.2.2.  RData Format - Discovery Optional (D-bit)
+       4.2.3.  RData Format - Type
+       4.2.4.  RData Format - Relay
+     4.3.  AMTRELAY Record Presentation Format
+       4.3.1.  Representation of AMTRELAY RRs
+       4.3.2.  Examples
+   5.  IANA Considerations
+   6.  Security Considerations
+     6.1.  Use of AMT
+     6.2.  Record-Spoofing
+     6.3.  Congestion
+   7.  References
+     7.1.  Normative References
+     7.2.  Informative References
+   Appendix A.  Unknown RRType Construction
+   Acknowledgements
+   Author's Address
+
+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 network segments that are not multicast
+   capable.
+
+   Section 4.1.5 of [RFC7450] explains that the relay selection process
+   for AMT is intended to be more flexible than the particular discovery
+   method described in that document.  That section further explains
+   that the selection process might need to depend on the source of the
+   multicast traffic in some deployments, since a relay must be able to
+   receive multicast traffic from the desired source in order to forward
+   it.
+
+   Section 4.1.5 of [RFC7450] goes on to suggest DNS-based queries as a
+   possible solution: DRIAD is DNS based.  This solution also addresses
+   the relay discovery issues in the "Disadvantages of this
+   configuration" lists in Sections 3.3 and 3.4 of [RFC8313].
+
+   The goal for DRIAD is to enable multicast connectivity between
+   separate multicast-enabled networks without preconfiguring any
+   peering arrangements between the networks when neither the sending
+   nor the receiving network is connected to a multicast-enabled
+   backbone.
+
+   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 Internet Group Management Protocol Version 3
+   (IGMPv3) [RFC3376] and Multicast Listener Discovery Version 2 (MLDv2)
+   [RFC3810] for group management of source-specific multicast channels,
+   as described in [RFC4604].
+
+   The reader should also be familiar with AMT, particularly the
+   terminology listed in Sections 3.2 and 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.  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. |
+     +------------+-------------------------------------------------+
+     |       CMTS | Cable Modem Termination System                  |
+     +------------+-------------------------------------------------+
+     |  discovery | A broker or load balancer for AMT relay         |
+     |     broker | discovery, as mentioned in Section 4.2.1.1 of   |
+     |            | [RFC7450].                                      |
+     +------------+-------------------------------------------------+
+     | downstream | Further from the source of traffic, as          |
+     |            | described in [RFC7450].                         |
+     +------------+-------------------------------------------------+
+     |       FQDN | Fully Qualified Domain Name, as described in    |
+     |            | [RFC8499].                                      |
+     +------------+-------------------------------------------------+
+     |    gateway | An AMT gateway, as described in [RFC7450].      |
+     +------------+-------------------------------------------------+
+     |     L flag | The "Limit" flag described in Section 5.1.4.4   |
+     |            | of [RFC7450].                                   |
+     +------------+-------------------------------------------------+
+     |        OLT | Optical Line Terminal                           |
+     +------------+-------------------------------------------------+
+     |      relay | An AMT relay, as described in [RFC7450].        |
+     +------------+-------------------------------------------------+
+     |        RPF | Reverse Path Forwarding, as described in        |
+     |            | [RFC5110].                                      |
+     +------------+-------------------------------------------------+
+     |         RR | A DNS Resource Record, as described in          |
+     |            | [RFC1034].                                      |
+     +------------+-------------------------------------------------+
+     |     RRType | A DNS Resource Record Type, as described in     |
+     |            | [RFC1034].                                      |
+     +------------+-------------------------------------------------+
+     |        SSM | Source-specific multicast, as described in      |
+     |            | [RFC4607].                                      |
+     +------------+-------------------------------------------------+
+     |   upstream | Closer to the source of traffic, as described   |
+     |            | in [RFC7450].                                   |
+     +------------+-------------------------------------------------+
+
+                           Table 1: Definitions
+
+1.2.3.  Requirements Language
+
+   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 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 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,
+   the source IP addresses for desired (S,G)s are known to the gateway,
+   and conditions match the requirements outlined in Section 3.1.
+
+   Some detailed example use cases are provided in Section 2.3, and
+   other applicable example topologies appear in Sections 3.3, 3.4, and
+   3.5 of [RFC8313].
+
+2.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 two multicast-enabled networks that
+   are both connected to the internet with non-multicast-capable links
+   and which have no direct association with each other.
+
+   A content provider operates a sender, which is a source of multicast
+   traffic inside a multicast-capable network.
+
+   An end user who is a customer of the content provider has a
+   multicast-capable Internet Service Provider (ISP), which operates a
+   receiving network that uses an AMT gateway.  The AMT gateway is DRIAD
+   capable.
+
+   The content provider provides the user with a receiving application
+   that tries to subscribe to at least one (S,G).  This receiving
+   application could, for example, be a file transfer system using File
+   Delivery over Unidirectional Transport (FLUTE) [RFC6726], a live
+   video stream using RTP [RFC3550], or any other application that might
+   subscribe to an SSM channel.
+
+                     +---------------+
+                     |    Sender     |
+      |    |         |  2001:db8::a  |
+      |    |         +---------------+
+      |Data|                 |
+      |Flow|      Multicast  |
+     \|    |/      Network   |
+      \    /                 |        5: Propagate RPF for Join(S,G)
+       \  /          +---------------+
+        \/           |   AMT relay   |
+                     | 2001:db8:c::f |
+                     +---------------+
+                             |        4: Gateway connects to Relay,
+                                         sends Join(S,G) over tunnel
+                             |
+                    Unicast
+                     Tunnel  |        3: --> DNS Query: type=AMTRELAY,
+                                     /        a.0.0.0.0.0.0.0.0.0.0.0.
+         ^                   |      /         0.0.0.0.0.0.0.0.0.0.0.0.
+         |                         /          8.b.d.0.1.0.0.2.ip6.arpa
+         |                   |    /      <-- Response:
+     Join/Leave       +-------------+         AMTRELAY=2001:db8:c::f
+      Signals         | AMT gateway |
+         |            +-------------+
+         |                   |        2: Propagate RPF for Join(S,G)
+         |        Multicast  |
+                   Network   |
+                             |     1: Join(S=2001:db8::a,G=ff3e::8000:d)
+                      +-------------+
+                      |   Receiver  |
+                      |  (end user) |
+                      +-------------+
+
+                         Figure 2: DRIAD Messaging
+
+   In this simple example, the sender IP is 2001:db8::a, which is
+   sending traffic to the group address ff3e::8000:d, and the relay IP
+   is 2001:db8::c:f.
+
+   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 and then forwards the appropriate AMT-encapsulated traffic
+       to the gateway, which decapsulates and forwards it as a native
+       multicast through its downstream network to the end user.
+
+   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.  Example Deployments
+
+2.3.1.  Example Receiving Networks
+
+2.3.1.1.  Internet Service Provider
+
+   One example of a receiving network 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 described in [RFC4604], and the AMT gateway in this ISP
+   can receive and forward multicast traffic from one of the example
+   sending networks in Section 2.3.2 by discovering the appropriate AMT
+   relays with a DNS lookup for the AMTRELAY RR with the reverse IP of
+   the source in the (S,G).
+
+                        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 a small branch office that
+   regularly accesses some multicast content, illustrated in Figure 4.
+
+   This office has desktop devices that need to receive some multicast
+   traffic, so an AMT gateway runs on a LAN with these devices to pull
+   traffic in through a non-multicast next hop.
+
+   The office also hosts some mobile devices that have AMT gateway
+   instances embedded inside apps in order to receive multicast traffic
+   over their non-multicast wireless LAN.  (Note that the "Legacy
+   Router" is a simplification that's meant to describe a variety of
+   possible conditions; for example, it could be a device providing a
+   split-tunnel VPN as described in [RFC7359], deliberately excluding
+   multicast traffic for a VPN tunnel, rather than a device that is
+   incapable of multicast forwarding.)
+
+                     Internet
+                  (non-multicast)
+                         ^
+                         |                  Office Network
+              +----------|----------------------------------+
+              |          |                                  |
+              |    +---------------+ (Wifi)   Mobile apps   |
+              |    | Modem+ | Wifi | - - - -  w/ embedded   |
+              |    | Router |  AP  |          AMT gateways  |
+              |    +---------------+                        |
+              |          |                                  |
+              |          |                                  |
+              |     +----------------+                      |
+              |     | Legacy Router  |                      |
+              |     |   (unicast)    |                      |
+              |     +----------------+                      |
+              |      /        |      \                      |
+              |     /         |       \                     |
+              | +--------+ +--------+ +--------+=========+  |
+              | | Phones | | ConfRm | | Desks  |   AMT   |  |
+              | | subnet | | subnet | | subnet | gateway |  |
+              | +--------+ +--------+ +--------+=========+  |
+              |                                             |
+              +---------------------------------------------+
+
+                  Figure 4: Small Office (No Multicast Up)
+
+   By adding an AMT relay to this office network as in Figure 5, it's
+   possible to make use of multicast services from the example
+   multicast-capable ISP in Section 2.3.1.1.
+
+               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 one in Figure 5 receiving Internet services from a
+   multicast-capable network like the one in Figure 3, it's important
+   for AMT gateways to reach the more local AMT relay in order to avoid
+   accidentally tunneling multicast traffic from a more distant AMT
+   relay with unicast and failing to utilize the multicast transport
+   capabilities of the network in Figure 3.
+
+2.3.2.  Example Sending Networks
+
+2.3.2.1.  Sender-Controlled Relays
+
+   When a sender network is also operating AMT relays to distribute
+   multicast traffic, as in Figure 6, each address could appear as an
+   AMTRELAY RR for the reverse IP of the sender.  Alternately, one or
+   more domain names could appear in AMTRELAY RRs, and the AMT relay
+   addresses can be discovered by finding A or AAAA records from those
+   domain names.
+
+                                          Sender Network
+                    +-----------------------------------+
+                    |                                   |
+                    | +--------+   +=======+  +=======+ |
+                    | | Sender |   |  AMT  |  |  AMT  | |
+                    | +--------+   | relay |  | relay | |
+                    |     |        +=======+  +=======+ |
+                    |     |            |          |     |
+                    |     +-----+------+----------+     |
+                    |           |                       |
+                    +-----------|-----------------------+
+                                v
+                             Internet
+                          (non-multicast)
+
+                       Figure 6: Small Office Example
+
+2.3.2.2.  Provider-Controlled Relays
+
+   When an ISP offers a service to transmit outbound multicast traffic
+   through a forwarding network, it might also offer AMT relays in order
+   to reach receivers without multicast connectivity to the forwarding
+   network, as in Figure 7.  In this case, it's recommended that the ISP
+   also provide at least one domain name for the AMT relays for use with
+   the AMTRELAY RR.
+
+   When the sender wishes to use the relays provided by the ISP for
+   forwarding multicast traffic, an AMTRELAY RR should be configured to
+   use the domain name provided by the ISP to allow for address
+   reassignment of the relays without forcing the sender to reconfigure
+   the corresponding AMTRELAY RRs.
+
+                      +--------+
+                      | 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 an AMTRELAY RR is a good way for a
+   gateway to discover a relay that is known to the sender.
+
+   However, it is *not* necessarily a good way to discover the best
+   relay for that gateway to use, because the RR will only provide
+   information about relays known to the source.
+
+   If there is an upstream relay in a network that is topologically
+   closer to the gateway and is able to receive and forward multicast
+   traffic from the sender, that relay is better for the gateway to use
+   since more of the network path uses native multicast, allowing more
+   chances for packet replication.  But since that relay is not known to
+   the sender, it won't be advertised in the sender's reverse IP DNS
+   record.  An example network that illustrates this scenario is
+   outlined in Figure 5 from Section 2.3.1.2.
+
+   It's only appropriate for an AMT gateway to discover an AMT relay by
+   querying an AMTRELAY RR owned by a sender when all of these
+   conditions are met:
+
+   1.  The gateway needs to propagate a join of an (S,G) over AMT
+       because in the gateway's network, no RPF next hop toward the
+       source can propagate a native multicast join of the (S,G);
+
+   2.  The gateway is not already connected to a relay that forwards
+       multicast traffic from the source of the (S,G);
+
+   3.  The gateway is not configured to use a particular IP address for
+       AMT discovery, or a relay discovered with that IP is not able to
+       forward traffic from the source of the (S,G);
+
+   4.  The gateway is not able to find an upstream AMT relay with DNS-
+       based Service Discovery (DNS-SD) [RFC6763] using "_amt._udp" as
+       the Service section of the queries, or a relay discovered this
+       way is not able to forward traffic from the source of the (S,G)
+       (as described in Section 3.3.4.1 and 3.3.5); and
+
+   5.  The gateway is not able to find an upstream AMT relay with the
+       well-known anycast addresses from Section 7 of [RFC7450].
+
+   When all of the above conditions are met, the gateway has no path
+   within its local network that can receive multicast traffic from the
+   source IP of the (S,G).
+
+   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 that the above conditions are designed to prefer the use of a
+   local AMT relay if one can be discovered.  However, note also that
+   the network upstream of the locally discovered relay would still need
+   to receive traffic from the sender of the (S,G) in order to forward
+   it.  Therefore, unless the upstream network contains the sender or
+   has a multicast-capable peering with a network that can forward
+   traffic from the sender, the upstream network might still use AMT to
+   ingest the traffic from a network that can receive traffic from the
+   sender.  If this is the case, the upstream AMT gateway could still
+   rely on the AMTRELAY RR provided by the sender, even though the
+   AMTRELAY RR is not directly used by gateways topologically closer to
+   the receivers.  For a concrete example of such a situation, consider
+   the network in Figure 5 connected as one of the customers to the
+   network in Figure 3.
+
+3.1.2.  Preference Ordering
+
+   This section defines a preference ordering for relay addresses during
+   the relay discovery process.  Gateways are encouraged to implement a
+   Happy Eyeballs [RFC8305] algorithm to try candidate relays
+   concurrently (see Section 3.2), but even gateways that do not
+   implement a Happy Eyeballs algorithm SHOULD use this ordering, except
+   as noted.
+
+   When establishing an AMT tunnel to forward multicast data, it's very
+   important for the discovery process to prioritize network topology
+   considerations ahead of address selection considerations in order to
+   gain the packet replication benefits from using multicast instead of
+   unicast tunneling in the multicast-capable portions of the network
+   path.
+
+   The intent of the advice and requirements in this section is to
+   describe how a gateway should make use of the concurrency provided by
+   a Happy Eyeballs algorithm to reduce the join latency while still
+   prioritizing network efficiency considerations over address selection
+   considerations.
+
+   Section 4 of [RFC8305] requires a Happy Eyeballs algorithm to sort
+   the addresses with the Destination Address Selection defined in
+   Section 6 of [RFC6724], but for the above reasons, that requirement
+   is superseded in the AMT discovery use case by the following
+   considerations:
+
+   *  Prefer Local Relays
+
+      Figure 5 and Section 2.3.1.2 provide a motivating example to
+      prefer DNS-SD [RFC6763] for discovery strictly ahead of using the
+      AMTRELAY RR controlled by the sender for AMT discovery.
+
+      For this reason, it's RECOMMENDED that AMT gateways by default
+      perform service discovery using DNS Service Discovery (DNS-SD)
+      [RFC6763] for _amt._udp.<domain> (with <domain> chosen as
+      described in Section 11 of [RFC6763]) and use the AMT relays
+      discovered that way in preference to AMT relays discoverable via
+      the mechanism defined in this document (DRIAD).
+
+   *  Prefer Relays Managed by the Containing Network
+
+      When no local relay is discoverable with DNS-SD, it still may be
+      the case that a relay local to the receiver is operated by the
+      network providing transit services to the receiver.
+
+      In this case, when the network cannot make the relay discoverable
+      via DNS-SD, the network SHOULD use the well-known anycast
+      addresses from Section 7 of [RFC7450] to route discovery traffic
+      to the relay most appropriate to the receiver's gateway.
+
+      Accordingly, the gateway SHOULD by default discover a relay with
+      the well-known AMT anycast addresses as the next-best option after
+      DNS-SD when searching for a local relay.
+
+   *  Let Sender Manage Relay Provisioning
+
+      A related motivating example is provided by considering a sender
+      whose traffic can be forwarded by relays in a sender-controlled
+      network like Figure 6 in Section 2.3.2.1 and by relays in a
+      provider-controlled network like Figure 7 in Section 2.3.2.2, with
+      different cost and scalability profiles for the different options.
+
+      In this example about the sending-side network, the precedence
+      field described in Section 4.2.1 is a critical method of control
+      so that senders can provide the appropriate guidance to gateways
+      during the discovery process in order to manage load and failover
+      scenarios in a manner that operates well with the sender's
+      provisioning strategy for horizontal scaling of AMT relays.
+
+      Therefore, after DNS-SD, the precedence from the RR MUST be used
+      for sorting preference ahead of the Destination Address Selection
+      ordering from Section 6 of [RFC6724] so that only relay IPs with
+      the same precedence are directly compared according to the
+      Destination Address Selection ordering.
+
+   Accordingly, 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 the
+   gateway within its network.
+
+   Among relay addresses that have an equivalent preference as described
+   above, a Happy Eyeballs algorithm for AMT SHOULD use the Destination
+   Address Selection defined in Section 6 of [RFC6724].
+
+   Among relay addresses that still have an equivalent preference after
+   the above orderings, a gateway SHOULD make a non-deterministic choice
+   (such as a pseudorandom selection) for relay preference ordering in
+   order to support load balancing by DNS configurations that provide
+   many relay options.
+
+   The gateway MAY introduce a bias in the non-deterministic choice
+   according to information that indicates expected benefits from
+   selecting some relays in preference to others.  Details about the
+   structure and collection of this information are out of scope for
+   this document but could, for example, be obtained by out-of-band
+   methods or from a historical record about network topology, timing
+   information, or the response to a probing mechanism.  A gateway in
+   possession of such information MAY use it to prefer topologically
+   closer relays.
+
+   Within the above constraints, gateways MAY make use of other
+   considerations from Section 4 of [RFC8305], such as the address
+   family interleaving strategies, to produce a final ordering of
+   candidate relay addresses.
+
+   Note also that certain relay addresses might be excluded from
+   consideration by the hold-down timers described in Section 3.3.4.1 or
+   3.3.5.  These relays constitute "unusable destinations" under Rule 1
+   of the Destination Address Selection and are also not part of the
+   superseding considerations described above.
+
+   The discovery and connection process for the relay addresses in the
+   above described ordering MAY operate in parallel, subject to delays
+   prescribed by the Happy Eyeballs requirements described in Section 5
+   of [RFC8305] for successively launched concurrent connection
+   attempts.
+
+3.1.3.  Connecting to Multiple Relays
+
+   In some deployments, it may be useful for a gateway to connect to
+   multiple upstream relays and subscribe to the same traffic in order
+   to support an active/active failover model.  A gateway SHOULD NOT be
+   configured to do so without guaranteeing that adequate bandwidth is
+   available.
+
+   A gateway configured to do this SHOULD still use the same preference-
+   ordering logic from Section 3.1.2 for each connection.  (Note that
+   this ordering allows for overriding by explicit administrative
+   configuration where required.)
+
+3.2.  Happy Eyeballs
+
+3.2.1.  Overview
+
+   Often, multiple choices of relay will exist for a gateway using DRIAD
+   for relay discovery.  Happy Eyeballs [RFC8305] provides a widely
+   deployed and generalizable strategy for probing multiple possible
+   connections in parallel.  Therefore, it is RECOMMENDED that DRIAD-
+   capable gateways implement a Happy Eyeballs algorithm to support fast
+   discovery of the most preferred available relay by probing multiple
+   relays concurrently.
+
+   The parallel discovery logic of a Happy Eyeballs algorithm serves to
+   reduce join latency for the initial join of an SSM channel.  This
+   section and the preference ordering of relays defined in
+   Section 3.1.2 together provide guidance on use of a Happy Eyeballs
+   algorithm for the case of establishing AMT connections.
+
+   Note that according to the definition in Section 3.2.3 of this
+   document, establishing the connection occurs before sending a
+   membership report.  As described in Section 5 of [RFC8305], only one
+   of the successful connections will be used, and the others are all
+   canceled or ignored.  In the context of an AMT connection, this means
+   the gateway will send the membership reports that subscribe to
+   traffic only for the chosen connection after the Happy Eyeballs
+   algorithm resolves.
+
+3.2.2.  Algorithm Guidelines
+
+   During the "Initiation of asynchronous DNS queries" phase described
+   in Section 3 of [RFC8305], a gateway attempts to resolve the domain
+   names listed in Section 3.1.  This consists of resolving the SRV
+   queries for DNS-SD domains for the AMT service, as well as the
+   AMTRELAY query for the reverse IP domain defined in this document.
+
+   Each of the SRV and AMTRELAY responses might contain:
+
+   *  one or more IP addresses (as with type 1 or type 2 AMTRELAY
+      responses or when the SRV Additional Data section of the SRV
+      response contains the address records for the target, as urged by
+      [RFC2782]), or
+
+   *  only domain names (as with type 3 responses from Section 4.2.3 or
+      an SRV response without an additional data section).
+
+   When present, IP addresses in the initial response provide resolved
+   destination address candidates for the "Sorting of resolved
+   destination addresses" phase described in Section 4 of [RFC8305]),
+   whereas domain names without IP addresses in the initial response
+   result in another set of queries for AAAA and A records, whose
+   responses provide the candidate resolved destination addresses.
+
+   Since the SRV or AMTRELAY responses don't have a bound on the count
+   of queries that might be generated aside from the bounds imposed by
+   the DNS resolver, it's important for the gateway to provide a rate
+   limit on the DNS queries.  The DNS query functionality is expected to
+   follow ordinary standards and best practices for DNS clients.  A
+   gateway MAY use an existing DNS client implementation that does so
+   and MAY rely on that client's rate-limiting logic to avoid issuing
+   excessive queries.  Otherwise, a gateway MUST provide a rate limit
+   for the DNS queries, and its default settings SHOULD NOT permit more
+   than 10 queries for any 100-millisecond period (though this MAY be
+   overridable by the administrative configuration).
+
+   As the resolved IP addresses arrive, the Happy Eyeballs algorithm
+   sorts them according to the requirements and recommendations given in
+   Section 3.1.2 and attempts connections with the corresponding relays
+   under the algorithm restrictions and guidelines given in [RFC8305]
+   for the "Establishment of one connection, which cancels all other
+   attempts" phase.  As described in Section 3 of [RFC8305], DNS
+   resolution is treated as asynchronous, and connection initiation does
+   not wait for lagging DNS responses.
+
+3.2.3.  Connection Definition
+
+   Section 5 of [RFC8305] non-normatively describes a successful
+   connection attempt as "generally when the TCP handshake completes".
+
+   There is no normative definition of a connection in the AMT
+   specification [RFC7450], and there is no TCP connection involved in
+   an AMT tunnel.
+
+   However, the concept of an AMT connection in the context of a Happy
+   Eyeballs algorithm is a useful one, and so this section provides the
+   following normative definition:
+
+   *  An AMT connection is established successfully when the gateway
+      receives from a newly discovered relay a valid Membership Query
+      message (Section 5.1.4 of [RFC7450]) that does not have the L flag
+      set.
+
+   See Section 3.3.5 of this document for further information about the
+   relevance of the L flag to the establishment of a Happy Eyeballs
+   connection.  See Section 3.3.4 for an overview of how to respond if
+   the connection does not provide multicast connectivity to the source.
+
+   To "cancel" this kind of AMT connection for the Happy Eyeballs
+   algorithm, a gateway that has not sent a membership report with a
+   subscription would simply stop sending AMT packets for that
+   connection.  A gateway only sends a membership report to a connection
+   it has chosen as the most preferred available connection.
+
+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 decide when it's appropriate to
+   restart the relay discovery process in order to meet different
+   performance goals (for example, to fulfill different kinds of service
+   level agreements).
+
+   In general, restarting the discovery process is always safe for the
+   gateway and relay during any of the events listed in this section but
+   may cause a disruption in the forwarded traffic if the discovery
+   process results in choosing a different relay because this changes
+   the RPF forwarding tree for the multicast traffic upstream of the
+   gateway.  This is likely to result in some dropped or duplicated
+   packets from channels actively being tunneled from the old relay to
+   the gateway.
+
+   The degree of impact on the traffic from choosing a different relay
+   may depend on network conditions between the gateway and the new
+   relay, as well as the network conditions and topology between the
+   sender and the new relay, as this may cause the relay to propagate a
+   new RPF join toward the sender.
+
+   Balancing the expected impact on the tunneled traffic against likely
+   or observed problems with an existing connection to the relay is the
+   goal of the heuristics that gateways use to determine when to restart
+   the discovery process.
+
+   The non-normative advice in this section should be treated as
+   guidelines to operators and implementors working with AMT systems
+   that can use DRIAD as part of the relay discovery process.
+
+3.3.2.  Updates to Restarting Events
+
+   Section 5.2.3.4.1 of [RFC7450] lists several events that may cause a
+   gateway to start or restart the discovery procedure.
+
+   This document provides some updates and recommendations regarding the
+   handling of these and similar events.  The first five events are
+   copied here and numbered for easier reference, and the remaining four
+   events are newly added for consideration in this document:
+
+   1.  When a gateway pseudo-interface is started (enabled).
+
+   2.  When the gateway wishes to report a group subscription when none
+       currently exists.
+
+   3.  Before sending the next Request message in a membership update
+       cycle.
+
+   4.  After the gateway fails to receive a response to a Request
+       message.
+
+   5.  After the gateway receives a Membership Query message with the L
+       flag set to 1.
+
+   6.  When the gateway wishes 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; for example, when a
+       gateway is operating inside an end user device or application and
+       the device joins a different network or when the domain portion
+       of a DNS-SD domain name changes in response to a DHCP message or
+       administrative configuration.
+
+   8.  When substantial loss, persistent congestion, or network overload
+       is detected in the stream of AMT packets from a relay.
+
+   9.  When the gateway has reported one or more (S,G) subscriptions but
+       no traffic is received from the source for some timeout (see
+       Section 3.3.4.1).
+
+   This list is not exhaustive, nor are any of the listed events
+   strictly required to always force a restart of the discovery process.
+
+   Note that during event #1, a gateway may use DNS-SD but does not have
+   sufficient information to use DRIAD, since no source is known.
+
+3.3.3.  Tunnel Stability
+
+   In general, subscribers to active traffic flows that are being
+   forwarded by an AMT gateway are less likely to experience a
+   degradation in service (for example, from missing or duplicated
+   packets) when the gateway continues using the same relay as long as
+   the relay is not overloaded and the network conditions remain stable.
+
+   Therefore, gateways SHOULD avoid performing a full restart of the
+   discovery process during routine cases of event #3 (sending a new
+   Request message), since it occurs frequently in normal operation.
+
+   However, see Sections 3.3.4, 3.3.6, and 3.3.4.3 for more information
+   about exceptional cases when it may be appropriate to use event #3.
+
+3.3.4.  Traffic Health
+
+3.3.4.1.  Absence of 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 4 seconds
+   and a RECOMMENDED maximum_timeout of 120 seconds (which is the
+   recommended minimum NAT mapping timeout described in [RFC4787]).
+
+   Note that the recommended initial_timeout is larger than the initial
+   timeout recommended in the similar algorithm from Section 5.2.3.4.3
+   of [RFC7450].  This is to provide time for RPF Join propagation in
+   the sending network.  Although the timeout values may be
+   administratively adjusted to support performance requirements,
+   operators are advised to consider the possibility of join propagation
+   delays between the sender and the relay when choosing an appropriate
+   timeout value.
+
+   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 deployments, it is also feasible to monitor the
+   health of traffic flows through the gateway -- for example, by
+   detecting the rate of packet loss by communicating out of band with
+   receivers or monitoring the packets of known protocols with sequence
+   numbers.  Where feasible, it's encouraged for gateways to use such
+   traffic health information to trigger a restart of the discovery
+   process during event #3 (before sending a new Request message).
+
+   However, if a transient network event that affects the tunneled
+   multicast stream -- as opposed to an event that affects the tunnel
+   connection between the relay and gateway -- occurs, poor health
+   detection could be triggered for many gateways simultaneously.  In
+   this situation, adding a random delay to avoid synchronized
+   rediscovery by many gateways is recommended.
+
+   The span of the random portion of the delay should be no less than 10
+   seconds by default but may be administratively configured to support
+   different performance requirements.
+
+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
+   concurrent Happy Eyeballs discovery process is underway for multiple
+   candidate relays (Section 3.2), the relay sending the L flag SHOULD
+   NOT be considered for the relay selection.
+
+   It is also RECOMMENDED that gateways avoid choosing a relay that has
+   recently sent an L flag, with approximately a 10-minute hold-down.
+   Gateways SHOULD treat this hold-down timer in the same way as the
+   hold-down in Section 3.3.4.1 so that the relay is removed from
+   consideration for subsequent short-term rounds of discovery.
+
+3.3.6.  Relay Discovery Messages vs. Restarting Discovery
+
+   All AMT relays are required by [RFC7450] to support handling of Relay
+   Discovery messages (e.g., in Section 5.3.3.2 of [RFC7450]).
+
+   So a gateway with an existing connection to a relay can send a Relay
+   Discovery message to the unicast address of that AMT relay.  Under
+   stable conditions with an unloaded relay, it's expected that the
+   relay will return its own unicast address in the Relay Advertisement
+   in response to such a Relay Discovery message.  Since this will not
+   result in the gateway changing to another relay unless the relay
+   directs the gateway away, this is a reasonable exception to the
+   advice against handling event #3 described in Section 3.3.3.
+
+   This behavior is discouraged for gateways that do support the L flag
+   to avoid sending unnecessary packets over the network.
+
+   However, gateways that do not support the L flag may be able to avoid
+   a disruption in the forwarded traffic by sending such Relay Discovery
+   messages regularly.  When a relay is under load or has started a
+   graceful shutdown, it may respond with a different relay address,
+   which the gateway can use to connect to a different relay.  This kind
+   of coordinated handoff will likely result in a smaller disruption to
+   the traffic than if the relay simply stops responding to Request
+   messages and stops forwarding traffic.
+
+   This style of Relay Discovery message (one sent to the unicast
+   address of a relay that's already forwarding traffic to this gateway)
+   SHOULD NOT be considered a full restart of the relay discovery
+   process.  It is RECOMMENDED that gateways support the L flag, but for
+   gateways that do not support the L flag, sending this message during
+   event #3 may help mitigate service degradation when relays become
+   unstable.
+
+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 via a non-source-specific
+   address, as described in Section 4.1.2.1 of [RFC7450].
+
+   Restarting the discovery process for one pseudo-interface does not
+   require restarting the discovery process for other pseudo-interfaces.
+   Gateway heuristics about restarting the discovery process should
+   operate independently for different tunnels to relays when responding
+   to events that are specific to the different tunnels.
+
+3.4.  DNS Configuration
+
+   Often, an AMT gateway will only have access to the source and group
+   IP addresses of the desired traffic and will not know any other name
+   for the source of the traffic.  Because of this, typically, the best
+   way of looking up AMTRELAY RRs will be by using the source IP address
+   as an index into one of the reverse mapping trees (in-addr.arpa for
+   IPv4, as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6,
+   as described in Section 2.5 of [RFC3596]).
+
+   Therefore, it is RECOMMENDED that AMTRELAY RRs be added to reverse IP
+   zones as appropriate.  AMTRELAY records MAY also appear in other
+   zones, since this may be necessary to perform delegation from the
+   reverse zones (see, for example, Section 5.2 of [RFC2317]), but the
+   use case enabled by this document requires a reverse IP mapping for
+   the source from an (S,G) in order to be useful to most AMT gateways.
+   This document does not define semantics for the use of AMTRELAY
+   records obtained in a way other than by a reverse IP lookup.
+
+   When performing the AMTRELAY RR lookup, any CNAMEs or DNAMEs found
+   MUST be followed.  This is necessary to support zone delegation.
+   Some examples outlining this need are described in [RFC2317].
+
+   See Sections 4 and 4.3 for a detailed explanation of the contents of
+   a DNS zone file.
+
+3.5.  Waiting for DNS Resolution
+
+   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 resend a DNS query if it does not receive an
+   appropriate DNS response within some timeout period.  If the gateway
+   retries multiple times, the timeout period SHOULD be adjusted to
+   provide a random exponential back-off.
+
+   As with the waiting process for the Relay Advertisement message from
+   Section 5.2.3.4.3 of [RFC7450], the RECOMMENDED timeout is a random
+   value in the range [initial_timeout, MIN(initial_timeout *
+   2^retry_count, maximum_timeout)], with a RECOMMENDED initial_timeout
+   of 1 second and a RECOMMENDED maximum_timeout of 120 seconds.
+
+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 an 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:
+
+   *  type = 0: The relay field is empty (0 bytes).
+
+   *  type = 1: The relay field contains a 4-octet IPv4 address.
+
+   *  type = 2: The relay field contains a 16-octet IPv6 address.
+
+   *  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].  For the
+   reasons given in Section 4 of [RFC3597], compression MUST NOT be
+   used.
+
+   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 that can receive
+   traffic from the source 198.51.100.12.  The IPv4 and IPv6 addresses
+   are configured with a D-bit of 0 (meaning discovery is mandatory, as
+   described in Section 4.2.2) and a precedence 10 (meaning they're
+   preferred ahead of the last entry, which has precedence 128).
+
+   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 DNS "Resource Record (RR) TYPEs" registry
+   by assigning type 260 to the AMTRELAY record.
+
+   This document creates a new registry named "AMTRELAY Resource Record
+   Parameters" with a subregistry for the "Relay Type Field".  The
+   initial values in the subregistry are:
+
+   +-------+---------------------------------------+
+   | Value | Description                           |
+   +=======+=======================================+
+   | 0     | No relay is present                   |
+   +-------+---------------------------------------+
+   | 1     | A 4-byte IPv4 address is present      |
+   +-------+---------------------------------------+
+   | 2     | A 16-byte IPv6 address is present     |
+   +-------+---------------------------------------+
+   | 3     | A wire-encoded domain name is present |
+   +-------+---------------------------------------+
+   | 4-255 | Unassigned                            |
+   +-------+---------------------------------------+
+
+      Table 2: Initial Contents of the "Relay Type
+                    Field" Registry
+
+   Values 0, 1, 2, and 3 are further explained in Sections 4.2.3 and
+   4.2.4.  Relay type numbers 4 through 255 can be assigned with a
+   policy of Specification Required (as described in [RFC8126]).
+
+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 for
+   Multicast Data packets (Section 5.1.6 of [RFC7450]), so absent
+   protections like those mentioned above, even an off-path attacker who
+   discovers the gateway IP, the relay IP, and the relay source port for
+   an active AMT connection can inject multicast data packets for a
+   joined (S,G) into the data stream if he can get data packets
+   delivered to the gateway IP that spoof the relay as the source.
+
+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 a 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.  References
+
+7.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>.
+
+7.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.
+
+   The length of the wire-encoded domain name is 22, so 2 was added to
+   that value (1 for the precedence field and 1 for the combined D-bit
+   and relay type fields) to get the full length 24 of the RData.  For
+   the 2 octets ahead of the domain name, we encode the precedence,
+   D-bit, and relay type fields, as described in Section 4.
+
+   This results in a zone file entry like this:
+
+     IN TYPE260  \# ( 24 ; length
+             80 ; precedence = 128
+             03 ; D-bit=0, relay type=3 (wire-encoded domain name)
+           09616d7472656c617973076578616d706c6503636f6d ) ; domain name
+
+Acknowledgements
+
+   This specification was inspired by the previous work of Doug Nortz,
+   Robert Sayko, David Segelstein, and Percy Tarapore, presented in the
+   MBONED Working Group at IETF 93.
+
+   Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny
+   Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, Ben Kaduk, Bill
+   Atwood, Tim Chown, Christian Worm Mortensen, Warren Kumari, Dan
+   Romanescu, Bernard Aboba, Carlos Pignataro, Niclas Comstedt, Mirja
+   Kühlewind, Henning Rogge, Eric Vyncke, Barry Lieba, Roman Danyliw,
+   Alissa Cooper, Suresh Krishnan, Adam Roach, and Daniel Franke for
+   their very helpful reviews and comments.
+
+Author's Address
+
+   Jake Holland
+   Akamai Technologies, Inc.
+   150 Broadway
+   Cambridge, MA 02144
+   United States of America
+
+   Email: jakeholland.net@gmail.com