draft-ietf-mboned-driad-amt-discovery-12.txt   draft-ietf-mboned-driad-amt-discovery-13.txt 
Mboned J. Holland Mboned J. Holland
Internet-Draft Akamai Technologies, Inc. Internet-Draft Akamai Technologies, Inc.
Updates: 7450 (if approved) December 19, 2019 Updates: 7450 (if approved) December 20, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: June 21, 2020 Expires: June 22, 2020
DNS Reverse IP AMT (Automatic Multicast Tunneling) Discovery DNS Reverse IP AMT (Automatic Multicast Tunneling) Discovery
draft-ietf-mboned-driad-amt-discovery-12 draft-ietf-mboned-driad-amt-discovery-13
Abstract Abstract
This document updates RFC 7450 (Automatic Multicast Tunneling, or This document updates RFC 7450 (Automatic Multicast Tunneling, or
AMT) by modifying the relay discovery process. A new DNS resource AMT) by modifying the relay discovery process. A new DNS resource
record named AMTRELAY is defined for publishing AMT relays for record named AMTRELAY is defined for publishing AMT relays for
source-specific multicast channels. The reverse IP DNS zone for a source-specific multicast channels. The reverse IP DNS zone for a
multicast sender's IP address is configured to use AMTRELAY resource multicast sender's IP address is configured to use AMTRELAY resource
records to advertise a set of AMT relays that can receive and forward records to advertise a set of AMT relays that can receive and forward
multicast traffic from that sender over an AMT tunnel. Other multicast traffic from that sender over an AMT tunnel. Other
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 21, 2020. This Internet-Draft will expire on June 22, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1. Relays and Gateways . . . . . . . . . . . . . . . . . 4 1.2.1. Relays and Gateways . . . . . . . . . . . . . . . . . 4
1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 4 1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 4
2. Relay Discovery Operation . . . . . . . . . . . . . . . . . . 6 2. Relay Discovery Overview . . . . . . . . . . . . . . . . . . 6
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Basic Mechanics . . . . . . . . . . . . . . . . . . . . . 6
2.2. Signaling and Discovery . . . . . . . . . . . . . . . . . 6 2.2. Signaling and Discovery . . . . . . . . . . . . . . . . . 6
2.3. Optimal Relay Selection . . . . . . . . . . . . . . . . . 9 2.3. Example Deployments . . . . . . . . . . . . . . . . . . . 9
2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 9 2.3.1. Example Receiving Networks . . . . . . . . . . . . . 9
2.3.2. Preference Ordering . . . . . . . . . . . . . . . . . 10 2.3.2. Example Sending Networks . . . . . . . . . . . . . . 12
2.3.3. Connecting to Multiple Relays . . . . . . . . . . . . 13 3. Relay Discovery Operation . . . . . . . . . . . . . . . . . . 14
2.4. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . . 13 3.1. Optimal Relay Selection . . . . . . . . . . . . . . . . . 14
2.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13 3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 14
2.4.2. Algorithm Guidelines . . . . . . . . . . . . . . . . 13 3.1.2. Preference Ordering . . . . . . . . . . . . . . . . . 15
2.4.3. Connection Definition . . . . . . . . . . . . . . . . 14 3.1.3. Connecting to Multiple Relays . . . . . . . . . . . . 18
2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 15 3.2. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . . 18
2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 15 3.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 18
2.5.2. Updates to Restarting Events . . . . . . . . . . . . 16 3.2.2. Algorithm Guidelines . . . . . . . . . . . . . . . . 19
2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 17 3.2.3. Connection Definition . . . . . . . . . . . . . . . . 20
2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 17 3.3. Guidelines for Restarting Discovery . . . . . . . . . . . 20
2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 19 3.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 20
2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 19 3.3.2. Updates to Restarting Events . . . . . . . . . . . . 21
2.5.7. Independent Discovery Per Traffic Source . . . . . . 20 3.3.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 22
2.6. DNS Configuration . . . . . . . . . . . . . . . . . . . . 20 3.3.4. Traffic Health . . . . . . . . . . . . . . . . . . . 22
2.7. Waiting for DNS resolution . . . . . . . . . . . . . . . 21 3.3.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 24
3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 21 3.3.6. Relay Discovery Messages vs. Restarting Discovery . . 24
3.1. Example Receiving Networks . . . . . . . . . . . . . . . 21 3.3.7. Independent Discovery Per Traffic Source . . . . . . 25
3.1.1. Internet Service Provider . . . . . . . . . . . . . . 21 3.4. DNS Configuration . . . . . . . . . . . . . . . . . . . . 25
3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 22 3.5. Waiting for DNS resolution . . . . . . . . . . . . . . . 26
3.2. Example Sending Networks . . . . . . . . . . . . . . . . 24
3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 24
3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 25
4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 26 4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 26
4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 26 4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 26
4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 26 4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 27
4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 27 4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 27
4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 27 4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 27
4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 27 4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 28
4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 28 4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 28
4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 29
4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 28 4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 29
4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 28
4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 29 4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 29
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
6.1. Use of AMT . . . . . . . . . . . . . . . . . . . . . . . 30 6.1. Use of AMT . . . . . . . . . . . . . . . . . . . . . . . 30
6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 30 6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 31
6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 31 6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 31
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Normative References . . . . . . . . . . . . . . . . . . 32 8.1. Normative References . . . . . . . . . . . . . . . . . . 32
8.2. Informative References . . . . . . . . . . . . . . . . . 33 8.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Unknown RRType construction . . . . . . . . . . . . 35 Appendix A. Unknown RRType construction . . . . . . . . . . . . 35
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
This document defines DNS Reverse IP AMT Discovery (DRIAD), a This document defines DNS Reverse IP AMT Discovery (DRIAD), a
mechanism for AMT gateways to discover AMT relays that are capable of mechanism for AMT gateways to discover AMT relays that are capable of
forwarding multicast traffic from a known source IP address. forwarding multicast traffic from a known source IP address.
AMT (Automatic Multicast Tunneling) is defined in [RFC7450], and AMT (Automatic Multicast Tunneling) is defined in [RFC7450], and
skipping to change at page 6, line 5 skipping to change at page 6, line 5
| | | | | |
| OLT | Optical Line Terminal | | OLT | Optical Line Terminal |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Relay Discovery Operation 2. Relay Discovery Overview
2.1. Overview 2.1. Basic Mechanics
The AMTRELAY resource record (RR) defined in this document is used to 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 publish the IP address or domain name of a set of AMT relays or
discovery brokers that can receive, encapsulate, and forward discovery brokers that can receive, encapsulate, and forward
multicast traffic from a particular sender. multicast traffic from a particular sender.
The sender is the owner of the RR, and configures the zone so that it 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 contains a set of RRs that provide the addresses or domain names of
AMT relays (or discovery brokers that advertise relays) that can AMT relays (or discovery brokers that advertise relays) that can
receive multicast IP traffic from that sender. receive multicast IP traffic from that sender.
skipping to change at page 6, line 38 skipping to change at page 6, line 38
index into one of the reverse mapping trees (in-addr.arpa for IPv4, 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 as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, as
described in Section 2.5 of [RFC3596]). described in Section 2.5 of [RFC3596]).
This mechanism should be treated as an extension of the AMT relay This mechanism should be treated as an extension of the AMT relay
discovery procedure described in Section 5.2.3.4 of [RFC7450]. A discovery procedure described in Section 5.2.3.4 of [RFC7450]. A
gateway that supports this method of AMT relay discovery SHOULD use gateway that supports this method of AMT relay discovery SHOULD use
this method whenever it's performing the relay discovery procedure, this method whenever it's performing the relay discovery procedure,
and the source IP addresses for desired (S,G)s are known to the and the source IP addresses for desired (S,G)s are known to the
gateway, and conditions match the requirements outlined in gateway, and conditions match the requirements outlined in
Section 2.3. Section 3.1.
Some detailed example use cases are provided in Section 3, and other Some detailed example use cases are provided in Section 2.3, and
applicable example topologies appear in Section 3.3 of [RFC8313], other applicable example topologies appear in Section 3.3 of
Section 3.4 of [RFC8313], and Section 3.5 of [RFC8313]. [RFC8313], Section 3.4 of [RFC8313], and Section 3.5 of [RFC8313].
2.2. Signaling and Discovery 2.2. Signaling and Discovery
This section describes a typical example of the end-to-end process 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 for signaling a receiver's join of an SSM channel that relies on an
AMTRELAY RR. AMTRELAY RR.
The example in Figure 2 contains 2 multicast-enabled networks that The example in Figure 2 contains 2 multicast-enabled networks that
are both connected to the internet with non-multicast-capable links, are both connected to the internet with non-multicast-capable links,
and which have no direct association with each other. and which have no direct association with each other.
skipping to change at page 7, line 34 skipping to change at page 7, line 34
|Flow| Multicast | |Flow| Multicast |
\| |/ Network | \| |/ Network |
\ / | 5: Propagate RPF for Join(S,G) \ / | 5: Propagate RPF for Join(S,G)
\ / +---------------+ \ / +---------------+
\/ | AMT Relay | \/ | AMT Relay |
| 2001:db8:c::f | | 2001:db8:c::f |
+---------------+ +---------------+
| 4: Gateway connects to Relay, | 4: Gateway connects to Relay,
sends Join(S,G) over tunnel sends Join(S,G) over tunnel
| |
Unicast 3: --> DNS Query: type=AMTRELAY, Unicast
Tunnel | / a.0.0.0.0.0.0.0.0.0.0.0. Tunnel | 3: --> DNS Query: type=AMTRELAY,
/ 0.0.0.0.0.0.0.0.0.0.0.0. / a.0.0.0.0.0.0.0.0.0.0.0.
^ | / 8.b.d.0.1.0.0.2.ip6.arpa ^ | / 0.0.0.0.0.0.0.0.0.0.0.0.
| / | / 8.b.d.0.1.0.0.2.ip6.arpa
| | / <-- Response: | | / <-- Response:
Join/Leave +-------------+ AMTRELAY=2001:db8:c::f Join/Leave +-------------+ AMTRELAY=2001:db8:c::f
Signals | AMT gateway | Signals | AMT gateway |
| +-------------+ | +-------------+
| | 2: Propagate RPF for Join(S,G) | | 2: Propagate RPF for Join(S,G)
| Multicast | | Multicast |
Network | Network |
| 1: Join(S=2001:db8::a,G=ff3e::8000:d) | 1: Join(S=2001:db8::a,G=ff3e::8000:d)
+-------------+ +-------------+
| Receiver | | Receiver |
| (end user) | | (end user) |
skipping to change at page 9, line 10 skipping to change at page 9, line 10
In the case of an IPv4 (S,G), the only difference in the AMT relay 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 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 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, 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 232.252.0.2), the reverse IP FQDN for the AMTRELAY query would be
"12.100.51.198.in-addr.arpa.". "12.100.51.198.in-addr.arpa.".
Note that the address family of the AMT tunnel is independent of the Note that the address family of the AMT tunnel is independent of the
address family for the multicast traffic. address family for the multicast traffic.
2.3. Optimal Relay Selection 2.3. Example Deployments
2.3.1. Overview 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 which is
incapable of multicast forwarding.)
Internet
(non-multicast)
^
| Office Network
+----------|----------------------------------+
| | |
| +---------------+ (Wifi) Mobile apps |
| | Modem+ | Wifi | - - - - w/ embedded |
| | Router | AP | AMT gateways |
| +---------------+ |
| | |
| | |
| +----------------+ |
| | Legacy Router | |
| | (unicast) | |
| +----------------+ |
| / | \ |
| / | \ |
| +--------+ +--------+ +--------+=========+ |
| | Phones | | ConfRm | | Desks | AMT | |
| | subnet | | subnet | | subnet | 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, or 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 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. gateway to discover a relay that is known to the sender.
However, it is NOT necessarily a good way to discover the best relay 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 for that gateway to use, because the RR will only provide information
about relays known to the source. about relays known to the source.
If there is an upstream relay in a network that is topologically If there is an upstream relay in a network that is topologically
closer to the gateway and able to receive and forward multicast closer to the gateway and able to receive and forward multicast
traffic from the sender, that relay is better for the gateway to use, traffic from the sender, that relay is better for the gateway to use,
since more of the network path uses native multicast, allowing more since more of the network path uses native multicast, allowing more
chances for packet replication. But since that relay is not known to 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 the sender, it won't be advertised in the sender's reverse IP DNS
record. An example network that illustrates this scenario is record. An example network that illustrates this scenario is
outlined in Section 3.1.2. outlined in Figure 5 from Section 2.3.1.2.
It's only appropriate for an AMT gateway to discover an AMT relay by 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 querying an AMTRELAY RR owned by a sender when all of these
conditions are met: conditions are met:
1. The gateway needs to propagate a join of an (S,G) over AMT, 1. The gateway needs to propagate a join of an (S,G) over AMT,
because in the gateway's network, no RPF next hop toward the because in the gateway's network, no RPF next hop toward the
source can propagate a native multicast join of the (S,G); and source can propagate a native multicast join of the (S,G); and
2. The gateway is not already connected to a relay that forwards 2. The gateway is not already connected to a relay that forwards
multicast traffic from the source of the (S,G); and multicast traffic from the source of the (S,G); and
3. The gateway is not configured to use a particular IP address for 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 AMT discovery, or a relay discovered with that IP is not able to
forward traffic from the source of the (S,G); and forward traffic from the source of the (S,G); and
4. The gateway is not able to find an upstream AMT relay with DNS-SD 4. The gateway is not able to find an upstream AMT relay with DNS-SD
[RFC6763], using "_amt._udp" as the Service section of the [RFC6763], using "_amt._udp" as the Service section of the
queries, or a relay discovered this way is not able to forward queries, or a relay discovered this way is not able to forward
traffic from the source of the (S,G) (as described in traffic from the source of the (S,G) (as described in
Section 2.5.4.1 or Section 2.5.5); and Section 3.3.4.1 or Section 3.3.5); and
5. The gateway is not able to find an upstream AMT relay with the 5. The gateway is not able to find an upstream AMT relay with the
well-known anycast addresses from Section 7 of [RFC7450]. well-known anycast addresses from Section 7 of [RFC7450].
When the above conditions are met, the gateway has no path within its When the above conditions are met, the gateway has no path within its
local network that can receive multicast traffic from the source IP local network that can receive multicast traffic from the source IP
of the (S,G). of the (S,G).
In this situation, the best way to find a relay that can forward the 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 required traffic is to use information that comes from the operator
of the sender. When the sender has configured an AMTRELAY RR, of the sender. When the sender has configured an AMTRELAY RR,
gateways can use the DRIAD mechanism defined in this document to gateways can use the DRIAD mechanism defined in this document to
discover the relay information provided by the sender. discover the relay information provided by the sender.
Note that the DNS-SD service is not source-specific, so even though Note that the DNS-SD service is not source-specific, so even though
several methods of finding a more local source of multicast traffic when available, several methods of finding a more local source of
connectivity are preferred where available to using a relay provided multicast traffic connectivity are preferred to using a relay
by an AMTRELAY RR, a gateway further upstream would still be using provided by an AMTRELAY RR, a gateway further upstream would still be
the AMTRELAY RR unless the upstream network has a peering or direct using the AMTRELAY RR unless the upstream network has a peering that
connectivity that provides an alternative end-to-end multicast provides an alternative end-to-end multicast transport path for the
transport path for the (S,G)'s traffic. (S,G)'s traffic.
2.3.2. Preference Ordering 3.1.2. Preference Ordering
This section defines a preference ordering for relay addresses during This section defines a preference ordering for relay addresses during
the relay discovery process. Gateways are encouraged to implement a the relay discovery process. Gateways are encouraged to implement a
Happy Eyeballs algorithm to try candidate relays concurrently, but Happy Eyeballs algorithm to try candidate relays concurrently, but
even gateways that do not implement a Happy Eyeballs algorithm SHOULD even gateways that do not implement a Happy Eyeballs algorithm SHOULD
use this ordering, except as noted. use this ordering, except as noted.
When establishing an AMT tunnel to forward multicast data, it's very When establishing an AMT tunnel to forward multicast data, it's very
important for the discovery process to prioritize the network important for the discovery process to prioritize the network
topology considerations ahead of address selection considerations, in topology considerations ahead of address selection considerations, in
skipping to change at page 11, line 7 skipping to change at page 16, line 28
considerations. considerations.
Section 4 of [RFC8305] requires a Happy Eyeballs algorithm to sort Section 4 of [RFC8305] requires a Happy Eyeballs algorithm to sort
the addresses with the Destination Address Selection defined in the addresses with the Destination Address Selection defined in
Section 6 of [RFC6724], but for the above reasons, that requirement Section 6 of [RFC6724], but for the above reasons, that requirement
is superseded in the AMT discovery use case by the following is superseded in the AMT discovery use case by the following
considerations: considerations:
o Prefer Local Relays o Prefer Local Relays
Figure 5 and Section 3.1.2 provide a motivating example to prefer Figure 5 and Section 2.3.1.2 provide a motivating example to
DNS-SD [RFC6763] for discovery strictly ahead of using the prefer DNS-SD [RFC6763] for discovery strictly ahead of using the
AMTRELAY RR controlled by the sender for AMT discovery. AMTRELAY RR controlled by the sender for AMT discovery.
For this reason, it's RECOMMENDED that AMT gateways by default For this reason, it's RECOMMENDED that AMT gateways by default
perform service discovery using DNS Service Discovery (DNS-SD) perform service discovery using DNS Service Discovery (DNS-SD)
[RFC6763] for _amt._udp.<domain> (with <domain> chosen as [RFC6763] for _amt._udp.<domain> (with <domain> chosen as
described in Section 11 of [RFC6763]) and use the AMT relays described in Section 11 of [RFC6763]) and use the AMT relays
discovered that way in preference to AMT relays discoverable via discovered that way in preference to AMT relays discoverable via
the mechanism defined in this document (DRIAD). the mechanism defined in this document (DRIAD).
o Prefer Relays Managed by the Containing Network o Prefer Relays Managed by the Containing Network
skipping to change at page 11, line 37 skipping to change at page 17, line 13
to the relay most appropriate to the receiver's gateway. to the relay most appropriate to the receiver's gateway.
Accordingly, the gateway SHOULD by default discover a relay with Accordingly, the gateway SHOULD by default discover a relay with
the well-known AMT anycast addresses as the second preference the well-known AMT anycast addresses as the second preference
after DNS-SD when searching for a local relay. after DNS-SD when searching for a local relay.
o Let Sender Manage Relay Provisioning o Let Sender Manage Relay Provisioning
A related motivating example is provided by considering a sender A related motivating example is provided by considering a sender
whose traffic can be forwarded by relays in a sender-controlled whose traffic can be forwarded by relays in a sender-controlled
network like Figure 6 in Section 3.2.1, and also by relays in a network like Figure 6 in Section 2.3.2.1, and also by relays in a
provider-controlled network like Figure 7 in Section 3.2.2, with provider-controlled network like Figure 7 in Section 2.3.2.2, with
different cost and scalability profiles for the different options. different cost and scalability profiles for the different options.
In this example about the sending-side network, the precedence In this example about the sending-side network, the precedence
field described in Section 4.2.1 is a critical method of control field described in Section 4.2.1 is a critical method of control
so that senders can provide the appropriate guidance to gateways so that senders can provide the appropriate guidance to gateways
during the discovery process, in order to manage load and failover during the discovery process, in order to manage load and failover
scenarios in a manner that operates well with the sender's scenarios in a manner that operates well with the sender's
provisioning strategy for horizontal scaling of AMT relays. provisioning strategy for horizontal scaling of AMT relays.
Therefore, after DNS-SD, the precedence from the RR MUST be used Therefore, after DNS-SD, the precedence from the RR MUST be used
skipping to change at page 12, line 41 skipping to change at page 18, line 17
structure and collection of this information are out of scope for structure and collection of this information are out of scope for
this document, but a gateway in possession of such information MAY this document, but a gateway in possession of such information MAY
use it to prefer topologically closer relays. use it to prefer topologically closer relays.
Within the above constraints, gateways MAY make use of other Within the above constraints, gateways MAY make use of other
considerations from Section 4 of [RFC8305], such as the address considerations from Section 4 of [RFC8305], such as the address
family interleaving strategies, to produce a final ordering of family interleaving strategies, to produce a final ordering of
candidate relay addresses. candidate relay addresses.
Note also that certain relay addresses might be excluded from Note also that certain relay addresses might be excluded from
consideration by the hold-down timers described in Section 2.5.4.1 or consideration by the hold-down timers described in Section 3.3.4.1 or
Section 2.5.5. These relays constitute "unusable destinations" under Section 3.3.5. These relays constitute "unusable destinations" under
Rule 1 of the Destination Address Selection, and are also not part of Rule 1 of the Destination Address Selection, and are also not part of
the superseding considerations described above. the superseding considerations described above.
The discovery and connection process for the relay addresses in the The discovery and connection process for the relay addresses in the
above described ordering MAY operate in parallel, subject to delays above described ordering MAY operate in parallel, subject to delays
prescribed by the Happy Eyeballs requirements described in Section 5 prescribed by the Happy Eyeballs requirements described in Section 5
of [RFC8305] for successively launched concurrent connection of [RFC8305] for successively launched concurrent connection
attempts. attempts.
2.3.3. Connecting to Multiple Relays 3.1.3. Connecting to Multiple Relays
In some deployments, it may be useful for a gateway to connect to In some deployments, it may be useful for a gateway to connect to
multiple upstream relays and subscribe to the same traffic, in order multiple upstream relays and subscribe to the same traffic, in order
to support an active/active failover model. A gateway SHOULD NOT be to support an active/active failover model. A gateway SHOULD NOT be
configured to do so without guaranteeing that adequate bandwidth is configured to do so without guaranteeing that adequate bandwidth is
available. available.
A gateway configured to do this SHOULD still use the same preference A gateway configured to do this SHOULD still use the same preference
ordering logic from Section 2.3.2 for each connection. (Note that ordering logic from Section 3.1.2 for each connection. (Note that
this ordering allows for overriding by explicit administrative this ordering allows for overriding by explicit administrative
configuration where required.) configuration where required.)
2.4. Happy Eyeballs 3.2. Happy Eyeballs
2.4.1. Overview 3.2.1. Overview
Often, multiple choices of relay will exist for a gateway using DRIAD Often, multiple choices of relay will exist for a gateway using DRIAD
for relay discovery. Happy Eyeballs [RFC8305] provides a widely for relay discovery. Happy Eyeballs [RFC8305] provides a widely
deployed and generalizable strategy for probing multiple possible deployed and generalizable strategy for probing multiple possible
connections in parallel, therefore it is RECOMMENDED that DRIAD- connections in parallel, therefore it is RECOMMENDED that DRIAD-
capable gateways implement a Happy Eyeballs algorithm to support fast capable gateways implement a Happy Eyeballs algorithm to support fast
discovery of the most preferred available relay, by probing multiple discovery of the most preferred available relay, by probing multiple
relays concurrently. relays concurrently.
The parallel discovery logic of a Happy Eyeballs algorithm serves to The parallel discovery logic of a Happy Eyeballs algorithm serves to
reduce join latency for the initial join of an SSM channel. This reduce join latency for the initial join of an SSM channel. This
section and the preference ordering of relays defined in section and the preference ordering of relays defined in
Section 2.3.2 taken together provide guidance on use of a Happy Section 3.1.2 taken together provide guidance on use of a Happy
Eyeballs algorithm for the case of establishing AMT connections. Eyeballs algorithm for the case of establishing AMT connections.
Note that according to the definition in Section 2.4.3 of this Note that according to the definition in Section 3.2.3 of this
document, establishing the connection occurs before sending a document, establishing the connection occurs before sending a
membership report. As described in Section 5 of [RFC8305], only one membership report. As described in Section 5 of [RFC8305], only one
of the successful connections will be used, and the others are all of the successful connections will be used, and the others are all
canceled or ignored. In the context of an AMT connection, this means canceled or ignored. In the context of an AMT connection, this means
the gateway will send the membership reports that subscribe to the gateway will send the membership reports that subscribe to
traffic only for the chosen connection, after the Happy Eyeballs traffic only for the chosen connection, after the Happy Eyeballs
algorithm resolves. algorithm resolves.
2.4.2. Algorithm Guidelines 3.2.2. Algorithm Guidelines
During the "Initiation of asynchronous DNS queries" phase described During the "Initiation of asynchronous DNS queries" phase described
in Section 3 of [RFC8305]), a gateway attempts to resolve the domain in Section 3 of [RFC8305]), a gateway attempts to resolve the domain
names listed in Section 2.3. This consists of resolving the SRV 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 queries for DNS-SD domains for the AMT service, as well as the
AMTRELAY query for the reverse IP domain defined in this document. AMTRELAY query for the reverse IP domain defined in this document.
Each of the SRV and AMTRELAY responses might contain one or more IP 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 addresses, (as with type 1 or type 2 AMTRELAY responses, or when the
SRV Additional Data section of the SRV response contains the address SRV Additional Data section of the SRV response contains the address
records for the target, as urged by [RFC2782]), or they might contain records for the target, as urged by [RFC2782]), or they might contain
only domain names (as with type 3 responses from Section 4.2.3, or an only domain names (as with type 3 responses from Section 4.2.3, or an
SRV response without an additional data section). SRV response without an additional data section).
skipping to change at page 14, line 33 skipping to change at page 20, line 7
follow ordinary standards and best practices for DNS clients. A follow ordinary standards and best practices for DNS clients. A
gateway MAY use an existing DNS client implementation that does so, gateway MAY use an existing DNS client implementation that does so,
and MAY rely on that client's rate limiting logic to avoid issuing and MAY rely on that client's rate limiting logic to avoid issuing
excessive queries. Otherwise, a gateway MUST provide a rate limit excessive queries. Otherwise, a gateway MUST provide a rate limit
for the DNS queries, and its default settings SHOULD NOT permit more for the DNS queries, and its default settings SHOULD NOT permit more
than 10 queries for any 100-millisecond period (though this MAY be than 10 queries for any 100-millisecond period (though this MAY be
overridable by administrative configuration). overridable by administrative configuration).
As the resolved IP addresses arrive, the Happy Eyeballs algorithm As the resolved IP addresses arrive, the Happy Eyeballs algorithm
sorts them according to the requirements and recommendations given in sorts them according to the requirements and recommendations given in
Section 2.3.2, and attempts connections with the corresponding relays Section 3.1.2, and attempts connections with the corresponding relays
under the algorithm restrictions and guidelines given in [RFC8305] under the algorithm restrictions and guidelines given in [RFC8305]
for the "Establishment of one connection, which cancels all other for the "Establishment of one connection, which cancels all other
attempts" phase. As described in Section 3 of [RFC8305], DNS attempts" phase. As described in Section 3 of [RFC8305], DNS
resolution is treated as asynchronous, and connection initiation does resolution is treated as asynchronous, and connection initiation does
not wait for lagging DNS responses. not wait for lagging DNS responses.
2.4.3. Connection Definition 3.2.3. Connection Definition
Section 5 of [RFC8305] non-normatively describes success at a Section 5 of [RFC8305] non-normatively describes success at a
connection attempt as "generally when the TCP handshake completes". connection attempt as "generally when the TCP handshake completes".
There is no normative definition of a connection in the AMT There is no normative definition of a connection in the AMT
specification [RFC7450], and there is no TCP connection involved in specification [RFC7450], and there is no TCP connection involved in
an AMT tunnel. an AMT tunnel.
However, the concept of an AMT connection in the context of a Happy 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 Eyeballs algorithm is a useful one, and so this section provides the
following normative definition: following normative definition:
o An AMT connection is established successfully when the gateway o An AMT connection is established successfully when the gateway
receives from a newly discovered relay a valid Membership Query receives from a newly discovered relay a valid Membership Query
message (Section 5.1.4 of [RFC7450]) that does not have the L flag message (Section 5.1.4 of [RFC7450]) that does not have the L flag
set. set.
See Section 2.5.5 of this document for further information about the 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 relevance of the L flag to the establishment of a Happy Eyeballs
connection. See Section 2.5.4 for an overview of how to respond if connection. See Section 3.3.4 for an overview of how to respond if
the connection does not provide multicast connectivity to the source. the connection does not provide multicast connectivity to the source.
To "cancel" this kind of AMT connection for the Happy Eyeballs To "cancel" this kind of AMT connection for the Happy Eyeballs
algorithm, a gateway that has not sent a membership report with a algorithm, a gateway that has not sent a membership report with a
subscription would simply stop sending AMT packets for that subscription would simply stop sending AMT packets for that
connection. A gateway only sends a membership report to a connection connection. A gateway only sends a membership report to a connection
it has chosen as the most preferred available connection. it has chosen as the most preferred available connection.
2.5. Guidelines for Restarting Discovery 3.3. Guidelines for Restarting Discovery
2.5.1. Overview 3.3.1. Overview
It's expected that gateways deployed in different environments will It's expected that gateways deployed in different environments will
use a variety of heuristics to decide when it's appropriate to use a variety of heuristics to decide when it's appropriate to
restart the relay discovery process, in order to meet different restart the relay discovery process, in order to meet different
performance goals (for example, to fulfill different kinds of service performance goals (for example, to fulfill different kinds of service
level agreements). level agreements).
In general, restarting the discovery process is always safe for the In general, restarting the discovery process is always safe for the
gateway and relay during any of the events listed in this section, gateway and relay during any of the events listed in this section,
but may cause a disruption in the forwarded traffic if the discovery but may cause a disruption in the forwarded traffic if the discovery
skipping to change at page 16, line 9 skipping to change at page 21, line 29
Balancing the expected impact on the tunneled traffic against likely Balancing the expected impact on the tunneled traffic against likely
or observed problems with an existing connection to the relay is the or observed problems with an existing connection to the relay is the
goal of the heuristics that gateways use to determine when to restart goal of the heuristics that gateways use to determine when to restart
the discovery process. the discovery process.
The non-normative advice in this section should be treated as The non-normative advice in this section should be treated as
guidelines to operators and implementors working with AMT systems guidelines to operators and implementors working with AMT systems
that can use DRIAD as part of the relay discovery process. that can use DRIAD as part of the relay discovery process.
2.5.2. Updates to Restarting Events 3.3.2. Updates to Restarting Events
Section 5.2.3.4.1 of [RFC7450] lists several events that may cause a Section 5.2.3.4.1 of [RFC7450] lists several events that may cause a
gateway to start or restart the discovery procedure. gateway to start or restart the discovery procedure.
This document provides some updates and recommendations regarding the This document provides some updates and recommendations regarding the
handling of these and similar events. The first 5 events are copied handling of these and similar events. The first 5 events are copied
here and numbered for easier reference, and the remaining 4 events here and numbered for easier reference, and the remaining 4 events
are newly added for consideration in this document: are newly added for consideration in this document:
1. When a gateway pseudo-interface is started (enabled). 1. When a gateway pseudo-interface is started (enabled).
skipping to change at page 16, line 48 skipping to change at page 22, line 20
gateway is operating inside an end user device or application, gateway is operating inside an end user device or application,
and the device joins a different network, or when the domain and the device joins a different network, or when the domain
portion of a DNS-SD domain name changes in response to a DHCP portion of a DNS-SD domain name changes in response to a DHCP
message or administrative configuration. message or administrative configuration.
8. When substantial loss, persistent congestion, or network overload 8. When substantial loss, persistent congestion, or network overload
is detected in the stream of AMT packets from a relay. is detected in the stream of AMT packets from a relay.
9. When the gateway has reported one or more (S,G) subscriptions, 9. When the gateway has reported one or more (S,G) subscriptions,
but no traffic is received from the source for some timeout. but no traffic is received from the source for some timeout.
(See Section 2.5.4.1). (See Section 3.3.4.1).
This list is not exhaustive, nor are any of the listed events This list is not exhaustive, nor are any of the listed events
strictly required to always force a restart of the discovery process. 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 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. have sufficient information to use DRIAD, since no source is known.
2.5.3. Tunnel Stability 3.3.3. Tunnel Stability
In general, subscribers to active traffic flows that are being In general, subscribers to active traffic flows that are being
forwarded by an AMT gateway are less likely to experience a forwarded by an AMT gateway are less likely to experience a
degradation in service (for example, from missing or duplicated degradation in service (for example, from missing or duplicated
packets) when the gateway continues using the same relay, as long as packets) when the gateway continues using the same relay, as long as
the relay is not overloaded and the network conditions remain stable. the relay is not overloaded and the network conditions remain stable.
Therefore, gateways SHOULD avoid performing a full restart of the Therefore, gateways SHOULD avoid performing a full restart of the
discovery process during routine cases of event #3 (sending a new discovery process during routine cases of event #3 (sending a new
Request message), since it occurs frequently in normal operation. Request message), since it occurs frequently in normal operation.
However, see Section 2.5.4, Section 2.5.6, and Section 2.5.4.3 for However, see Section 3.3.4, Section 3.3.6, and Section 3.3.4.3 for
more information about exceptional cases when it may be appropriate more information about exceptional cases when it may be appropriate
to use event #3. to use event #3.
2.5.4. Traffic Health 3.3.4. Traffic Health
2.5.4.1. Absence of Traffic 3.3.4.1. Absence of Traffic
If a gateway indicates one or more (S,G) subscriptions in a 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 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 received in a reasonable time, it's appropriate for the gateway to
restart the discovery process. restart the discovery process.
If the gateway restarts the discovery process multiple times If the gateway restarts the discovery process multiple times
consecutively for this reason, the timeout period SHOULD be adjusted consecutively for this reason, the timeout period SHOULD be adjusted
to provide a random exponential back-off. to provide a random exponential back-off.
skipping to change at page 18, line 8 skipping to change at page 23, line 29
adjusted to support performance requirements, operators are advised adjusted to support performance requirements, operators are advised
to consider the possibility of join propagation delays between the to consider the possibility of join propagation delays between the
sender and the relay when choosing an appropriate timeout value. sender and the relay when choosing an appropriate timeout value.
Gateways restarting the discovery process because of an absence of Gateways restarting the discovery process because of an absence of
traffic MUST use a hold-down timer that removes this relay from traffic MUST use a hold-down timer that removes this relay from
consideration during subsequent rounds of discovery while active. consideration during subsequent rounds of discovery while active.
The hold-down SHOULD last for no less than 3 minutes and no more than The hold-down SHOULD last for no less than 3 minutes and no more than
10 minutes. 10 minutes.
2.5.4.2. Loss and Congestion 3.3.4.2. Loss and Congestion
In some gateway deployments, it is also feasible to monitor the In some gateway deployments, it is also feasible to monitor the
health of traffic flows through the gateway, for example by detecting health of traffic flows through the gateway, for example by detecting
the rate of packet loss by communicating out of band with receivers, the rate of packet loss by communicating out of band with receivers,
or monitoring the packets of known protocols with sequence numbers. or monitoring the packets of known protocols with sequence numbers.
Where feasible, it's encouraged for gateways to use such traffic Where feasible, it's encouraged for gateways to use such traffic
health information to trigger a restart of the discovery process health information to trigger a restart of the discovery process
during event #3 (before sending a new Request message). during event #3 (before sending a new Request message).
However, to avoid synchronized rediscovery by many gateways However, to avoid synchronized rediscovery by many gateways
simultaneously after a transient network event upstream of a relay simultaneously after a transient network event upstream of a relay
results in many receivers detecting poor flow health at the same results in many receivers detecting poor flow health at the same
time, it's recommended to add a random delay before restarting the time, it's recommended to add a random delay before restarting the
discovery process in this case. discovery process in this case.
The span of the random portion of the delay should be no less than 10 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 seconds by default, but may be administratively configured to support
different performance requirements. different performance requirements.
2.5.4.3. Ancient Discovery Information 3.3.4.3. Ancient Discovery Information
In most cases, a gateway actively receiving healthy traffic from a In most cases, a gateway actively receiving healthy traffic from a
relay that has not indicated load with the L flag should prefer to relay that has not indicated load with the L flag should prefer to
remain connected to the same relay, as described in Section 2.5.3. remain connected to the same relay, as described in Section 3.3.3.
However, a relay that appears healthy but has been forwarding traffic However, a relay that appears healthy but has been forwarding traffic
for days or weeks may have an increased chance of becoming unstable. for days or weeks may have an increased chance of becoming unstable.
Gateways may benefit from restarting the discovery process during Gateways may benefit from restarting the discovery process during
event #3 (before sending a Request message) after the expiration of a 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 long-term timeout, on the order of multiple hours, or even days in
some deployments. some deployments.
It may be beneficial for such timers to consider the amount of It may be beneficial for such timers to consider the amount of
traffic currently being forwarded, and to give a higher probability traffic currently being forwarded, and to give a higher probability
of restarting discovery during periods with an unusually low data of restarting discovery during periods with an unusually low data
rate, to reduce the impact on active traffic while still avoiding rate, to reduce the impact on active traffic while still avoiding
relying on the results of a very old discovery. relying on the results of a very old discovery.
Other issues may also be worth considering as part of this heuristic; 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 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 discover the current relay has not passed, the long term timer might
be restarted without restarting the discovery process. be restarted without restarting the discovery process.
2.5.5. Relay Loaded or Shutting Down 3.3.5. Relay Loaded or Shutting Down
The L flag (see Section 5.1.4.4 of [RFC7450]) is the preferred 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 mechanism for a relay to signal overloading or a graceful shutdown to
gateways. gateways.
A gateway that supports handling of the L flag should generally A gateway that supports handling of the L flag should generally
restart the discovery process when it processes a Membership Query restart the discovery process when it processes a Membership Query
packet with the L flag set. If an L flag is received while a packet with the L flag set. If an L flag is received while a
concurrent Happy Eyeballs discovery process is under way for multiple concurrent Happy Eyeballs discovery process is under way for multiple
candidate relays (Section 2.4), the relay sending the L flag SHOULD candidate relays (Section 3.2), the relay sending the L flag SHOULD
NOT be considered for the relay selection. NOT be considered for the relay selection.
It is also RECOMMENDED that gateways avoid choosing a relay that has It is also RECOMMENDED that gateways avoid choosing a relay that has
recently sent an L flag, with approximately a 10-minute hold-down. 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 Gateways SHOULD treat this hold-down timer in the same way as the
hold-down in Section 2.5.4.1, so that the relay is removed from hold-down in Section 3.3.4.1, so that the relay is removed from
consideration for short-term subsequent rounds of discovery. consideration for short-term subsequent rounds of discovery.
2.5.6. Relay Discovery Messages vs. Restarting Discovery 3.3.6. Relay Discovery Messages vs. Restarting Discovery
All AMT relays are required by [RFC7450] to support handling of Relay All AMT relays are required by [RFC7450] to support handling of Relay
Discovery messages (e.g. in Section 5.3.3.2 of [RFC7450]). 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 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 Discovery message to the unicast address of that AMT relay. Under
stable conditions with an unloaded relay, it's expected that the stable conditions with an unloaded relay, it's expected that the
relay will return its own unicast address in the Relay Advertisement, relay will return its own unicast address in the Relay Advertisement,
in response to such a Relay Discovery message. Since this will not in response to such a Relay Discovery message. Since this will not
result in the gateway changing to another relay unless the relay result in the gateway changing to another relay unless the relay
directs the gateway away, this is a reasonable exception to the directs the gateway away, this is a reasonable exception to the
advice against handling event #3 described in Section 2.5.3. advice against handling event #3 described in Section 3.3.3.
This behavior is discouraged for gateways that do support the L flag, This behavior is discouraged for gateways that do support the L flag,
to avoid sending unnecessary packets over the network. to avoid sending unnecessary packets over the network.
However, gateways that do not support the L flag may be able to avoid 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 a disruption in the forwarded traffic by sending such Relay Discovery
messages regularly. When a relay is under load or has started a messages regularly. When a relay is under load or has started a
graceful shutdown, it may respond with a different relay address, graceful shutdown, it may respond with a different relay address,
which the gateway can use to connect to a different relay. This kind which the gateway can use to connect to a different relay. This kind
of coordinated handoff will likely result in a smaller disruption to of coordinated handoff will likely result in a smaller disruption to
skipping to change at page 20, line 9 skipping to change at page 25, line 34
messages, and stops forwarding traffic. messages, and stops forwarding traffic.
This style of Relay Discovery message (one sent to the unicast This style of Relay Discovery message (one sent to the unicast
address of a relay that's already forwarding traffic to this gateway) address of a relay that's already forwarding traffic to this gateway)
SHOULD NOT be considered a full restart of the relay discovery SHOULD NOT be considered a full restart of the relay discovery
process. It is RECOMMENDED for gateways to support the L flag, but process. It is RECOMMENDED for gateways to support the L flag, but
for gateways that do not support the L flag, sending this message for gateways that do not support the L flag, sending this message
during event #3 may help mitigate service degradation when relays during event #3 may help mitigate service degradation when relays
become unstable. become unstable.
2.5.7. Independent Discovery Per Traffic Source 3.3.7. Independent Discovery Per Traffic Source
Relays discovered via the AMTRELAY RR are source-specific relay Relays discovered via the AMTRELAY RR are source-specific relay
addresses, and may use different pseudo-interfaces from each other addresses, and may use different pseudo-interfaces from each other
and from relays discovered via DNS-SD or a non-source-specific and from relays discovered via DNS-SD or a non-source-specific
address, as described in Section 4.1.2.1 of [RFC7450]. address, as described in Section 4.1.2.1 of [RFC7450].
Restarting the discovery process for one pseudo-interface does not Restarting the discovery process for one pseudo-interface does not
require restarting the discovery process for other pseudo-interfaces. require restarting the discovery process for other pseudo-interfaces.
Gateway heuristics about restarting the discovery process should Gateway heuristics about restarting the discovery process should
operate independently for different tunnels to relays, when operate independently for different tunnels to relays, when
responding to events that are specific to the different tunnels. responding to events that are specific to the different tunnels.
2.6. DNS Configuration 3.4. DNS Configuration
Often an AMT gateway will only have access to the source and group IP 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 addresses of the desired traffic, and will not know any other name
for the source of the traffic. Because of this, typically the best 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 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 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, IPv4, as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6,
as described in Section 2.5 of [RFC3596]). as described in Section 2.5 of [RFC3596]).
Therefore, it is RECOMMENDED that AMTRELAY RRs be added to reverse IP Therefore, it is RECOMMENDED that AMTRELAY RRs be added to reverse IP
skipping to change at page 21, line 5 skipping to change at page 26, line 24
This document does not define semantics for the use of AMTRELAY This document does not define semantics for the use of AMTRELAY
records obtained in a way other than by a reverse IP lookup. records obtained in a way other than by a reverse IP lookup.
When performing the AMTRELAY RR lookup, any CNAMEs or DNAMEs found When performing the AMTRELAY RR lookup, any CNAMEs or DNAMEs found
MUST be followed. This is necessary to support zone delegation. MUST be followed. This is necessary to support zone delegation.
Some examples outlining this need are described in [RFC2317]. Some examples outlining this need are described in [RFC2317].
See Section 4 and Section 4.3 for a detailed explanation of the See Section 4 and Section 4.3 for a detailed explanation of the
contents for a DNS Zone file. contents for a DNS Zone file.
2.7. Waiting for DNS resolution 3.5. Waiting for DNS resolution
The DNS query functionality is expected to follow ordinary standards The DNS query functionality is expected to follow ordinary standards
and best practices for DNS clients. A gateway MAY use an existing 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 DNS client implementation that does so, and MAY rely on that client's
retry logic to determine the timeouts between retries. retry logic to determine the timeouts between retries.
Otherwise, a gateway MAY re-send a DNS query if it does not receive Otherwise, a gateway MAY re-send a DNS query if it does not receive
an appropriate DNS response within some timeout period. If the an appropriate DNS response within some timeout period. If the
gateway retries multiple times, the timeout period SHOULD be adjusted gateway retries multiple times, the timeout period SHOULD be adjusted
to provide a random exponential back-off. to provide a random exponential back-off.
As with the waiting process for the Relay Advertisement message from 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 Section 5.2.3.4.3 of [RFC7450], the RECOMMENDED timeout is a random
value in the range [initial_timeout, MIN(initial_timeout * value in the range [initial_timeout, MIN(initial_timeout *
2^retry_count, maximum_timeout)], with a RECOMMENDED initial_timeout 2^retry_count, maximum_timeout)], with a RECOMMENDED initial_timeout
of 1 second and a RECOMMENDED maximum_timeout of 120 seconds. of 1 second and a RECOMMENDED maximum_timeout of 120 seconds.
3. Example Deployments
3.1. Example Receiving Networks
3.1.1. Internet Service Provider
One example of a receiving network 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 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
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 which is
incapable of multicast forwarding.)
Internet
(non-multicast)
^
| Office Network
+----------|----------------------------------+
| | |
| +---------------+ (Wifi) Mobile apps |
| | Modem+ | Wifi | - - - - w/ embedded |
| | Router | AP | AMT gateways |
| +---------------+ |
| | |
| | |
| +----------------+ |
| | Legacy Router | |
| | (unicast) | |
| +----------------+ |
| / | \ |
| / | \ |
| +--------+ +--------+ +--------+=========+ |
| | Phones | | ConfRm | | Desks | AMT | |
| | subnet | | subnet | | subnet | 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 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.
3.2. Example Sending Networks
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, or 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
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
4. AMTRELAY Resource Record Definition 4. AMTRELAY Resource Record Definition
4.1. AMTRELAY RRType 4.1. AMTRELAY RRType
The AMTRELAY RRType has the mnemonic AMTRELAY and type code 260 The AMTRELAY RRType has the mnemonic AMTRELAY and type code 260
(decimal). (decimal).
The AMTRELAY RR is class independent. The AMTRELAY RR is class independent.
4.2. AMTRELAY RData Format 4.2. AMTRELAY RData Format
skipping to change at page 30, line 45 skipping to change at page 31, line 14
AMT gateway are advised to carefully consider the security AMT gateway are advised to carefully consider the security
considerations in Section 6 of [RFC7450]. considerations in Section 6 of [RFC7450].
AMT gateway operators also are encouraged to take appropriate steps AMT gateway operators also are encouraged to take appropriate steps
to ensure the integrity of the data received via AMT, for example by to ensure the integrity of the data received via AMT, for example by
the opportunistic use of IPSec [RFC4301] to secure traffic received the opportunistic use of IPSec [RFC4301] to secure traffic received
from AMT relays, when IPSECKEY records [RFC4025] are available or from AMT relays, when IPSECKEY records [RFC4025] are available or
when a trust relationship with the AMT relays can be otherwise when a trust relationship with the AMT relays can be otherwise
established and secured. established and secured.
Note that AMT does not itself provide any integrity protection on
Multicast Data packets (Section 5.1.6 of [RFC7450]), so absent
protections like those mentioned above, even an off-path attacker who
discovers the gateway IP, the relay IP, and the relay source port for
an active AMT connection can inject multicast data packets for a
joined (S,G) into the data stream if he can get data packets
delivered to the gateway IP that spoof the relay as the source.
6.2. Record-spoofing 6.2. Record-spoofing
The AMTRELAY resource record contains information that SHOULD be The AMTRELAY resource record contains information that SHOULD be
communicated to the DNS client without being modified. The method communicated to the DNS client without being modified. The method
used to ensure the result was unmodified is up to the client. used to ensure the result was unmodified is up to the client.
There must be a trust relationship between the end consumer of this There must be a trust relationship between the end consumer of this
resource record and the DNS server. This relationship may be end-to- resource record and the DNS server. This relationship may be end-to-
end DNSSEC validation, or a secure connection to a trusted DNS server end DNSSEC validation, or a secure connection to a trusted DNS server
that provides end-to-end safety, to prevent record-spoofing of the that provides end-to-end safety, to prevent record-spoofing of the
skipping to change at page 31, line 43 skipping to change at page 32, line 21
risk. risk.
7. Acknowledgements 7. Acknowledgements
This specification was inspired by the previous work of Doug Nortz, This specification was inspired by the previous work of Doug Nortz,
Robert Sayko, David Segelstein, and Percy Tarapore, presented in the Robert Sayko, David Segelstein, and Percy Tarapore, presented in the
MBONED working group at IETF 93. MBONED working group at IETF 93.
Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny
Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, Ben Kaduk, Bill Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, Ben Kaduk, Bill
Atwood, Tim Chown, Warren Kumari, Dan Romanescu, Bernard Aboba, Atwood, Tim Chown, Christian Worm Mortensen, Warren Kumari, Dan
Carlos Pignataro, Niclas Comstedt, Mirja Kuehlewind, Henning Rogge, Romanescu, Bernard Aboba, Carlos Pignataro, Niclas Comstedt, Mirja
Eric Vyncke, Barry Lieba, Roman Danyliw, Alissa Cooper, Suresh Kuehlewind, Henning Rogge, Eric Vyncke, Barry Lieba, Roman Danyliw,
Krishnan, Adam Roach, and Daniel Franke for their very helpful Alissa Cooper, Suresh Krishnan, Adam Roach, and Daniel Franke for
reviews and comments. their very helpful reviews and comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
 End of changes. 62 change blocks. 
305 lines changed or deleted 312 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/