--- 1/draft-ietf-mboned-driad-amt-discovery-02.txt 2019-04-04 14:13:13.138898014 -0700 +++ 2/draft-ietf-mboned-driad-amt-discovery-03.txt 2019-04-04 14:13:13.214900014 -0700 @@ -1,19 +1,19 @@ Mboned J. Holland Internet-Draft Akamai Technologies, Inc. -Updates: 7450 (if approved) March 08, 2019 +Updates: 7450 (if approved) April 04, 2019 Intended status: Standards Track -Expires: September 9, 2019 +Expires: October 6, 2019 DNS Reverse IP AMT Discovery - draft-ietf-mboned-driad-amt-discovery-02 + draft-ietf-mboned-driad-amt-discovery-03 Abstract This document updates RFC 7450 (Automatic Multicast Tunneling, or AMT) by extending the relay discovery process to use a new DNS resource record named AMTRELAY when discovering AMT relays for source-specific multicast channels. The reverse IP DNS zone for a multicast sender's IP address is configured to use AMTRELAY resource records to advertise a set of AMT relays that can receive and forward multicast traffic from that sender over an AMT tunnel. @@ -26,21 +26,21 @@ 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 9, 2019. + This Internet-Draft will expire on October 6, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -59,60 +59,60 @@ 1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 4 2. Relay Discovery Operation . . . . . . . . . . . . . . . . . . 5 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Signaling and Discovery . . . . . . . . . . . . . . . . . 6 2.3. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . . 8 2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 8 2.3.2. Connection Definition . . . . . . . . . . . . . . . . 9 2.4. Optimal Relay Selection . . . . . . . . . . . . . . . . . 9 2.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 9 2.4.2. Preference Ordering . . . . . . . . . . . . . . . . . 10 - 2.4.3. Connecting to Multiple Relays . . . . . . . . . . . . 12 + 2.4.3. Connecting to Multiple Relays . . . . . . . . . . . . 13 2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 13 2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13 - 2.5.2. Updates to Restarting Events . . . . . . . . . . . . 13 - 2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 14 + 2.5.2. Updates to Restarting Events . . . . . . . . . . . . 14 + 2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 15 2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 15 - 2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 16 + 2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 17 2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 17 - 2.5.7. Independent Discovery Per Traffic Source . . . . . . 17 + 2.5.7. Independent Discovery Per Traffic Source . . . . . . 18 2.6. DNS Configuration . . . . . . . . . . . . . . . . . . . . 18 - 2.7. Waiting for DNS resolution . . . . . . . . . . . . . . . 18 + 2.7. Waiting for DNS resolution . . . . . . . . . . . . . . . 19 3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 19 3.1. Example Receiving Networks . . . . . . . . . . . . . . . 19 3.1.1. Tier 3 ISP . . . . . . . . . . . . . . . . . . . . . 19 3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 20 - 3.2. Example Sending Networks . . . . . . . . . . . . . . . . 21 - 3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 21 - 3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 22 - 4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 23 - 4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 23 - 4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 23 - 4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 24 - 4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 24 - 4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 24 - 4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 25 - 4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 25 - 4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 25 - 4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 26 + 3.2. Example Sending Networks . . . . . . . . . . . . . . . . 22 + 3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 22 + 3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 23 + 4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 24 + 4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 24 + 4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 24 + 4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 25 + 4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 25 + 4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 25 + 4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 26 + 4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 26 + 4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 26 + 4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 27 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 - 6.1. Use of AMT . . . . . . . . . . . . . . . . . . . . . . . 27 - 6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 27 - 6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 28 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 28 - 8.2. Informative References . . . . . . . . . . . . . . . . . 30 - Appendix A. Unknown RRType construction . . . . . . . . . . . . 31 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 + 6.1. Use of AMT . . . . . . . . . . . . . . . . . . . . . . . 28 + 6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 28 + 6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 29 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 29 + 8.2. Informative References . . . . . . . . . . . . . . . . . 31 + Appendix A. Unknown RRType construction . . . . . . . . . . . . 32 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33 1. Introduction This document defines DNS Reverse IP AMT Discovery (DRIAD), a mechanism for AMT gateways to discover AMT relays that are capable of forwarding multicast traffic from a known source IP address. AMT (Automatic Multicast Tunneling) is defined in [RFC7450], and provides a method to transport multicast traffic over a unicast tunnel, in order to traverse non-multicast-capable network segments. @@ -418,21 +418,24 @@ multicast traffic from the source of the (S,G); and 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 forward traffic from the source of the (S,G); and 4. The gateway is not able to find an upstream AMT relay with DNS-SD [RFC6763], using "_amt._udp" as the Service section of the queries, or a relay discovered this way is not able to forward traffic from the source of the (S,G) (as described in - Section 2.5.4.1 or Section 2.5.5). + Section 2.5.4.1 or Section 2.5.5); and + + 5. The gateway is not able to find an upstream AMT relay with the + well-known anycast addresses from Section 7 of [RFC7450]. When the above conditions are met, the gateway has no path within its local network that can receive multicast traffic from the source IP of the (S,G). 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 of the sender. When the sender has configured an AMTRELAY RR, gateways can use the DRIAD mechanism defined in this document to discover the relay information provided by the sender. @@ -469,56 +472,60 @@ DNS-SD [RFC6763] for discovery strictly ahead of using the AMTRELAY RR controlled by the sender for AMT discovery. For this reason, it's RECOMMENDED that AMT gateways by default perform service discovery using DNS Service Discovery (DNS-SD) [RFC6763] for _amt._udp. (with chosen as described in Section 11 of [RFC6763]) and use the AMT relays discovered that way in preference to AMT relays discoverable via the mechanism defined in this document (DRIAD). - 2. Let Sender Manage Relay Provisioning + 2. Prefer Relays Managed by the Containing Network + + 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 + network providing transit services to the receiver. + + In this case, when the network cannot make the relay discoverable + via DNS-SD, the network SHOULD use the well-known anycast + addresses from Section 7 of [RFC7450] to route discovery traffic + to the relay most appropriate to the receiver's gateway. + + Accordingly, the gateway SHOULD by default discover a relay with + the well-known AMT anycast addresses as the second preference + after DNS-SD when searching for a local relay. + + 3. Let Sender Manage Relay Provisioning A related motivating example in the sending-side network is provided by considering a sender which needs to instruct the gateways on how to select between connecting to Figure 6 or Figure 7 (from Section 3.2), in order to manage load and failover scenarios in a manner that operates well with the sender's provisioning strategy for horizontal scaling of AMT relays. In this example about the sending-side network, the precedence field described in Section 4.2.1 is a critical method of control so that senders can provide the appropriate guidance to gateways during the discovery process. Therefore, after DNS-SD, the precedence from the RR MUST be used for sorting preference ahead of the Destination Address Selection ordering from Section 6 of [RFC6724], so that only relay IPs with the same precedence are directly compared according to the Destination Address Selection ordering. - 3. Let Sender Manage Non-DRIAD discovery - - It's also RECOMMENDED that if the well-known anycast IP addresses - defined in Section 7 of [RFC7450] are suitable for discovering an - AMT relay that can forward traffic from the source, that a DNS - record with the AMTRELAY RRType be published by the sender for - those IP addresses along with any other appropriate AMTRELAY RRs - to indicate the best relative precedences for receiving the - source traffic. - Accordingly, AMT gateways SHOULD by default prefer relays first by - DNS-SD if available, then by DRIAD as described in this document (in - precedence order, as described in Section 4.2.1), then with the - anycast addresses defined in Section 7 of [RFC7450] (namely: - 192.52.193.1 and 2001:3::1) if those IPs weren't listed in the - AMTRELAY RRs. + DNS-SD if available, then with the anycast addresses defined in + Section 7 of [RFC7450] (namely: 192.52.193.1 and 2001:3::1), then by + DRIAD as described in this document (in precedence order, as + described in Section 4.2.1). This default behavior MAY be overridden by administrative configuration where other behavior is more appropriate for the gateway within its network. Among relay addresses that have an equivalent preference as described above, a Happy Eyeballs algorithm for AMT MUST use the Destination Address Selection defined in Section 6 of [RFC6724], as required by [RFC8305]. @@ -894,21 +901,21 @@ regularly accesses some multicast content, illustrated in Figure 4. This office has desktop devices that need to receive some multicast traffic, so an AMT gateway runs on a LAN with these devices, to pull traffic in through a non-multicast next-hop. The office also hosts some mobile devices that have AMT gateway instances embedded inside apps, in order to receive multicast traffic over their non-multicast wireless LAN. (Note that the "Legacy Router" is a simplification that's meant to describe a variety of - possible conditions- for example it could be a device providing a + possible conditions; for example it could be a device providing a split-tunnel VPN as described in [RFC7359], deliberately excluding multicast traffic for a VPN tunnel, rather than a device which is incapable of multicast forwarding.) Internet (non-multicast) ^ | Office Network +----------|----------------------------------+ | | |