--- 1/draft-ietf-mboned-driad-amt-discovery-12.txt 2019-12-20 12:13:15.558498766 -0800 +++ 2/draft-ietf-mboned-driad-amt-discovery-13.txt 2019-12-20 12:13:15.638500806 -0800 @@ -1,19 +1,19 @@ Mboned J. Holland Internet-Draft Akamai Technologies, Inc. -Updates: 7450 (if approved) December 19, 2019 +Updates: 7450 (if approved) December 20, 2019 Intended status: Standards Track -Expires: June 21, 2020 +Expires: June 22, 2020 DNS Reverse IP AMT (Automatic Multicast Tunneling) Discovery - draft-ietf-mboned-driad-amt-discovery-12 + draft-ietf-mboned-driad-amt-discovery-13 Abstract This document updates RFC 7450 (Automatic Multicast Tunneling, or AMT) by modifying the relay discovery process. A new DNS resource record named AMTRELAY is defined for publishing 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. Other @@ -28,92 +28,89 @@ 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 June 21, 2020. + This Internet-Draft will expire on June 22, 2020. 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.1. Relays and Gateways . . . . . . . . . . . . . . . . . 4 1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 4 - 2. Relay Discovery Operation . . . . . . . . . . . . . . . . . . 6 - 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2. Relay Discovery Overview . . . . . . . . . . . . . . . . . . 6 + 2.1. Basic Mechanics . . . . . . . . . . . . . . . . . . . . . 6 2.2. Signaling and Discovery . . . . . . . . . . . . . . . . . 6 - 2.3. Optimal Relay Selection . . . . . . . . . . . . . . . . . 9 - 2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 9 - 2.3.2. Preference Ordering . . . . . . . . . . . . . . . . . 10 - 2.3.3. Connecting to Multiple Relays . . . . . . . . . . . . 13 - 2.4. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . . 13 - 2.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13 - 2.4.2. Algorithm Guidelines . . . . . . . . . . . . . . . . 13 - 2.4.3. Connection Definition . . . . . . . . . . . . . . . . 14 - 2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 15 - 2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 15 - 2.5.2. Updates to Restarting Events . . . . . . . . . . . . 16 - 2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 17 - 2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 17 - 2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 19 - 2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 19 - 2.5.7. Independent Discovery Per Traffic Source . . . . . . 20 - 2.6. DNS Configuration . . . . . . . . . . . . . . . . . . . . 20 - 2.7. Waiting for DNS resolution . . . . . . . . . . . . . . . 21 - 3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 21 - 3.1. Example Receiving Networks . . . . . . . . . . . . . . . 21 - 3.1.1. Internet Service Provider . . . . . . . . . . . . . . 21 - 3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 22 - 3.2. Example Sending Networks . . . . . . . . . . . . . . . . 24 - 3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 24 - 3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 25 + 2.3. Example Deployments . . . . . . . . . . . . . . . . . . . 9 + 2.3.1. Example Receiving Networks . . . . . . . . . . . . . 9 + 2.3.2. Example Sending Networks . . . . . . . . . . . . . . 12 + 3. Relay Discovery Operation . . . . . . . . . . . . . . . . . . 14 + 3.1. Optimal Relay Selection . . . . . . . . . . . . . . . . . 14 + 3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 14 + 3.1.2. Preference Ordering . . . . . . . . . . . . . . . . . 15 + 3.1.3. Connecting to Multiple Relays . . . . . . . . . . . . 18 + 3.2. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . . 18 + 3.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 18 + 3.2.2. Algorithm Guidelines . . . . . . . . . . . . . . . . 19 + 3.2.3. Connection Definition . . . . . . . . . . . . . . . . 20 + 3.3. Guidelines for Restarting Discovery . . . . . . . . . . . 20 + 3.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 20 + 3.3.2. Updates to Restarting Events . . . . . . . . . . . . 21 + 3.3.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 22 + 3.3.4. Traffic Health . . . . . . . . . . . . . . . . . . . 22 + 3.3.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 24 + 3.3.6. Relay Discovery Messages vs. Restarting Discovery . . 24 + 3.3.7. Independent Discovery Per Traffic Source . . . . . . 25 + 3.4. DNS Configuration . . . . . . . . . . . . . . . . . . . . 25 + 3.5. Waiting for DNS resolution . . . . . . . . . . . . . . . 26 4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 26 4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 26 - 4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 26 + 4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 27 4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 27 4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 27 - 4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 27 + 4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 28 4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 28 - - 4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 28 - 4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 28 + 4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 29 + 4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 29 4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 29 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6.1. Use of AMT . . . . . . . . . . . . . . . . . . . . . . . 30 - 6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 30 + 6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 31 6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 31 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 8.1. Normative References . . . . . . . . . . . . . . . . . . 32 - 8.2. Informative References . . . . . . . . . . . . . . . . . 33 + 8.2. Informative References . . . . . . . . . . . . . . . . . 34 Appendix A. Unknown RRType construction . . . . . . . . . . . . 35 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36 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 @@ -214,23 +211,23 @@ | | | | OLT | Optical Line Terminal | +------------+------------------------------------------------------+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. -2. Relay Discovery Operation +2. Relay Discovery Overview -2.1. Overview +2.1. Basic Mechanics The AMTRELAY resource record (RR) defined in this document is used to publish the IP address or domain name of a set of AMT relays or discovery brokers that can receive, encapsulate, and forward multicast traffic from a particular sender. 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 AMT relays (or discovery brokers that advertise relays) that can receive multicast IP traffic from that sender. @@ -247,25 +244,25 @@ 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 described in Section 2.5 of [RFC3596]). This mechanism should be treated as an extension of the AMT relay discovery procedure described in Section 5.2.3.4 of [RFC7450]. A gateway that supports this method of AMT relay discovery SHOULD use this method whenever it's performing the relay discovery procedure, and the source IP addresses for desired (S,G)s are known to the gateway, and conditions match the requirements outlined in - Section 2.3. + Section 3.1. - Some detailed example use cases are provided in Section 3, and other - applicable example topologies appear in Section 3.3 of [RFC8313], - Section 3.4 of [RFC8313], and Section 3.5 of [RFC8313]. + Some detailed example use cases are provided in Section 2.3, and + other applicable example topologies appear in Section 3.3 of + [RFC8313], Section 3.4 of [RFC8313], and Section 3.5 of [RFC8313]. 2.2. Signaling and Discovery 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 AMTRELAY RR. The example in Figure 2 contains 2 multicast-enabled networks that are both connected to the internet with non-multicast-capable links, and which have no direct association with each other. @@ -292,25 +289,25 @@ |Flow| Multicast | \| |/ Network | \ / | 5: Propagate RPF for Join(S,G) \ / +---------------+ \/ | AMT Relay | | 2001:db8:c::f | +---------------+ | 4: Gateway connects to Relay, sends Join(S,G) over tunnel | - Unicast 3: --> DNS Query: type=AMTRELAY, - Tunnel | / 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 - | / + Unicast + Tunnel | 3: --> DNS Query: type=AMTRELAY, + / 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 | | / <-- Response: Join/Leave +-------------+ AMTRELAY=2001:db8:c::f Signals | AMT gateway | | +-------------+ | | 2: Propagate RPF for Join(S,G) | Multicast | Network | | 1: Join(S=2001:db8::a,G=ff3e::8000:d) +-------------+ | Receiver | @@ -365,83 +362,285 @@ 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 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, 232.252.0.2), the reverse IP FQDN for the AMTRELAY query would be "12.100.51.198.in-addr.arpa.". Note that the address family of the AMT tunnel is independent of the address family for the multicast traffic. -2.3. Optimal Relay Selection +2.3. Example Deployments -2.3.1. Overview +2.3.1. Example Receiving Networks + +2.3.1.1. Internet Service Provider + + One example of a receiving network is an Internet Service Provider + (ISP) that offers multicast ingest services to its subscribers, + illustrated in Figure 3. + + In the example network below, subscribers can join (S,G)s with MLDv2 + or IGMPv3 as described in [RFC4604], and the AMT gateway in this ISP + can receive and forward multicast traffic from one of the example + sending networks in Section 2.3.2 by discovering the appropriate AMT + relays with a DNS lookup for the AMTRELAY RR with the reverse IP of + the source in the (S,G). + + Internet + ^ ^ Multicast-enabled + | | Receiving Network + +------|------------|-------------------------+ + | | | | + | +--------+ +--------+ +=========+ | + | | Border |---| Border | | AMT | | + | | Router | | Router | | gateway | | + | +--------+ +--------+ +=========+ | + | | | | | + | +-----+------+-----------+--+ | + | | | | + | +-------------+ +-------------+ | + | | Agg Routers | .. | Agg Routers | | + | +-------------+ +-------------+ | + | / \ \ / \ | + | +---------------+ +---------------+ | + | |Access Systems | ....... |Access Systems | | + | |(CMTS/OLT/etc.)| |(CMTS/OLT/etc.)| | + | +---------------+ +---------------+ | + | | | | + +--------|------------------------|-----------+ + | | + +---+-+-+---+---+ +---+-+-+---+---+ + | | | | | | | | | | + /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ + |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| + + Subscribers + + Figure 3: Receiving ISP Example + +2.3.1.2. Small Office + + Another example receiving network is a small branch office that + regularly accesses some multicast content, illustrated in Figure 4. + + This office has desktop devices that need to receive some multicast + traffic, so an AMT gateway runs on a LAN with these devices, to pull + traffic in through a non-multicast next-hop. + + The office also hosts some mobile devices that have AMT gateway + instances embedded inside apps, in order to receive multicast traffic + over their non-multicast wireless LAN. (Note that the "Legacy + Router" is a simplification that's meant to describe a variety of + possible conditions; for example it could be a device providing a + split-tunnel VPN as described in [RFC7359], deliberately excluding + multicast traffic for a VPN tunnel, rather than a device which is + incapable of multicast forwarding.) + + Internet + (non-multicast) + ^ + | Office Network + +----------|----------------------------------+ + | | | + | +---------------+ (Wifi) Mobile apps | + | | Modem+ | Wifi | - - - - w/ embedded | + | | Router | AP | AMT gateways | + | +---------------+ | + | | | + | | | + | +----------------+ | + | | Legacy Router | | + | | (unicast) | | + | +----------------+ | + | / | \ | + | / | \ | + | +--------+ +--------+ +--------+=========+ | + | | Phones | | ConfRm | | Desks | AMT | | + | | subnet | | subnet | | subnet | gateway | | + | +--------+ +--------+ +--------+=========+ | + | | + +---------------------------------------------+ + + Figure 4: Small Office (no multicast up) + + By adding an AMT relay to this office network as in Figure 5, it's + possible to make use of multicast services from the example + multicast-capable ISP in Section 2.3.1.1. + + Multicast-capable ISP + ^ + | Office Network + +----------|----------------------------------+ + | | | + | +---------------+ (Wifi) Mobile apps | + | | Modem+ | Wifi | - - - - w/ embedded | + | | Router | AP | AMT gateways | + | +---------------+ | + | | +=======+ | + | +---Wired LAN---| AMT | | + | | | relay | | + | +----------------+ +=======+ | + | | Legacy Router | | + | | (unicast) | | + | +----------------+ | + | / | \ | + | / | \ | + | +--------+ +--------+ +--------+=========+ | + | | Phones | | ConfRm | | Desks | AMT | | + | | subnet | | subnet | | subnet | gateway | | + | +--------+ +--------+ +--------+=========+ | + | | + +---------------------------------------------+ + + Figure 5: Small Office Example + + When multicast-capable networks are chained like this, with a network + like the one in Figure 5 receiving internet services from a + multicast-capable network like the one in Figure 3, it's important + for AMT gateways to reach the more local AMT relay, in order to avoid + accidentally tunneling multicast traffic from a more distant AMT + relay with unicast, and failing to utilize the multicast transport + capabilities of the network in Figure 3. + +2.3.2. Example Sending Networks + +2.3.2.1. Sender-controlled Relays + + When a sender network is also operating AMT relays to distribute + multicast traffic, as in Figure 6, each address could appear as an + AMTRELAY RR for the reverse IP of the sender, or one or more domain + names could appear in AMTRELAY RRs, and the AMT relay addresses can + be discovered by finding A or AAAA records from those domain names. + + Sender Network + +-----------------------------------+ + | | + | +--------+ +=======+ +=======+ | + | | Sender | | AMT | | AMT | | + | +--------+ | relay | | relay | | + | | +=======+ +=======+ | + | | | | | + | +-----+------+----------+ | + | | | + +-----------|-----------------------+ + v + Internet + (non-multicast) + + Figure 6: Small Office Example + +2.3.2.2. Provider-controlled Relays + + When an ISP offers a service to transmit outbound multicast traffic + through a forwarding network, it might also offer AMT relays in order + to reach receivers without multicast connectivity to the forwarding + network, as in Figure 7. In this case it's recommended that the ISP + also provide at least one domain name for the AMT relays for use with + the AMTRELAY RR. + + When the sender wishes to use the relays provided by the ISP for + forwarding multicast traffic, an AMTRELAY RR should be configured to + use the domain name provided by the ISP, to allow for address + reassignment of the relays without forcing the sender to reconfigure + the corresponding AMTRELAY RRs. + + +--------+ + | Sender | + +---+----+ Multicast-enabled + | Sending Network + +-----------|-------------------------------+ + | v | + | +------------+ +=======+ +=======+ | + | | Agg Router | | AMT | | AMT | | + | +------------+ | relay | | relay | | + | | +=======+ +=======+ | + | | | | | + | +-----+------+--------+---------+ | + | | | | + | +--------+ +--------+ | + | | Border |---| Border | | + | | Router | | Router | | + | +--------+ +--------+ | + +-----|------------|------------------------+ + | | + v v + Internet + (non-multicast) + + Figure 7: Sending ISP Example + +3. Relay Discovery Operation + +3.1. Optimal Relay Selection + +3.1.1. Overview The reverse source IP DNS query of an AMTRELAY RR is a good way for a gateway to discover a relay that is known to the sender. 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 about relays known to the source. If there is an upstream relay in a network that is topologically closer to the gateway and able to receive and forward multicast traffic from the sender, that relay is better for the gateway to use, since more of the network path uses native multicast, allowing more 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 record. An example network that illustrates this scenario is - outlined in Section 3.1.2. + outlined in Figure 5 from Section 2.3.1.2. It's only appropriate for an AMT gateway to discover an AMT relay by querying an AMTRELAY RR owned by a sender when all of these conditions are met: 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 source can propagate a native multicast join of the (S,G); and 2. The gateway is not already connected to a relay that forwards 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); and + Section 3.3.4.1 or Section 3.3.5); and 5. The gateway is not able to find an upstream AMT relay with the 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. Note that the DNS-SD service is not source-specific, so even though - several methods of finding a more local source of multicast traffic - connectivity are preferred where available to using a relay provided - by an AMTRELAY RR, a gateway further upstream would still be using - the AMTRELAY RR unless the upstream network has a peering or direct - connectivity that provides an alternative end-to-end multicast - transport path for the (S,G)'s traffic. + when available, several methods of finding a more local source of + multicast traffic connectivity are preferred to using a relay + provided by an AMTRELAY RR, a gateway further upstream would still be + using the AMTRELAY RR unless the upstream network has a peering that + provides an alternative end-to-end multicast transport path for the + (S,G)'s traffic. -2.3.2. Preference Ordering +3.1.2. Preference Ordering This section defines a preference ordering for relay addresses during the relay discovery process. Gateways are encouraged to implement a Happy Eyeballs algorithm to try candidate relays concurrently, but 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 important for the discovery process to prioritize the network topology considerations ahead of address selection considerations, in @@ -456,22 +655,22 @@ considerations. Section 4 of [RFC8305] requires a Happy Eyeballs algorithm to sort the addresses with the Destination Address Selection defined in Section 6 of [RFC6724], but for the above reasons, that requirement is superseded in the AMT discovery use case by the following considerations: o Prefer Local Relays - Figure 5 and Section 3.1.2 provide a motivating example to prefer - DNS-SD [RFC6763] for discovery strictly ahead of using the + Figure 5 and Section 2.3.1.2 provide a motivating example to + prefer 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). o Prefer Relays Managed by the Containing Network @@ -486,22 +685,22 @@ 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. o Let Sender Manage Relay Provisioning A related motivating example is provided by considering a sender whose traffic can be forwarded by relays in a sender-controlled - network like Figure 6 in Section 3.2.1, and also by relays in a - provider-controlled network like Figure 7 in Section 3.2.2, with + network like Figure 6 in Section 2.3.2.1, and also by relays in a + provider-controlled network like Figure 7 in Section 2.3.2.2, with different cost and scalability profiles for the different options. 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, 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. Therefore, after DNS-SD, the precedence from the RR MUST be used @@ -539,76 +738,76 @@ structure and collection of this information are out of scope for this document, but 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 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 - consideration by the hold-down timers described in Section 2.5.4.1 or - Section 2.5.5. These relays constitute "unusable destinations" under + consideration by the hold-down timers described in Section 3.3.4.1 or + Section 3.3.5. These relays constitute "unusable destinations" under Rule 1 of the Destination Address Selection, and are also not part of the superseding considerations described above. The discovery and connection process for the relay addresses in the above described ordering MAY operate in parallel, subject to delays prescribed by the Happy Eyeballs requirements described in Section 5 of [RFC8305] for successively launched concurrent connection attempts. -2.3.3. Connecting to Multiple Relays +3.1.3. Connecting to Multiple Relays In some deployments, it may be useful for a gateway to connect to multiple upstream relays and subscribe to the same traffic, in order to support an active/active failover model. A gateway SHOULD NOT be configured to do so without guaranteeing that adequate bandwidth is available. A gateway configured to do this SHOULD still use the same preference - ordering logic from Section 2.3.2 for each connection. (Note that + ordering logic from Section 3.1.2 for each connection. (Note that this ordering allows for overriding by explicit administrative configuration where required.) -2.4. Happy Eyeballs +3.2. Happy Eyeballs -2.4.1. Overview +3.2.1. Overview Often, multiple choices of relay will exist for a gateway using DRIAD 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 + Section 3.1.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 + Note that according to the definition in Section 3.2.3 of this document, establishing the connection occurs before sending a membership report. As described in Section 5 of [RFC8305], 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 +3.2.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 + 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 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). @@ -626,59 +825,59 @@ 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 SHOULD 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 + Section 3.1.2, and attempts connections with the corresponding relays under the algorithm restrictions and guidelines given in [RFC8305] for the "Establishment of one connection, which cancels all other 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 +3.2.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 established 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 + 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 - connection. See Section 2.5.4 for an overview of how to respond if + connection. See Section 3.3.4 for an overview of how to respond if the connection does not provide multicast connectivity to the source. 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 +3.3. Guidelines for Restarting Discovery -2.5.1. Overview +3.3.1. Overview It's expected that gateways deployed in different environments will use a variety of heuristics to decide when it's appropriate to restart the relay discovery process, in order to meet different performance goals (for example, to fulfill different kinds of service level agreements). In general, restarting the discovery process is always safe for the gateway and relay during any of the events listed in this section, but may cause a disruption in the forwarded traffic if the discovery @@ -696,21 +895,21 @@ Balancing the expected impact on the tunneled traffic against likely or observed problems with an existing connection to the relay is the goal of the heuristics that gateways use to determine when to restart the discovery process. The non-normative advice in this section should be treated as guidelines to operators and implementors working with AMT systems that can use DRIAD as part of the relay discovery process. -2.5.2. Updates to Restarting Events +3.3.2. Updates to Restarting Events Section 5.2.3.4.1 of [RFC7450] lists several events that may cause a gateway to start or restart the discovery procedure. This document provides some updates and recommendations regarding the handling of these and similar events. The first 5 events are copied here and numbered for easier reference, and the remaining 4 events are newly added for consideration in this document: 1. When a gateway pseudo-interface is started (enabled). @@ -735,47 +934,47 @@ gateway is operating inside an end user device or application, and the device joins a different network, or when the domain portion of a DNS-SD domain name changes in response to a DHCP message or administrative configuration. 8. When substantial loss, persistent congestion, or network overload is detected in the stream of AMT packets from a relay. 9. When the gateway has reported one or more (S,G) subscriptions, but no traffic is received from the source for some timeout. - (See Section 2.5.4.1). + (See Section 3.3.4.1). This list is not exhaustive, nor are any of the listed events 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 have sufficient information to use DRIAD, since no source is known. -2.5.3. Tunnel Stability +3.3.3. Tunnel Stability In general, subscribers to active traffic flows that are being forwarded by an AMT gateway are less likely to experience a degradation in service (for example, from missing or duplicated packets) when the gateway continues using the same relay, as long as the relay is not overloaded and the network conditions remain stable. Therefore, gateways SHOULD avoid performing a full restart of the discovery process during routine cases of event #3 (sending a new Request message), since it occurs frequently in normal operation. - However, see Section 2.5.4, Section 2.5.6, and Section 2.5.4.3 for + However, see Section 3.3.4, Section 3.3.6, and Section 3.3.4.3 for more information about exceptional cases when it may be appropriate to use event #3. -2.5.4. Traffic Health +3.3.4. Traffic Health -2.5.4.1. Absence of Traffic +3.3.4.1. Absence of Traffic If a gateway indicates one or more (S,G) subscriptions in a 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 restart the discovery process. If the gateway restarts the discovery process multiple times consecutively for this reason, the timeout period SHOULD be adjusted to provide a random exponential back-off. @@ -792,96 +991,96 @@ adjusted to support performance requirements, operators are advised to consider the possibility of join propagation delays between the sender and the relay when choosing an appropriate timeout value. Gateways restarting the discovery process because of an absence of traffic MUST use a hold-down timer that removes this relay from consideration during subsequent rounds of discovery while active. The hold-down SHOULD last for no less than 3 minutes and no more than 10 minutes. -2.5.4.2. Loss and Congestion +3.3.4.2. Loss and Congestion In some gateway deployments, it is also feasible to monitor the health of traffic flows through the gateway, for example by detecting the rate of packet loss by communicating out of band with receivers, or monitoring the packets of known protocols with sequence numbers. Where feasible, it's encouraged for gateways to use such traffic health information to trigger a restart of the discovery process during event #3 (before sending a new Request message). However, to avoid synchronized rediscovery by many gateways simultaneously after a transient network event upstream of a relay results in many receivers detecting poor flow health at the same time, it's recommended to add a random delay before restarting the discovery process in this case. 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 different performance requirements. -2.5.4.3. Ancient Discovery Information +3.3.4.3. Ancient Discovery Information In most cases, a gateway actively receiving healthy traffic from a relay that has not indicated load with the L flag should prefer to - remain connected to the same relay, as described in Section 2.5.3. + remain connected to the same relay, as described in Section 3.3.3. However, a relay that appears healthy but has been forwarding traffic for days or weeks may have an increased chance of becoming unstable. Gateways may benefit from restarting the discovery process during 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 some deployments. It may be beneficial for such timers to consider the amount of traffic currently being forwarded, and to give a higher probability of restarting discovery during periods with an unusually low data rate, to reduce the impact on active traffic while still avoiding relying on the results of a very old discovery. 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 discover the current relay has not passed, the long term timer might be restarted without restarting the discovery process. -2.5.5. Relay Loaded or Shutting Down +3.3.5. Relay Loaded or Shutting Down The L flag (see Section 5.1.4.4 of [RFC7450]) is the preferred mechanism for a relay to signal overloading or a graceful shutdown to gateways. A gateway that supports handling of the L flag should generally restart the discovery process when it processes a Membership Query packet with the L flag set. If an L flag is received while a concurrent Happy Eyeballs discovery process is under way for multiple - candidate relays (Section 2.4), the relay sending the L flag SHOULD + candidate relays (Section 3.2), the relay sending the L flag SHOULD NOT be considered for the relay selection. It is also RECOMMENDED that gateways avoid choosing a relay that has 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 - hold-down in Section 2.5.4.1, so that the relay is removed from + hold-down in Section 3.3.4.1, so that the relay is removed from consideration for short-term subsequent rounds of discovery. -2.5.6. Relay Discovery Messages vs. Restarting Discovery +3.3.6. Relay Discovery Messages vs. Restarting Discovery All AMT relays are required by [RFC7450] to support handling of Relay 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 Discovery message to the unicast address of that AMT relay. Under stable conditions with an unloaded relay, it's expected that the relay will return its own unicast address in the Relay Advertisement, in response to such a Relay Discovery message. Since this will not result in the gateway changing to another relay unless the relay directs the gateway away, this is a reasonable exception to the - advice against handling event #3 described in Section 2.5.3. + advice against handling event #3 described in Section 3.3.3. This behavior is discouraged for gateways that do support the L flag, to avoid sending unnecessary packets over the network. 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 messages regularly. When a relay is under load or has started a graceful shutdown, it may respond with a different relay address, which the gateway can use to connect to a different relay. This kind of coordinated handoff will likely result in a smaller disruption to @@ -889,34 +1088,34 @@ messages, and stops forwarding traffic. This style of Relay Discovery message (one sent to the unicast address of a relay that's already forwarding traffic to this gateway) SHOULD NOT be considered a full restart of the relay discovery process. It is RECOMMENDED for gateways to support the L flag, but for gateways that do not support the L flag, sending this message during event #3 may help mitigate service degradation when relays become unstable. -2.5.7. Independent Discovery Per Traffic Source +3.3.7. Independent Discovery Per Traffic Source Relays discovered via the AMTRELAY RR are source-specific relay addresses, and may use different pseudo-interfaces from each other and from relays discovered via DNS-SD or a non-source-specific address, as described in Section 4.1.2.1 of [RFC7450]. Restarting the discovery process for one pseudo-interface does not require restarting the discovery process for other pseudo-interfaces. Gateway heuristics about restarting the discovery process should operate independently for different tunnels to relays, when responding to events that are specific to the different tunnels. -2.6. DNS Configuration +3.4. DNS Configuration Often an AMT gateway will only have access to the source and group IP addresses of the desired traffic, and will not know any other name 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 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, as described in Section 2.5 of [RFC3596]). Therefore, it is RECOMMENDED that AMTRELAY RRs be added to reverse IP @@ -928,238 +1127,38 @@ This document does not define semantics for the use of AMTRELAY records obtained in a way other than by a reverse IP lookup. When performing the AMTRELAY RR lookup, any CNAMEs or DNAMEs found MUST be followed. This is necessary to support zone delegation. Some examples outlining this need are described in [RFC2317]. See Section 4 and Section 4.3 for a detailed explanation of the contents for a DNS Zone file. -2.7. Waiting for DNS resolution +3.5. Waiting for DNS resolution The DNS query functionality is expected to follow ordinary standards 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 retry logic to determine the timeouts between retries. Otherwise, a gateway MAY re-send a DNS query if it does not receive an appropriate DNS response within some timeout period. If the gateway retries multiple times, the timeout period SHOULD be adjusted to provide a random exponential back-off. 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 value in the range [initial_timeout, MIN(initial_timeout * 2^retry_count, maximum_timeout)], with a RECOMMENDED initial_timeout of 1 second and a RECOMMENDED maximum_timeout of 120 seconds. -3. Example Deployments - -3.1. Example Receiving Networks - -3.1.1. Internet Service Provider - - One example of a receiving network is an Internet Service Provider - (ISP) that offers multicast ingest services to its subscribers, - illustrated in Figure 3. - - In the example network below, subscribers can join (S,G)s with MLDv2 - or IGMPv3 as described in [RFC4604], and the AMT gateway in this ISP - can receive and forward multicast traffic from one of the example - sending networks in Section 3.2 by discovering the appropriate AMT - relays with a DNS lookup for the AMTRELAY RR with the reverse IP of - the source in the (S,G). - - Internet - ^ ^ Multicast-enabled - | | Receiving Network - +------|------------|-------------------------+ - | | | | - | +--------+ +--------+ +=========+ | - | | Border |---| Border | | AMT | | - | | Router | | Router | | gateway | | - | +--------+ +--------+ +=========+ | - | | | | | - | +-----+------+-----------+--+ | - | | | | - | +-------------+ +-------------+ | - | | Agg Routers | .. | Agg Routers | | - | +-------------+ +-------------+ | - | / \ \ / \ | - | +---------------+ +---------------+ | - | |Access Systems | ....... |Access Systems | | - | |(CMTS/OLT/etc.)| |(CMTS/OLT/etc.)| | - | +---------------+ +---------------+ | - | | | | - +--------|------------------------|-----------+ - | | - +---+-+-+---+---+ +---+-+-+---+---+ - | | | | | | | | | | - /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ - |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| - - Subscribers - - Figure 3: Receiving ISP Example - -3.1.2. Small Office - - Another example receiving network is a small branch office that - regularly accesses some multicast content, illustrated in Figure 4. - - This office has desktop devices that need to receive some multicast - traffic, so an AMT gateway runs on a LAN with these devices, to pull - traffic in through a non-multicast next-hop. - - The office also hosts some mobile devices that have AMT gateway - instances embedded inside apps, in order to receive multicast traffic - over their non-multicast wireless LAN. (Note that the "Legacy - Router" is a simplification that's meant to describe a variety of - possible conditions; for example it could be a device providing a - split-tunnel VPN as described in [RFC7359], deliberately excluding - multicast traffic for a VPN tunnel, rather than a device which is - incapable of multicast forwarding.) - - Internet - (non-multicast) - ^ - | Office Network - +----------|----------------------------------+ - | | | - | +---------------+ (Wifi) Mobile apps | - | | Modem+ | Wifi | - - - - w/ embedded | - | | Router | AP | AMT gateways | - | +---------------+ | - | | | - | | | - | +----------------+ | - | | Legacy Router | | - | | (unicast) | | - | +----------------+ | - | / | \ | - | / | \ | - | +--------+ +--------+ +--------+=========+ | - | | Phones | | ConfRm | | Desks | AMT | | - | | subnet | | subnet | | subnet | gateway | | - | +--------+ +--------+ +--------+=========+ | - | | - +---------------------------------------------+ - - Figure 4: Small Office (no multicast up) - - By adding an AMT relay to this office network as in Figure 5, it's - possible to make use of multicast services from the example - multicast-capable ISP in Section 3.1.1. - - Multicast-capable ISP - ^ - | Office Network - +----------|----------------------------------+ - | | | - | +---------------+ (Wifi) Mobile apps | - | | Modem+ | Wifi | - - - - w/ embedded | - | | Router | AP | AMT gateways | - | +---------------+ | - | | +=======+ | - | +---Wired LAN---| AMT | | - | | | relay | | - | +----------------+ +=======+ | - | | Legacy Router | | - | | (unicast) | | - | +----------------+ | - | / | \ | - | / | \ | - | +--------+ +--------+ +--------+=========+ | - | | Phones | | ConfRm | | Desks | AMT | | - | | subnet | | subnet | | subnet | gateway | | - | +--------+ +--------+ +--------+=========+ | - | | - +---------------------------------------------+ - - Figure 5: Small Office Example - - When multicast-capable networks are chained like this, with a network - like the one in Figure 5 receiving internet services from a - multicast-capable network like the one in Figure 3, it's important - for AMT gateways to reach the more local AMT relay, in order to avoid - accidentally tunneling multicast traffic from a more distant AMT - relay with unicast, and failing to utilize the multicast transport - capabilities of the network in Figure 3. - -3.2. Example Sending Networks - -3.2.1. Sender-controlled Relays - - When a sender network is also operating AMT relays to distribute - multicast traffic, as in Figure 6, each address could appear as an - AMTRELAY RR for the reverse IP of the sender, or one or more domain - names could appear in AMTRELAY RRs, and the AMT relay addresses can - be discovered by finding A or AAAA records from those domain names. - - Sender Network - +-----------------------------------+ - | | - | +--------+ +=======+ +=======+ | - | | Sender | | AMT | | AMT | | - | +--------+ | relay | | relay | | - | | +=======+ +=======+ | - | | | | | - | +-----+------+----------+ | - | | | - +-----------|-----------------------+ - v - Internet - (non-multicast) - - Figure 6: Small Office Example - -3.2.2. Provider-controlled Relays - - When an ISP offers a service to transmit outbound multicast traffic - through a forwarding network, it might also offer AMT relays in order - to reach receivers without multicast connectivity to the forwarding - network, as in Figure 7. In this case it's recommended that the ISP - also provide at least one domain name for the AMT relays for use with - the AMTRELAY RR. - - When the sender wishes to use the relays provided by the ISP for - forwarding multicast traffic, an AMTRELAY RR should be configured to - use the domain name provided by the ISP, to allow for address - reassignment of the relays without forcing the sender to reconfigure - the corresponding AMTRELAY RRs. - - +--------+ - | Sender | - +---+----+ Multicast-enabled - | Sending Network - +-----------|-------------------------------+ - | v | - | +------------+ +=======+ +=======+ | - | | Agg Router | | AMT | | AMT | | - | +------------+ | relay | | relay | | - | | +=======+ +=======+ | - | | | | | - | +-----+------+--------+---------+ | - | | | | - | +--------+ +--------+ | - | | Border |---| Border | | - | | Router | | Router | | - | +--------+ +--------+ | - +-----|------------|------------------------+ - | | - v v - Internet - (non-multicast) - - Figure 7: Sending ISP Example - 4. AMTRELAY Resource Record Definition 4.1. AMTRELAY RRType The AMTRELAY RRType has the mnemonic AMTRELAY and type code 260 (decimal). The AMTRELAY RR is class independent. 4.2. AMTRELAY RData Format @@ -1348,20 +1347,28 @@ AMT gateway are advised to carefully consider the security considerations in Section 6 of [RFC7450]. AMT gateway operators also are encouraged to take appropriate steps to ensure the integrity of the data received via AMT, for example by the opportunistic use of IPSec [RFC4301] to secure traffic received from AMT relays, when IPSECKEY records [RFC4025] are available or when a trust relationship with the AMT relays can be otherwise established and secured. + Note that AMT does not itself provide any integrity protection on + Multicast Data packets (Section 5.1.6 of [RFC7450]), so absent + protections like those mentioned above, even an off-path attacker who + discovers the gateway IP, the relay IP, and the relay source port for + an active AMT connection can inject multicast data packets for a + joined (S,G) into the data stream if he can get data packets + delivered to the gateway IP that spoof the relay as the source. + 6.2. Record-spoofing The AMTRELAY resource record contains information that SHOULD be communicated to the DNS client without being modified. The method used to ensure the result was unmodified is up to the client. There must be a trust relationship between the end consumer of this resource record and the DNS server. This relationship may be end-to- end DNSSEC validation, or a secure connection to a trusted DNS server that provides end-to-end safety, to prevent record-spoofing of the @@ -1395,25 +1402,25 @@ risk. 7. 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, 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. + 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 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and