RFC 8777
DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery
DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery ✨
Okay bestie, so this is RFC 8777 🎀, and it's written by J. Holland from Akamai Technologies, Inc. 💅 It's a Standards Track document dated April 2020, and it updates RFC 7450 (it doesn't obsolete anything). It's part of the ISSN 2070-1721 series, so you can find it there too 🌸.
Abstract 💖
Hiii, so this doc updates RFC 7450, "Automatic Multicast Tunneling" (or AMT), by changing up the relay discovery process 🦋. It defines a brand new DNS resource record called AMTRELAY for publishing AMT relays for source-specific multicast channels. The reverse IP DNS zone for a multicast sender's IP address is set up to use AMTRELAY resource records to advertise a set of AMT relays that can receive and forward that sender's multicast traffic over an AMT tunnel. There are also other extensions and clarifications to the relay discovery process defined here 🧚.
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.
Info about the current status of this document, any errata, and how to give feedback on it lives at:
https://www.rfc-editor.org/info/rfc8777Copyright 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, in effect on the date of publication, which you can find at https://trustee.ietf.org/license-info. Please review these carefully, because they spell out 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 they 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 Address1. Introduction 🧚♀️
So this doc defines DNS Reverse IP AMT Discovery (DRIAD) 🔍, which is a mechanism for AMT gateways to find AMT relays that are capable of forwarding multicast traffic from a known source IP address.
AMT (Automatic Multicast Tunneling) is defined in [RFC7450]. It gives you a way to carry multicast traffic over a unicast tunnel, so it can get across network segments that aren't multicast capable. It's giving main character energy 👑.
Section 4.1.5 of [RFC7450] explains that the relay selection process for AMT is meant to be more flexible than the particular discovery method described in that document. That same section explains that the selection process might need to depend on the source of the multicast traffic in some deployments, since a relay has to be able to receive multicast traffic from the desired source in order to forward it 🌸.
Section 4.1.5 of [RFC7450] also suggests DNS-based queries as a possible solution, and that's exactly what DRIAD is 💖. This solution also addresses the relay discovery issues in the "Disadvantages of this configuration" lists in Sections 3.3 and 3.4 of [RFC8313]. Iconic 🙌.
The goal for DRIAD is to enable multicast connectivity between separate multicast-enabled networks without preconfiguring any peering arrangements between the networks. This applies 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 around source-specific multicast as described in [RFC4607]. That includes 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, especially the terminology listed in Sections 3.2 and 3.3 of [RFC7450] 🍓.
1.2. Terminology 🎀
1.2.1. Relays and Gateways 🔁
When you're reading this document, it's really helpful to remember 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 those tunnel-encapsulated packets, decapsulates them, and forwards them as native multicast packets, as shown in Figure 1 🦋.
Multicast +-----------+ Unicast +-------------+ Multicast
>---------> | AMT relay | >=======> | AMT gateway | >--------->
+-----------+ +-------------+
Figure 1: AMT Tunnel Illustration1.2.2. Definitions 📖
Here's the glossary, bestie. Table 1 has all the terms you need 🌈.
+------------+-------------------------------------------------+
| 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: Definitions1.2.3. Requirements Language 🫶
So here's the deal with 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 ✨
okay so the AMTRELAY resource record (RR) defined in this document is basically a DNS record that publishes the IP address or domain name of a set of AMT relays or discovery brokers. these relays can receive, encapsulate, and forward multicast traffic from one particular sender 🦋
the sender is the owner of the RR. they set up the zone so it holds a bunch of RRs giving the addresses or domain names of AMT relays (or discovery brokers that advertise relays) that can receive multicast IP traffic from that sender 💅
this is what lets AMT gateways in remote networks find a relay that can forward the sender's traffic. then those gateways can get the multicast traffic tunneled over a unicast AMT tunnel from those relays, and pass the multicast packets into the networks or apps that are using the gateway to subscribe to that sender. it's giving teamwork 🫶
this mechanism only works for source-specific multicast (SSM) channels 🌸 the source address of the (S,G) gets 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 in Section 2.3, and other applicable example topologies show up in Sections 3.3, 3.4, and 3.5 of [RFC8313] 🎀
2.2. Signaling and Discovery 🌈
this section walks through a typical end-to-end example of how a receiver's join of an SSM channel gets signaled, using an AMTRELAY RR 💖
Figure 2 has two multicast-enabled networks that are both connected to the internet with non-multicast-capable links, and they have no direct association with each other 🙈
a content provider runs 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). that ISP runs a receiving network that uses an AMT gateway, and the AMT gateway is DRIAD capable 👑
the content provider gives the user a receiving app that tries to subscribe to at least one (S,G). this app could be, for example, a file transfer system using File Delivery over Unidirectional Transport (FLUTE) [RFC6726], a live video stream using RTP [RFC3550], or any other app 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 Messagingin 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 already set up the DNS zone that holds the reverse IP domain name for the sender's IP address, so it gives back 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 in Figure 2 goes like this 🌸
- the end user starts the app, which issues a join to the (S,G): (2001:db8::a, ff3e::8000:d).
- 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).
- the AMT gateway does a reverse DNS lookup for the AMTRELAY RRType by sending an AMTRELAY RRType query for the reverse IP domain name of 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 gets the authoritative result the content provider configured, which tells the AMT gateway that the relay address is 2001:db8::c:f 🧚
- 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) 🫶
- the relay propagates the join through its network toward the sender, then forwards the appropriate AMT-encapsulated traffic to the gateway. the gateway decapsulates it 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. 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]. 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, using 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 Example2.3.1.2. Small Office 💼
okay so this one's a small branch office that keeps pulling in some multicast content, see Figure 4 🍓
the desktops in this office need to receive some multicast traffic, so an AMT gateway runs on the LAN with them and pulls the traffic in through a non-multicast next hop 🖥️✨
the office also has mobile devices with AMT gateway instances embedded inside apps, so they can get multicast traffic over their non-multicast wireless LAN 📱💜 (quick note: the "Legacy Router" is a simplification that stands in for a bunch of different setups 🙈 for example, it could be a split-tunnel VPN from [RFC7359] that deliberately leaves multicast traffic out of the VPN tunnel, rather than a device that just can't forward multicast at all.)
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)now here's the glow-up 🦋 by adding an AMT relay to this office network like in Figure 5, the office can use 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 Examplewhen multicast-capable networks are chained like this, with a network like the Figure 5 one getting Internet services from a multicast-capable network like the Figure 3 one, it's important for AMT gateways to reach the closer AMT relay 🎯 otherwise they could accidentally tunnel multicast traffic from a more distant AMT relay as unicast, and that means not using the multicast transport the Figure 3 network can actually provide 😭
2.3.2. Example Sending Networks 📤
2.3.2.1. Sender-Controlled Relays
okay so when a sender network also runs AMT relays to distribute its multicast traffic, like in Figure 6, each address could show up as an AMTRELAY RR for the reverse IP of the sender 🌸 or, alternatively, one or more domain names could appear in AMTRELAY RRs, and the AMT relay addresses can be found by looking up the A or AAAA records for those domain names 🧚
Sender Network
+-----------------------------------+
| |
| +--------+ +=======+ +=======+ |
| | Sender | | AMT | | AMT | |
| +--------+ | relay | | relay | |
| | +=======+ +=======+ |
| | | | |
| +-----+------+----------+ |
| | |
+-----------|-----------------------+
v
Internet
(non-multicast)
Figure 6: Small Office Example2.3.2.2. Provider-Controlled Relays
when an ISP offers a service that sends outbound multicast traffic through a forwarding network, it might also offer AMT relays so it can reach receivers that don't have multicast connectivity to that forwarding network, like 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 wants to use the relays the ISP provides for forwarding multicast traffic, an AMTRELAY RR should be configured to use the domain name the ISP gave. that way the relays can get new addresses without forcing the sender to reconfigure its 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 Example3. Relay Discovery Operation 🔍
3.1. Optimal Relay Selection 💖
3.1.1. Overview ✨
okay so a gateway can use the reverse source IP DNS query of an AMTRELAY RR to find a relay that the sender knows about 🕵️♀️
but that's not necessarily the best way to find the best relay for the gateway to use 😬 the RR only tells you about relays the source knows about, so it's kind of limited
here's the tea 🍵 if there's an upstream relay in a network that's topologically closer to the gateway and can receive and forward multicast traffic from the sender, that relay is the better pick for the gateway. more of the path runs native multicast, which means more chances for packet replication 🦋 but that closer relay isn't known to the sender, so it won't show up in the sender's reverse IP DNS record. an example network for this exact scenario is the one in Figure 5 from Section 2.3.1.2 🌈
so a gateway should only go looking for an AMT relay by querying an AMTRELAY RR owned by a sender when all of these conditions are true 👀
- 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).
- The gateway is not already connected to a relay that forwards multicast traffic from the source of the (S,G).
- 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).
- 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
- 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 inside its local network that can receive multicast traffic from the source IP of the (S,G) 😭
in that situation, the best way to find a relay that can forward the traffic it needs is to use info 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 info the sender provides 💜
✨ quick heads up: these conditions are built to prefer a local AMT relay if one can be discovered. BUT, the network upstream of that locally discovered relay still needs to receive traffic from the sender of the (S,G) in order to forward it 🙈 so 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 it from the sender. if that's the case, the upstream AMT gateway could still rely on the AMTRELAY RR the sender provides, even though gateways closer to the receivers don't use that RR directly. for a concrete example of this, picture the network in Figure 5 connected as one of the customers of the network in Figure 3 💅
okay bestie, picking up right where we left off 💖
3.1.2. Preference Ordering ✨
okay so this section is all about the order gateways should try relay addresses in during discovery 🦋 gateways are encouraged to run a Happy Eyeballs [RFC8305] algorithm to try candidate relays at the same time (more on that in Section 3.2), but even gateways that don't do Happy Eyeballs SHOULD still use this ordering, except where noted. no cap, it matters 💅
when you're setting up an AMT tunnel to forward multicast data, it's so important that discovery puts network topology ahead of address selection. why? because you want those packet replication benefits from multicast instead of unicast tunneling in the parts of the path that can do multicast 🌸 main character energy for efficiency 👑
the whole point of this section is to show how a gateway can use the concurrency from Happy Eyeballs to cut down join latency, while still putting network efficiency first over address selection 🎀
Section 4 of [RFC8305] says a Happy Eyeballs algorithm has to sort addresses using Destination Address Selection from Section 6 of [RFC6724]. BUT for the reasons above, the AMT discovery use case overrides that with the following considerations 🙈
Prefer Local Relays 🏠
Figure 5 and Section 2.3.1.2 give a motivating example for preferring DNS-SD [RFC6763] discovery strictly ahead of the AMTRELAY RR controlled by the sender 💜
so it's RECOMMENDED that AMT gateways, by default, do 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 found 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 can be found with DNS-SD, it can still happen that a relay local to the receiver is run by the network providing transit services to the receiver 🧚
in that case, if the network can't 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 that fits the receiver's gateway best 🍓
so the gateway SHOULD, by default, discover a relay using the well-known AMT anycast addresses as the next-best option after DNS-SD when it's looking for a local relay 🦋
Let Sender Manage Relay Provisioning 🎀
okay this one is a fave 😭 a sender's 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), and those options have different cost and scalability profiles 💅
for the sending side, the precedence field from Section 4.2.1 is a critical control knob 🔥 it lets senders give gateways the right guidance during discovery, so they can manage load and failover in a way that works with the sender's plan for horizontally scaling AMT relays 👑
so after DNS-SD, the precedence from the RR MUST be used for sorting, ahead of the Destination Address Selection ordering from Section 6 of [RFC6724]. that means only relay IPs with the same precedence get compared directly using Destination Address Selection 🫶
so, by default, AMT gateways SHOULD prefer relays in this order:
- DNS-SD
- Anycast addresses from Section 7 of [RFC7450]
- DRIAD
this default MAY be overridden by administrative configuration when some other behaviour fits the gateway better inside its network 🌸
among relay addresses with equivalent preference (per the above), a Happy Eyeballs algorithm for AMT SHOULD use the Destination Address Selection defined in Section 6 of [RFC6724] ✨
among relay addresses that still tie after all of the above, a gateway SHOULD make a non-deterministic choice (like a pseudorandom selection) for relay preference ordering, so load gets balanced across DNS configurations that give lots of relay options 💖
the gateway MAY add a bias to that non-deterministic choice based on information showing expected benefits from picking some relays over others 🦋 how that information is structured and collected is out of scope for this document. it could come from out-of-band methods, or from a historical record about network topology, timing information, or the response to a probing mechanism 🧚 a gateway that has such information MAY use it to prefer topologically closer relays 🍓
within those constraints, gateways MAY also use other considerations from Section 4 of [RFC8305], like the address family interleaving strategies, to build the final ordering of candidate relay addresses 🌈
heads up: certain relay addresses might get excluded from consideration by the hold-down timers in Section 3.3.4.1 or 3.3.5. those relays are "unusable destinations" under Rule 1 of Destination Address Selection, and they're also not part of the superseding considerations above 🙈
the discovery and connection process for the relay addresses in the ordering above MAY run in parallel, subject to the delays from the Happy Eyeballs requirements in Section 5 of [RFC8305] for successively launched concurrent connection attempts 💜
3.1.3. Connecting to Multiple Relays 🌸
in some deployments, it can be useful for a gateway to connect to multiple upstream relays and subscribe to the same traffic, to support an active/active failover model 🧚 but a gateway SHOULD NOT be configured to do this unless it's guaranteed that adequate bandwidth is available 😭
a gateway set up this way SHOULD still use the same preference-ordering logic from Section 3.1.2 for each connection 💅 (note that this ordering allows overriding by explicit administrative configuration where needed ✨)
3.2. Happy Eyeballs 🦋
3.2.1. Overview 💖
okay so, a gateway using DRIAD for relay discovery will often have multiple relay choices 🌈 Happy Eyeballs [RFC8305] is a widely deployed, generalizable strategy for probing multiple possible connections in parallel, so it is RECOMMENDED that DRIAD-capable gateways implement a Happy Eyeballs algorithm to find the most preferred available relay fast by probing several relays at once 🎀
the parallel discovery logic in Happy Eyeballs cuts join latency for the initial join of an SSM channel 👑 this section plus the relay preference ordering from Section 3.1.2 together give guidance on using Happy Eyeballs when establishing AMT connections ✨
note that, per the definition in Section 3.2.3 of this document, establishing the connection happens before a membership report gets sent 🙈 as Section 5 of [RFC8305] describes, only one of the successful connections gets used, and the rest are canceled or ignored 💅 for AMT, that means the gateway only sends membership reports subscribing to traffic on the chosen connection, after the Happy Eyeballs algorithm resolves 🫶
3.2.2. Algorithm Guidelines 🍓
during the "Initiation of asynchronous DNS queries" phase from Section 3 of [RFC8305], a gateway tries to resolve the domain names listed in Section 3.1 🔥 this means resolving the SRV queries for DNS-SD domains for the AMT service, plus the AMTRELAY query for the reverse IP domain defined in this document 🧚
each SRV and AMTRELAY response might contain:
- one or more IP addresses (like with type 1 or type 2 AMTRELAY responses, or when the SRV Additional Data section of the SRV response has the address records for the target, as urged by [RFC2782]), or
- only domain names (like with type 3 responses from Section 4.2.3, or an SRV response without an additional data section) 🌈
when IP addresses show up in the initial response, they give resolved destination address candidates for the "Sorting of resolved destination addresses" phase from Section 4 of [RFC8305]) 💖 but domain names without IP addresses in the initial response trigger another set of AAAA and A queries, whose responses give the candidate resolved destination addresses 🦋
heads up bestie: SRV and AMTRELAY responses don't have a bound on how many queries they could generate, except for the bounds the DNS resolver imposes 😭 so it's important for the gateway to rate-limit its 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 this, and MAY rely on that client's rate-limiting logic to avoid issuing excessive queries 🫶 otherwise, a gateway MUST provide a rate limit for DNS queries, and its default settings SHOULD NOT permit more than 10 queries for any 100-millisecond period (though this MAY be overridable by administrative configuration) 🌸
as resolved IP addresses arrive, the Happy Eyeballs algorithm sorts them according to the requirements and recommendations in Section 3.1.2 and attempts connections with the matching relays, under the algorithm restrictions and guidelines in [RFC8305] for the "Establishment of one connection, which cancels all other attempts" phase ✨ as Section 3 of [RFC8305] describes, DNS resolution is 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's no normative definition of a connection in the AMT specification [RFC7450], and there's no TCP connection involved in an AMT tunnel at all 🙈
BUT the idea of an AMT connection inside a Happy Eyeballs algorithm is still useful, so this section gives 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 more on how the L flag relates to establishing a Happy Eyeballs connection 💖 and see Section 3.3.4 for an overview of how to respond if the connection doesn't give multicast connectivity to the source 🍓
to "cancel" this kind of AMT connection for the Happy Eyeballs algorithm, a gateway that hasn't sent a membership report with a subscription simply stops sending AMT packets for that connection ✨ a gateway only sends a membership report to the connection it chose as the most preferred available one 👑
3.3. Guidelines for Restarting Discovery 💅
3.3.1. Overview
okay so gateways living in totally different environments are gonna use all kinds of heuristics to figure out when it's time to restart relay discovery 💅 because different setups chase different performance goals (like, different SLAs, ya know? 🎀)
restarting discovery is always safe for the gateway and the relay during any of the events listed in this section 🦋 BUT it can mess with the forwarded traffic if discovery ends up picking a different relay, bc that changes the RPF forwarding tree for the multicast traffic upstream of the gateway. that can mean some dropped or duplicated packets from channels that are actively being tunneled from the old relay to the gateway 😭
how much it hurts depends on the network conditions between the gateway and the new relay, plus the conditions and topology between the sender and the new relay, since that can make the relay propagate a new RPF join toward the sender 🌸
so the whole point of these heuristics is balancing the expected hit to tunneled traffic against likely or observed problems with an existing connection to the relay ✨ it's a total vibe check 💖
the non-normative advice in this section should be treated as guidelines for 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 can make a gateway start or restart the discovery procedure, ngl 🙈
this doc gives some updates and recommendations on handling these (and similar) events. the first five are copied here and numbered for easy reference, and the last four are newly added in this document 🍓
- When a gateway pseudo-interface is started (enabled).
- When the gateway wishes to report a group subscription when none currently exists.
- Before sending the next Request message in a membership update cycle.
- After the gateway fails to receive a response to a Request message.
- After the gateway receives a Membership Query message with the
Lflag set to1. - When the gateway wishes to report an
(S,G)subscription with a source address that does not currently have other group subscriptions. - 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.
- When substantial loss, persistent congestion, or network overload is detected in the stream of AMT packets from a relay.
- 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 hit a degradation in service (like missing or duplicated packets) when the gateway keeps using the same relay, as long as the relay isn't overloaded and the network conditions stay 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 happens all the time in normal operation. 💅
however, see Sections 3.3.4, 3.3.6, and 3.3.4.3 for more info about the exceptional cases where 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 shows up in a reasonable time, it's appropriate for the gateway to restart the discovery process 🙈
if the gateway restarts the discovery process multiple times in a row 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 give time for RPF Join propagation in the sending network. although the timeout values can 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's also feasible to monitor the health of traffic flows through the gateway, like by detecting the rate of packet loss by communicating out of band with receivers, or by monitoring the packets of known protocols with sequence numbers 🔥 where that's feasible, it's encouraged for gateways to use this traffic health info 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) happens, poor health detection could get triggered for many gateways at once 😭 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 it may be administratively configured to support different performance requirements 🌈
3.3.4.3. Ancient Discovery Information
in most cases, a gateway that's actively receiving healthy traffic from a relay that hasn't indicated load with the L flag should prefer to stay connected to the same relay, as described in Section 3.3.3 🦋
however, a relay that looks 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 a long-term timeout on the order of multiple hours or even days expires, in some deployments ⏳
it may be beneficial for these timers to consider how much traffic is being forwarded right now, and to give a higher probability of restarting discovery during periods with an unusually low data rate. that reduces 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 hasn't passed yet, 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 relay selection 🙅♀️
it's 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 the same way as the hold-down in Section 3.3.4.1, so the relay gets 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 that Relay Discovery message 🦋 since this won't make the gateway change to another relay unless the relay directs it away, it's 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 these 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 then use to connect to a different relay. this kind of coordinated handoff will likely cause a smaller disruption to the traffic than if the relay just 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 theLflag, but for gateways that do not support theLflag, 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 the other pseudo-interfaces. gateway heuristics about restarting discovery should operate independently for different tunnels to relays when responding to events that are specific to those tunnels 🌈💖
3.4. DNS Configuration 🌸
Okay so, an AMT gateway usually only knows the source and group IP addresses of the traffic it wants, and it has no idea what name the source goes by 🥺. So the best way to look up AMTRELAY RRs is typically to use 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]). It's giving reverse lookup energy ✨.
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, and 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 it 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 relay4.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 nameSee 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" RegistryValues 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 🛡️.
🚨 Bestie, read this next part twice. 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 ✨
okay bestie, the AMTRELAY record is carrying info that SHOULD reach the DNS client totally unmodified 🎀. How the client checks that it wasn't messed with? That's up to the client 💅.
There must be a trust relationship between the end consumer of this record and the DNS server 🔐. That can look like end-to-end DNSSEC validation, or a secure connection to a trusted DNS server that keeps the answer safe from record-spoofing on its way over. The connection to that trusted server can use any secure channel, like 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 authenticates 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. Not a vibe at all 😭.
6.3. Congestion 🌊
Multicast traffic, especially interdomain multicast traffic, comes with some congestion risks, as described in Section 4 of [RFC8085] 🫶.
Application implementors and network operators that use AMT gateways are advised to take precautions 🛡️. That includes monitoring application traffic behavior, traffic authentication at ingest, rate-limiting multicast traffic, and using circuit-breaker techniques like the ones described in Section 3.1.10 of [RFC8085], plus similar protections at the network level. The goal is keeping the network healthy when there's a 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] give some extra considerations and advice on 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 🧁
okay so, in a DNS resolver that understands the AMTRELAY type, the zone file might contain this line 📝:
IN AMTRELAY 128 0 3 amtrelays.example.com.To translate this example so it shows up 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 nameAcknowledgements 🫶
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 ✨
okay bestie, the last bit is where we find out who wrote this whole thing 🫶 Jake Holland is the author, and they're at Akamai Technologies, Inc. 💅
Jake Holland
Akamai Technologies, Inc.
150 Broadway
Cambridge, MA 02144
United States of AmericaWant to reach them? The email is jakeholland.net@gmail.com 💌
📦 where this page comes from
- ietf: rfc8777 2020-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms