draft-ietf-mboned-driad-amt-discovery-10.txt   draft-ietf-mboned-driad-amt-discovery-11.txt 
Mboned J. Holland Mboned J. Holland
Internet-Draft Akamai Technologies, Inc. Internet-Draft Akamai Technologies, Inc.
Updates: 7450 (if approved) December 12, 2019 Updates: 7450 (if approved) December 18, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: June 14, 2020 Expires: June 20, 2020
DNS Reverse IP AMT Discovery DNS Reverse IP AMT (Automatic Multicast Tunneling) Discovery
draft-ietf-mboned-driad-amt-discovery-10 draft-ietf-mboned-driad-amt-discovery-11
Abstract Abstract
This document updates RFC 7450 (Automatic Multicast Tunneling, or This document updates RFC 7450 (Automatic Multicast Tunneling, or
AMT) by extending the relay discovery process to use a new DNS AMT) by modifying the relay discovery process. A new DNS resource
resource record named AMTRELAY when discovering 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. multicast traffic from that sender over an AMT tunnel. Other
extensions and clarifications to the relay discovery process are also
defined.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 14, 2020. This Internet-Draft will expire on June 20, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 17
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1. Relays and Gateways . . . . . . . . . . . . . . . . . 4 1.2.1. Relays and Gateways . . . . . . . . . . . . . . . . . 4
1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 4 1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 4
2. Relay Discovery Operation . . . . . . . . . . . . . . . . . . 5 2. Relay Discovery Operation . . . . . . . . . . . . . . . . . . 6
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Signaling and Discovery . . . . . . . . . . . . . . . . . 6 2.2. Signaling and Discovery . . . . . . . . . . . . . . . . . 6
2.3. Optimal Relay Selection . . . . . . . . . . . . . . . . . 8 2.3. Optimal Relay Selection . . . . . . . . . . . . . . . . . 9
2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 8 2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2. Preference Ordering . . . . . . . . . . . . . . . . . 10 2.3.2. Preference Ordering . . . . . . . . . . . . . . . . . 10
2.3.3. Connecting to Multiple Relays . . . . . . . . . . . . 12 2.3.3. Connecting to Multiple Relays . . . . . . . . . . . . 13
2.4. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . . 12 2.4. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . . 13
2.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13 2.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13
2.4.2. Algorithm Guidelines . . . . . . . . . . . . . . . . 13 2.4.2. Algorithm Guidelines . . . . . . . . . . . . . . . . 13
2.4.3. Connection Definition . . . . . . . . . . . . . . . . 14 2.4.3. Connection Definition . . . . . . . . . . . . . . . . 14
2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 15 2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 15
2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 15 2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 15
2.5.2. Updates to Restarting Events . . . . . . . . . . . . 15 2.5.2. Updates to Restarting Events . . . . . . . . . . . . 16
2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 16 2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 17
2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 17 2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 17
2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 18 2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 19
2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 19 2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 19
2.5.7. Independent Discovery Per Traffic Source . . . . . . 19 2.5.7. Independent Discovery Per Traffic Source . . . . . . 20
2.6. DNS Configuration . . . . . . . . . . . . . . . . . . . . 20 2.6. DNS Configuration . . . . . . . . . . . . . . . . . . . . 20
2.7. Waiting for DNS resolution . . . . . . . . . . . . . . . 20 2.7. Waiting for DNS resolution . . . . . . . . . . . . . . . 20
3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 20 3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 21
3.1. Example Receiving Networks . . . . . . . . . . . . . . . 20 3.1. Example Receiving Networks . . . . . . . . . . . . . . . 21
3.1.1. Internet Service Provider . . . . . . . . . . . . . . 21 3.1.1. Internet Service Provider . . . . . . . . . . . . . . 21
3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 22 3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 22
3.2. Example Sending Networks . . . . . . . . . . . . . . . . 23 3.2. Example Sending Networks . . . . . . . . . . . . . . . . 24
3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 23 3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 24
3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 24 3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 25
4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 25 4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 26
4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 25 4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 26
4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 25 4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 26
4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 26 4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 27
4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 26 4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 27
4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 26 4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 27
4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 27 4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 28
4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 27
4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 27 4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 28
4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 28 4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 28
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
6.1. Use of AMT . . . . . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 29 6.1. Use of AMT . . . . . . . . . . . . . . . . . . . . . . . 30
6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 30 6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 30
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
8.1. Normative References . . . . . . . . . . . . . . . . . . 30 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.2. Informative References . . . . . . . . . . . . . . . . . 32 8.1. Normative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Unknown RRType construction . . . . . . . . . . . . 34 8.2. Informative References . . . . . . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 35 Appendix A. Unknown RRType construction . . . . . . . . . . . . 35
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
This document defines DNS Reverse IP AMT Discovery (DRIAD), a This document defines DNS Reverse IP AMT Discovery (DRIAD), a
mechanism for AMT gateways to discover AMT relays that are capable of mechanism for AMT gateways to discover AMT relays that are capable of
forwarding multicast traffic from a known source IP address. forwarding multicast traffic from a known source IP address.
AMT (Automatic Multicast Tunneling) is defined in [RFC7450], and AMT (Automatic Multicast Tunneling) is defined in [RFC7450], and
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 non-multicast-capable network segments.
skipping to change at page 5, line 38 skipping to change at page 5, line 38
| | | | | |
| RR | A DNS Resource Record, as described in [RFC1034] | | RR | A DNS Resource Record, as described in [RFC1034] |
| | | | | |
| RRType | A DNS Resource Record Type, as described in | | RRType | A DNS Resource Record Type, as described in |
| | [RFC1034] | | | [RFC1034] |
| | | | | |
| SSM | Source-specific multicast, as described in [RFC4607] | | SSM | Source-specific multicast, as described in [RFC4607] |
| | | | | |
| upstream | Closer to the source of traffic, as described in | | upstream | Closer to the source of traffic, as described in |
| | [RFC7450]. | | | [RFC7450]. |
| | |
| CMTS | Cable Modem Termination System |
| | |
| OLT | Optical Line Terminal |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119] and [RFC8174] when, and only when, they appear in all [RFC2119] and [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Relay Discovery Operation 2. Relay Discovery Operation
2.1. Overview 2.1. Overview
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
skipping to change at page 7, line 19 skipping to change at page 7, line 19
multicast-capable internet service provider, which operates a multicast-capable internet service provider, 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-capable. DRIAD-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 FLUTE
[RFC6726] or a live video stream using RTP [RFC3550], or any other [RFC6726] or a live video stream using RTP [RFC3550], or any other
application that might subscribe to an SSM channel. application that might subscribe to an SSM channel.
+---------------+ +---------------+
| Sender | | Sender |
| | | 198.51.100.15 | | | | 198.51.100.15 |
| | +---------------+ | | +---------------+
|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 |
| 203.0.113.15 | | 2001:db8::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 | Tunnel |
^ | 3: --> DNS Query: type=AMTRELAY, ^ | 3: --> DNS Query: type=AMTRELAY,
| / 15.100.51.198.in-addr.arpa. | / 15.100.51.198.in-addr.arpa.
| | / <-- Response: | | / <-- Response:
Join/Leave +-------------+ AMTRELAY=203.0.113.15 Join/Leave +-------------+ AMTRELAY=2001:db8::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=198.51.100.15, G) | 1: Join(S=198.51.100.15,G=232.252.0.2)
+-------------+ +-------------+
| Receiver | | Receiver |
| (end user) | | (end user) |
+-------------+ +-------------+
Figure 2: DRIAD Messaging Figure 2: DRIAD Messaging
In this simple example, the sender IP is 198.51.100.15, and the relay In this simple example, the sender IP is 198.51.100.15, it is sending
IP is 203.0.113.15. traffic to the group address 232.252.0.2, and the relay IP is
2001:db8::f.
The content provider has previously configured the DNS zone that The content provider has previously configured the DNS zone that
contains the domain name "15.100.51.198.in-addr.arpa.", which is the contains the domain name "15.100.51.198.in-addr.arpa.", which is the
reverse lookup domain name for his sender. The zone file contains an reverse lookup domain name for his sender. The zone file contains an
AMTRELAY RR with the Relay's IP address. (See Section 4.3 for AMTRELAY RR with the Relay's IP address. (See Section 4.3 for
details about the AMTRELAY RR format and semantics.) details about the AMTRELAY RR format and semantics.)
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):
skipping to change at page 8, line 33 skipping to change at page 8, line 34
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 FQDN RRType, by sending an AMTRELAY RRType query for the FQDN
"15.100.51.198.in-addr.arpa.", using the reverse IP domain name "15.100.51.198.in-addr.arpa.", using the reverse IP domain name
for the sender's source IP address (the S from the (S,G)), as for the sender's source IP address (the S from the (S,G)), as
described in Section 3.5 of [RFC1035]. described in Section 3.5 of [RFC1035].
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 203.0.113.15. address is 2001:db8::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, then forwards the appropriate AMT-encapsulated traffic to
the gateway, which decapsulates and forwards it as native the gateway, which decapsulates and forwards it as native
multicast through its downstream network to the end user. multicast through its downstream network to the end user.
In the case of an IPv6 (S,G), the only difference in the AMT relay
discovery process is the use of the ip6.arpa reverse IP domain name,
as described in Section 2.5 of [RFC3596]), instead of the in-
addr.arpa domain name.
For example, if the (S,G) is (2001:db8:c::f, ffe3::80fc:2), the
reverse domain name for the AMTRELAY query would be:
f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.0.0.0.8.b.d.0.1.0.0.2.ip6.
arpa.
2.3. Optimal Relay Selection 2.3. Optimal Relay Selection
2.3.1. Overview 2.3.1. Overview
The reverse source IP DNS query of an AMTRELAY RR is a good way for a The reverse source IP DNS query of an AMTRELAY RR is a good way for a
gateway to discover a relay that is known to the sender. gateway to discover a relay that is known to the sender.
However, it is NOT necessarily a good way to discover the best relay However, it is NOT necessarily a good way to discover the best relay
for that gateway to use, because the RR will only provide information for that gateway to use, because the RR will only provide information
about relays known to the source. about relays known to the source.
skipping to change at page 11, line 52 skipping to change at page 12, line 14
1. DNS-SD 1. DNS-SD
2. Anycast addresses from Section 7 of [RFC7450] 2. Anycast addresses from Section 7 of [RFC7450]
3. DRIAD 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 MUST use the Destination above, a Happy Eyeballs algorithm for AMT SHOULD use use the
Address Selection defined in Section 6 of [RFC6724], as required by Destination Address Selection defined in Section 6 of [RFC6724].
[RFC8305].
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 MUST make a non-deterministic choice the above orderings, a gateway SHOULD make a non-deterministic choice
for relay preference ordering, in order to support load balancing by (such as a pseudorandom selection) for relay preference ordering, in
DNS configurations that provide many relay options. order to support load balancing by DNS configurations that provide
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 obtained out of band or from a historical
record about network topology, timing information, or the response to record about network topology, timing information, or the response to
a probing mechanism, that indicates some expected benefits from 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 a gateway in possession of such information MAY
use it to prefer topologically closer relays. use it to prefer topologically closer relays.
Within the above constraints, gateways MAY make use of other
considerations from Section 4 of [RFC8305], such as the address
family interleaving strategies, to produce a final ordering of
candidate relay addresses.
Note also that certain relay addresses might be excluded from Note also that certain relay addresses might be excluded from
consideration by the hold-down timers described in Section 2.5.4.1 or consideration by the hold-down timers described in Section 2.5.4.1 or
Section 2.5.5. These relays constitute "unusable destinations" under Section 2.5.5. These relays constitute "unusable destinations" under
Rule 1 of the Destination Address Selection, and are also not part of Rule 1 of the Destination Address Selection, and are also not part of
the superseding considerations described above. the superseding considerations described above.
The discovery and connection process for the relay addresses in the The discovery and connection process for the relay addresses in the
above described ordering MAY operate in parallel, subject to delays above described ordering MAY operate in parallel, subject to delays
prescribed by the Happy Eyeballs requirements described in Section 5 prescribed by the Happy Eyeballs requirements described in Section 5
of [RFC8305] for successively launched concurrent connection of [RFC8305] for successively launched concurrent connection
skipping to change at page 13, line 22 skipping to change at page 13, line 38
relays concurrently. relays concurrently.
The parallel discovery logic of a Happy Eyeballs algorithm serves to The parallel discovery logic of a Happy Eyeballs algorithm serves to
reduce join latency for the initial join of an SSM channel. This reduce join latency for the initial join of an SSM channel. This
section and the preference ordering of relays defined in section and the preference ordering of relays defined in
Section 2.3.2 taken together provide guidance on use of a Happy Section 2.3.2 taken together provide guidance on use of a Happy
Eyeballs algorithm for the case of establishing AMT connections. Eyeballs algorithm for the case of establishing AMT connections.
Note that according to the definition in Section 2.4.3 of this Note that according to the definition in Section 2.4.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 [RFC8085], only one membership report. As described in Section 5 of [RFC8305], only one
of the successful connections will be used, and the others are all of the successful connections will be used, and the others are all
canceled or ignored. In the context of an AMT connection, this means canceled or ignored. In the context of an AMT connection, this means
the gateway will send the membership reports that subscribe to the gateway will send the membership reports that subscribe to
traffic only for the chosen connection, after the Happy Eyeballs traffic only for the chosen connection, after the Happy Eyeballs
algorithm resolves. algorithm resolves.
2.4.2. Algorithm Guidelines 2.4.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
skipping to change at page 13, line 46 skipping to change at page 14, line 14
Each of the SRV and AMTRELAY responses might contain one or more IP Each of the SRV and AMTRELAY responses might contain one or more IP
addresses, (as with type 1 or type 2 AMTRELAY responses, or when the addresses, (as with type 1 or type 2 AMTRELAY responses, or when the
SRV Additional Data section of the SRV response contains the address SRV Additional Data section of the SRV response contains the address
records for the target, as urged by [RFC2782]), or they might contain records for the target, as urged by [RFC2782]), or they might contain
only domain names (as with type 3 responses from Section 4.2.3, or an only domain names (as with type 3 responses from Section 4.2.3, or an
SRV response without an additional data section). SRV response without an additional data section).
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 [RFC8085]), 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 MUST NOT permit more for the DNS queries, and its default settings SHOULD NOT permit more
than 10 queries for any 100-millisecond period (though this MAY be than 10 queries for any 100-millisecond period (though this MAY be
overridable by administrative configuration). overridable by administrative configuration).
As the resolved IP addresses arrive, the Happy Eyeballs algorithm As the resolved IP addresses arrive, the Happy Eyeballs algorithm
sorts them according to the requirements and recommendations given in sorts them according to the requirements and recommendations given in
Section 2.3.2, and attempts connections with the corresponding relays Section 2.3.2, and attempts connections with the corresponding relays
under the algorithm restrictions and guidelines given in [RFC8085] 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. attempts" phase. As described in Section 3 of [RFC8305], DNS
resolution is treated as asynchronous, and connection initiation does
not wait for lagging DNS responses.
2.4.3. Connection Definition 2.4.3. Connection Definition
Section 5 of [RFC8305] non-normatively describes success at a Section 5 of [RFC8305] non-normatively describes success at a
connection attempt as "generally when the TCP handshake completes". connection attempt as "generally when the TCP handshake completes".
There is no normative definition of a connection in the AMT There is no normative definition of a connection in the AMT
specification [RFC7450], and there is no TCP connection involved in specification [RFC7450], and there is no TCP connection involved in
an AMT tunnel. an AMT tunnel.
skipping to change at page 16, line 24 skipping to change at page 16, line 43
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 the device joins a different network, or when the domain and the device joins a different network, or when the domain
portion of a DNS-SD domain name changes in response to a DHCP portion of a DNS-SD domain name changes in response to a DHCP
message or administrative configuration. message or administrative configuration.
8. When congestion or substantial loss is detected in the stream of 8. When substantial loss, persistent congestion, or network overload
AMT packets from a relay. is detected in the stream of AMT packets from a relay.
9. When the gateway has reported one or more (S,G) subscriptions, 9. When the gateway has reported one or more (S,G) subscriptions,
but no traffic is received from the source for some timeout. but no traffic is received from the source for some timeout.
(See Section 2.5.4.1). (See Section 2.5.4.1).
This list is not exhaustive, nor are any of the listed events This list is not exhaustive, nor are any of the listed events
strictly required to always force a restart of the discovery process. strictly required to always force a restart of the discovery process.
Note that during event #1, a gateway may use DNS-SD, but does not Note that during event #1, a gateway may use DNS-SD, but does not
have sufficient information to use DRIAD, since no source is known. have sufficient information to use DRIAD, since no source is known.
skipping to change at page 20, line 17 skipping to change at page 20, line 34
Often an AMT gateway will only have access to the source and group IP Often an AMT gateway will only have access to the source and group IP
addresses of the desired traffic, and will not know any other name addresses of the desired traffic, and will not know any other name
for the source of the traffic. Because of this, typically the best for the source of the traffic. Because of this, typically the best
way of looking up AMTRELAY RRs will be by using the source IP address way of looking up AMTRELAY RRs will be by using the source IP address
as an index into one of the reverse mapping trees (in-addr.arpa for as an index into one of the reverse mapping trees (in-addr.arpa for
IPv4, as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, IPv4, as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6,
as described in Section 2.5 of [RFC3596]). as described in Section 2.5 of [RFC3596]).
Therefore, it is RECOMMENDED that AMTRELAY RRs be added to reverse IP Therefore, it is RECOMMENDED that AMTRELAY RRs be added to reverse IP
zones as appropriate. AMTRELAY records MAY also appear in other zones as appropriate. AMTRELAY records MAY also appear in other
zones, but the primary intended use case requires a reverse IP zones, since this may be necessary to perform delegation from the
mapping for the source from an (S,G) in order to be useful to most reverse zones (see for example Section 5.2 of [RFC2317]), but the use
AMT gateways. case enabled by this document requires a reverse IP mapping for the
source from an (S,G) in order to be useful to most AMT gateways.
When performing the AMTRELAY RR lookup, any CNAMEs or DNAMEs found When performing the AMTRELAY RR lookup, any CNAMEs or DNAMEs found
MUST be followed. This is necessary to support zone delegation. MUST be followed. This is necessary to support zone delegation.
Some examples outlining this need are described in [RFC2317]. Some examples outlining this need are described in [RFC2317].
See Section 4 and Section 4.3 for a detailed explanation of the See Section 4 and Section 4.3 for a detailed explanation of the
contents for a DNS Zone file. contents for a DNS Zone file.
2.7. Waiting for DNS resolution 2.7. Waiting for DNS resolution
skipping to change at page 24, line 27 skipping to change at page 25, line 27
Internet Internet
(non-multicast) (non-multicast)
Figure 6: Small Office Example Figure 6: Small Office Example
3.2.2. Provider-controlled Relays 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.
+--------+ +--------+
skipping to change at page 28, line 12 skipping to change at page 29, line 12
IN AMTRELAY precedence D-bit type relay IN AMTRELAY precedence D-bit type relay
4.3.2. Examples 4.3.2. Examples
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.
10 IN AMTRELAY 10 0 1 203.0.113.15 10 IN AMTRELAY 10 0 1 203.0.113.15
10 IN AMTRELAY 10 0 2 2001:DB8::15 10 IN AMTRELAY 10 0 2 2001:db8::15
10 IN AMTRELAY 128 1 3 amtrelays.example.com. 10 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 which can receive
traffic from the source 198.51.100.10. The IPv4 and IPv6 addresses traffic from the source 198.51.100.10. 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
skipping to change at page 30, line 15 skipping to change at page 31, line 15
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 traffic from a source under the attacker's control. multicast 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 DRIAD-capable Application implementors and network operators that use AMT gateways
AMT gateways are advised to take precautions including monitoring of are advised to take precautions including monitoring of application
application traffic behavior, traffic authentication at ingest, rate- traffic behavior, traffic authentication at ingest, rate-limiting of
limiting of multicast traffic, and the use of circuit-breaker multicast traffic, and the use of circuit-breaker techniques such as
techniques such as those described in Section 3.1.10 of [RFC8085] and those described in Section 3.1.10 of [RFC8085] and similar
similar protections at the network level, in order to ensure network protections at the network level, in order to ensure network health
health in the event of misconfiguration, poorly written applications in the event of misconfiguration, poorly written applications that
that don't follow UDP congestion control principles, or deliberate don't follow UDP congestion control principles, or deliberate attack.
attack.
Section 4.1.4.2 of [RFC7450] and Section 6.1 of [RFC7450] provide
some further considerations and advice about mitigating congestion
risk.
7. Acknowledgements 7. Acknowledgements
This specification was inspired by the previous work of Doug Nortz, This specification was inspired by the previous work of Doug Nortz,
Robert Sayko, David Segelstein, and Percy Tarapore, presented in the Robert Sayko, David Segelstein, and Percy Tarapore, presented in the
MBONED working group at IETF 93. MBONED working group at IETF 93.
Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny
Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, Ben Kaduk, Bill Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, Ben Kaduk, Bill
Atwood, Tim Chown, Warren Kumari, Dan Romanescu, Bernard Aboba, Atwood, Tim Chown, Warren Kumari, Dan Romanescu, Bernard Aboba,
Carlos Pignataro, and Niclas Comstedt for their very helpful reviews Carlos Pignataro, Niclas Comstedt, Mirja Kuehlewind, Henning Rogge,
and comments. Eric Vyncke, Barry Lieba, Roman Danyliw, Alissa Cooper, Suresh
Krishnan, and Adam Roach for their very helpful reviews and comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
 End of changes. 35 change blocks. 
106 lines changed or deleted 138 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/