ietf-corpus

rfc-8777

DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery

J. Holland
date2020-04 streamIETF areaops wgmboned statusPROPOSED STANDARD pages33 canonicalhttps://www.rfc-editor.org/rfc/rfc8777 doi10.17487/RFC8777 errataview
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.

updates

Extracted elements (27)

design-rationale §3.1.1

DNS-SD is preferred strictly ahead of DRIAD to prefer topologically local relays. A locally discovered relay results in more native multicast hops, increasing packet replication efficiency. An AMTRELAY RR from the sender can only advertise relays known to the sender, which may be far from the gateway.

dns, multicast

design-rationale §3.4

DRIAD uses reverse IP DNS zones because AMT gateways typically only know the source IP of an (S,G) and have no other name for the sender. Reverse IP lookup is thus the natural and universal index for finding per-sender relay information.

dns, multicast

design-rationale §3.1.2

The AMTRELAY precedence field is a critical control mechanism for senders to guide load and failover across relays in sender-controlled vs. provider-controlled networks. It is intentionally prioritized over RFC 6724 address selection to preserve multicast topology efficiency over address family preferences.

multicast

interoperability-note §4.3.2

For DNS servers that do not natively support the AMTRELAY RRType, the unknown RRType format from RFC 3597 (TYPE260 with \# encoding) can be used to publish AMTRELAY records. Appendix A provides a Python script to convert wire-encoded domain names for this purpose.

dns, multicast

interoperability-note §2.2

The address family of the AMT tunnel is independent of the address family of the multicast traffic. A gateway may use an IPv4 AMT tunnel to receive IPv6 multicast, or vice versa.

multicast, ip

normative-requirement §3.2.2 MUST

A gateway MUST provide a rate limit for DNS queries; by default settings SHOULD NOT permit more than 10 queries per 100-millisecond period (though this MAY be overridable by administrative configuration).

dns, multicast

normative-requirement §4.2.3 MUST NOT

A type 3 AMTRELAY relay field contains a wire-encoded domain name that MUST NOT be compressed, per RFC 1035 Section 3.3 and RFC 3597 Section 4.

dns, multicast

normative-requirement §3.1.2 MUST

After DNS-SD, relay addresses MUST be sorted by AMTRELAY precedence field ahead of the Destination Address Selection ordering from RFC 6724 Section 6; only relay IPs with the same precedence are compared using RFC 6724.

dns, multicast

normative-requirement §3.1.2 SHOULD

AMT gateways SHOULD by default prefer relay sources in this order: (1) DNS-SD (_amt._udp), (2) well-known anycast addresses from RFC 7450 Section 7, (3) DRIAD (AMTRELAY RR). This default MAY be overridden by administrative configuration.

dns, multicast

normative-requirement §3.4 SHOULD

AMTRELAY RRs SHOULD be added to reverse IP zones (in-addr.arpa for IPv4, ip6.arpa for IPv6). Records MAY also appear in other zones to support delegation, but reverse IP lookup is required for most AMT gateway use cases.

dns, multicast

normative-requirement §3.3.4.1 MUST

Gateways restarting discovery due to absence of traffic MUST use a hold-down timer that removes the unresponsive relay from consideration during subsequent rounds. The hold-down SHOULD last no less than 3 minutes and no more than 10 minutes.

multicast

normative-requirement §3.5 SHOULD

If a gateway retries DNS queries multiple times, the timeout period SHOULD use random exponential back-off with a recommended initial_timeout of 1 second and maximum_timeout of 120 seconds.

dns, multicast

normative-requirement §3.3.5 SHOULD NOT

If an L flag (relay loaded/shutting down) is received while a concurrent Happy Eyeballs discovery is underway for multiple candidate relays, the relay sending the L flag SHOULD NOT be considered for selection. Gateways SHOULD apply approximately a 10-minute hold-down for such relays.

multicast

normative-requirement §3.2.1 RECOMMENDED

It is RECOMMENDED that DRIAD-capable gateways implement a Happy Eyeballs algorithm (RFC 8305) to support fast discovery of the most preferred available relay by probing multiple relays concurrently.

multicast

normative-requirement §4.2.2 MUST

The D-bit MUST be set to zero when no information is available from the AMT relay operator about its suitability for direct Request messages.

multicast

normative-requirement §3.4 MUST

When performing an AMTRELAY RR lookup, any CNAMEs or DNAMEs found MUST be followed to support zone delegation.

dns, multicast

normative-requirement §4.2.2 MUST

When the D-bit is 0, a gateway MUST perform AMT relay discovery (receive a Relay Advertisement) before sending an AMT Request to the address. This is necessary for load balancers and brokers that are not full AMT relays.

multicast

protocol-element §3.2.3

An AMT connection (for Happy Eyeballs purposes) is established successfully when the gateway receives from a newly discovered relay a valid Membership Query message (RFC 7450 Section 5.1.4) that does not have the L flag set.

multicast

protocol-element §4.1

The AMTRELAY resource record (RRType 260) is defined for publishing AMT relays or discovery brokers for source-specific multicast channels. The reverse IP DNS zone for a sender's IP address is configured with AMTRELAY RRs to advertise relays that can receive and forward multicast from that sender.

dns, multicast

protocol-element §4.2.2

The Discovery Optional (D-bit) flag controls whether a gateway may send an AMT Request message directly to the relay address. D-bit=0 requires a full AMT relay discovery exchange (Relay Discovery then Relay Advertisement) before sending a Request; D-bit=1 permits skipping the discovery step.

dns, multicast

protocol-element §4.2.1

The precedence field is an 8-bit value interpreted the same as the PREFERENCE field in RFC 1035 Section 3.3.9. Relays with a lower precedence value are to be attempted first.

dns, multicast

protocol-element §4.2.3

The type field in AMTRELAY RData specifies the relay field format: type=0 means no relay (0 bytes), type=1 means 4-octet IPv4 address, type=2 means 16-octet IPv6 address, and type=3 means wire-encoded domain name of self-describing length.

dns, multicast

registry §5

IANA assigned RRType 260 (mnemonic AMTRELAY) in the DNS Resource Record Types registry. A new 'AMTRELAY Resource Record Parameters' registry was created with a 'Relay Type Field' subregistry; values 0–3 are defined, 4–255 are Unassigned (Specification Required).

dns, registry, multicast

security-consideration §6.1

AMT does not provide integrity protection for Multicast Data packets. An off-path attacker who discovers the gateway IP, relay IP, and relay source port can inject spoofed multicast data packets. Operators are encouraged to use IPsec opportunistically when IPSECKEY records are available.

security, multicast, ipsec

security-consideration §6.2 SHOULD

AMTRELAY RR data SHOULD be protected against spoofing via DNSSEC end-to-end validation or a secure DNS transport (DNS over TLS, DNS over HTTPS, TSIG, SIG(0), etc.). A maliciously crafted AMTRELAY record could cause Denial of Service or redirect receivers to attacker-controlled multicast traffic.

dns, security, multicast

security-consideration §6.3

Interdomain multicast traffic carried over AMT carries congestion risks. Operators should use traffic authentication at ingest, rate-limiting, and circuit-breaker techniques (per RFC 8085) to protect network health against misconfiguration, poorly written applications, or deliberate attacks.

security, multicast, congestion

wire-format §4.2

The AMTRELAY RData consists of an 8-bit precedence field, a 1-bit Discovery Optional (D-bit), a 7-bit type field, and a variable-length relay field. Total fixed overhead is 2 octets before the relay payload.

dns, multicast