draft-ietf-mboned-driad-amt-discovery-08.txt   draft-ietf-mboned-driad-amt-discovery-09.txt 
Mboned J. Holland Mboned J. Holland
Internet-Draft Akamai Technologies, Inc. Internet-Draft Akamai Technologies, Inc.
Updates: 7450 (if approved) June 14, 2019 Updates: 7450 (if approved) October 27, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: December 16, 2019 Expires: April 29, 2020
DNS Reverse IP AMT Discovery DNS Reverse IP AMT Discovery
draft-ietf-mboned-driad-amt-discovery-08 draft-ietf-mboned-driad-amt-discovery-09
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 extending the relay discovery process to use a new DNS
resource record named AMTRELAY when discovering AMT relays for resource record named AMTRELAY when discovering 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.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 December 16, 2019. This Internet-Draft will expire on April 29, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . 5
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Signaling and Discovery . . . . . . . . . . . . . . . . . 6 2.2. Signaling and Discovery . . . . . . . . . . . . . . . . . 6
2.3. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . . 8 2.3. Optimal Relay Selection . . . . . . . . . . . . . . . . . 8
2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 8 2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2. Connection Definition . . . . . . . . . . . . . . . . 9 2.3.2. Preference Ordering . . . . . . . . . . . . . . . . . 10
2.4. Optimal Relay Selection . . . . . . . . . . . . . . . . . 9 2.3.3. Connecting to Multiple Relays . . . . . . . . . . . . 12
2.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 9 2.4. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . . 12
2.4.2. Preference Ordering . . . . . . . . . . . . . . . . . 10 2.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 12
2.4.3. Connecting to Multiple Relays . . . . . . . . . . . . 13 2.4.2. Algorithm Guidelines . . . . . . . . . . . . . . . . 13
2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 13 2.4.3. Connection Definition . . . . . . . . . . . . . . . . 14
2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13 2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 14
2.5.2. Updates to Restarting Events . . . . . . . . . . . . 14 2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 14
2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 15 2.5.2. Updates to Restarting Events . . . . . . . . . . . . 15
2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 15 2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 16
2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 17 2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 16
2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 17 2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 18
2.5.7. Independent Discovery Per Traffic Source . . . . . . 18 2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 18
2.6. DNS Configuration . . . . . . . . . . . . . . . . . . . . 18 2.5.7. Independent Discovery Per Traffic Source . . . . . . 19
2.7. Waiting for DNS resolution . . . . . . . . . . . . . . . 18 2.6. DNS Configuration . . . . . . . . . . . . . . . . . . . . 19
3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 19 2.7. Waiting for DNS resolution . . . . . . . . . . . . . . . 20
3.1. Example Receiving Networks . . . . . . . . . . . . . . . 19 3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 20
3.1.1. Tier 3 ISP . . . . . . . . . . . . . . . . . . . . . 19 3.1. Example Receiving Networks . . . . . . . . . . . . . . . 20
3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 20 3.1.1. Tier 3 ISP . . . . . . . . . . . . . . . . . . . . . 20
3.2. Example Sending Networks . . . . . . . . . . . . . . . . 22 3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 21
3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 22 3.2. Example Sending Networks . . . . . . . . . . . . . . . . 23
3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 23 3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 23
4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 24 3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 24
4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 24 4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 25
4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 24 4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 25
4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 25 4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 25
4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 25 4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 26
4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 25 4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 26
4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 26 4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 26
4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 26 4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 27
4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 26 4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 27
4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 27 4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 27
4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 28
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
6.1. Use of AMT . . . . . . . . . . . . . . . . . . . . . . . 28 6.1. Use of AMT . . . . . . . . . . . . . . . . . . . . . . . 29
6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 28 6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 29
6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 29 6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 30
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.1. Normative References . . . . . . . . . . . . . . . . . . 29 8.1. Normative References . . . . . . . . . . . . . . . . . . 30
8.2. Informative References . . . . . . . . . . . . . . . . . 31 8.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Unknown RRType construction . . . . . . . . . . . . 32 Appendix A. Unknown RRType construction . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34
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 6, line 35 skipping to change at page 6, line 35
index into one of the reverse mapping trees (in-addr.arpa for IPv4, index into one of the reverse mapping trees (in-addr.arpa for IPv4,
as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, as as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, as
described in Section 2.5 of [RFC3596]). described in Section 2.5 of [RFC3596]).
This mechanism should be treated as an extension of the AMT relay This mechanism should be treated as an extension of the AMT relay
discovery procedure described in Section 5.2.3.4 of [RFC7450]. A discovery procedure described in Section 5.2.3.4 of [RFC7450]. A
gateway that supports this method of AMT relay discovery SHOULD use gateway that supports this method of AMT relay discovery SHOULD use
this method whenever it's performing the relay discovery procedure, this method whenever it's performing the relay discovery procedure,
and the source IP addresses for desired (S,G)s are known to the and the source IP addresses for desired (S,G)s are known to the
gateway, and conditions match the requirements outlined in gateway, and conditions match the requirements outlined in
Section 2.4. Section 2.3.
Some detailed example use cases are provided in Section 3, and other Some detailed example use cases are provided in Section 3, and other
applicable example topologies appear in Section 3.3 of [RFC8313], applicable example topologies appear in Section 3.3 of [RFC8313],
Section 3.4 of [RFC8313], and Section 3.5 of [RFC8313]. Section 3.4 of [RFC8313], and Section 3.5 of [RFC8313].
2.2. Signaling and Discovery 2.2. Signaling and Discovery
This section describes a typical example of the end-to-end process This section describes a typical example of the end-to-end process
for signaling a receiver's join of an SSM channel that relies on an for signaling a receiver's join of an SSM channel that relies on an
AMTRELAY RR. AMTRELAY RR.
skipping to change at page 8, line 19 skipping to change at page 8, line 19
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):
(198.51.100.15, 232.252.0.2). (198.51.100.15, 232.252.0.2).
2. The join propagates with RPF through the multicast-enabled 2. The join propagates with RPF through the receiver's multicast-
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 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
skipping to change at page 8, line 44 skipping to change at page 8, line 44
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.
2.3. Happy Eyeballs 2.3. Optimal Relay Selection
2.3.1. Overview 2.3.1. Overview
Often, multiple choices of relay will exist for a gateway using DRIAD
for relay discovery. It is RECOMMENDED that DRIAD-capable gateways
implement a Happy Eyeballs [RFC8305] algorithm to support connecting
to multiple relays in parallel.
The parallel discovery logic of a Happy Eyeballs algorithm serves to
reduce join latency for the initial join of an SSM channel. This
section and Section 2.4.2 taken together provide guidance on use of a
Happy Eyeballs algorithm for the case of establishing AMT
connections.
2.3.2. Connection Definition
Section 5 of [RFC8305] non-normatively describes success at a
connection attempt as "generally when the TCP handshake completes".
There is no normative definition of a connection in the AMT
specification [RFC7450], and there is no TCP connection involved in
an AMT tunnel.
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
following normative definition:
o An AMT connection is completed successfully when the gateway
receives from a newly discovered relay a valid Membership Query
message (Section 5.1.4 of [RFC7450]) that does not have the L flag
set.
See Section 2.5.5 of this document for further information about the
relevance of the L flag to the establishment of a Happy Eyeballs
connection. See Section 2.5.4 for an overview of how to respond if
the connection does not provide multicast connectivity to the source.
2.4. Optimal Relay Selection
2.4.1. Overview
The reverse source IP DNS query of an AMTRELAY RR is a good way for a The reverse source IP DNS query of an AMTRELAY RR is a good way for a
gateway to discover a relay that is known to the sender. gateway to discover a relay that is known to the sender.
However, it is NOT necessarily a good way to discover the best relay However, it is NOT necessarily a good way to discover the best relay
for that gateway to use, because the RR will only provide information for that gateway to use, because the RR will only provide information
about relays known to the source. about relays known to the source.
If there is an upstream relay in a network that is topologically If there is an upstream relay in a network that is topologically
closer to the gateway and able to receive and forward multicast closer to the gateway and able to receive and forward multicast
traffic from the sender, that relay is better for the gateway to use, traffic from the sender, that relay is better for the gateway to use,
skipping to change at page 10, line 39 skipping to change at page 10, line 5
When the above conditions are met, the gateway has no path within its When the above conditions are met, the gateway has no path within its
local network that can receive multicast traffic from the source IP local network that can receive multicast traffic from the source IP
of the (S,G). of the (S,G).
In this situation, the best way to find a relay that can forward the In this situation, the best way to find a relay that can forward the
required traffic is to use information that comes from the operator required traffic is to use information that comes from the operator
of the sender. When the sender has configured an AMTRELAY RR, of the sender. When the sender has configured an AMTRELAY RR,
gateways can use the DRIAD mechanism defined in this document to gateways can use the DRIAD mechanism defined in this document to
discover the relay information provided by the sender. discover the relay information provided by the sender.
2.4.2. Preference Ordering 2.3.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, but even gateways that do not implement a Happy Eyeballs algorithm to try candidate relays concurrently, but
Happy Eyeballs algorithm SHOULD use this ordering, except as noted. even gateways that do not 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 the network
topology considerations ahead of address selection considerations, in topology considerations ahead of address selection considerations, in
order to gain the packet replication benefits from using multicast order to gain the packet replication benefits from using multicast
instead of unicast tunneling in the multicast-capable portions of the instead of unicast tunneling in the multicast-capable portions of the
network path. network 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
skipping to change at page 13, line 11 skipping to change at page 12, line 26
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
attempts. attempts.
2.4.3. Connecting to Multiple Relays 2.3.3. Connecting to Multiple Relays
In some deployments, it may be useful for a gateway to connect to In some deployments, it may be useful for a gateway to connect to
multiple upstream relays and subscribe to the same traffic, in order multiple upstream relays and subscribe to the same traffic, in order
to support an active/active failover model. A gateway SHOULD NOT be to support an active/active failover model. A gateway SHOULD NOT be
configured to do so without guaranteeing that adequate bandwidth is configured to do so without guaranteeing that adequate bandwidth is
available. available.
A gateway configured to do this SHOULD still use the same preference A gateway configured to do this SHOULD still use the same preference
ordering logic from Section 2.4.2 for each connection. (Note that ordering logic from Section 2.3.2 for each connection. (Note that
this ordering allows for overriding by explicit administrative this ordering allows for overriding by explicit administrative
configuration where required.) configuration where required.)
2.4. Happy Eyeballs
2.4.1. Overview
Often, multiple choices of relay will exist for a gateway using DRIAD
for relay discovery. Happy Eyeballs [RFC8305] provides a widely
deployed and generalizable strategy for probing multiple possible
connections in parallel, therefore it is RECOMMENDED that DRIAD-
capable gateways implement a Happy Eyeballs algorithm to support fast
discovery of the most preferred available relay, by probing multiple
relays concurrently.
The parallel discovery logic of a Happy Eyeballs algorithm serves to
reduce join latency for the initial join of an SSM channel. This
section and the preference ordering of relays defined in
Section 2.3.2 taken together provide guidance on use of a Happy
Eyeballs algorithm for the case of establishing AMT connections.
Note that according to the definition in Section 2.4.3 of this
document, establishing the connection occurs before sending a
membership report. As described in Section 5 of [RFC8085], only one
of the successful connections will be used, and the others are all
canceled or ignored. In the context of an AMT connection, this means
the gateway will send the membership reports that subscribe to
traffic only for the chosen connection, after the Happy Eyeballs
algorithm resolves.
2.4.2. Algorithm Guidelines
During the "Initiation of asynchronous DNS queries" phase described
in Section 3 of [RFC8305]), a gateway attempts to resolve the domain
names listed in Section 2.3. This consists of resolving the SRV
queries for DNS-SD domains for the AMT service, as well as the
AMTRELAY query for the reverse IP domain defined in this document.
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
SRV Additional Data section of the SRV response contains the address
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
SRV response without an additional data section).
When present, IP addresses in the initial response provide resolved
destination address candidates for the "Sorting of resolved
destination addresses" phase described in Section 4 of [RFC8085]),
whereas domain names without IP addresses in the initial response
result in another set of queries for AAAA and A records, whose
responses provide the candidate resolved destination addresses.
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
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
follow ordinary standards and best practices for DNS clients. A
gateway MAY use an existing DNS client implementation that does so,
and MAY rely on that client's rate limiting logic to avoid issuing
excessive queries. Otherwise, a gateway MUST provide a rate limit
for the DNS queries, and its default settings MUST NOT permit more
than 10 queries for any 100-millisecond period (though this MAY be
overridable by administrative configuration).
As the resolved IP addresses arrive, the Happy Eyeballs algorithm
sorts them according to the requirements and recommendations given in
Section 2.3.2, and attempts connections with the corresponding relays
under the algorithm restrictions and guidelines given in [RFC8085]
for the "Establishment of one connection, which cancels all other
attempts" phase.
2.4.3. Connection Definition
Section 5 of [RFC8305] non-normatively describes success at a
connection attempt as "generally when the TCP handshake completes".
There is no normative definition of a connection in the AMT
specification [RFC7450], and there is no TCP connection involved in
an AMT tunnel.
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
following normative definition:
o An AMT connection is completed successfully when the gateway
receives from a newly discovered relay a valid Membership Query
message (Section 5.1.4 of [RFC7450]) that does not have the L flag
set.
See Section 2.5.5 of this document for further information about the
relevance of the L flag to the establishment of a Happy Eyeballs
connection. See Section 2.5.4 for an overview of how to respond if
the connection does not provide multicast connectivity to the source.
To "cancel" this kind of AMT connection for the Happy Eyeballs
algorithm, a gateway that has not sent a membership report with a
subscription would simply stop sending AMT packets for that
connection. A gateway only sends a membership report to a connection
it has chosen as the most preferred available connection.
2.5. Guidelines for Restarting Discovery 2.5. Guidelines for Restarting Discovery
2.5.1. Overview 2.5.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).
skipping to change at page 17, line 15 skipping to change at page 18, line 33
2.5.5. Relay Loaded or Shutting Down 2.5.5. Relay Loaded or Shutting Down
The L flag (see Section 5.1.4.4 of [RFC7450]) is the preferred The L flag (see Section 5.1.4.4 of [RFC7450]) is the preferred
mechanism for a relay to signal overloading or a graceful shutdown to mechanism for a relay to signal overloading or a graceful shutdown to
gateways. gateways.
A gateway that supports handling of the L flag should generally A gateway that supports handling of the L flag should generally
restart the discovery process when it processes a Membership Query restart the discovery process when it processes a Membership Query
packet with the L flag set. If an L flag is received while a packet with the L flag set. If an L flag is received while a
concurrent Happy Eyeballs discovery process is under way for multiple concurrent Happy Eyeballs discovery process is under way for multiple
candidate relays (Section 2.3), the relay sending the L flag SHOULD candidate relays (Section 2.4), the relay sending the L flag SHOULD
NOT be considered for the relay selection. NOT be considered for the relay selection.
It is also RECOMMENDED that gateways avoid choosing a relay that has It is also RECOMMENDED that gateways avoid choosing a relay that has
recently sent an L flag, with approximately a 10-minute hold-down. recently sent an L flag, with approximately a 10-minute hold-down.
Gateways SHOULD treat this hold-down timer in the same way as the Gateways SHOULD treat this hold-down timer in the same way as the
hold-down in Section 2.5.4.1, so that the relay is removed from hold-down in Section 2.5.4.1, so that the relay is removed from
consideration for short-term subsequent rounds of discovery. consideration for short-term subsequent rounds of discovery.
2.5.6. Relay Discovery Messages vs. Restarting Discovery 2.5.6. Relay Discovery Messages vs. Restarting Discovery
skipping to change at page 29, line 28 skipping to change at page 30, line 28
that don't follow UDP congestion control principles, or deliberate that don't follow UDP congestion control principles, or deliberate
attack. attack.
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, and Bill Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, Ben Kaduk, Bill
Atwood for their very helpful comments. Atwood, Tim Chown, and Warren Kumari for their very helpful 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
skipping to change at page 30, line 5 skipping to change at page 31, line 5
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<https://www.rfc-editor.org/info/rfc2181>. <https://www.rfc-editor.org/info/rfc2181>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/info/rfc2782>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/info/rfc3376>. <https://www.rfc-editor.org/info/rfc3376>.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", STD 88, "DNS Extensions to Support IP Version 6", STD 88,
RFC 3596, DOI 10.17487/RFC3596, October 2003, RFC 3596, DOI 10.17487/RFC3596, October 2003,
<https://www.rfc-editor.org/info/rfc3596>. <https://www.rfc-editor.org/info/rfc3596>.
 End of changes. 19 change blocks. 
100 lines changed or deleted 165 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/