Mboned J. Holland Internet-Draft Akamai Technologies, Inc. Updates: 7450 (if approved)January 25,February 14, 2019 Intended status: Standards Track Expires:July 29,August 18, 2019 DNS Reverse IP AMT Discoverydraft-ietf-mboned-driad-amt-discovery-00draft-ietf-mboned-driad-amt-discovery-01 Abstract This document updates RFC 7450(AMT)(Automatic Multicast Tunneling, or AMT) by extending the relay discovery process to use a new DNS resource recordfor source-specific AMT relay discoverynamed AMTRELAY whenjoiningdiscovering AMT relays for source-specific multicast channels.A multicast sender configures aThe reverse IP DNS zonewith the newfor a multicast sender's IP address is configured to use AMTRELAYRR (defined in this document)resource records to advertise a set of AMT relays that can receive and forward multicast traffic from that senderinside a unicastover an AMTtunnel, in order to transit non-multicast- capable network segments.tunnel. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months 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 onJuly 29,August 18, 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 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 . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.1. Relays and Gateways . . . . . . . . . . . . . . . . . 4 1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 4 2. Relay Discovery Operation . . . . . . . . . . . . . . . . . . 5 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . .56 2.2. Signaling and Discovery . . . . . . . . . . . . . . . . . 6 2.3.Optimal Relay SelectionHappy Eyeballs . . . . . . . . . . . . . . . . . . . . . 82.4. Guidelines for Restarting Discovery2.3.1. Overview . . . . . . . . . . . . . .9 2.4.1. Overview. . . . . . . . 8 2.3.2. Connection Definition . . . . . . . . . . . . . . . . 92.4.2. Tunnel Stability2.4. Optimal Relay Selection . . . . . . . . . . . . . . . . . 9 2.4.1. Overview .11 2.4.3. Flow Health. . . . . . . . . . . . . . . . . . . . .11 2.4.4. Relay Loading and Shutdown9 2.4.2. Preference Ordering . . . . . . . . . . . . .11 2.4.5. Relay Discovery Messages vs. Restarting Discovery. .12 2.4.6.. . 10 2.4.3. Connecting to Multiple Relays . . . . . . . . . . . .1312 2.5.DNS ConfigurationGuidelines for Restarting Discovery . . . . . . . . . . . 13 2.5.1. Overview . . . . . . . . .13 2.6. Waiting for DNS resolution. . . . . . . . . . . . . 13 2.5.2. Updates to Restarting Events . .13 3. Example Deployments. . . . . . . . . . 13 2.5.3. Tunnel Stability . . . . . . . . . . .14 3.1. Example Receiving Networks. . . . . . . 14 2.5.4. Traffic Health . . . . . . . .14 3.1.1. Tier 3 ISP. . . . . . . . . . . 15 2.5.5. Relay Loaded or Shutting Down . . . . . . . . . .14 3.1.2. Small Office. . 16 2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 17 2.5.7. Independent Discovery Per Traffic Source . . . . . . 17 2.6. DNS Configuration . . . . . . . . . .15 3.2. Example Sending Networks. . . . . . . . . . 18 2.7. Waiting for DNS resolution . . . . . .18 3.2.1. Sender-controlled Relays. . . . . . . . . 18 3. Example Deployments . . . . . . . .18 3.2.2. Provider-controlled Relays. . . . . . . . . . . . . 194. AMTRELAY Resource Record Definition3.1. Example Receiving Networks . . . . . . . . . . . . .20 4.1. AMTRELAY RRType. . 19 3.1.1. Tier 3 ISP . . . . . . . . . . . . . . . . . . .20 4.2. AMTRELAY RData Format. . 19 3.1.2. Small Office . . . . . . . . . . . . . . . .20 4.2.1. RData Format - Precedence. . . . 20 3.2. Example Sending Networks . . . . . . . . . .21 4.2.2. RData Format - Discovery Optional (D-bit). . . . . . 214.2.3. RData Format - Type3.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 . . . . . . . . . . . . . . . .2225 4.3. AMTRELAY Record Presentation Format . . . . . . . . . . .2225 4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . .2225 4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . .2326 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . .2426 6. Security Considerations . . . . . . . . . . . . . . . . . . .2427 6.1. Record-spoofing . . . . . . . . . . . . . . . . . . . . .2427 6.2. Local Override . . . . . . . . . . . . . . . . . . . . .2427 6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . .2527 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .2528 8. References . . . . . . . . . . . . . . . . . . . . . . . . .2528 8.1. Normative References . . . . . . . . . . . . . . . . . .2528 8.2. Informative References . . . . . . . . . . . . . . . . .2629 Appendix A.New RRType Request Form . . . . . . . . . . . . . . 28 Appendix B.Unknown RRType construction . . . . . . . . . . . .2930 Author's Address . . . . . . . . . . . . . . . . . . . . . . . .3031 1. Introduction This document defines DNS Reverse IP AMT Discovery (DRIAD), a mechanism for AMT gateways to discover AMT relayswhichthat 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. Section 4.1.5 of [RFC7450] explains that the relay selection process for AMT is intended to be more flexible than the particular discovery method described in that document, and further explains that the selection process might need to depend on the source of the multicasttraffic,traffic in some deployments, since a relay must be able to receive multicast traffic from the desired source in order to forward it. That sectionsuggestsgoes on to suggest DNS-based queries as a possible solution. DRIAD is a DNS-based solution, as suggested there. This solution also addresses the relay discovery issues in the "Disadvantages" lists in Section 3.3 of [RFC8313] and Section 3.4 of [RFC8313]. The goal for DRIAD is to enable multicast connectivity between separate multicast-enabled networks when neither the sending nor the receiving network is connected to a multicast-enabled backbone, without pre-configuring any peering arrangement between the networks. This document updates Section 5.2.3.4 of [RFC7450] by adding a new extension to the relay discovery procedure. 1.1. Background The reader is assumed to be familiar with the basic DNS concepts described in [RFC1034], [RFC1035], and the subsequent documents that update them, particularly [RFC2181]. The reader is also assumed to be familiar with the concepts and terminology regarding source-specific multicast as described in [RFC4607] and the use of IGMPv3 [RFC3376] and MLDv2 [RFC3810] for group management of source-specific multicast channels, as described in [RFC4604]. The reader should also be familiar with AMT, particularly the terminology listed in Section 3.2 of [RFC7450] and Section 3.3 of [RFC7450]. 1.2. Terminology 1.2.1. Relays and Gateways When reading this document, it's especially helpful to recall that once an AMT tunnel is established, the relay receives native multicast traffic and sends unicast tunnel-encapsulated traffic to the gateway, and the gateway receives the tunnel-encapsulated packets, decapsulates them, and forwards them as native multicast packets, as illustrated in Figure 1. Multicast +-----------+ Unicast +-------------+ Multicast >---------> | AMT relay | >=======> | AMT gateway | >---------> +-----------+ +-------------+ Figure 1: AMT Tunnel Illustration 1.2.2. Definitions +------------+------------------------------------------------------+ | Term | Definition | +------------+------------------------------------------------------+ | (S,G) | A source-specific multicast channel, as described in | | | [RFC4607]. A pair of IP addresses with a source host | | | IP and destination group IP. | | | | | discovery | A broker or load balancer for AMT relay discovery, | | broker | as mentioned in section 4.2.1.1 of [RFC7450]. | | | | | downstream | Further from the source oftraffic.traffic, as described in | | | [RFC7450]. | | | | | FQDN | Fully Qualified Domain Name, as described in | | | [RFC8499] | | | | | gateway | An AMT gateway, as described in [RFC7450] | | | | | L flag | The "Limit" flag described in Section 5.1.1.4 of | | | [RFC7450] | | | | | relay | An AMT relay, as described in [RFC7450] | | | | | RPF | Reverse Path Forwarding, as described in [RFC5110] | | | | | RR | A DNS Resource Record, as described in [RFC1034] | | | | | RRType | A DNS Resource Record Type, as described in | | | [RFC1034] | | | | | SSM | Source-specific multicast, as described in [RFC4607] | | | | | upstream | Closer to the source oftraffic.traffic, as described in | | | [RFC7450]. | +------------+------------------------------------------------------+ 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 [RFC2119] and [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Relay Discovery Operation 2.1. Overview The AMTRELAY resource record (RR) defined in this document is used to publish the IP address or domain name ofan AMT relaya 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 theRRzone so that it contains a set of RRs that provide theaddressaddresses or domainnamenames ofanAMTrelayrelays (or discovery brokers that advertise relays) that can receive multicast IP traffic from that sender. This enables AMT gateways in remote networks to discover an AMT relay that is capable of forwarding traffic from the sender. This in turn enables those AMT gateways to receive the multicast traffic tunneled over a unicast AMT tunnel from those relays, and then to pass the multicast packets into networks or applications that are using the gateway to subscribe to traffic from that sender. This mechanism only works for source-specific multicast (SSM) channels. The source address of the (S,G) is reversed and used as an index into one of the reverse mapping trees (in-addr.arpa for IPv4, 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 insectionSection 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 Section2.3.2.4. 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]. 2.2. Signaling and Discovery This section describes a typical example of the end-to-end process for signaling a receiver's join of a 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. A content provider operates a sender, which is a source of multicast traffic inside a multicast-capable network. An end user who is a customer of the content provider has a multicast-capable internet service provider, which operates a receiving network that uses an AMT gateway. The AMT gateway is DRIAD-capable. The content provider provides the user with a receiving application that tries to subscribe to at least one (S,G). This receiving application could for example be a file transfer system using FLUTE [RFC6726] or a live video stream using RTP [RFC3550], or any other application that might subscribe to a SSM channel. +---------------+ | Sender | | | | 198.51.100.15 | | | +---------------+ |Data| | |Flow| Multicast | \| |/ Network | \ / | 5: Propagate RPF for Join(S,G) \ / +---------------+ \/ | AMT Relay | | 203.0.113.15 | +---------------+ | 4: Gateway connects to Relay, sends Join(S,G) over tunnel | Unicast Tunnel | ^ | 3: --> DNS Query: type=AMTRELAY, | / 15.100.51.198.in-addr.arpa. | | / <-- Response: Join/Leave +-------------+ AMTRELAY=203.0.113.15 Signals | AMT gateway | | +-------------+ | | 2: Propagate RPF for Join(S,G) | Multicast | Network | | 1: Join(S=198.51.100.15, G) +-------------+ | Receiver | | (end user) | +-------------+ Figure 2: DRIAD Messaging In this simple example, the sender IP is 198.51.100.15, and the relay IP is 203.0.113.15. The content provider has previously configured the DNS zone that 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 AMTRELAY RR with the Relay's IP address. (See Section 4.3 for details about the AMTRELAY RR format and semantics.) 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): (198.51.100.15, 232.252.0.2). 2. The join propagates with RPF through the multicast-enabled network with PIM [RFC7761] or another multicast routing mechanism, until the AMT gateway receives a signal to join the (S,G). 3. The AMT gateway performs a reverse DNS lookup for the AMTRELAY RRType, by sending an AMTRELAY RRType query for the FQDN "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 described in Section 3.5 of [RFC1035]. The DNS resolver for the AMT gateway uses ordinary DNS recursive resolution until it has the authoritative result that the content provider configured, which informs the AMT gateway that the relay address is 203.0.113.15. 4. The AMT gateway performs AMT handshakes with the AMT relay as described in Section 4 of [RFC7450], then forwards a Membership report to the relay indicating subscription to the (S,G). 5. The relay propagates the join through its network toward the sender, then forwards the appropriate AMT-encapsulated traffic to the gateway, which decapsulates and forwards it as native multicast through its downstream network to the end user. 2.3. Happy Eyeballs 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 a 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 for further information about the relevance of the L flag to the establishment of a Happy Eyeballs connection. 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 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 RRIPwill 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. 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). 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 configuredthean AMTRELAYRR defined in this document,RR, gateways can use the DRIAD mechanism defined in this document to discover the relay information provided by the sender.2.4. Guidelines2.4.2. Preference Ordering This section defines a preference ordering forRestarting Discovery 2.4.1. Overview It's expected thatrelay addresses during the relay discovery process. Gateways are encouraged to implement a Happy Eyeballs algorithm, but even gatewaysdeployed in different environments will usethat do not implement avariety of heuristicsHappy Eyeballs algorithm SHOULD use this ordering, except as noted. When establishing an AMT tunnel todecide whenforward multicast data, it'sappropriate to restartvery important for therelaydiscoveryprocess,process to prioritize the network topology considerations ahead of address selection considerations, in order tomeet different performance goals (for example, to fulfill different kindsgain the packet replication benefits from using multicast instead ofservice level agreements).unicast tunneling in the multicast-capable portions of the network path. The intent of the advice and requirements in this sectionshould be treated as non-normative guidelinesis tooperators and implementors working with AMT systems that candescribe how a gateway should make useDRIAD as partof therelay discovery process.concurrency provided by a Happy Eyeballs algorithm to reduce the join latency, while still prioritizing network efficiency considerations over Address Selection considerations. Section5.2.3.4.14 of[RFC7450] lists several events that may cause[RFC8305] requires agatewayHappy Eyeballs algorithm tostart or restartsort thediscovery procedure. This document provides some updates and recommendations regardingaddresses with thehandlingDestination Address Selection defined in Section 6 ofthese and similar events. The events are copied here and numbered[RFC6724], but foreasier reference: 1. When a gateway pseudo-interface is started (enabled). 2. When the gateway wishes to report a group subscription when none currently exist. 3. Before sendingthenext Request messageabove reasons, that requirement is superseded ina membership update cycle. 4. After the gateway fails to receive a response to a Request message. 5. After the gateway receives a Membership Query message withtheL flag set to 1. There are several new events that gateway heuristics may appropriatelyAMT discovery useto restartcase by thediscovery process, including:following considerations: 1.When the gateway wishes to report a (S,G) subscription withPrefer Local Relays Figure 5 and Section 3.1.2 provide asource address that does not currently have other group subscriptions. 2. When the DNS TTL expiresmotivating example to prefer DNS-SD [RFC6763] forandiscovery strictly ahead of using the AMTRELAY RRor for a domain name contained withincontrolled by theAMTRELAY RR. 3. When there is a network change detected,sender forexample when a gateway is operating inside an end user device or application,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.<domain> (with <domain> chosen as described in Section 11 of [RFC6763]) and use thedevice joins a different network, or when the domain portion of a DNS-SD domain name changesAMT relays discovered that way inresponsepreference to AMT relays discoverable via the mechanism defined in this document (DRIAD). 2. Let Sender Manage Relay Provisioning A related motivating example in the sending-side network is provided by considering aDHCP message or administrative configuration. 4. When losssender which needs to instruct the gateways on how to select between connecting to Figure 6 orcongestion is detectedFigure 7 (from Section 3.2), in order to manage load and failover scenarios in a manner that operates well with thestreamsender's provisioning strategy for horizontal scaling of AMTpackets from a relay. This listrelays. In this example about the sending-side network, the precedence field described in Section 4.2.1 isnot exhaustive, nor are anya critical method of control so that senders can provide thelisted events always strictly requiredappropriate guidance toforce a restart ofgateways during the discovery process.Note that during event #1, a gateway may useTherefore, after DNS-SD,but does not have sufficient information to use DRIAD, since no source is known. 2.4.2. 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 usingthesame relay, as longprecedence from therelay is not overloaded andRR MUST be used for sorting preference ahead of thenetwork conditions remain stable. Therefore, gateways should avoid performing a full restartDestination 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 discoveryprocess during routine cases of event #3 (sending a new Request message), but see Section 2.4.3 andIt's also RECOMMENDED that if the well-known anycast IP addresses defined in Section2.4.5 for more information about exceptions when it may be appropriate to use this event. Likewise, some operators might use a short DNS TTL expiration (event #7) to allow7 of [RFC7450] are suitable formore responsive load balancing. Ifdiscovering an AMT relay that can forward traffic from the source, that agateway frequently sees shortDNSTTLs (for example, under approximately 15 minutes) for some sources, a helpful heuristic mayrecord with the AMTRELAY RRType beto avoid restartingpublished by thediscovery processsender for thosesources, for exampleIP addresses along withan exponential backoff, or a hold-down timer that depends on the health or bit-rate of the active and subscribed traffic currently being forwarded through the tunnel. 2.4.3. Flow Health In some gateway deployments, it is feasibleany other appropriate AMTRELAY RRs tomonitor the health of traffic flows throughindicate thegateway,best relative precedences forexample by detectingreceiving therate of packet losssource traffic. Accordingly, AMT gateways SHOULD bycommunicating out of banddefault 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 withclients, or monitoring packets of known protocols with sequence numbers. Where feasible, it's encouraged for gateways to use such traffic health information to trigger a restartthe anycast addresses defined in Section 7 of [RFC7450] (namely: 192.52.193.1 and 2001:3::1) if those IPs weren't listed in thediscovery process during event #3 (before sendingAMTRELAY RRs. 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, anew Request message). However, to avoid synchronized rediscoveryHappy Eyeballs algorithm for AMT MUST use the Destination Address Selection defined in Section 6 of [RFC6724], as required bymany gateways simultaneously[RFC8305]. Among relay addresses that still have an equivalent preference after the above orderings, atransient network event upstream ofgateway MUST make a non-deterministic choice for relayresultspreference ordering, in order to support load balancing by DNS configurations that provide manyreceivers detecting poor flow health atrelay options. (Note that gateways not implementing a Happy Eyeballs algorithm are not required to use thesame time, it's recommendedDestination Address Selection ordering, but are still required toadd a random delay before restartinguse non-deterministic ordering among equally preferred relays.) Note also that certain relay addresses may be excluded from consideration by thediscovery processhold-down timers described inthis case. The spanSection 2.5.4.1 or Section 2.5.5. These relays constitute "unusable destinations" under Rule 1 of therandom portionDestination Address Selection, and are also not part of thedelay should be no less than 10 seconds by default, but may be administratively configured to support different performance requirements. 2.4.4. Relay Loading and Shutdownsuperseding considerations described above. TheL flag (seediscovery 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 Section5.1.4.45 of[RFC7450] is the preferred mechanism[RFC8305] fora relaysuccessively launched concurrent connection attempts. 2.4.3. Connecting tosignal overloading orMultiple Relays In some deployments, it may be useful for agraceful shutdowngateway togateways.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 thatsupports handling of the L flag should generally restart the discovery process when it processes a Membership Query packet with the L flag set. Itadequate bandwidth isalso recommendedavailable. A gateway configured to do this SHOULD still use the same preference ordering logic from Section 2.4.2 for both connections. (Note thatgateways avoid choosing a relaythis ordering allows for overriding by explicit administrative configuration where required.) 2.5. Guidelines for Restarting Discovery 2.5.1. Overview It's expected thathas recently sent an L flag, with approximately a 10-minute hold-down. Gateways MAYgateways deployed in different environments will use a variety of heuristicssuch as this hold-downtooverride selectiondecide when it's appropriate to restart the relay discovery process, in order to meet different performance goals (for example, to fulfill different kinds ofaservice level agreements). In general, restarting the discovery process is always safe for the gateway and relaypreferred byduring any of theprecedence fieldevents listed in this section, but may cause a disruption in theAMTRELAY RR (see Section 4.2.1). 2.4.5. Relay Discovery Messages vs. Restarting Discovery A gateway should only send DNS queries withforwarded traffic if theAMTRELAY RRType ordiscovery process results in choosing a different relay, because this changes theDNS-SD DNS queriesRPF forwarding tree foran AMT service as partthe multicast traffic upstream ofstartingthe gateway. This is likely to result in some dropped orrestartingduplicated packets from channels actively being tunneled from thediscovery process. However, all AMT relays are requiredold relay tosupport handlingthe gateway. The degree ofRelay Discovery messages (e.g. in Section 5.3.3.2 of [RFC7450]). So a gateway with an existing connection toimpact on the traffic from choosing a different relaycan send a Relay Discovery message tomay depend on network conditions between theunicast address of that AMT relay. Under stablegateway and the new relay, as well as the network conditionswith an unloadedand topology between the sender and the new relay,it's expected thatas this may cause the relaywill return its own unicast address in the Relay Advertisement, in responsetosuchpropagate aRelay Discovery message. Since this will not result innew RPF join toward thegateway changing to another relay unlesssender. Balancing therelay directsexpected impact on thegateway away, this is a reasonable exceptiontunneled traffic against likely or observed problems with an existing connection to theadvice against handling event #3 described in Section 2.4.2. This behaviorrelay isdiscouraged for gateways that do supporttheL flag, to avoid sending unnecessary packets overgoal of thenetwork. However, gatewaysheuristics thatdo not supportgateways use to determine when to restart theL flag maydiscovery process. The non-normative advice in this section should beabletreated as guidelines toavoid 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 respondoperators and implementors working witha different relay address, which the gatewayAMT systems that can useto connect to a different relay. This kindDRIAD as part ofcoordinated handoff will likely result in a smaller disruption to the traffic than ifthe relaysimply stops respondingdiscovery process. 2.5.2. Updates toRequest messages, and stops forwarding traffic. This style of Relay Discovery message (one sent to the unicast addressRestarting Events Section 5.2.3.4.1 of [RFC7450] lists several events that may cause arelay that's already forwarding trafficgateway tothis gateway) should not be considered a fullstart or restartoftherelaydiscoveryprocess. 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.4.6. Connecting to Multiple Relays Relays discovered viaprocedure. This document provides some updates and recommendations regarding theAMTRELAY RRhandling of these and similar events. The first 5 events aresource-specific relay addresses,copied here andmay use different pseudo-interfaces from each othernumbered for easier reference, andfrom relays discovered via DNS-SD or a non-source-specific address, as described in Section 4.1.2.1 of [RFC7450]. Restartingthediscovery processfollowing events are newly added foroneconsideration in this document: 1. When a gateway pseudo-interfacedoes not require restarting the discovery process for other pseudo-interfaces. Gateway heuristics about restartingis started (enabled). 2. When thediscovery process should operate independently for different tunnelsgateway wishes torelays,report a group subscription whenrespondingnone currently exist. 3. Before sending the next Request message in a membership update cycle. 4. After the gateway fails toevents that are specificreceive a response to a Request message. 5. After thedifferent tunnels. 2.5. DNS Configuration Often an AMTgatewaywill only have accessreceives a Membership Query message with the L flag set to 1. 6. When the gateway wishes to report a (S,G) subscription with a sourceand group IP addresses of the desired traffic, and willaddress that does notknow anycurrently have othernamegroup subscriptions. 7. When there is a network change detected, for example when a gateway is operating inside an end user device or application, and thesource of the traffic. Because of this, typically the best way of looking up AMTRELAY RRs will be by usingdevice joins a different network, or when thesource IP address as an index into onedomain portion ofthe reverse mapping trees (in-addr.arpa for IPv4, as describeda DNS-SD domain name changes inSection 3.5 of [RFC1035],response to a DHCP message orip6.arpa for IPv6, as described in Section 2.5 of [RFC3596]). Therefore, itadministrative configuration. 8. When congestion or substantial loss isRECOMMENDED that AMTRELAY RRs be added to reverse IP zones as appropriate. AMTRELAY records MAY also appeardetected inother zones, but the primary intended use case requires a reverse IP mapping forthesource from an (S,G) in order to be useful to moststream of AMTgateways.packets from a relay. 9. WhenperformingtheAMTRELAY RR lookup, any CNAMEsgateway has reported one orDNAMEs found MUST be followed.more (S,G) subscriptions, but no traffic is received from the source for some timeout. (See Section 2.5.4.1). This list isnecessary to support zone delegation. Some examples outlining this neednot exhaustive, nor aredescribed in [RFC2317]. See Section 4 and Section 4.3 forany of the listed events strictly required to always force adetailed explanationrestart of thecontents fordiscovery process. Note that during event #1, aDNS Zone file. 2.6. Waiting for DNS resolution The DNS query functionality is expected to follow ordinary standards and best practices for DNS clients. AgatewayMAYmay usean existing DNS client implementation thatDNS-SD, but doesso, and MAY rely onnot have sufficient information to use DRIAD, since no source is known. 2.5.3. Tunnel Stability In general, subscribers to active traffic flows thatclient's retry logicare being forwarded by an AMT gateway are less likely todetermine the timeouts between retries. Otherwise,experience a degradation in service (for example, from missing or duplicated packets) when the gatewayMAY re-sendcontinues using the same relay, as long the relay is not overloaded and the network conditions remain stable. Therefore, gateways SHOULD avoid performing aDNS query iffull restart of the discovery process during routine cases of event #3 (sending a new Request message), since itdoes not receive anoccurs frequently in normal operation. However, see Section 2.5.4, Section 2.5.6, and Section 2.5.4.3 for more information about exceptional cases when it may be appropriateDNS response within some timeout period.to use event #3. 2.5.4. Traffic Health 2.5.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 gatewayretriesto restart the discovery process. If the gateway restarts the discovery process multipletimes,times consecutively for this reason, 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], theThe RECOMMENDED timeout is a random value in the range [initial_timeout, MIN(initial_timeout * 2^retry_count, maximum_timeout)], with a RECOMMENDED initial_timeout of1 second4 seconds and a RECOMMENDED maximum_timeout of 120 seconds.3. Example Deployments 3.1. Example Receiving Networks 3.1.1. Tier 3 ISP One example of a receiving network is an ISPNote thatoffers multicast ingest services to its subscribers, illustrated in Figure 3. Intheexample network below, subscribers can join (S,G)s with MLDv2 or IGMPv3 as describedrecommended initial_timeout is larger than the initial timout recommended in[RFC4604], andtheAMT gatewaysimilar algorithm from Section 5.2.3.4.3 of [RFC7450]. This is to provide time for RPF Join propagation inthis ISP can receivethe sending network. Although the timeout values may be administratively adjusted to support performance requirements, operators are advised to consider the possibility of join propagation delays between the sender andforward multicastthe 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 fromoneconsideration 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 In some gateway deployments, it is also feasible to monitor the health of traffic flows through the gateway, for examplesending networks in Section 3.2bydiscoveringdetecting theappropriate AMT relaysrate of packet loss by communicating out of band witha DNS lookup forreceivers, or monitoring theAMTRELAY RRpackets of known protocols with sequence numbers. Where feasible, it's encouraged for gateways to use such traffic health information to trigger a restart of thereverse IPdiscovery 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 thesourcesame time, it's recommended to add a random delay before restarting the discovery process in this case. The span of the(S,G). Internet ^ ^ Multicast-enabled | | Receiving Network +------|------------|-------------------------+ | | | | | +--------+ +--------+ +=========+ | | | Border |---| Border | | AMT | | | | Router | | Router | |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 In most cases, a 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 exampleactively receivingnetwork ishealthy traffic from asmall branch officerelay thatregularly accesses some multicast content, illustrated in Figure 4. This officehasdesktop devices that need to receive some multicast traffic, so an AMT gateway runs on a LANnot indicated load withthese devices,the L flag should prefer topull trafficremain connected to the same relay, as described inthroughSection 2.5.3. However, anon-multicast next-hop. The office also hosts some mobile devicesrelay thathave AMT gateway instances embedded inside apps, in order to receive multicastappears healthy but has been forwarding trafficover their non-multicast wireless LAN. (Notefor 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"Legacy Router"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 The L flag (see Section 5.1.4.4 of [RFC7450]) is the preferred mechanism for asimplification that's meantrelay todescribesignal overloading or avarietygraceful shutdown to gateways. A gateway that supports handling ofpossible conditions- for examplethe L flag should generally restart the discovery process when itcould beprocesses adevice providingMembership Query packet with the L flag set. If an L flag is received while asplit-tunnel VPN as described in [RFC7359], deliberately excluding multicast trafficconcurrent Happy Eyeballs discovery process is under way for multiple candidate relays (Section 2.3), the relay sending the L flag SHOULD NOT be considered for the relay selection. It is also RECOMMENDED that gateways avoid choosing aVPN tunnel, rather thanrelay that has recently sent an L flag, with approximately adevice which10-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 isincapableremoved from consideration for short-term subsequent rounds ofmulticast forwarding.) Internet (non-multicast) ^ | Office Network +----------|----------------------------------+ | | | | +---------------+ (Wifi) Mobile apps | | | Modem+ | Wifi | - - - - w/ embedded | | | Router | AP |discovery. 2.5.6. Relay Discovery Messages vs. Restarting Discovery A gateway should only send DNS queries with the AMTRELAY RRType or the DNS-SD DNS queries for an AMTgateways | | +---------------+ | | | | | | | | +----------------+ | | | Legacy Router | | | | (unicast) | | | +----------------+ | | / | \ | | / | \ | | +--------+ +--------+ +--------+=========+ | | | Phones | | ConfRm | | Desks |service as part of starting or restarting the discovery process. However, all AMT| | | | subnet | | subnet | | subnet |relays are required to support handling of Relay Discovery messages (e.g. in Section 5.3.3.2 of [RFC7450]). So a gateway| | | +--------+ +--------+ +--------+=========+ | | | +---------------------------------------------+ Figure 4: Small Office (no multicast up) By addingwith 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 thisoffice network aswill not result inFigure 5, it's possiblethe gateway changing tomake use of multicast services fromanother relay unless theexample 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 likedirects theone in Figure 5 receiving internet services fromgateway away, this is amulticast-capable network likereasonable exception to theoneadvice against handling event #3 described inFigure 3, it's importantSection 2.5.3. This behavior is discouraged forAMTgateways that do support the L flag, toreachavoid sending unnecessary packets over themore local AMT relay, in ordernetwork. However, gateways that do not support the L flag may be able to avoidaccidentally tunneling multicasta disruption in the forwarded trafficfromby sending such Relay Discovery messages regularly. When amore distant AMTrelay is under load or has started a graceful shutdown, it may respond withunicast, and failing to utilizea different relay address, which themulticast transport capabilitiesgateway can use to connect to a different relay. This kind ofthe network in Figure 3. For this reason, it's RECOMMENDED that AMT gateways by default perform service discovery using DNS Service Discovery (DNS-SD) [RFC6763] for _amt._udp.<domain> (with <domain> chosen as described in Section 11 of [RFC6763]) and use the AMT relays discovered that waycoordinated handoff will likely result inpreferencea smaller disruption toAMT relays discoverable viathemechanism defined in this document (DRIAD). It's also RECOMMENDED that whentraffic than if thewell-known anycast IP addresses defined in Section 7relay simply stops responding to Request messages, and stops forwarding traffic. This style of[RFC7450] are suitable for discovering an AMTRelay Discovery message (one sent to the unicast address of a relaythat can forwardthat's already forwarding trafficfrom the source, thatto this gateway) should not be considered aDNS record withfull restart of theAMTRELAY RRType be publishedrelay discovery process. It is recommended forthose IP addresses along with any other appropriate AMTRELAY RRsgateways toindicatesupport thebest relative precedencesL flag, but forreceiving the source traffic. Accordingly, AMTgatewaysSHOULD by default discoverthat do not support themost- preferred relay first by DNS-SD, then by DRIAD as described inL flag, sending thisdocument (in precedence order,message during event #3 may help mitigate service degradation when relays become unstable. 2.5.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 Section4.2.1), then with the anycast addresses defined in Section 74.1.2.1 of[RFC7450] (namely: 192.52.193.1 and 2001:3::1) if those IPs weren't listed in[RFC7450]. Restarting theAMTRELAY RRs. This default behavior MAY be overridden by administrative configuration where other behavior is more appropriatediscovery process for one pseudo-interface does not require restarting thegateway within its network. Thediscoveryand connectionprocess formultiple relays MAYother pseudo-interfaces. Gateway heuristics about restarting the discovery process should operatein parallel, but when forwarding multicast group membership reports with new joins from an AMT gateway, membership reports SHOULD be forwardedindependently for different tunnels tothe most-preferred relays first, falling backrelays, when responding toless preferred relays only after failingevents that are specific toreceive traffic forthe different tunnels. 2.6. DNS Configuration Often anappropriate timeout, andAMT gateway will onlyafter reporting a leave to any more- preferred connected relays thathavefailed to subscribeaccess to thetraffic. It is RECOMMENDED thatsource and group IP addresses of thedefault timeoutdesired traffic, and will not know any other name forreceiving traffic be no less than 3 seconds, butthevalue MAYsource of the traffic. Because of this, typically the best way of looking up AMTRELAY RRs will beoverriddenbyadministrative configuration, where known groups or channels need a different timeout for successful application performance. 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, eachusing the source IP addresscould appearas anAMTRELAY RR forindex into one of the reverseIPmapping trees (in-addr.arpa for IPv4, as described in Section 3.5 ofthe sender, or one[RFC1035], ormore domain names could appearip6.arpa for IPv6, as described in Section 2.5 of [RFC3596]). Therefore, it is RECOMMENDED that AMTRELAYRRs, and the AMT relay addresses canRRs bediscovered by finding an A or AAAA record 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 serviceadded totransmit outbound multicast traffic through a forwarding network, it mightreverse IP zones as appropriate. AMTRELAY records MAY alsooffer AMT relaysappear inorder to reach receivers without multicast connectivity toother zones, but theforwarding network, as in Figure 7. In thisprimary intended use caseit's RECOMMENDED that the ISP also providerequires adomain name for the AMT relaysreverse IP mapping foruse withthediscovery process definedsource from an (S,G) inthis document. When the sender wishesorder touse the relays provided bybe useful to most AMT gateways. When performing theISP for forwarding multicast traffic, anAMTRELAY RRshouldlookup, any CNAMEs or DNAMEs found MUST beconfigured to use the domain name provided by the ISP,followed. This is necessary toallowsupport zone delegation. Some examples outlining this need are described in [RFC2317]. See Section 4 and Section 4.3 foraddress reassignmenta detailed explanation of therelays without forcing the sendercontents for a DNS Zone file. 2.7. Waiting for DNS resolution The DNS query functionality is expected toreconfigure the corresponding AMTRELAY RRs. +--------+ | Sender | +---+----+ Multicast-enabled | Sending Network +-----------|-------------------------------+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. Tier 3 ISP One example of a receiving network is an 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 |v| Receiving Network +------|------------|-------------------------+ |+------------+ +=======+ +=======+| | |Agg Router| +--------+ +--------+ +=========+ |AMT| |AMTBorder |---| Border | | AMT |+------------+|relay| |relayRouter | | Router | |+=======+ +=======+gateway | | | +--------+ +--------+ +=========+ | | | |+-----+------+--------+---------+| | | +-----+------+-----------+--+ | | |+--------+ +--------+| | |Border |---| Border+-------------+ +-------------+ | | | Agg Routers |Router.. | Agg Routers |Router| | +-------------+ +-------------+ |+--------+ +--------+|+-----|------------|------------------------+/ \ \ / \ | |v v Internet (non-multicast)+---------------+ +---------------+ | | |Access Systems | ....... |Access Systems | | | |(CMTS/OLT/etc.)| |(CMTS/OLT/etc.)| | | +---------------+ +---------------+ | | | | | +--------|------------------------|-----------+ | | +---+-+-+---+---+ +---+-+-+---+---+ | | | | | | | | | | /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| Subscribers Figure7: Sending3: 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.AMTRELAY Resource Record Definition 4.1. AMTRELAY RRType The AMTRELAY RRTypeThis office hasthe mnemonic AMTRELAY and type code TBD1 (decimal). 4.2. AMTRELAY RData Formatdesktop 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. TheAMTRELAY RData consistsoffice 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 a8-bit precedence field,device providing a1-bit "Discovery Optional" field,split-tunnel VPN as described in [RFC7359], deliberately excluding multicast traffic for a7-bit type field, andVPN tunnel, rather than avariable length relay field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+device which is incapable of multicast forwarding.) Internet (non-multicast) ^ |precedence |D| typeOffice Network +----------|----------------------------------+ | |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ relay ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2.1. RData Format| | +---------------+ (Wifi) Mobile apps | | | Modem+ | Wifi | -Precedence This is- - - 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 an8-bit precedence for this record. It is interpreted in the same way as the PREFERENCE field described in Section 3.3.9 of [RFC1035]. Relays listed in AMTRELAY records with a lower value for precedence are to be attempted first. Where there is a tie in precedence, the default choice ofAMT relayMUST be non-deterministic,tosupport load balancing. The AMT gateway operator MAY overridethisdefault choice with explicit configuration when it's necessary for administrative purposes. For example, oneoffice networkmight preferas in Figure 5, it's possible totunnel IPv6 multicast traffic over IPv6 AMT and IPv4make use of multicasttraffic over IPv4 AMT to avoid routeability problems in IPv6services fromaffecting IPv4 traffic and vice versa, while another network might prefer to tunnel both kinds of traffic over IPv6 to reducetheIPv4 space used by its AMT gateways. In thisexamplescenario or other cases where there is an administrative preference that requires explicit configuration,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 areceivingnetworkMAY make systematically different precedence choices among records withlike thesame precedence value. 4.2.2. RData Format - Discovery Optional (D-bit) The D bit isone in Figure 5 receiving internet services from a"Discovery Optional" flag. Ifmulticast-capable network like theD bit is setone in Figure 3, it's important for AMT gateways to0, a gateway using this RR MUST performreach the more local AMTrelay discovery as describedrelay, inSection 4.2.1.1 of [RFC7450], rather than directly sending an AMT request messageorder tothe relay. That is, the gateway MUST receive anavoid accidentally tunneling multicast traffic from a more distant AMT relayadvertisement message (Section 5.1.2 of [RFC7450]) for an address before sending an AMT request message (Section 5.1.3 of [RFC7450])with unicast, and failing tothat address. Before receivingutilize therelay advertisement message, this record has only indicated thatmulticast transport capabilities of theaddress can be used for AMT relay discovery, not fornetwork in Figure 3. 3.2. Example Sending Networks 3.2.1. Sender-controlled Relays When arequest message. Thissender network isnecessary for devices that are not fully functionalalso operating AMTrelays, but rather load balancers or brokers,relays to distribute multicast traffic, asmentionedinSection 4.2.1.1Figure 6, each address could appear as an AMTRELAY RR for the reverse IP of[RFC7450]. IftheD bit is set to 1,sender, or one or more domain names could appear in AMTRELAY RRs, and thegateway MAY send anAMTrequest message directly to the discoveredrelayaddress without first sending an AMT discovery message. This bit shouldaddresses can beset according to advicediscovered by finding a A or AAAA records fromthethose domain names. Sender Network +-----------------------------------+ | | | +--------+ +=======+ +=======+ | | | Sender | | AMTrelay operator. The D bit MUST be set to zero when no information is available from the| | AMT | | | +--------+ | relayoperator about its suitability. 4.2.3. RData Format - Type The type field indicates the format of the information that is stored in the| | relayfield. The following values are defined: o type = 0: The relay field is empty (0 bytes). o type = 1: The relay field contains a 4-octet IPv4 address. o type = 2: The relay field contains| | | | +=======+ +=======+ | | | | | | | +-----+------+----------+ | | | | +-----------|-----------------------+ v Internet (non-multicast) Figure 6: Small Office Example 3.2.2. Provider-controlled Relays When an ISP offers a16-octet IPv6 address. o type = 3: The relay field containsservice to transmit outbound multicast traffic through awire-encoded domain name. The wire-encoded format is self-describing, soforwarding network, it might also offer AMT relays in order to reach receivers without multicast connectivity to thelength is implicit. The domain name MUST NOT be compressed. (See Section 3.3 of [RFC1035] and Section 4 of [RFC3597].) 4.2.4. RData Format - Relay The relay field isforwarding network, as in Figure 7. In this case it's RECOMMENDED that theaddress orISP also provide at least one domain nameoffor the AMTrelay. It is formatted according torelays for use with thetype field.AMTRELAY RR. When thetype field is 0,sender wishes to use thelength ofrelays provided by therelay field is 0, and it indicates that no AMT relay should be usedISP for forwarding multicasttraffic from this source. Whentraffic, an AMTRELAY RR should be configured to use thetype field is 1,domain name provided by thelengthISP, to allow for address reassignment of therelay field is 4 octets, and a 32-bit IPv4 address is present. This is an IPv4 address as described in Section 3.4.1 of [RFC1035]. This is a 32-bit number in network byte order. When the type field is 2,relays without forcing thelength ofsender to reconfigure the corresponding AMTRELAY RRs. +--------+ | Sender | +---+----+ Multicast-enabled | Sending Network +-----------|-------------------------------+ | v | | +------------+ +=======+ +=======+ | | | Agg Router | | AMT | | AMT | | | +------------+ | relayfield is 16 octets, and a 128-bit IPv6 address is present. This is an IPv6 address as described in Section 2.2 of [RFC3596]. This is a 128-bit number in network byte order. When the type field is 3, the| | relayfield is a normal wire-encoded domain name, as described in Section 3.3 of [RFC1035]. Compression MUST NOT be used, for the reasons given in Section 4 of [RFC3597]. 4.3.| | | | +=======+ +=======+ | | | | | | | +-----+------+--------+---------+ | | | | | | +--------+ +--------+ | | | Border |---| Border | | | | Router | | Router | | | +--------+ +--------+ | +-----|------------|------------------------+ | | v v Internet (non-multicast) Figure 7: Sending ISP Example 4. AMTRELAY Resource RecordPresentation Format 4.3.1. Representation of AMTRELAY RRsDefinition 4.1. AMTRELAYRRs may appear in a zone data master file.RRType Theprecedence, D-bit, relay type, and relay fields are REQUIRED. IfAMTRELAY RRType has therelaymnemonic AMTRELAY and typefield is 0, the relay field MUST be ".".code 260 (decimal). Thepresentation for the recordAMTRELAY RR isas follows: INclass independent. 4.2. AMTRELAY RData Format The AMTRELAY RData consists of a 8-bit precedenceD-bit type relay 4.3.2. Examples Infield, aDNS authoritative nameserver that understands the AMTRELAY type, the zone might contain1-bit "Discovery Optional" field, aset of entries like this: $ORIGIN 100.51.198.in-addr.arpa. 10 IN AMTRELAY 107-bit type field, and a variable length relay field. 0 1203.0.113.15 10 IN AMTRELAY 102 3 0 1 22001:DB8::15 10 IN AMTRELAY 1283 4 5 6 7 8 9 0 1 2 3amtrelays.example.com.4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | precedence |D| type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ relay ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2.1. RData Format - Precedence Thisconfiguration advertises an IPv4 discovery address,is anIPv6 discovery address, and a domain name8-bit precedence forAMT relays which can receive traffic from the source 198.51.100.10. The IPv4 and IPv6 addresses are configured with a D-bit of 0 (meaning discoverythis record. It ismandatory,interpreted in the same way as the PREFERENCE field described in Section4.2.2), and a precedence 10 (meaning they're preferred ahead3.3.9 ofthe last entry, which has precedence 128). For zone files[RFC1035]. Relays listed inname servers that don't support theAMTRELAYRRType natively, it's possiblerecords with a lower value for precedence are tousebe attempted first. 4.2.2. RData Format - Discovery Optional (D-bit) The D bit is a "Discovery Optional" flag. If theformat for unknownD bit is set to 0, a gateway using this RRtypes,MUST perform AMT relay discovery as described in[RFC3597]. This approach would replace the AMTRELAY entries inSection 4.2.1.1 of [RFC7450], rather than directly sending an AMT Request message to theexample above with the entries below: [To be removed (TBD): replace 65280 withrelay. That is, theIANA-assigned value TBD1, here and in Appendix B. ] 10 IN TYPE65280 \# ( 6 ; length 0a ; precedence=10 01 ; D=0, relay type=1,gateway MUST receive an AMT Relay Advertisement message (Section 5.1.2 of [RFC7450]) for anIPv4addresscb00710f ) ; 203.0.113.15 10 IN TYPE65280 \# ( 18 ; length 0a ; precedence=10 02 ; D=0, relay type=2,before sending anIPv6AMT Request message (Section 5.1.3 of [RFC7450]) to that address. Before receiving the Relay Advertisement message, this record has only indicated that the address20010db800000000000000000000000f ) ; 2001:db8::15 10 IN TYPE65280 \# ( 24 ; length 80 ; precedence=128 83 ; D=1,can be used for AMT relaytype=3, a wire-encoded domain name 09616d7472656c617973076578616d706c6503636f6d ) ; domain name See Appendix Bdiscovery, not formore details. 5. IANA Considerationsa Request message. Thisdocument updates the IANA Registryis necessary forDNS Resource Record Types by assigning type TBD1devices that are not fully functional AMT relays, but rather load balancers or brokers, as mentioned in Section 4.2.1.1 of [RFC7450]. If the D bit is set to 1, theAMTRELAY record.gateway MAY send an AMT Request message directly to the discovered relay address without first sending an AMT Discovery message. Thisdocument creates a new registry named "AMTRELAY Resource Record Parameters", with a sub-registry forbit should be set according to advice from the"Relay Type Field".AMT relay operator. Theinitial values inD bit MUST be set to zero when no information is available from thesub-registry are: +-------+---------------------------------------+ | Value | Description | +-------+---------------------------------------+ | 0 | NoAMT relay operator about its suitability. 4.2.3. RData Format - Type The type field indicates the format of the information that ispresent. | | 1 | A 4-byte IPv4 addressstored in the relay field. The following values are defined: o type = 0: The relay field ispresent | | 2 | A 16-byteempty (0 bytes). o type = 1: The relay field contains a 4-octet IPv4 address. o type = 2: The relay field contains a 16-octet IPv6address is present | | 3 | Aaddress. o type = 3: The relay field contains a wire-encoded domainnamename. The wire-encoded format ispresent | | 4-255 | Unassigned | +-------+---------------------------------------+ Values 0, 1, 2, and 3 are further explained inself-describing, so the length is implicit. The domain name MUST NOT be compressed. (See Section4.2.33.3 of [RFC1035] and Section4.2.4. Relay type numbers4through 255 can be assigned with a policyofSpecification Required (as described in [RFC8126]). 6. Security Considerations [ TBD: these 3 are just[RFC3597].) 4.2.4. RData Format - Relay The relay field is thefirst few most obvious issues, with just sketchesaddress or domain name of theproblem. Explain better, and look for trickier issues. ] 6.1. Record-spoofing IfAMT relay. It isused to ingest multicast traffic, providing a false AMTRELAY recordformatted according toa gateway usingthe type field. When the type field is 0, the length of the relay field is 0, and it indicates that no AMT relay should be used fordiscovery can result in Denial of Service, or artificialmulticast traffic froma source under an attacker's control. Therefore, it is important to ensure thatthis source. When theAMTRELAY recordtype field isauthentic, with DNSSEC [RFC4033] or other operational safeguards that can provide assurance of1, theauthenticitylength of therecord contents. 6.2. Local Override The local relays, while important for overall network performance, can't be secured by DNSSEC. 6.3. Congestion Multicast traffic, particularly interdomain multicast traffic, carries some congestion risks,relay field is 4 octets, and a 32-bit IPv4 address is present. This is an IPv4 address as described in Section43.4.1 of[RFC8085]. Network operators are advised to take precautions including monitoring[RFC1035]. This is a 32-bit number in network byte order. When the type field is 2, the length ofapplication traffic behavior, traffic authentication,the relay field is 16 octets, andrate-limitinga 128-bit IPv6 address is present. This is an IPv6 address as described in Section 2.2 ofmulticast traffic,[RFC3596]. This is a 128-bit number inorder to ensurenetworkhealth. 7. Acknowledgements This specification was inspired bybyte order. When theprevious worktype field is 3, the relay field is a normal wire-encoded domain name, as described in Section 3.3 ofDoug Nortz, Robert Sayko, David Segelstein, and Percy Tarapore, presented[RFC1035]. Compression MUST NOT be used, for the reasons given in Section 4 of [RFC3597]. For a type 3 record, theMBONED working group at IETF 93. Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny Giuliano,D-bit andMark Andrewspreference fields carry over to all A or AAAA records fortheir very helpful 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, <https://www.rfc-editor.org/info/rfc1034>. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>. [RFC2119] Bradner, S., "Key words for usethe domain name. There is no difference inRFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2181] Elz, R.the result of the discovery process when it's obtained by type 1 or type 2 AMTRELAY records with identical D-bit andR. Bush, "Clarificationspreference fields, vs. when the result is obtained by a type 3 AMTRELAY record that resolves to theDNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <https://www.rfc-editor.org/info/rfc2181>. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B.,same set of IPv4 andA. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, <https://www.rfc-editor.org/info/rfc3376>. [RFC3596] Thomson, S., Huitema, C., Ksinant, V.,IPv6 addresses via A andM. Souissi, "DNS Extensions to Support IP Version 6", STD 88, RFC 3596, DOI 10.17487/RFC3596, October 2003, <https://www.rfc-editor.org/info/rfc3596>. [RFC3597] Gustafsson, A., "Handling of Unknown DNS ResourceAAAA lookups. 4.3. AMTRELAY Record(RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 2003, <https://www.rfc-editor.org/info/rfc3597>. [RFC3810] Vida, R., Ed.Presentation Format 4.3.1. Representation of AMTRELAY RRs AMTRELAY RRs may appear in a zone data master file. The precedence, D-bit, relay type, andL. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2)relay fields are REQUIRED. If the relay type field is 0, the relay field MUST be ".". The presentation forIPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <https://www.rfc-editor.org/info/rfc3810>. [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Versionthe record is as follows: IN AMTRELAY precedence D-bit type relay 4.3.2. Examples In a DNS authoritative nameserver that understands the AMTRELAY type, the zone might contain a set of entries like this: $ORIGIN 100.51.198.in-addr.arpa. 10 IN AMTRELAY 10 0 1 203.0.113.15 10 IN AMTRELAY 10 0 2(MLDv2) for Source- Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, August 2006, <https://www.rfc-editor.org/info/rfc4604>. [RFC4607] Holbrook, H.2001:DB8::15 10 IN AMTRELAY 128 1 3 amtrelays.example.com. This configuration advertises an IPv4 discovery address, an IPv6 discovery address, andB. Cain, "Source-Specific Multicasta domain name forIP", RFC 4607, DOI 10.17487/RFC4607, August 2006, <https://www.rfc-editor.org/info/rfc4607>. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>. [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, DOI 10.17487/RFC7450, February 2015, <https://www.rfc-editor.org/info/rfc7450>. [RFC8085] Eggert, L., Fairhurst, G.,AMT relays which can receive traffic from the source 198.51.100.10. The IPv4 andG. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>. [RFC8174] Leiba, B., "AmbiguityIPv6 addresses are configured with a D-bit ofUppercase vs Lowercase0 (meaning discovery is mandatory, as described inRFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. 8.2. Informative References [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/RFC2317, March 1998, <https://www.rfc-editor.org/info/rfc2317>. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R.,Section 4.2.2), andV. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>. [RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March 2005, <https://www.rfc-editor.org/info/rfc4025>. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>. [RFC5110] Savola, P., "Overviewa precedence 10 (meaning they're preferred ahead of theInternet Multicast Routing Architecture", RFC 5110, DOI 10.17487/RFC5110, January 2008, <https://www.rfc-editor.org/info/rfc5110>. [RFC5507] IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch, Ed., "Design Choices When Expanding the DNS", RFC 5507, DOI 10.17487/RFC5507, April 2009, <https://www.rfc-editor.org/info/rfc5507>. [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, "FLUTE - File Delivery over Unidirectional Transport", RFC 6726, DOI 10.17487/RFC6726, November 2012, <https://www.rfc-editor.org/info/rfc6726>. [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, <https://www.rfc-editor.org/info/rfc6895>. [RFC7359] Gont, F., "Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks", RFC 7359, DOI 10.17487/RFC7359, August 2014, <https://www.rfc-editor.org/info/rfc7359>. [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <https://www.rfc-editor.org/info/rfc7761>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Sectionlast entry, which has precedence 128). For zone files inRFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. [RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T., Ed., and R. Krishnan, "Use of Multicast across Inter- domain Peering Points", BCP 213, RFC 8313, DOI 10.17487/RFC8313, January 2018, <https://www.rfc-editor.org/info/rfc8313>. [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, <https://www.rfc-editor.org/info/rfc8499>. Appendix A. Newname servers that don't support the AMTRELAY RRTypeRequest Form This isnatively, it's possible to use thetemplateformat forrequesting a new RRType recommendedunknown RR types, as described inAppendix A of [RFC6895]. A. Submission Date: B.1 Submission Type: [x] New RRTYPE [ ] Modification to RRTYPE B.2 Kind of RR: [x] Data RR [ ] Meta-RR C. Contact Information for submitter (will be publicly posted): Name: Jake Holland Email Address: jakeholland.net@gmail.com International telephone number: +1-626-486-3706 Other contact handles: jholland@akamai.com D. Motivation for the new RRTYPE application. It provides a bootstrap so AMT (RFC 7450) gateways can discover an AMT relay that can receive multicast traffic from a specific source, in order to signal multicast group membership and receive multicast traffic over a unicast tunnel using AMT. E. Description of the proposed RR type.[RFC3597]. Thisdescription can be provided in-lineapproach would replace the AMTRELAY entries in thetemplate, as an attachment, orexample above witha publicly available URL. Please see draft-ietf-mboned-driad-amt-discovery. F. What existing RRTYPE or RRTYPEs come closest to filling that need and why are they unsatisfactory? Some similar concepts appear in IPSECKEY, as described in Section 1.2 of [RFC4025]. The IPSECKEY RRType is unsatisfactory because it refers to IPSec Keys instead of to AMT relays, butthemotivating considerations for using reverse IP and for providing a precedence are similar--an AMT gateway often has access to a sourceentries below: 10 IN TYPE260 \# ( 6 ; length 0a ; precedence=10 01 ; D=0, relay type=1, an IPv4 addressfor a multicast (S,G), but does not have access to acb00710f ) ; 203.0.113.15 10 IN TYPE260 \# ( 18 ; length 0a ; precedence=10 02 ; D=0, relay type=2, an IPv6 addressthat can receive multicast traffic from the source, without administrative configuration. Defining20010db800000000000000000000000f ) ; 2001:db8::15 10 IN TYPE260 \# ( 24 ; length 80 ; precedence=128 83 ; D=1, relay type=3, aformatwire-encoded domain name 09616d7472656c617973076578616d706c6503636f6d ) ; domain name See Appendix A fora TXT record could servemore details. 5. IANA Considerations This document updates theneed for AMT relay discovery semantics, but Section 5 of [RFC5507] provides a compelling argumentIANA Registry forrequestingDNS Resource Record Types by assigning type 260 to the AMTRELAY record. This document creates a newRRType instead. G. What mnemonic is requestedregistry named "AMTRELAY Resource Record Parameters", with a sub-registry for thenew RRTYPE (optional)? AMTRELAY H. Does"Relay Type Field". The initial values in therequested RRTYPE make usesub-registry are: +-------+---------------------------------------+ | Value | Description | +-------+---------------------------------------+ | 0 | No relay is present. | | 1 | A 4-byte IPv4 address is present | | 2 | A 16-byte IPv6 address is present | | 3 | A wire-encoded domain name is present | | 4-255 | Unassigned | +-------+---------------------------------------+ Values 0, 1, 2, and 3 are further explained in Section 4.2.3 and Section 4.2.4. Relay type numbers 4 through 255 can be assigned with a policy ofany existing IANA registry or requireSpecification Required (as described in [RFC8126]). 6. Security Considerations [ TBD: these 3 are just thecreationfirst few most obvious issues, with just sketches ofa new IANA subregistry in DNS Parameters? Yes, IANAthe problem. Explain better, and look for trickier issues. ] 6.1. Record-spoofing If AMT isrequestedused tocreateingest multicast traffic, providing asubregistry named "AMT Relay Type Field"false AMTRELAY record to a gateway using it for discovery can result in Denial of Service, or artificial multicast traffic from a"AMTRELAY Resource Record Parameters" registry.source under an attacker's control. Therefore, it is important to ensure that the AMTRELAY record is authentic, with DNSSEC [RFC4033] or other operational safeguards that can provide assurance of the authenticity of the record contents. 6.2. Local Override Thefield values are definedlocal relays, while important for overall network performance, can't be secured by DNSSEC. 6.3. Congestion Multicast traffic, particularly interdomain multicast traffic, carries some congestion risks, as described in Section 4 of [RFC8085]. Network operators are advised to take precautions including monitoring of application traffic behavior, traffic authentication, and rate-limiting of multicast traffic, in order to ensure network health. 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, and Mark Andrews for their very helpful 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, <https://www.rfc-editor.org/info/rfc1034>. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <https://www.rfc-editor.org/info/rfc2181>. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, <https://www.rfc-editor.org/info/rfc3376>. [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", STD 88, RFC 3596, DOI 10.17487/RFC3596, October 2003, <https://www.rfc-editor.org/info/rfc3596>. [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 2003, <https://www.rfc-editor.org/info/rfc3597>. [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <https://www.rfc-editor.org/info/rfc3810>. [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source- Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, August 2006, <https://www.rfc-editor.org/info/rfc4604>. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, <https://www.rfc-editor.org/info/rfc4607>. [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <https://www.rfc-editor.org/info/rfc6724>. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>. [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, DOI 10.17487/RFC7450, February 2015, <https://www.rfc-editor.org/info/rfc7450>. [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, <https://www.rfc-editor.org/info/rfc8305>. 8.2. Informative References [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/RFC2317, March 1998, <https://www.rfc-editor.org/info/rfc2317>. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>. [RFC5110] Savola, P., "Overview of the Internet Multicast Routing Architecture", RFC 5110, DOI 10.17487/RFC5110, January 2008, <https://www.rfc-editor.org/info/rfc5110>. [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, "FLUTE - File Delivery over Unidirectional Transport", RFC 6726, DOI 10.17487/RFC6726, November 2012, <https://www.rfc-editor.org/info/rfc6726>. [RFC7359] Gont, F., "Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages inSection 4.2.3Dual-Stack Hosts/Networks", RFC 7359, DOI 10.17487/RFC7359, August 2014, <https://www.rfc-editor.org/info/rfc7359>. [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., andSection 4.2.4,L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <https://www.rfc-editor.org/info/rfc7761>. [RFC8126] Cotton, M., Leiba, B., anda summary table is given in Section 5. I. Does the proposal require/expect any changes in DNS servers/resolvers that prevent the new type from being processed asT. Narten, "Guidelines for Writing anunknown RRTYPE (see RFC3597)? No. J. Comments: It may be worth noting that the gateway type field fromIANA Considerations Section2.3 of [RFC4025]in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. [RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T., Ed., andSection 2.5R. Krishnan, "Use of[RFC4025] is very similar to the Relay Type field in this request. I tentatively assume that trying to re-use that sub-registry is a worse idea than duplicating it, but I'll invite others to consider the questionMulticast across Inter- domain Peering Points", BCP 213, RFC 8313, DOI 10.17487/RFC8313, January 2018, <https://www.rfc-editor.org/info/rfc8313>. [RFC8499] Hoffman, P., Sullivan, A., andvoice an opinion, in case there is a different consensus. https://www.ietf.org/assignments/ ipseckey-rr-parameters/ipseckey-rr-parameters.xmlK. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, <https://www.rfc-editor.org/info/rfc8499>. AppendixB.A. Unknown RRType construction In a DNS resolver that understands the AMTRELAY type, the zone file might contain this line: IN AMTRELAY 128 0 3 amtrelays.example.com. In order to translate this example to appear as an unknown RRType as defined in [RFC3597], one could run the following program: <CODE BEGINS> $ cat translate.py #!/usr/bin/env python3 import sys name=sys.argv[1] wire='' for dn in name.split('.'): if len(dn) > 0: wire += ('%02x' % len(dn)) wire += (''.join('%02x'%ord(x) for x in dn)) print(len(wire)//2) + 2 print(wire) $ ./translate.py amtrelays.example.com2224 09616d7472656c617973076578616d706c6503636f6d <CODE ENDS> The length and the hex string for the domain name "amtrelays.example.com" are the outputs of this program, yielding a length of 22 and the above hex string. 22 is the length of the wire-encoded domain name, so to this we add 2 (1 for the precedence field and 1 for the combined D-bit and relay type fields) to get the full length of theRData.RData, and encode the precedence, D-bit, and relay type fields as octets, as described in Section 4. This results in a zone file entry like this: INTYPE65280TYPE260 \# ( 24 ; length 80 ; precedence = 128 03 ; D-bit=0, relay type=3 (wire-encoded domain name) 09616d7472656c617973076578616d706c6503636f6d ) ; domain name Author's Address Jake Holland Akamai Technologies, Inc. 150 Broadway Cambridge, MA 02144 United States of America Email: jakeholland.net@gmail.com