draft-ietf-mboned-driad-amt-discovery-13.txt   rfc8777.txt 
Mboned J. Holland Internet Engineering Task Force (IETF) J. Holland
Internet-Draft Akamai Technologies, Inc. Request for Comments: 8777 Akamai Technologies, Inc.
Updates: 7450 (if approved) December 20, 2019 Updates: 7450 April 2020
Intended status: Standards Track Category: Standards Track
Expires: June 22, 2020 ISSN: 2070-1721
DNS Reverse IP AMT (Automatic Multicast Tunneling) Discovery DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery
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
extensions and clarifications to the relay discovery process are also extensions and clarifications to the relay discovery process are also
defined. defined.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on June 22, 2020. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8777.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology
1.2.1. Relays and Gateways . . . . . . . . . . . . . . . . . 4 1.2.1. Relays and Gateways
1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 4 1.2.2. Definitions
2. Relay Discovery Overview . . . . . . . . . . . . . . . . . . 6 1.2.3. Requirements Language
2.1. Basic Mechanics . . . . . . . . . . . . . . . . . . . . . 6 2. Relay Discovery Overview
2.2. Signaling and Discovery . . . . . . . . . . . . . . . . . 6 2.1. Basic Mechanics
2.3. Example Deployments . . . . . . . . . . . . . . . . . . . 9 2.2. Signaling and Discovery
2.3.1. Example Receiving Networks . . . . . . . . . . . . . 9 2.3. Example Deployments
2.3.2. Example Sending Networks . . . . . . . . . . . . . . 12 2.3.1. Example Receiving Networks
3. Relay Discovery Operation . . . . . . . . . . . . . . . . . . 14 2.3.2. Example Sending Networks
3.1. Optimal Relay Selection . . . . . . . . . . . . . . . . . 14 3. Relay Discovery Operation
3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Optimal Relay Selection
3.1.2. Preference Ordering . . . . . . . . . . . . . . . . . 15 3.1.1. Overview
3.1.3. Connecting to Multiple Relays . . . . . . . . . . . . 18 3.1.2. Preference Ordering
3.2. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . . 18 3.1.3. Connecting to Multiple Relays
3.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 18 3.2. Happy Eyeballs
3.2.2. Algorithm Guidelines . . . . . . . . . . . . . . . . 19 3.2.1. Overview
3.2.3. Connection Definition . . . . . . . . . . . . . . . . 20 3.2.2. Algorithm Guidelines
3.3. Guidelines for Restarting Discovery . . . . . . . . . . . 20 3.2.3. Connection Definition
3.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 20 3.3. Guidelines for Restarting Discovery
3.3.2. Updates to Restarting Events . . . . . . . . . . . . 21 3.3.1. Overview
3.3.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 22 3.3.2. Updates to Restarting Events
3.3.4. Traffic Health . . . . . . . . . . . . . . . . . . . 22 3.3.3. Tunnel Stability
3.3.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 24 3.3.4. Traffic Health
3.3.6. Relay Discovery Messages vs. Restarting Discovery . . 24 3.3.5. Relay Loaded or Shutting Down
3.3.7. Independent Discovery Per Traffic Source . . . . . . 25 3.3.6. Relay Discovery Messages vs. Restarting Discovery
3.4. DNS Configuration . . . . . . . . . . . . . . . . . . . . 25 3.3.7. Independent Discovery per Traffic Source
3.5. Waiting for DNS resolution . . . . . . . . . . . . . . . 26 3.4. DNS Configuration
4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 26 3.5. Waiting for DNS Resolution
4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 26 4. AMTRELAY Resource Record Definition
4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 27 4.1. AMTRELAY RRType
4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 27 4.2. AMTRELAY RData Format
4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 27 4.2.1. RData Format - Precedence
4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 28 4.2.2. RData Format - Discovery Optional (D-bit)
4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 28 4.2.3. RData Format - Type
4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 29 4.2.4. RData Format - Relay
4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 29 4.3. AMTRELAY Record Presentation Format
4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 29 4.3.1. Representation of AMTRELAY RRs
4.3.2. Examples
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 5. IANA Considerations
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6. Security Considerations
6.1. Use of AMT . . . . . . . . . . . . . . . . . . . . . . . 30 6.1. Use of AMT
6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 31 6.2. Record-Spoofing
6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 31 6.3. Congestion
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 7. References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.1. Normative References
8.1. Normative References . . . . . . . . . . . . . . . . . . 32 7.2. Informative References
8.2. Informative References . . . . . . . . . . . . . . . . . 34 Appendix A. Unknown RRType Construction
Appendix A. Unknown RRType construction . . . . . . . . . . . . 35 Acknowledgements
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36 Author's Address
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
provides a method to transport multicast traffic over a unicast provides a method to transport multicast traffic over a unicast
tunnel, in order to traverse non-multicast-capable network segments. tunnel in order to traverse network segments that are not multicast
capable.
Section 4.1.5 of [RFC7450] explains that the relay selection process Section 4.1.5 of [RFC7450] explains that the relay selection process
for AMT is intended to be more flexible than the particular discovery for AMT is intended to be more flexible than the particular discovery
method described in that document, and further explains that the method described in that document. That section further explains
selection process might need to depend on the source of the multicast that the selection process might need to depend on the source of the
traffic in some deployments, since a relay must be able to receive multicast traffic in some deployments, since a relay must be able to
multicast traffic from the desired source in order to forward it. receive multicast traffic from the desired source in order to forward
it.
That section goes on to suggest DNS-based queries as a possible Section 4.1.5 of [RFC7450] goes on to suggest DNS-based queries as a
solution. DRIAD is a DNS-based solution, as suggested there. This possible solution: DRIAD is DNS based. This solution also addresses
solution also addresses the relay discovery issues in the the relay discovery issues in the "Disadvantages of this
"Disadvantages" lists in Section 3.3 of [RFC8313] and Section 3.4 of configuration" lists in Sections 3.3 and 3.4 of [RFC8313].
[RFC8313].
The goal for DRIAD is to enable multicast connectivity between The goal for DRIAD is to enable multicast connectivity between
separate multicast-enabled networks when neither the sending nor the separate multicast-enabled networks without preconfiguring any
receiving network is connected to a multicast-enabled backbone, peering arrangements between the networks when neither the sending
without pre-configuring any peering arrangement between the networks. nor the receiving network is connected to a multicast-enabled
backbone.
This document extends the relay discovery procedure described in This document extends the relay discovery procedure described in
Section 5.2.3.4 of [RFC7450]. Section 5.2.3.4 of [RFC7450].
1.1. Background 1.1. Background
The reader is assumed to be familiar with the basic DNS concepts The reader is assumed to be familiar with the basic DNS concepts
described in [RFC1034], [RFC1035], and the subsequent documents that described in [RFC1034], [RFC1035], and the subsequent documents that
update them, particularly [RFC2181]. update them, particularly [RFC2181].
The reader is also assumed to be familiar with the concepts and The reader is also assumed to be familiar with the concepts and
terminology regarding source-specific multicast as described in terminology regarding source-specific multicast as described in
[RFC4607] and the use of IGMPv3 [RFC3376] and MLDv2 [RFC3810] for [RFC4607] and the use of Internet Group Management Protocol Version 3
group management of source-specific multicast channels, as described (IGMPv3) [RFC3376] and Multicast Listener Discovery Version 2 (MLDv2)
in [RFC4604]. [RFC3810] for group management of source-specific multicast channels,
as described in [RFC4604].
The reader should also be familiar with AMT, particularly the The reader should also be familiar with AMT, particularly the
terminology listed in Section 3.2 of [RFC7450] and Section 3.3 of terminology listed in Sections 3.2 and 3.3 of [RFC7450].
[RFC7450].
1.2. Terminology 1.2. Terminology
1.2.1. Relays and Gateways 1.2.1. Relays and Gateways
When reading this document, it's especially helpful to recall that When reading this document, it's especially helpful to recall that
once an AMT tunnel is established, the relay receives native once an AMT tunnel is established, the relay receives native
multicast traffic and sends unicast tunnel-encapsulated traffic to multicast traffic and sends unicast tunnel-encapsulated traffic to
the gateway, and the gateway receives the tunnel-encapsulated the gateway. The gateway receives the tunnel-encapsulated packets,
packets, decapsulates them, and forwards them as native multicast decapsulates them, and forwards them as native multicast packets, as
packets, as illustrated in Figure 1. illustrated in Figure 1.
Multicast +-----------+ Unicast +-------------+ Multicast Multicast +-----------+ Unicast +-------------+ Multicast
>---------> | AMT relay | >=======> | AMT gateway | >---------> >---------> | AMT relay | >=======> | AMT gateway | >--------->
+-----------+ +-------------+ +-----------+ +-------------+
Figure 1: AMT Tunnel Illustration Figure 1: AMT Tunnel Illustration
1.2.2. Definitions 1.2.2. Definitions
+------------+------------------------------------------------------+
| Term | Definition | +------------+-------------------------------------------------+
+------------+------------------------------------------------------+ | Term | Definition |
| (S,G) | A source-specific multicast channel, as described in | +============+=================================================+
| | [RFC4607]. A pair of IP addresses with a source host | | (S,G) | A source-specific multicast channel, as |
| | IP and destination group IP. | | | described in [RFC4607]. A pair of IP addresses |
| | | | | with a source host IP and destination group IP. |
| discovery | A broker or load balancer for AMT relay discovery, | +------------+-------------------------------------------------+
| broker | as mentioned in section 4.2.1.1 of [RFC7450]. | | CMTS | Cable Modem Termination System |
| | | +------------+-------------------------------------------------+
| downstream | Further from the source of traffic, as described in | | discovery | A broker or load balancer for AMT relay |
| | [RFC7450]. | | broker | discovery, as mentioned in Section 4.2.1.1 of |
| | | | | [RFC7450]. |
| FQDN | Fully Qualified Domain Name, as described in | +------------+-------------------------------------------------+
| | [RFC8499] | | downstream | Further from the source of traffic, as |
| | | | | described in [RFC7450]. |
| gateway | An AMT gateway, as described in [RFC7450] | +------------+-------------------------------------------------+
| | | | FQDN | Fully Qualified Domain Name, as described in |
| L flag | The "Limit" flag described in Section 5.1.4.4 of | | | [RFC8499]. |
| | [RFC7450] | +------------+-------------------------------------------------+
| | | | gateway | An AMT gateway, as described in [RFC7450]. |
| relay | An AMT relay, as described in [RFC7450] | +------------+-------------------------------------------------+
| | | | L flag | The "Limit" flag described in Section 5.1.4.4 |
| RPF | Reverse Path Forwarding, as described in [RFC5110] | | | of [RFC7450]. |
| | | +------------+-------------------------------------------------+
| RR | A DNS Resource Record, as described in [RFC1034] | | OLT | Optical Line Terminal |
| | | +------------+-------------------------------------------------+
| RRType | A DNS Resource Record Type, as described in | | relay | An AMT relay, as described in [RFC7450]. |
| | [RFC1034] | +------------+-------------------------------------------------+
| | | | RPF | Reverse Path Forwarding, as described in |
| SSM | Source-specific multicast, as described in [RFC4607] | | | [RFC5110]. |
| | | +------------+-------------------------------------------------+
| upstream | Closer to the source of traffic, as described in | | RR | A DNS Resource Record, as described in |
| | [RFC7450]. | | | [RFC1034]. |
| | | +------------+-------------------------------------------------+
| CMTS | Cable Modem Termination System | | RRType | A DNS Resource Record Type, as described in |
| | | | | [RFC1034]. |
| OLT | Optical Line Terminal | +------------+-------------------------------------------------+
+------------+------------------------------------------------------+ | SSM | Source-specific multicast, as described in |
| | [RFC4607]. |
+------------+-------------------------------------------------+
| upstream | Closer to the source of traffic, as described |
| | in [RFC7450]. |
+------------+-------------------------------------------------+
Table 1: Definitions
1.2.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 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
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Relay Discovery Overview 2. Relay Discovery Overview
2.1. Basic Mechanics 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.
This enables AMT gateways in remote networks to discover an AMT relay This enables AMT gateways in remote networks to discover an AMT relay
that is capable of forwarding traffic from the sender. This in turn that is capable of forwarding traffic from the sender. This, in
enables those AMT gateways to receive the multicast traffic tunneled turn, enables those AMT gateways to receive the multicast traffic
over a unicast AMT tunnel from those relays, and then to pass the tunneled over a unicast AMT tunnel from those relays and then pass
multicast packets into networks or applications that are using the the multicast packets into networks or applications that are using
gateway to subscribe to traffic from that sender. the gateway to subscribe to traffic from that sender.
This mechanism only works for source-specific multicast (SSM) This mechanism only works for source-specific multicast (SSM)
channels. The source address of the (S,G) is reversed and used as an channels. The source address of the (S,G) is reversed and used as an
index into one of the reverse mapping trees (in-addr.arpa for IPv4, 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 the source IP addresses for desired (S,G)s are known to the gateway,
gateway, and conditions match the requirements outlined in and conditions match the requirements outlined in Section 3.1.
Section 3.1.
Some detailed example use cases are provided in Section 2.3, and Some detailed example use cases are provided in Section 2.3, and
other applicable example topologies appear in Section 3.3 of other applicable example topologies appear in Sections 3.3, 3.4, and
[RFC8313], Section 3.4 of [RFC8313], and Section 3.5 of [RFC8313]. 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 two 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.
A content provider operates a sender, which is a source of multicast A content provider operates a sender, which is a source of multicast
traffic inside a multicast-capable network. traffic inside a multicast-capable network.
An end user who is a customer of the content provider has a An end user who is a customer of the content provider has a
multicast-capable internet service provider, which operates a multicast-capable Internet Service Provider (ISP), which operates a
receiving network that uses an AMT gateway. The AMT gateway is receiving network that uses an AMT gateway. The AMT gateway is DRIAD
DRIAD-capable. capable.
The content provider provides the user with a receiving application The content provider provides the user with a receiving application
that tries to subscribe to at least one (S,G). This receiving that tries to subscribe to at least one (S,G). This receiving
application could for example be a file transfer system using FLUTE application could, for example, be a file transfer system using File
[RFC6726] or a live video stream using RTP [RFC3550], or any other Delivery over Unidirectional Transport (FLUTE) [RFC6726], a live
application that might subscribe to an SSM channel. video stream using RTP [RFC3550], or any other application that might
subscribe to an SSM channel.
+---------------+ +---------------+
| Sender | | Sender |
| | | 2001:db8::a | | | | 2001:db8::a |
| | +---------------+ | | +---------------+
|Data| | |Data| |
|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 Unicast
Tunnel | 3: --> DNS Query: type=AMTRELAY, Tunnel | 3: --> DNS Query: type=AMTRELAY,
/ a.0.0.0.0.0.0.0.0.0.0.0. / a.0.0.0.0.0.0.0.0.0.0.0.
^ | / 0.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 | / 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) |
+-------------+ +-------------+
Figure 2: DRIAD Messaging Figure 2: DRIAD Messaging
In this simple example, the sender IP is 2001:db8::a, it is sending In this simple example, the sender IP is 2001:db8::a, which is
traffic to the group address ff3e::8000:d, and the relay IP is sending traffic to the group address ff3e::8000:d, and the relay IP
2001:db8::c:f. is 2001:db8::c:f.
The content provider has previously configured the DNS zone that The content provider has previously configured the DNS zone that
contains the reverse IP domain name for the sender's IP address so contains the reverse IP domain name for the sender's IP address so
that it provides an AMTRELAY RR with the relay's IP address. (See that it provides an AMTRELAY RR with the relay's IP address (see
Section 4.3 for details about the AMTRELAY RR format and semantics.) 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 As described in Section 2.5 of [RFC3596], the reverse IP FQDN of the
sender's address "2001:db8::a" is: 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. 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. arpa.
The sequence of events depicted in Figure 2 is as follows: The sequence of events depicted in Figure 2 is as follows:
1. The end user starts the app, which issues a join to the (S,G): 1. The end user starts the app, which issues a join to the (S,G):
(2001:db8::a, ff3e::8000:d). (2001:db8::a, ff3e::8000:d).
2. The join propagates with RPF through the receiver's multicast- 2. The join propagates with RPF through the receiver's multicast-
enabled network with PIM [RFC7761] or another multicast routing enabled network with PIM [RFC7761] or another multicast routing
mechanism, until the AMT gateway receives a signal to join the mechanism until the AMT gateway receives a signal to join the
(S,G). (S,G).
3. The AMT gateway performs a reverse DNS lookup for the AMTRELAY 3. The AMT gateway performs a reverse DNS lookup for the AMTRELAY
RRType, by sending an AMTRELAY RRType query for the reverse IP RRType by sending an AMTRELAY RRType query for the reverse IP
domain name for the sender's source IP address (the S from the domain name for the sender's source IP address (the S from the
(S,G)). (S,G)).
The DNS resolver for the AMT gateway uses ordinary DNS recursive The DNS resolver for the AMT gateway uses ordinary DNS recursive
resolution until it has the authoritative result that the content resolution until it has the authoritative result that the content
provider configured, which informs the AMT gateway that the relay provider configured, which informs the AMT gateway that the relay
address is 2001:db8::c:f. address is 2001:db8::c:f.
4. The AMT gateway performs AMT handshakes with the AMT relay as 4. The AMT gateway performs AMT handshakes with the AMT relay as
described in Section 4 of [RFC7450], then forwards a Membership described in Section 4 of [RFC7450], then forwards a membership
report to the relay indicating subscription to the (S,G). report to the relay, indicating subscription to the (S,G).
5. The relay propagates the join through its network toward the 5. The relay propagates the join through its network toward the
sender, then forwards the appropriate AMT-encapsulated traffic to sender and then forwards the appropriate AMT-encapsulated traffic
the gateway, which decapsulates and forwards it as native to the gateway, which decapsulates and forwards it as a native
multicast through its downstream network to the end user. multicast through its downstream network to the end user.
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
skipping to change at page 10, line 5 skipping to change at line 396
(ISP) that offers multicast ingest services to its subscribers, (ISP) that offers multicast ingest services to its subscribers,
illustrated in Figure 3. illustrated in Figure 3.
In the example network below, subscribers can join (S,G)s with MLDv2 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 or IGMPv3 as described in [RFC4604], and the AMT gateway in this ISP
can receive and forward multicast traffic from one of the example can receive and forward multicast traffic from one of the example
sending networks in Section 2.3.2 by discovering the appropriate AMT 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 relays with a DNS lookup for the AMTRELAY RR with the reverse IP of
the source in the (S,G). the source in the (S,G).
Internet Internet
^ ^ Multicast-enabled ^ ^ Multicast-enabled
| | Receiving Network | | Receiving Network
+------|------------|-------------------------+ +------|------------|-------------------------+
| | | | | | | |
| +--------+ +--------+ +=========+ | | +--------+ +--------+ +=========+ |
| | Border |---| Border | | AMT | | | | Border |---| Border | | AMT | |
| | Router | | Router | | gateway | | | | Router | | Router | | gateway | |
| +--------+ +--------+ +=========+ | | +--------+ +--------+ +=========+ |
| | | | | | | | | |
| +-----+------+-----------+--+ | | +-----+------+-----------+--+ |
| | | | | | | |
| +-------------+ +-------------+ | | +-------------+ +-------------+ |
| | Agg Routers | .. | Agg Routers | | | | Agg Routers | .. | Agg Routers | |
| +-------------+ +-------------+ | | +-------------+ +-------------+ |
| / \ \ / \ | | / \ \ / \ |
| +---------------+ +---------------+ | | +---------------+ +---------------+ |
| |Access Systems | ....... |Access Systems | | | |Access Systems | ....... |Access Systems | |
| |(CMTS/OLT/etc.)| |(CMTS/OLT/etc.)| | | |(CMTS/OLT/etc.)| |(CMTS/OLT/etc.)| |
| +---------------+ +---------------+ | | +---------------+ +---------------+ |
| | | | | | | |
+--------|------------------------|-----------+ +--------|------------------------|-----------+
| | | |
+---+-+-+---+---+ +---+-+-+---+---+ +---+-+-+---+---+ +---+-+-+---+---+
| | | | | | | | | | | | | | | | | | | |
/-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\
|_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_|
Subscribers Subscribers
Figure 3: Receiving ISP Example Figure 3: Receiving ISP Example
2.3.1.2. Small Office 2.3.1.2. Small Office
Another example receiving network is a small branch office that Another example receiving network is a small branch office that
regularly accesses some multicast content, illustrated in Figure 4. regularly accesses some multicast content, illustrated in Figure 4.
This office has desktop devices that need to receive some multicast 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, so an AMT gateway runs on a LAN with these devices to pull
traffic in through a non-multicast next-hop. traffic in through a non-multicast next hop.
The office also hosts some mobile devices that have AMT gateway The office also hosts some mobile devices that have AMT gateway
instances embedded inside apps, in order to receive multicast traffic instances embedded inside apps in order to receive multicast traffic
over their non-multicast wireless LAN. (Note that the "Legacy over their non-multicast wireless LAN. (Note that the "Legacy
Router" is a simplification that's meant to describe a variety of Router" is a simplification that's meant to describe a variety of
possible conditions; for example it could be a device providing a possible conditions; for example, it could be a device providing a
split-tunnel VPN as described in [RFC7359], deliberately excluding split-tunnel VPN as described in [RFC7359], deliberately excluding
multicast traffic for a VPN tunnel, rather than a device which is multicast traffic for a VPN tunnel, rather than a device that is
incapable of multicast forwarding.) incapable of multicast forwarding.)
Internet Internet
(non-multicast) (non-multicast)
^ ^
| Office Network | Office Network
+----------|----------------------------------+ +----------|----------------------------------+
| | | | | |
| +---------------+ (Wifi) Mobile apps | | +---------------+ (Wifi) Mobile apps |
| | Modem+ | Wifi | - - - - w/ embedded | | | Modem+ | Wifi | - - - - w/ embedded |
| | Router | AP | AMT gateways | | | Router | AP | AMT gateways |
| +---------------+ | | +---------------+ |
| | | | | |
| | | | | |
| +----------------+ | | +----------------+ |
| | Legacy Router | | | | Legacy Router | |
| | (unicast) | | | | (unicast) | |
| +----------------+ | | +----------------+ |
| / | \ | | / | \ |
| / | \ | | / | \ |
| +--------+ +--------+ +--------+=========+ | | +--------+ +--------+ +--------+=========+ |
| | Phones | | ConfRm | | Desks | AMT | | | | Phones | | ConfRm | | Desks | AMT | |
| | subnet | | subnet | | subnet | gateway | | | | subnet | | subnet | | subnet | gateway | |
| +--------+ +--------+ +--------+=========+ | | +--------+ +--------+ +--------+=========+ |
| | | |
+---------------------------------------------+ +---------------------------------------------+
Figure 4: Small Office (no multicast up) Figure 4: Small Office (No Multicast Up)
By adding an AMT relay to this office network as in Figure 5, it's 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 possible to make use of multicast services from the example
multicast-capable ISP in Section 2.3.1.1. multicast-capable ISP in Section 2.3.1.1.
Multicast-capable ISP Multicast-capable ISP
^ ^
| Office Network | Office Network
+----------|----------------------------------+ +----------|----------------------------------+
| | | | | |
| +---------------+ (Wifi) Mobile apps | | +---------------+ (Wifi) Mobile apps |
| | Modem+ | Wifi | - - - - w/ embedded | | | Modem+ | Wifi | - - - - w/ embedded |
| | Router | AP | AMT gateways | | | Router | AP | AMT gateways |
| +---------------+ | | +---------------+ |
| | +=======+ | | | +=======+ |
| +---Wired LAN---| AMT | | | +---Wired LAN---| AMT | |
| | | relay | | | | | relay | |
| +----------------+ +=======+ | | +----------------+ +=======+ |
| | Legacy Router | | | | Legacy Router | |
| | (unicast) | | | | (unicast) | |
| +----------------+ | | +----------------+ |
| / | \ | | / | \ |
| / | \ | | / | \ |
| +--------+ +--------+ +--------+=========+ | | +--------+ +--------+ +--------+=========+ |
| | Phones | | ConfRm | | Desks | AMT | | | | Phones | | ConfRm | | Desks | AMT | |
| | subnet | | subnet | | subnet | gateway | | | | subnet | | subnet | | subnet | gateway | |
| +--------+ +--------+ +--------+=========+ | | +--------+ +--------+ +--------+=========+ |
| | | |
+---------------------------------------------+ +---------------------------------------------+
Figure 5: Small Office Example Figure 5: Small Office Example
When multicast-capable networks are chained like this, with a network When multicast-capable networks are chained like this, with a network
like the one in Figure 5 receiving internet services from a like the one in Figure 5 receiving Internet services from a
multicast-capable network like the one in Figure 3, it's important 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 for AMT gateways to reach the more local AMT relay in order to avoid
accidentally tunneling multicast traffic from a more distant AMT accidentally tunneling multicast traffic from a more distant AMT
relay with unicast, and failing to utilize the multicast transport relay with unicast and failing to utilize the multicast transport
capabilities of the network in Figure 3. capabilities of the network in Figure 3.
2.3.2. Example Sending Networks 2.3.2. Example Sending Networks
2.3.2.1. Sender-controlled Relays 2.3.2.1. Sender-Controlled Relays
When a sender network is also operating AMT relays to distribute When a sender network is also operating AMT relays to distribute
multicast traffic, as in Figure 6, each address could appear as an 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 AMTRELAY RR for the reverse IP of the sender. Alternately, one or
names could appear in AMTRELAY RRs, and the AMT relay addresses can more domain names could appear in AMTRELAY RRs, and the AMT relay
be discovered by finding A or AAAA records from those domain names. addresses can be discovered by finding A or AAAA records from those
domain names.
Sender Network Sender Network
+-----------------------------------+ +-----------------------------------+
| | | |
| +--------+ +=======+ +=======+ | | +--------+ +=======+ +=======+ |
| | Sender | | AMT | | AMT | | | | Sender | | AMT | | AMT | |
| +--------+ | relay | | relay | | | +--------+ | relay | | relay | |
| | +=======+ +=======+ | | | +=======+ +=======+ |
| | | | | | | | | |
| +-----+------+----------+ | | +-----+------+----------+ |
| | | | | |
+-----------|-----------------------+ +-----------|-----------------------+
v v
Internet Internet
(non-multicast) (non-multicast)
Figure 6: Small Office Example Figure 6: Small Office Example
2.3.2.2. Provider-controlled Relays 2.3.2.2. Provider-Controlled Relays
When an ISP offers a service to transmit outbound multicast traffic When an ISP offers a service to transmit outbound multicast traffic
through a forwarding network, it might also offer AMT relays in order through a forwarding network, it might also offer AMT relays in order
to reach receivers without multicast connectivity to the forwarding to reach receivers without multicast connectivity to the forwarding
network, as in Figure 7. In this case it's recommended that the ISP 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 also provide at least one domain name for the AMT relays for use with
the AMTRELAY RR. the AMTRELAY RR.
When the sender wishes to use the relays provided by the ISP for When the sender wishes to use the relays provided by the ISP for
forwarding multicast traffic, an AMTRELAY RR should be configured to forwarding multicast traffic, an AMTRELAY RR should be configured to
use the domain name provided by the ISP, to allow for address use the domain name provided by the ISP to allow for address
reassignment of the relays without forcing the sender to reconfigure reassignment of the relays without forcing the sender to reconfigure
the corresponding AMTRELAY RRs. the corresponding AMTRELAY RRs.
+--------+ +--------+
| Sender | | Sender |
+---+----+ Multicast-enabled +---+----+ Multicast-enabled
| Sending Network | Sending Network
+-----------|-------------------------------+ +-----------|-------------------------------+
| v | | v |
| +------------+ +=======+ +=======+ | | +------------+ +=======+ +=======+ |
| | Agg Router | | AMT | | AMT | | | | Agg Router | | AMT | | AMT | |
| +------------+ | relay | | relay | | | +------------+ | relay | | relay | |
| | +=======+ +=======+ | | | +=======+ +=======+ |
| | | | | | | | | |
| +-----+------+--------+---------+ | | +-----+------+--------+---------+ |
| | | | | | | |
| +--------+ +--------+ | | +--------+ +--------+ |
| | Border |---| Border | | | | Border |---| Border | |
| | Router | | Router | | | | Router | | Router | |
| +--------+ +--------+ | | +--------+ +--------+ |
+-----|------------|------------------------+ +-----|------------|------------------------+
| | | |
v v v v
Internet Internet
(non-multicast) (non-multicast)
Figure 7: Sending ISP Example Figure 7: Sending ISP Example
3. Relay Discovery Operation 3. Relay Discovery Operation
3.1. Optimal Relay Selection 3.1. Optimal Relay Selection
3.1.1. Overview 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
for that gateway to use, because the RR will only provide information relay for that gateway to use, because the RR will only provide
about relays known to the source. information 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 is 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 Figure 5 from Section 2.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);
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);
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);
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-
[RFC6763], using "_amt._udp" as the Service section of the based Service Discovery (DNS-SD) [RFC6763] using "_amt._udp" as
queries, or a relay discovered this way is not able to forward the Service section of the queries, or a relay discovered this
traffic from the source of the (S,G) (as described in way is not able to forward traffic from the source of the (S,G)
Section 3.3.4.1 or Section 3.3.5); and (as described in Section 3.3.4.1 and 3.3.5); and
5. The gateway is not able to find an upstream AMT relay with the 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 all of the above conditions are met, the gateway has no path
local network that can receive multicast traffic from the source IP within its local network that can receive multicast traffic from the
of the (S,G). source IP 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 above conditions are designed to prefer the use of a
when available, several methods of finding a more local source of local AMT relay if one can be discovered. However, note also that
multicast traffic connectivity are preferred to using a relay the network upstream of the locally discovered relay would still need
provided by an AMTRELAY RR, a gateway further upstream would still be to receive traffic from the sender of the (S,G) in order to forward
using the AMTRELAY RR unless the upstream network has a peering that it. Therefore, unless the upstream network contains the sender or
provides an alternative end-to-end multicast transport path for the has a multicast-capable peering with a network that can forward
(S,G)'s traffic. traffic from the sender, the upstream network might still use AMT to
ingest the traffic from a network that can receive traffic from the
sender. If this is the case, the upstream AMT gateway could still
rely on the AMTRELAY RR provided by the sender, even though the
AMTRELAY RR is not directly used by gateways topologically closer to
the receivers. For a concrete example of such a situation, consider
the network in Figure 5 connected as one of the customers to the
network in Figure 3.
3.1.2. Preference Ordering 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 [RFC8305] algorithm to try candidate relays
even gateways that do not implement a Happy Eyeballs algorithm SHOULD concurrently (see Section 3.2), but even gateways that do not
use this ordering, except as noted. implement a Happy Eyeballs algorithm SHOULD 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 network topology
topology considerations ahead of address selection considerations, in considerations ahead of address selection considerations in order to
order to gain the packet replication benefits from using multicast gain the packet replication benefits from using multicast instead of
instead of unicast tunneling in the multicast-capable portions of the unicast tunneling in the multicast-capable portions of the network
network path. path.
The intent of the advice and requirements in this section is to The intent of the advice and requirements in this section is to
describe how a gateway should make use of the concurrency provided by describe how a gateway should make use of the concurrency provided by
a Happy Eyeballs algorithm to reduce the join latency, while still a Happy Eyeballs algorithm to reduce the join latency while still
prioritizing network efficiency considerations over Address Selection prioritizing network efficiency considerations over address selection
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 * Prefer Local Relays
Figure 5 and Section 2.3.1.2 provide a motivating example to Figure 5 and Section 2.3.1.2 provide a motivating example to
prefer 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 * Prefer Relays Managed by the Containing Network
When no local relay is discoverable with DNS-SD, it still may be When no local relay is discoverable with DNS-SD, it still may be
the case that a relay local to the receiver is operated by the the case that a relay local to the receiver is operated by the
network providing transit services to the receiver. network providing transit services to the receiver.
In this case, when the network cannot make the relay discoverable In this case, when the network cannot make the relay discoverable
via DNS-SD, the network SHOULD use the well-known anycast via DNS-SD, the network SHOULD use the well-known anycast
addresses from Section 7 of [RFC7450] to route discovery traffic addresses from Section 7 of [RFC7450] to route discovery traffic
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 next-best option after
after DNS-SD when searching for a local relay. DNS-SD when searching for a local relay.
o Let Sender Manage Relay Provisioning * 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 2.3.2.1, and also by relays in a network like Figure 6 in Section 2.3.2.1 and by relays in a
provider-controlled network like Figure 7 in Section 2.3.2.2, with 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
for sorting preference ahead of the Destination Address Selection for sorting preference ahead of the Destination Address Selection
ordering from Section 6 of [RFC6724], so that only relay IPs with ordering from Section 6 of [RFC6724] so that only relay IPs with
the same precedence are directly compared according to the the same precedence are directly compared according to the
Destination Address Selection ordering. Destination Address Selection ordering.
Accordingly, AMT gateways SHOULD by default prefer relays in this Accordingly, AMT gateways SHOULD by default prefer relays in this
order: order:
1. DNS-SD 1. DNS-SD
2. Anycast addresses from Section 7 of [RFC7450]
3. DRIAD 2. Anycast addresses from Section 7 of [RFC7450]
3. DRIAD
This default behavior MAY be overridden by administrative This default behavior MAY be overridden by administrative
configuration where other behavior is more appropriate for the configuration where other behavior is more appropriate for the
gateway within its network. gateway within its network.
Among relay addresses that have an equivalent preference as described Among relay addresses that have an equivalent preference as described
above, a Happy Eyeballs algorithm for AMT SHOULD use the Destination above, a Happy Eyeballs algorithm for AMT SHOULD use the Destination
Address Selection defined in Section 6 of [RFC6724]. Address Selection defined in Section 6 of [RFC6724].
Among relay addresses that still have an equivalent preference after Among relay addresses that still have an equivalent preference after
the above orderings, a gateway SHOULD make a non-deterministic choice the above orderings, a gateway SHOULD make a non-deterministic choice
(such as a pseudorandom selection) for relay preference ordering, in (such as a pseudorandom selection) for relay preference ordering in
order to support load balancing by DNS configurations that provide order to support load balancing by DNS configurations that provide
many relay options. many relay options.
The gateway MAY introduce a bias in the non-deterministic choice The gateway MAY introduce a bias in the non-deterministic choice
according to information obtained out of band or from a historical according to information that indicates expected benefits from
record about network topology, timing information, or the response to
a probing mechanism, that indicates some expected benefits from
selecting some relays in preference to others. Details about the selecting some relays in preference to others. Details about the
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 could, for example, be obtained by out-of-band
use it to prefer topologically closer relays. methods or from a historical record about network topology, timing
information, or the response to a probing mechanism. A gateway in
possession of such information MAY use it to prefer topologically
closer relays.
Within the above constraints, gateways MAY make use of other 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 3.3.4.1 or consideration by the hold-down timers described in Section 3.3.4.1 or
Section 3.3.5. These relays constitute "unusable destinations" under 3.3.5. These relays constitute "unusable destinations" under Rule 1
Rule 1 of the Destination Address Selection, and are also not part of of the Destination Address Selection and are also not part of the
the superseding considerations described above. 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.
3.1.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 3.1.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.)
3.2. Happy Eyeballs 3.2. Happy Eyeballs
3.2.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 3.1.2 taken together provide guidance on use of a Happy Section 3.1.2 together provide guidance on use of a Happy Eyeballs
Eyeballs algorithm for the case of establishing AMT connections. algorithm for the case of establishing AMT connections.
Note that according to the definition in Section 3.2.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.
3.2.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 3.1. 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:
addresses, (as with type 1 or type 2 AMTRELAY responses, or when the
SRV Additional Data section of the SRV response contains the address * one or more IP addresses (as with type 1 or type 2 AMTRELAY
records for the target, as urged by [RFC2782]), or they might contain responses or when the SRV Additional Data section of the SRV
only domain names (as with type 3 responses from Section 4.2.3, or an response contains the address records for the target, as urged by
SRV response without an additional data section). [RFC2782]), or
* only domain names (as with type 3 responses from Section 4.2.3 or
an SRV response without an additional data section).
When present, IP addresses in the initial response provide resolved When present, IP addresses in the initial response provide resolved
destination address candidates for the "Sorting of resolved destination address candidates for the "Sorting of resolved
destination addresses" phase described in Section 4 of [RFC8305]), destination addresses" phase described in Section 4 of [RFC8305]),
whereas domain names without IP addresses in the initial response whereas domain names without IP addresses in the initial response
result in another set of queries for AAAA and A records, whose result in another set of queries for AAAA and A records, whose
responses provide the candidate resolved destination addresses. responses provide the candidate resolved destination addresses.
Since the SRV or AMTRELAY responses don't have a bound on the count Since the SRV or AMTRELAY responses don't have a bound on the count
of queries that might be generated aside from the bounds imposed by of queries that might be generated aside from the bounds imposed by
the DNS resolver, it's important for the gateway to provide a rate the DNS resolver, it's important for the gateway to provide a rate
limit on the DNS queries. The DNS query functionality is expected to limit on the DNS queries. The DNS query functionality is expected to
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 the 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 3.1.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.
3.2.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 a successful
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 * 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 3.3.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 3.3.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
skipping to change at page 20, line 49 skipping to change at line 899
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.
3.3. Guidelines for Restarting Discovery 3.3. Guidelines for Restarting Discovery
3.3.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
but may cause a disruption in the forwarded traffic if the discovery may cause a disruption in the forwarded traffic if the discovery
process results in choosing a different relay, because this changes process results in choosing a different relay because this changes
the RPF forwarding tree for the multicast traffic upstream of the the RPF forwarding tree for the multicast traffic upstream of the
gateway. This is likely to result in some dropped or duplicated gateway. This is likely to result in some dropped or duplicated
packets from channels actively being tunneled from the old relay to packets from channels actively being tunneled from the old relay to
the gateway. the gateway.
The degree of impact on the traffic from choosing a different relay The degree of impact on the traffic from choosing a different relay
may depend on network conditions between the gateway and the new may depend on network conditions between the gateway and the new
relay, as well as the network conditions and topology between the relay, as well as the network conditions and topology between the
sender and the new relay, as this may cause the relay to propagate a sender and the new relay, as this may cause the relay to propagate a
new RPF join toward the sender. new RPF join toward the sender.
skipping to change at page 21, line 35 skipping to change at line 933
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.
3.3.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 five events are
here and numbered for easier reference, and the remaining 4 events copied here and numbered for easier reference, and the remaining four
are newly added for consideration in this document: events 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).
2. When the gateway wishes to report a group subscription when none 2. When the gateway wishes to report a group subscription when none
currently exist. currently exists.
3. Before sending the next Request message in a membership update 3. Before sending the next Request message in a membership update
cycle. cycle.
4. After the gateway fails to receive a response to a Request 4. After the gateway fails to receive a response to a Request
message. message.
5. After the gateway receives a Membership Query message with the L 5. After the gateway receives a Membership Query message with the L
flag set to 1. flag set to 1.
6. When the gateway wishes to report an (S,G) subscription with a 6. When the gateway wishes to report an (S,G) subscription with a
source address that does not currently have other group source address that does not currently have other group
subscriptions. subscriptions.
7. When there is a network change detected, for example when a 7. When there is a network change detected; for example, when a
gateway is operating inside an end user device or application, gateway is operating inside an end user device or application and
and the device joins a different network, or when the domain the device joins a different network or when the domain portion
portion of a DNS-SD domain name changes in response to a DHCP of a DNS-SD domain name changes in response to a DHCP message or
message or administrative configuration. 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
but no traffic is received from the source for some timeout. no traffic is received from the source for some timeout (see
(See Section 3.3.4.1). 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
have sufficient information to use DRIAD, since no source is known. sufficient information to use DRIAD, since no source is known.
3.3.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 3.3.4, Section 3.3.6, and Section 3.3.4.3 for However, see Sections 3.3.4, 3.3.6, and 3.3.4.3 for more information
more information about exceptional cases when it may be appropriate about exceptional cases when it may be appropriate to use event #3.
to use event #3.
3.3.4. Traffic Health 3.3.4. Traffic Health
3.3.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.
The RECOMMENDED timeout is a random value in the range The RECOMMENDED timeout is a random value in the range
[initial_timeout, MIN(initial_timeout * 2^retry_count, [initial_timeout, MIN(initial_timeout * 2^retry_count,
maximum_timeout)], with a RECOMMENDED initial_timeout of 4 seconds maximum_timeout)], with a RECOMMENDED initial_timeout of 4 seconds
and a RECOMMENDED maximum_timeout of 120 seconds (which is the and a RECOMMENDED maximum_timeout of 120 seconds (which is the
recommended minimum NAT mapping timeout described in [RFC4787]). recommended minimum NAT mapping timeout described in [RFC4787]).
Note that the recommended initial_timeout is larger than the initial Note that the recommended initial_timeout is larger than the initial
timout recommended in the similar algorithm from Section 5.2.3.4.3 of timeout recommended in the similar algorithm from Section 5.2.3.4.3
[RFC7450]. This is to provide time for RPF Join propagation in the of [RFC7450]. This is to provide time for RPF Join propagation in
sending network. Although the timeout values may be administratively the sending network. Although the timeout values may be
adjusted to support performance requirements, operators are advised administratively adjusted to support performance requirements,
to consider the possibility of join propagation delays between the operators are advised to consider the possibility of join propagation
sender and the relay when choosing an appropriate timeout value. delays between the 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.
3.3.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
the rate of packet loss by communicating out of band with receivers, detecting the rate of packet loss by communicating out of band with
or monitoring the packets of known protocols with sequence numbers. receivers or monitoring the packets of known protocols with sequence
Where feasible, it's encouraged for gateways to use such traffic numbers. Where feasible, it's encouraged for gateways to use such
health information to trigger a restart of the discovery process traffic health information to trigger a restart of the discovery
during event #3 (before sending a new Request message). process during event #3 (before sending a new Request message).
However, to avoid synchronized rediscovery by many gateways However, if a transient network event that affects the tunneled
simultaneously after a transient network event upstream of a relay multicast stream -- as opposed to an event that affects the tunnel
results in many receivers detecting poor flow health at the same connection between the relay and gateway -- occurs, poor health
time, it's recommended to add a random delay before restarting the detection could be triggered for many gateways simultaneously. In
discovery process in this case. 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 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.
3.3.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 3.3.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
some deployments. 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
of restarting discovery during periods with an unusually low data restarting discovery during periods with an unusually low data rate
rate, to reduce the impact on active traffic while still avoiding to reduce the impact on active traffic while still avoiding relying
relying on the results of a very old discovery. 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.
3.3.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 underway for multiple
candidate relays (Section 3.2), 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 3.3.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 subsequent short-term rounds of discovery.
3.3.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 3.3.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
the traffic than if the relay simply stops responding to Request the traffic than if the relay simply stops responding to Request
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 that gateways support the L flag, but for
for gateways that do not support the L flag, sending this message gateways that do not support the L flag, sending this message during
during event #3 may help mitigate service degradation when relays event #3 may help mitigate service degradation when relays become
become unstable. unstable.
3.3.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
and from relays discovered via DNS-SD or a non-source-specific from relays discovered via DNS-SD or via 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
responding to events that are specific to the different tunnels. to events that are specific to the different tunnels.
3.4. 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
addresses of the desired traffic, and will not know any other name IP addresses of the desired traffic and will not know any other name
for the source of the traffic. Because of this, typically the best 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
zones as appropriate. AMTRELAY records MAY also appear in other zones as appropriate. AMTRELAY records MAY also appear in other
zones, since this may be necessary to perform delegation from the zones, since this may be necessary to perform delegation from the
reverse zones (see for example Section 5.2 of [RFC2317]), but the use reverse zones (see, for example, Section 5.2 of [RFC2317]), but the
case enabled by this document requires a reverse IP mapping for the use case enabled by this document requires a reverse IP mapping for
source from an (S,G) in order to be useful to most AMT gateways. 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 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 Sections 4 and 4.3 for a detailed explanation of the contents of
contents for a DNS Zone file. a DNS zone file.
3.5. Waiting for DNS resolution 3.5. Waiting for DNS Resolution
The DNS query functionality is expected to follow ordinary standards DNS query functionality is expected to follow ordinary standards and
and best practices for DNS clients. A gateway MAY use an existing best practices for DNS clients. A gateway MAY use an existing DNS
DNS client implementation that does so, and MAY rely on that client's 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 resend a DNS query if it does not receive an
an appropriate DNS response within some timeout period. If the appropriate DNS response within some timeout period. If the gateway
gateway retries multiple times, the timeout period SHOULD be adjusted retries multiple times, the timeout period SHOULD be adjusted to
to provide a random exponential back-off. 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.
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
The AMTRELAY RData consists of a 8-bit precedence field, a 1-bit 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 "Discovery Optional" field, a 7-bit type field, and a variable length
relay field. relay field.
0 1 2 3 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 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 | | | precedence |D| type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ relay ~ ~ relay ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 27, line 30 skipping to change at line 1212
This is an 8-bit precedence for this record. It is interpreted in 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 the same way as the PREFERENCE field described in Section 3.3.9 of
[RFC1035]. [RFC1035].
Relays listed in AMTRELAY records with a lower value for precedence Relays listed in AMTRELAY records with a lower value for precedence
are to be attempted first. are to be attempted first.
4.2.2. RData Format - Discovery Optional (D-bit) 4.2.2. RData Format - Discovery Optional (D-bit)
The D bit is a "Discovery Optional" flag. The D-bit is a "Discovery Optional" flag.
If the D bit is set to 0, a gateway using this RR MUST perform AMT 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 relay discovery as described in Section 4.2.1.1 of [RFC7450] rather
than directly sending an AMT Request message to the relay. than directly sending an AMT Request message to the relay.
That is, the gateway MUST receive an AMT Relay Advertisement message That is, the gateway MUST receive an AMT Relay Advertisement message
(Section 5.1.2 of [RFC7450]) for an address before sending an AMT (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 Request message (Section 5.1.3 of [RFC7450]) to that address. Before
receiving the Relay Advertisement message, this record has only receiving the Relay Advertisement message, this record has only
indicated that the address can be used for AMT relay discovery, not indicated that the address can be used for AMT relay discovery, not
for a Request message. This is necessary for devices that are not for a Request message. This is necessary for devices that are not
fully functional AMT relays, but rather load balancers or brokers, as fully functional AMT relays but rather load balancers or brokers, as
mentioned in Section 4.2.1.1 of [RFC7450]. 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 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 directly to the discovered relay address without first sending an AMT
Discovery message. Discovery message.
This bit should be set according to advice from the AMT relay 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 operator. The D-bit MUST be set to zero when no information is
available from the AMT relay operator about its suitability. available from the AMT relay operator about its suitability.
4.2.3. RData Format - Type 4.2.3. RData Format - Type
The type field indicates the format of the information that is stored The type field indicates the format of the information that is stored
in the relay field. in the relay field.
The following values are defined: The following values are defined:
o type = 0: The relay field is empty (0 bytes). * type = 0: The relay field is empty (0 bytes).
o type = 1: The relay field contains a 4-octet IPv4 address. * type = 1: The relay field contains a 4-octet IPv4 address.
o type = 2: The relay field contains a 16-octet IPv6 address. * type = 2: The relay field contains a 16-octet IPv6 address.
o type = 3: The relay field contains a wire-encoded domain name. * type = 3: The relay field contains a wire-encoded domain name.
The wire-encoded format is self-describing, so the length is The wire-encoded format is self-describing, so the length is
implicit. The domain name MUST NOT be compressed. (See implicit. The domain name MUST NOT be compressed (see Section 3.3
Section 3.3 of [RFC1035] and Section 4 of [RFC3597].) of [RFC1035] and Section 4 of [RFC3597]).
RRs with an undefined value in the Type field SHOULD NOT be RRs with an undefined value in the Type field SHOULD NOT be
considered by receiving gateways for AMT relay discovery. considered by receiving gateways for AMT relay discovery.
4.2.4. RData Format - Relay 4.2.4. RData Format - Relay
The relay field is the address or domain name of the AMT relay. It The relay field is the address or domain name of the AMT relay. It
is formatted according to the type field. is formatted according to the type field.
When the type field is 0, the length of the relay field is 0, and it When the type field is 0, the length of the relay field is 0, and it
skipping to change at page 28, line 46 skipping to change at line 1276
and a 32-bit IPv4 address is present. This is an IPv4 address as 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 described in Section 3.4.1 of [RFC1035]. This is a 32-bit number in
network byte order. network byte order.
When the type field is 2, the length of the relay field is 16 octets, 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 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 described in Section 2.2 of [RFC3596]. This is a 128-bit number in
network byte order. network byte order.
When the type field is 3, the relay field is a normal wire-encoded When the type field is 3, the relay field is a normal wire-encoded
domain name, as described in Section 3.3 of [RFC1035]. Compression domain name, as described in Section 3.3 of [RFC1035]. For the
MUST NOT be used, for the reasons given in Section 4 of [RFC3597]. 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 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 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 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, type 2 AMTRELAY records with identical D-bit and preference fields
vs. when the result is obtained by a type 3 AMTRELAY record that 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 resolves to the same set of IPv4 and IPv6 addresses via A and AAAA
lookups. lookups.
4.3. AMTRELAY Record Presentation Format 4.3. AMTRELAY Record Presentation Format
4.3.1. Representation of AMTRELAY RRs 4.3.1. Representation of AMTRELAY RRs
AMTRELAY RRs may appear in a zone data master file. The precedence, AMTRELAY RRs may appear in a zone data master file. The precedence,
D-bit, relay type, and relay fields are REQUIRED. D-bit, relay type, and relay fields are REQUIRED.
skipping to change at page 29, line 32 skipping to change at line 1312
In a DNS authoritative nameserver that understands the AMTRELAY type, In a DNS authoritative nameserver that understands the AMTRELAY type,
the zone might contain a set of entries like this: the zone might contain a set of entries like this:
$ORIGIN 100.51.198.in-addr.arpa. $ORIGIN 100.51.198.in-addr.arpa.
12 IN AMTRELAY 10 0 1 203.0.113.15 12 IN AMTRELAY 10 0 1 203.0.113.15
12 IN AMTRELAY 10 0 2 2001:db8::15 12 IN AMTRELAY 10 0 2 2001:db8::15
12 IN AMTRELAY 128 1 3 amtrelays.example.com. 12 IN AMTRELAY 128 1 3 amtrelays.example.com.
This configuration advertises an IPv4 discovery address, an IPv6 This configuration advertises an IPv4 discovery address, an IPv6
discovery address, and a domain name for AMT relays which can receive 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 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 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 described in Section 4.2.2) and a precedence 10 (meaning they're
preferred ahead of the last entry, which has precedence 128). preferred ahead of the last entry, which has precedence 128).
For zone files in name servers that don't support the AMTRELAY RRType 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 natively, it's possible to use the format for unknown RR types, as
described in [RFC3597]. This approach would replace the AMTRELAY described in [RFC3597]. This approach would replace the AMTRELAY
entries in the example above with the entries below: entries in the example above with the entries below:
10 IN TYPE260 \# ( 10 IN TYPE260 \# (
6 ; length 6 ; length
0a ; precedence=10 0a ; precedence=10
01 ; D=0, relay type=1, an IPv4 address 01 ; D=0, relay type=1, an IPv4 address
cb00710f ) ; 203.0.113.15 cb00710f ) ; 203.0.113.15
10 IN TYPE260 \# ( 10 IN TYPE260 \# (
18 ; length 18 ; length
0a ; precedence=10 0a ; precedence=10
02 ; D=0, relay type=2, an IPv6 address 02 ; D=0, relay type=2, an IPv6 address
20010db800000000000000000000000f ) ; 2001:db8::15 20010db800000000000000000000000f ) ; 2001:db8::15
10 IN TYPE260 \# ( 10 IN TYPE260 \# (
24 ; length 24 ; length
80 ; precedence=128 80 ; precedence=128
83 ; D=1, relay type=3, a wire-encoded domain name 83 ; D=1, relay type=3, a wire-encoded domain name
09616d7472656c617973076578616d706c6503636f6d ) ; domain name 09616d7472656c617973076578616d706c6503636f6d ) ; domain name
See Appendix A for more details. See Appendix A for more details.
5. IANA Considerations 5. IANA Considerations
This document updates the IANA Registry for DNS Resource Record Types This document updates the DNS "Resource Record (RR) TYPEs" registry
by assigning type 260 to the AMTRELAY record. by assigning type 260 to the AMTRELAY record.
This document creates a new registry named "AMTRELAY Resource Record This document creates a new registry named "AMTRELAY Resource Record
Parameters", with a sub-registry for the "Relay Type Field". The Parameters" with a subregistry for the "Relay Type Field". The
initial values in the sub-registry are: initial values in the subregistry are:
+-------+---------------------------------------+ +-------+---------------------------------------+
| Value | Description | | Value | Description |
+-------+---------------------------------------+ +=======+=======================================+
| 0 | No relay is present. | | 0 | No relay is present |
| 1 | A 4-byte IPv4 address is present | +-------+---------------------------------------+
| 2 | A 16-byte IPv6 address is present | | 1 | A 4-byte IPv4 address is present |
| 3 | A wire-encoded domain name is present | +-------+---------------------------------------+
| 4-255 | Unassigned | | 2 | A 16-byte IPv6 address is present |
+-------+---------------------------------------+ +-------+---------------------------------------+
| 3 | A wire-encoded domain name is present |
+-------+---------------------------------------+
| 4-255 | Unassigned |
+-------+---------------------------------------+
Values 0, 1, 2, and 3 are further explained in Section 4.2.3 and Table 2: Initial Contents of the "Relay Type
Section 4.2.4. Relay type numbers 4 through 255 can be assigned with Field" Registry
a policy of Specification Required (as described in [RFC8126]).
Values 0, 1, 2, and 3 are further explained in Sections 4.2.3 and
4.2.4. Relay type numbers 4 through 255 can be assigned with a
policy of Specification Required (as described in [RFC8126]).
6. Security Considerations 6. Security Considerations
6.1. Use of AMT 6.1. Use of AMT
This document defines a mechanism that enables a more widespread and This document defines a mechanism that enables a more widespread and
automated use of AMT, even without access to a multicast backbone. automated use of AMT, even without access to a multicast backbone.
Operators of networks and applications that include a DRIAD-capable Operators of networks and applications that include a DRIAD-capable
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
when a trust relationship with the AMT relays can be otherwise a trust relationship with the AMT relays can be otherwise established
established and secured. and secured.
Note that AMT does not itself provide any integrity protection on Note that AMT does not itself provide any integrity protection for
Multicast Data packets (Section 5.1.6 of [RFC7450]), so absent Multicast Data packets (Section 5.1.6 of [RFC7450]), so absent
protections like those mentioned above, even an off-path attacker who protections like those mentioned above, even an off-path attacker who
discovers the gateway IP, the relay IP, and the relay source port for discovers the gateway IP, the relay IP, and the relay source port for
an active AMT connection can inject multicast data packets for a an active AMT connection can inject multicast data packets for a
joined (S,G) into the data stream if he can get data packets 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. 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
response from the trusted server. The connection to the trusted response from the trusted server. The connection to the trusted
server can use any secure channel, such as with a TSIG [RFC2845] or server can use any secure channel, such as with a TSIG [RFC2845] or
SIG(0) [RFC2931] channel, a secure local channel on the host, DNS SIG(0) [RFC2931] channel, a secure local channel on the host, DNS
over TLS [RFC7858], DNS over HTTPS [RFC8484], or some other mechanism over TLS [RFC7858], DNS over HTTPS [RFC8484], or some other mechanism
that provides authentication of the RR. that provides authentication of the RR.
If an AMT gateway accepts a maliciously crafted AMTRELAY record, the If an AMT gateway accepts a maliciously crafted AMTRELAY record, the
result could be a Denial of Service, or receivers processing result could be a Denial of Service or receivers processing multicast
multicast traffic from a source under the attacker's control. traffic from a source under the attacker's control.
6.3. Congestion 6.3. Congestion
Multicast traffic, particularly interdomain multicast traffic, Multicast traffic, particularly interdomain multicast traffic,
carries some congestion risks, as described in Section 4 of carries some congestion risks, as described in Section 4 of
[RFC8085]. [RFC8085].
Application implementors and network operators that use AMT gateways Application implementors and network operators that use AMT gateways
are advised to take precautions including monitoring of application are advised to take precautions, including monitoring of application
traffic behavior, traffic authentication at ingest, rate-limiting of traffic behavior, traffic authentication at ingest, rate-limiting of
multicast traffic, and the use of circuit-breaker techniques such as multicast traffic, and the use of circuit-breaker techniques such as
those described in Section 3.1.10 of [RFC8085] and similar those described in Section 3.1.10 of [RFC8085] and similar
protections at the network level, in order to ensure network health protections at the network level in order to ensure network health in
in the event of misconfiguration, poorly written applications that the event of misconfiguration, poorly written applications that don't
don't follow UDP congestion control principles, or deliberate attack. follow UDP congestion control principles, or a deliberate attack.
Section 4.1.4.2 of [RFC7450] and Section 6.1 of [RFC7450] provide Section 4.1.4.2 of [RFC7450] and Section 6.1 of [RFC7450] provide
some further considerations and advice about mitigating congestion some further considerations and advice about mitigating congestion
risk. risk.
7. Acknowledgements 7. References
This specification was inspired by the previous work of Doug Nortz,
Robert Sayko, David Segelstein, and Percy Tarapore, presented in the
MBONED working group at IETF 93.
Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny
Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, Ben Kaduk, Bill
Atwood, Tim Chown, Christian Worm Mortensen, Warren Kumari, Dan
Romanescu, Bernard Aboba, Carlos Pignataro, Niclas Comstedt, Mirja
Kuehlewind, Henning Rogge, Eric Vyncke, Barry Lieba, Roman Danyliw,
Alissa Cooper, Suresh Krishnan, Adam Roach, and Daniel Franke for
their very helpful reviews and comments.
8. References
8.1. Normative References 7.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
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 34, line 18 skipping to change at line 1520
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>. <https://www.rfc-editor.org/info/rfc8305>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
8.2. Informative References 7.2. Informative References
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
ADDR.ARPA delegation", BCP 20, RFC 2317, ADDR.ARPA delegation", BCP 20, RFC 2317,
DOI 10.17487/RFC2317, March 1998, DOI 10.17487/RFC2317, March 1998,
<https://www.rfc-editor.org/info/rfc2317>. <https://www.rfc-editor.org/info/rfc2317>.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
<https://www.rfc-editor.org/info/rfc2845>. <https://www.rfc-editor.org/info/rfc2845>.
skipping to change at page 35, line 45 skipping to change at line 1594
[RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T., [RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T.,
Ed., and R. Krishnan, "Use of Multicast across Inter- Ed., and R. Krishnan, "Use of Multicast across Inter-
domain Peering Points", BCP 213, RFC 8313, domain Peering Points", BCP 213, RFC 8313,
DOI 10.17487/RFC8313, January 2018, DOI 10.17487/RFC8313, January 2018,
<https://www.rfc-editor.org/info/rfc8313>. <https://www.rfc-editor.org/info/rfc8313>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
Appendix A. Unknown RRType construction Appendix A. Unknown RRType Construction
In a DNS resolver that understands the AMTRELAY type, the zone file In a DNS resolver that understands the AMTRELAY type, the zone file
might contain this line: might contain this line:
IN AMTRELAY 128 0 3 amtrelays.example.com. IN AMTRELAY 128 0 3 amtrelays.example.com.
In order to translate this example to appear as an unknown RRType as In order to translate this example to appear as an unknown RRType as
defined in [RFC3597], one could run the following program: defined in [RFC3597], one could run the following program:
<CODE BEGINS> <CODE BEGINS>
skipping to change at page 36, line 29 skipping to change at line 1625
print(wire) print(wire)
$ ./translate.py amtrelays.example.com $ ./translate.py amtrelays.example.com
24 24
09616d7472656c617973076578616d706c6503636f6d 09616d7472656c617973076578616d706c6503636f6d
<CODE ENDS> <CODE ENDS>
The length of the RData and the hex string for the domain name The length of the RData and the hex string for the domain name
"amtrelays.example.com" are the outputs of this program. "amtrelays.example.com" are the outputs of this program.
22 is the length of the wire-encoded domain name, so 2 was added to 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 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 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, the 2 octets ahead of the domain name, we encode the precedence,
D-bit, and relay type fields, as described in Section 4. D-bit, and relay type fields, as described in Section 4.
This results in a zone file entry like this: This results in a zone file entry like this:
IN TYPE260 \# ( 24 ; length IN TYPE260 \# ( 24 ; length
80 ; precedence = 128 80 ; precedence = 128
03 ; D-bit=0, relay type=3 (wire-encoded domain name) 03 ; D-bit=0, relay type=3 (wire-encoded domain name)
09616d7472656c617973076578616d706c6503636f6d ) ; domain name 09616d7472656c617973076578616d706c6503636f6d ) ; domain name
Acknowledgements
This specification was inspired by the previous work of Doug Nortz,
Robert Sayko, David Segelstein, and Percy Tarapore, presented in the
MBONED Working Group at IETF 93.
Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny
Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, Ben Kaduk, Bill
Atwood, Tim Chown, Christian Worm Mortensen, Warren Kumari, Dan
Romanescu, Bernard Aboba, Carlos Pignataro, Niclas Comstedt, Mirja
Kühlewind, Henning Rogge, Eric Vyncke, Barry Lieba, Roman Danyliw,
Alissa Cooper, Suresh Krishnan, Adam Roach, and Daniel Franke for
their very helpful reviews and comments.
Author's Address Author's Address
Jake Holland Jake Holland
Akamai Technologies, Inc. Akamai Technologies, Inc.
150 Broadway 150 Broadway
Cambridge, MA 02144 Cambridge, MA 02144
United States of America United States of America
Email: jakeholland.net@gmail.com Email: jakeholland.net@gmail.com
 End of changes. 158 change blocks. 
573 lines changed or deleted 604 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/