idnits 2.17.1 draft-ietf-mboned-driad-amt-discovery-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC7450, updated by this document, for RFC5378 checks: 2001-02-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 27, 2019) is 1637 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mboned J. Holland 3 Internet-Draft Akamai Technologies, Inc. 4 Updates: 7450 (if approved) October 27, 2019 5 Intended status: Standards Track 6 Expires: April 29, 2020 8 DNS Reverse IP AMT Discovery 9 draft-ietf-mboned-driad-amt-discovery-09 11 Abstract 13 This document updates RFC 7450 (Automatic Multicast Tunneling, or 14 AMT) by extending the relay discovery process to use a new DNS 15 resource record named AMTRELAY when discovering AMT relays for 16 source-specific multicast channels. The reverse IP DNS zone for a 17 multicast sender's IP address is configured to use AMTRELAY resource 18 records to advertise a set of AMT relays that can receive and forward 19 multicast traffic from that sender over an AMT tunnel. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 29, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.2.1. Relays and Gateways . . . . . . . . . . . . . . . . . 4 59 1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 4 60 2. Relay Discovery Operation . . . . . . . . . . . . . . . . . . 5 61 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.2. Signaling and Discovery . . . . . . . . . . . . . . . . . 6 63 2.3. Optimal Relay Selection . . . . . . . . . . . . . . . . . 8 64 2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 8 65 2.3.2. Preference Ordering . . . . . . . . . . . . . . . . . 10 66 2.3.3. Connecting to Multiple Relays . . . . . . . . . . . . 12 67 2.4. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . . 12 68 2.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 12 69 2.4.2. Algorithm Guidelines . . . . . . . . . . . . . . . . 13 70 2.4.3. Connection Definition . . . . . . . . . . . . . . . . 14 71 2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 14 72 2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 14 73 2.5.2. Updates to Restarting Events . . . . . . . . . . . . 15 74 2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 16 75 2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 16 76 2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 18 77 2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 18 78 2.5.7. Independent Discovery Per Traffic Source . . . . . . 19 79 2.6. DNS Configuration . . . . . . . . . . . . . . . . . . . . 19 80 2.7. Waiting for DNS resolution . . . . . . . . . . . . . . . 20 81 3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 20 82 3.1. Example Receiving Networks . . . . . . . . . . . . . . . 20 83 3.1.1. Tier 3 ISP . . . . . . . . . . . . . . . . . . . . . 20 84 3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 21 85 3.2. Example Sending Networks . . . . . . . . . . . . . . . . 23 86 3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 23 87 3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 24 88 4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 25 89 4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 25 90 4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 25 91 4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 26 92 4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 26 93 4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 26 94 4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 27 95 4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 27 96 4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 27 97 4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 28 98 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 100 6.1. Use of AMT . . . . . . . . . . . . . . . . . . . . . . . 29 101 6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 29 102 6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 30 103 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 104 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 105 8.1. Normative References . . . . . . . . . . . . . . . . . . 30 106 8.2. Informative References . . . . . . . . . . . . . . . . . 32 107 Appendix A. Unknown RRType construction . . . . . . . . . . . . 33 108 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 110 1. Introduction 112 This document defines DNS Reverse IP AMT Discovery (DRIAD), a 113 mechanism for AMT gateways to discover AMT relays that are capable of 114 forwarding multicast traffic from a known source IP address. 116 AMT (Automatic Multicast Tunneling) is defined in [RFC7450], and 117 provides a method to transport multicast traffic over a unicast 118 tunnel, in order to traverse non-multicast-capable network segments. 120 Section 4.1.5 of [RFC7450] explains that the relay selection process 121 for AMT is intended to be more flexible than the particular discovery 122 method described in that document, and further explains that the 123 selection process might need to depend on the source of the multicast 124 traffic in some deployments, since a relay must be able to receive 125 multicast traffic from the desired source in order to forward it. 127 That section goes on to suggest DNS-based queries as a possible 128 solution. DRIAD is a DNS-based solution, as suggested there. This 129 solution also addresses the relay discovery issues in the 130 "Disadvantages" lists in Section 3.3 of [RFC8313] and Section 3.4 of 131 [RFC8313]. 133 The goal for DRIAD is to enable multicast connectivity between 134 separate multicast-enabled networks when neither the sending nor the 135 receiving network is connected to a multicast-enabled backbone, 136 without pre-configuring any peering arrangement between the networks. 138 This document updates Section 5.2.3.4 of [RFC7450] by adding a new 139 extension to the relay discovery procedure. 141 1.1. Background 143 The reader is assumed to be familiar with the basic DNS concepts 144 described in [RFC1034], [RFC1035], and the subsequent documents that 145 update them, particularly [RFC2181]. 147 The reader is also assumed to be familiar with the concepts and 148 terminology regarding source-specific multicast as described in 149 [RFC4607] and the use of IGMPv3 [RFC3376] and MLDv2 [RFC3810] for 150 group management of source-specific multicast channels, as described 151 in [RFC4604]. 153 The reader should also be familiar with AMT, particularly the 154 terminology listed in Section 3.2 of [RFC7450] and Section 3.3 of 155 [RFC7450]. 157 1.2. Terminology 159 1.2.1. Relays and Gateways 161 When reading this document, it's especially helpful to recall that 162 once an AMT tunnel is established, the relay receives native 163 multicast traffic and sends unicast tunnel-encapsulated traffic to 164 the gateway, and the gateway receives the tunnel-encapsulated 165 packets, decapsulates them, and forwards them as native multicast 166 packets, as illustrated in Figure 1. 168 Multicast +-----------+ Unicast +-------------+ Multicast 169 >---------> | AMT relay | >=======> | AMT gateway | >---------> 170 +-----------+ +-------------+ 172 Figure 1: AMT Tunnel Illustration 174 1.2.2. Definitions 175 +------------+------------------------------------------------------+ 176 | Term | Definition | 177 +------------+------------------------------------------------------+ 178 | (S,G) | A source-specific multicast channel, as described in | 179 | | [RFC4607]. A pair of IP addresses with a source host | 180 | | IP and destination group IP. | 181 | | | 182 | discovery | A broker or load balancer for AMT relay discovery, | 183 | broker | as mentioned in section 4.2.1.1 of [RFC7450]. | 184 | | | 185 | downstream | Further from the source of traffic, as described in | 186 | | [RFC7450]. | 187 | | | 188 | FQDN | Fully Qualified Domain Name, as described in | 189 | | [RFC8499] | 190 | | | 191 | gateway | An AMT gateway, as described in [RFC7450] | 192 | | | 193 | L flag | The "Limit" flag described in Section 5.1.1.4 of | 194 | | [RFC7450] | 195 | | | 196 | relay | An AMT relay, as described in [RFC7450] | 197 | | | 198 | RPF | Reverse Path Forwarding, as described in [RFC5110] | 199 | | | 200 | RR | A DNS Resource Record, as described in [RFC1034] | 201 | | | 202 | RRType | A DNS Resource Record Type, as described in | 203 | | [RFC1034] | 204 | | | 205 | SSM | Source-specific multicast, as described in [RFC4607] | 206 | | | 207 | upstream | Closer to the source of traffic, as described in | 208 | | [RFC7450]. | 209 +------------+------------------------------------------------------+ 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 213 "OPTIONAL" in this document are to be interpreted as described in 214 [RFC2119] and [RFC8174] when, and only when, they appear in all 215 capitals, as shown here. 217 2. Relay Discovery Operation 218 2.1. Overview 220 The AMTRELAY resource record (RR) defined in this document is used to 221 publish the IP address or domain name of a set of AMT relays or 222 discovery brokers that can receive, encapsulate, and forward 223 multicast traffic from a particular sender. 225 The sender is the owner of the RR, and configures the zone so that it 226 contains a set of RRs that provide the addresses or domain names of 227 AMT relays (or discovery brokers that advertise relays) that can 228 receive multicast IP traffic from that sender. 230 This enables AMT gateways in remote networks to discover an AMT relay 231 that is capable of forwarding traffic from the sender. This in turn 232 enables those AMT gateways to receive the multicast traffic tunneled 233 over a unicast AMT tunnel from those relays, and then to pass the 234 multicast packets into networks or applications that are using the 235 gateway to subscribe to traffic from that sender. 237 This mechanism only works for source-specific multicast (SSM) 238 channels. The source address of the (S,G) is reversed and used as an 239 index into one of the reverse mapping trees (in-addr.arpa for IPv4, 240 as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, as 241 described in Section 2.5 of [RFC3596]). 243 This mechanism should be treated as an extension of the AMT relay 244 discovery procedure described in Section 5.2.3.4 of [RFC7450]. A 245 gateway that supports this method of AMT relay discovery SHOULD use 246 this method whenever it's performing the relay discovery procedure, 247 and the source IP addresses for desired (S,G)s are known to the 248 gateway, and conditions match the requirements outlined in 249 Section 2.3. 251 Some detailed example use cases are provided in Section 3, and other 252 applicable example topologies appear in Section 3.3 of [RFC8313], 253 Section 3.4 of [RFC8313], and Section 3.5 of [RFC8313]. 255 2.2. Signaling and Discovery 257 This section describes a typical example of the end-to-end process 258 for signaling a receiver's join of an SSM channel that relies on an 259 AMTRELAY RR. 261 The example in Figure 2 contains 2 multicast-enabled networks that 262 are both connected to the internet with non-multicast-capable links, 263 and which have no direct association with each other. 265 A content provider operates a sender, which is a source of multicast 266 traffic inside a multicast-capable network. 268 An end user who is a customer of the content provider has a 269 multicast-capable internet service provider, which operates a 270 receiving network that uses an AMT gateway. The AMT gateway is 271 DRIAD-capable. 273 The content provider provides the user with a receiving application 274 that tries to subscribe to at least one (S,G). This receiving 275 application could for example be a file transfer system using FLUTE 276 [RFC6726] or a live video stream using RTP [RFC3550], or any other 277 application that might subscribe to an SSM channel. 279 +---------------+ 280 | Sender | 281 | | | 198.51.100.15 | 282 | | +---------------+ 283 |Data| | 284 |Flow| Multicast | 285 \| |/ Network | 286 \ / | 5: Propagate RPF for Join(S,G) 287 \ / +---------------+ 288 \/ | AMT Relay | 289 | 203.0.113.15 | 290 +---------------+ 291 | 4: Gateway connects to Relay, 292 sends Join(S,G) over tunnel 293 | 294 Unicast 295 Tunnel | 297 ^ | 3: --> DNS Query: type=AMTRELAY, 298 | / 15.100.51.198.in-addr.arpa. 299 | | / <-- Response: 300 Join/Leave +-------------+ AMTRELAY=203.0.113.15 301 Signals | AMT gateway | 302 | +-------------+ 303 | | 2: Propagate RPF for Join(S,G) 304 | Multicast | 305 Network | 306 | 1: Join(S=198.51.100.15, G) 307 +-------------+ 308 | Receiver | 309 | (end user) | 310 +-------------+ 312 Figure 2: DRIAD Messaging 314 In this simple example, the sender IP is 198.51.100.15, and the relay 315 IP is 203.0.113.15. 317 The content provider has previously configured the DNS zone that 318 contains the domain name "15.100.51.198.in-addr.arpa.", which is the 319 reverse lookup domain name for his sender. The zone file contains an 320 AMTRELAY RR with the Relay's IP address. (See Section 4.3 for 321 details about the AMTRELAY RR format and semantics.) 323 The sequence of events depicted in Figure 2 is as follows: 325 1. The end user starts the app, which issues a join to the (S,G): 326 (198.51.100.15, 232.252.0.2). 328 2. The join propagates with RPF through the receiver's multicast- 329 enabled network with PIM [RFC7761] or another multicast routing 330 mechanism, until the AMT gateway receives a signal to join the 331 (S,G). 333 3. The AMT gateway performs a reverse DNS lookup for the AMTRELAY 334 RRType, by sending an AMTRELAY RRType query for the FQDN 335 "15.100.51.198.in-addr.arpa.", using the reverse IP domain name 336 for the sender's source IP address (the S from the (S,G)), as 337 described in Section 3.5 of [RFC1035]. 339 The DNS resolver for the AMT gateway uses ordinary DNS recursive 340 resolution until it has the authoritative result that the content 341 provider configured, which informs the AMT gateway that the relay 342 address is 203.0.113.15. 344 4. The AMT gateway performs AMT handshakes with the AMT relay as 345 described in Section 4 of [RFC7450], then forwards a Membership 346 report to the relay indicating subscription to the (S,G). 348 5. The relay propagates the join through its network toward the 349 sender, then forwards the appropriate AMT-encapsulated traffic to 350 the gateway, which decapsulates and forwards it as native 351 multicast through its downstream network to the end user. 353 2.3. Optimal Relay Selection 355 2.3.1. Overview 357 The reverse source IP DNS query of an AMTRELAY RR is a good way for a 358 gateway to discover a relay that is known to the sender. 360 However, it is NOT necessarily a good way to discover the best relay 361 for that gateway to use, because the RR will only provide information 362 about relays known to the source. 364 If there is an upstream relay in a network that is topologically 365 closer to the gateway and able to receive and forward multicast 366 traffic from the sender, that relay is better for the gateway to use, 367 since more of the network path uses native multicast, allowing more 368 chances for packet replication. But since that relay is not known to 369 the sender, it won't be advertised in the sender's reverse IP DNS 370 record. An example network that illustrates this scenario is 371 outlined in Section 3.1.2. 373 It's only appropriate for an AMT gateway to discover an AMT relay by 374 querying an AMTRELAY RR owned by a sender when all of these 375 conditions are met: 377 1. The gateway needs to propagate a join of an (S,G) over AMT, 378 because in the gateway's network, no RPF next hop toward the 379 source can propagate a native multicast join of the (S,G); and 381 2. The gateway is not already connected to a relay that forwards 382 multicast traffic from the source of the (S,G); and 384 3. The gateway is not configured to use a particular IP address for 385 AMT discovery, or a relay discovered with that IP is not able to 386 forward traffic from the source of the (S,G); and 388 4. The gateway is not able to find an upstream AMT relay with DNS-SD 389 [RFC6763], using "_amt._udp" as the Service section of the 390 queries, or a relay discovered this way is not able to forward 391 traffic from the source of the (S,G) (as described in 392 Section 2.5.4.1 or Section 2.5.5); and 394 5. The gateway is not able to find an upstream AMT relay with the 395 well-known anycast addresses from Section 7 of [RFC7450]. 397 When the above conditions are met, the gateway has no path within its 398 local network that can receive multicast traffic from the source IP 399 of the (S,G). 401 In this situation, the best way to find a relay that can forward the 402 required traffic is to use information that comes from the operator 403 of the sender. When the sender has configured an AMTRELAY RR, 404 gateways can use the DRIAD mechanism defined in this document to 405 discover the relay information provided by the sender. 407 2.3.2. Preference Ordering 409 This section defines a preference ordering for relay addresses during 410 the relay discovery process. Gateways are encouraged to implement a 411 Happy Eyeballs algorithm to try candidate relays concurrently, but 412 even gateways that do not implement a Happy Eyeballs algorithm SHOULD 413 use this ordering, except as noted. 415 When establishing an AMT tunnel to forward multicast data, it's very 416 important for the discovery process to prioritize the network 417 topology considerations ahead of address selection considerations, in 418 order to gain the packet replication benefits from using multicast 419 instead of unicast tunneling in the multicast-capable portions of the 420 network path. 422 The intent of the advice and requirements in this section is to 423 describe how a gateway should make use of the concurrency provided by 424 a Happy Eyeballs algorithm to reduce the join latency, while still 425 prioritizing network efficiency considerations over Address Selection 426 considerations. 428 Section 4 of [RFC8305] requires a Happy Eyeballs algorithm to sort 429 the addresses with the Destination Address Selection defined in 430 Section 6 of [RFC6724], but for the above reasons, that requirement 431 is superseded in the AMT discovery use case by the following 432 considerations: 434 o Prefer Local Relays 436 Figure 5 and Section 3.1.2 provide a motivating example to prefer 437 DNS-SD [RFC6763] for discovery strictly ahead of using the 438 AMTRELAY RR controlled by the sender for AMT discovery. 440 For this reason, it's RECOMMENDED that AMT gateways by default 441 perform service discovery using DNS Service Discovery (DNS-SD) 442 [RFC6763] for _amt._udp. (with chosen as 443 described in Section 11 of [RFC6763]) and use the AMT relays 444 discovered that way in preference to AMT relays discoverable via 445 the mechanism defined in this document (DRIAD). 447 o Prefer Relays Managed by the Containing Network 449 When no local relay is discoverable with DNS-SD, it still may be 450 the case that a relay local to the receiver is operated by the 451 network providing transit services to the receiver. 453 In this case, when the network cannot make the relay discoverable 454 via DNS-SD, the network SHOULD use the well-known anycast 455 addresses from Section 7 of [RFC7450] to route discovery traffic 456 to the relay most appropriate to the receiver's gateway. 458 Accordingly, the gateway SHOULD by default discover a relay with 459 the well-known AMT anycast addresses as the second preference 460 after DNS-SD when searching for a local relay. 462 o Let Sender Manage Relay Provisioning 464 A related motivating example in the sending-side network is 465 provided by considering a sender that needs to instruct the 466 gateways on how to select between connecting to Figure 6 or 467 Figure 7 (from Section 3.2), in order to manage load and failover 468 scenarios in a manner that operates well with the sender's 469 provisioning strategy for horizontal scaling of AMT relays. 471 In this example about the sending-side network, the precedence 472 field described in Section 4.2.1 is a critical method of control 473 so that senders can provide the appropriate guidance to gateways 474 during the discovery process. 476 Therefore, after DNS-SD, the precedence from the RR MUST be used 477 for sorting preference ahead of the Destination Address Selection 478 ordering from Section 6 of [RFC6724], so that only relay IPs with 479 the same precedence are directly compared according to the 480 Destination Address Selection ordering. 482 Accordingly, AMT gateways SHOULD by default prefer relays in this 483 order: 485 1. DNS-SD 486 2. Anycast addresses from Section 7 of [RFC7450] 487 3. DRIAD 489 This default behavior MAY be overridden by administrative 490 configuration where other behavior is more appropriate for the 491 gateway within its network. 493 Among relay addresses that have an equivalent preference as described 494 above, a Happy Eyeballs algorithm for AMT MUST use the Destination 495 Address Selection defined in Section 6 of [RFC6724], as required by 496 [RFC8305]. 498 Among relay addresses that still have an equivalent preference after 499 the above orderings, a gateway MUST make a non-deterministic choice 500 for relay preference ordering, in order to support load balancing by 501 DNS configurations that provide many relay options. 503 The gateway MAY introduce a bias in the non-deterministic choice 504 according to information obtained out of band or from a historical 505 record about network topology, timing information, or the response to 506 a probing mechanism, that indicates some expected benefits from 507 selecting some relays in preference to others. Details about the 508 structure and collection of this information are out of scope for 509 this document, but a gateway in possession of such information MAY 510 use it to prefer topologically closer relays. 512 Note also that certain relay addresses might be excluded from 513 consideration by the hold-down timers described in Section 2.5.4.1 or 514 Section 2.5.5. These relays constitute "unusable destinations" under 515 Rule 1 of the Destination Address Selection, and are also not part of 516 the superseding considerations described above. 518 The discovery and connection process for the relay addresses in the 519 above described ordering MAY operate in parallel, subject to delays 520 prescribed by the Happy Eyeballs requirements described in Section 5 521 of [RFC8305] for successively launched concurrent connection 522 attempts. 524 2.3.3. Connecting to Multiple Relays 526 In some deployments, it may be useful for a gateway to connect to 527 multiple upstream relays and subscribe to the same traffic, in order 528 to support an active/active failover model. A gateway SHOULD NOT be 529 configured to do so without guaranteeing that adequate bandwidth is 530 available. 532 A gateway configured to do this SHOULD still use the same preference 533 ordering logic from Section 2.3.2 for each connection. (Note that 534 this ordering allows for overriding by explicit administrative 535 configuration where required.) 537 2.4. Happy Eyeballs 539 2.4.1. Overview 541 Often, multiple choices of relay will exist for a gateway using DRIAD 542 for relay discovery. Happy Eyeballs [RFC8305] provides a widely 543 deployed and generalizable strategy for probing multiple possible 544 connections in parallel, therefore it is RECOMMENDED that DRIAD- 545 capable gateways implement a Happy Eyeballs algorithm to support fast 546 discovery of the most preferred available relay, by probing multiple 547 relays concurrently. 549 The parallel discovery logic of a Happy Eyeballs algorithm serves to 550 reduce join latency for the initial join of an SSM channel. This 551 section and the preference ordering of relays defined in 552 Section 2.3.2 taken together provide guidance on use of a Happy 553 Eyeballs algorithm for the case of establishing AMT connections. 555 Note that according to the definition in Section 2.4.3 of this 556 document, establishing the connection occurs before sending a 557 membership report. As described in Section 5 of [RFC8085], only one 558 of the successful connections will be used, and the others are all 559 canceled or ignored. In the context of an AMT connection, this means 560 the gateway will send the membership reports that subscribe to 561 traffic only for the chosen connection, after the Happy Eyeballs 562 algorithm resolves. 564 2.4.2. Algorithm Guidelines 566 During the "Initiation of asynchronous DNS queries" phase described 567 in Section 3 of [RFC8305]), a gateway attempts to resolve the domain 568 names listed in Section 2.3. This consists of resolving the SRV 569 queries for DNS-SD domains for the AMT service, as well as the 570 AMTRELAY query for the reverse IP domain defined in this document. 572 Each of the SRV and AMTRELAY responses might contain one or more IP 573 addresses, (as with type 1 or type 2 AMTRELAY responses, or when the 574 SRV Additional Data section of the SRV response contains the address 575 records for the target, as urged by [RFC2782]), or they might contain 576 only domain names (as with type 3 responses from Section 4.2.3, or an 577 SRV response without an additional data section). 579 When present, IP addresses in the initial response provide resolved 580 destination address candidates for the "Sorting of resolved 581 destination addresses" phase described in Section 4 of [RFC8085]), 582 whereas domain names without IP addresses in the initial response 583 result in another set of queries for AAAA and A records, whose 584 responses provide the candidate resolved destination addresses. 586 Since the SRV or AMTRELAY responses don't have a bound on the count 587 of queries that might be generated aside from the bounds imposed by 588 the DNS resolver, it's important for the gateway to provide a rate 589 limit on the DNS queries. The DNS query functionality is expected to 590 follow ordinary standards and best practices for DNS clients. A 591 gateway MAY use an existing DNS client implementation that does so, 592 and MAY rely on that client's rate limiting logic to avoid issuing 593 excessive queries. Otherwise, a gateway MUST provide a rate limit 594 for the DNS queries, and its default settings MUST NOT permit more 595 than 10 queries for any 100-millisecond period (though this MAY be 596 overridable by administrative configuration). 598 As the resolved IP addresses arrive, the Happy Eyeballs algorithm 599 sorts them according to the requirements and recommendations given in 600 Section 2.3.2, and attempts connections with the corresponding relays 601 under the algorithm restrictions and guidelines given in [RFC8085] 602 for the "Establishment of one connection, which cancels all other 603 attempts" phase. 605 2.4.3. Connection Definition 607 Section 5 of [RFC8305] non-normatively describes success at a 608 connection attempt as "generally when the TCP handshake completes". 610 There is no normative definition of a connection in the AMT 611 specification [RFC7450], and there is no TCP connection involved in 612 an AMT tunnel. 614 However, the concept of an AMT connection in the context of a Happy 615 Eyeballs algorithm is a useful one, and so this section provides the 616 following normative definition: 618 o An AMT connection is completed successfully when the gateway 619 receives from a newly discovered relay a valid Membership Query 620 message (Section 5.1.4 of [RFC7450]) that does not have the L flag 621 set. 623 See Section 2.5.5 of this document for further information about the 624 relevance of the L flag to the establishment of a Happy Eyeballs 625 connection. See Section 2.5.4 for an overview of how to respond if 626 the connection does not provide multicast connectivity to the source. 628 To "cancel" this kind of AMT connection for the Happy Eyeballs 629 algorithm, a gateway that has not sent a membership report with a 630 subscription would simply stop sending AMT packets for that 631 connection. A gateway only sends a membership report to a connection 632 it has chosen as the most preferred available connection. 634 2.5. Guidelines for Restarting Discovery 636 2.5.1. Overview 638 It's expected that gateways deployed in different environments will 639 use a variety of heuristics to decide when it's appropriate to 640 restart the relay discovery process, in order to meet different 641 performance goals (for example, to fulfill different kinds of service 642 level agreements). 644 In general, restarting the discovery process is always safe for the 645 gateway and relay during any of the events listed in this section, 646 but may cause a disruption in the forwarded traffic if the discovery 647 process results in choosing a different relay, because this changes 648 the RPF forwarding tree for the multicast traffic upstream of the 649 gateway. This is likely to result in some dropped or duplicated 650 packets from channels actively being tunneled from the old relay to 651 the gateway. 653 The degree of impact on the traffic from choosing a different relay 654 may depend on network conditions between the gateway and the new 655 relay, as well as the network conditions and topology between the 656 sender and the new relay, as this may cause the relay to propagate a 657 new RPF join toward the sender. 659 Balancing the expected impact on the tunneled traffic against likely 660 or observed problems with an existing connection to the relay is the 661 goal of the heuristics that gateways use to determine when to restart 662 the discovery process. 664 The non-normative advice in this section should be treated as 665 guidelines to operators and implementors working with AMT systems 666 that can use DRIAD as part of the relay discovery process. 668 2.5.2. Updates to Restarting Events 670 Section 5.2.3.4.1 of [RFC7450] lists several events that may cause a 671 gateway to start or restart the discovery procedure. 673 This document provides some updates and recommendations regarding the 674 handling of these and similar events. The first 5 events are copied 675 here and numbered for easier reference, and the remaining 4 events 676 are newly added for consideration in this document: 678 1. When a gateway pseudo-interface is started (enabled). 680 2. When the gateway wishes to report a group subscription when none 681 currently exist. 683 3. Before sending the next Request message in a membership update 684 cycle. 686 4. After the gateway fails to receive a response to a Request 687 message. 689 5. After the gateway receives a Membership Query message with the L 690 flag set to 1. 692 6. When the gateway wishes to report an (S,G) subscription with a 693 source address that does not currently have other group 694 subscriptions. 696 7. When there is a network change detected, for example when a 697 gateway is operating inside an end user device or application, 698 and the device joins a different network, or when the domain 699 portion of a DNS-SD domain name changes in response to a DHCP 700 message or administrative configuration. 702 8. When congestion or substantial loss is detected in the stream of 703 AMT packets from a relay. 705 9. When the gateway has reported one or more (S,G) subscriptions, 706 but no traffic is received from the source for some timeout. 707 (See Section 2.5.4.1). 709 This list is not exhaustive, nor are any of the listed events 710 strictly required to always force a restart of the discovery process. 712 Note that during event #1, a gateway may use DNS-SD, but does not 713 have sufficient information to use DRIAD, since no source is known. 715 2.5.3. Tunnel Stability 717 In general, subscribers to active traffic flows that are being 718 forwarded by an AMT gateway are less likely to experience a 719 degradation in service (for example, from missing or duplicated 720 packets) when the gateway continues using the same relay, as long as 721 the relay is not overloaded and the network conditions remain stable. 723 Therefore, gateways SHOULD avoid performing a full restart of the 724 discovery process during routine cases of event #3 (sending a new 725 Request message), since it occurs frequently in normal operation. 727 However, see Section 2.5.4, Section 2.5.6, and Section 2.5.4.3 for 728 more information about exceptional cases when it may be appropriate 729 to use event #3. 731 2.5.4. Traffic Health 733 2.5.4.1. Absence of Traffic 735 If a gateway indicates one or more (S,G) subscriptions in a 736 Membership Update message, but no traffic for any of the (S,G)s is 737 received in a reasonable time, it's appropriate for the gateway to 738 restart the discovery process. 740 If the gateway restarts the discovery process multiple times 741 consecutively for this reason, the timeout period SHOULD be adjusted 742 to provide a random exponential back-off. 744 The RECOMMENDED timeout is a random value in the range 745 [initial_timeout, MIN(initial_timeout * 2^retry_count, 746 maximum_timeout)], with a RECOMMENDED initial_timeout of 4 seconds 747 and a RECOMMENDED maximum_timeout of 120 seconds. 749 Note that the recommended initial_timeout is larger than the initial 750 timout recommended in the similar algorithm from Section 5.2.3.4.3 of 751 [RFC7450]. This is to provide time for RPF Join propagation in the 752 sending network. Although the timeout values may be administratively 753 adjusted to support performance requirements, operators are advised 754 to consider the possibility of join propagation delays between the 755 sender and the relay when choosing an appropriate timeout value. 757 Gateways restarting the discovery process because of an absence of 758 traffic MUST use a hold-down timer that removes this relay from 759 consideration during subsequent rounds of discovery while active. 760 The hold-down SHOULD last for no less than 3 minutes and no more than 761 10 minutes. 763 2.5.4.2. Loss and Congestion 765 In some gateway deployments, it is also feasible to monitor the 766 health of traffic flows through the gateway, for example by detecting 767 the rate of packet loss by communicating out of band with receivers, 768 or monitoring the packets of known protocols with sequence numbers. 769 Where feasible, it's encouraged for gateways to use such traffic 770 health information to trigger a restart of the discovery process 771 during event #3 (before sending a new Request message). 773 However, to avoid synchronized rediscovery by many gateways 774 simultaneously after a transient network event upstream of a relay 775 results in many receivers detecting poor flow health at the same 776 time, it's recommended to add a random delay before restarting the 777 discovery process in this case. 779 The span of the random portion of the delay should be no less than 10 780 seconds by default, but may be administratively configured to support 781 different performance requirements. 783 2.5.4.3. Ancient Discovery Information 785 In most cases, a gateway actively receiving healthy traffic from a 786 relay that has not indicated load with the L flag should prefer to 787 remain connected to the same relay, as described in Section 2.5.3. 789 However, a relay that appears healthy but has been forwarding traffic 790 for days or weeks may have an increased chance of becoming unstable. 791 Gateways may benefit from restarting the discovery process during 792 event #3 (before sending a Request message) after the expiration of a 793 long-term timeout, on the order of multiple hours, or even days in 794 some deployments. 796 It may be beneficial for such timers to consider the amount of 797 traffic currently being forwarded, and to give a higher probability 798 of restarting discovery during periods with an unusually low data 799 rate, to reduce the impact on active traffic while still avoiding 800 relying on the results of a very old discovery. 802 Other issues may also be worth considering as part of this heuristic; 803 for example, if the DNS expiry time of the record that was used to 804 discover the current relay has not passed, the long term timer might 805 be restarted without restarting the discovery process. 807 2.5.5. Relay Loaded or Shutting Down 809 The L flag (see Section 5.1.4.4 of [RFC7450]) is the preferred 810 mechanism for a relay to signal overloading or a graceful shutdown to 811 gateways. 813 A gateway that supports handling of the L flag should generally 814 restart the discovery process when it processes a Membership Query 815 packet with the L flag set. If an L flag is received while a 816 concurrent Happy Eyeballs discovery process is under way for multiple 817 candidate relays (Section 2.4), the relay sending the L flag SHOULD 818 NOT be considered for the relay selection. 820 It is also RECOMMENDED that gateways avoid choosing a relay that has 821 recently sent an L flag, with approximately a 10-minute hold-down. 822 Gateways SHOULD treat this hold-down timer in the same way as the 823 hold-down in Section 2.5.4.1, so that the relay is removed from 824 consideration for short-term subsequent rounds of discovery. 826 2.5.6. Relay Discovery Messages vs. Restarting Discovery 828 All AMT relays are required by [RFC7450] to support handling of Relay 829 Discovery messages (e.g. in Section 5.3.3.2 of [RFC7450]). 831 So a gateway with an existing connection to a relay can send a Relay 832 Discovery message to the unicast address of that AMT relay. Under 833 stable conditions with an unloaded relay, it's expected that the 834 relay will return its own unicast address in the Relay Advertisement, 835 in response to such a Relay Discovery message. Since this will not 836 result in the gateway changing to another relay unless the relay 837 directs the gateway away, this is a reasonable exception to the 838 advice against handling event #3 described in Section 2.5.3. 840 This behavior is discouraged for gateways that do support the L flag, 841 to avoid sending unnecessary packets over the network. 843 However, gateways that do not support the L flag may be able to avoid 844 a disruption in the forwarded traffic by sending such Relay Discovery 845 messages regularly. When a relay is under load or has started a 846 graceful shutdown, it may respond with a different relay address, 847 which the gateway can use to connect to a different relay. This kind 848 of coordinated handoff will likely result in a smaller disruption to 849 the traffic than if the relay simply stops responding to Request 850 messages, and stops forwarding traffic. 852 This style of Relay Discovery message (one sent to the unicast 853 address of a relay that's already forwarding traffic to this gateway) 854 SHOULD NOT be considered a full restart of the relay discovery 855 process. It is RECOMMENDED for gateways to support the L flag, but 856 for gateways that do not support the L flag, sending this message 857 during event #3 may help mitigate service degradation when relays 858 become unstable. 860 2.5.7. Independent Discovery Per Traffic Source 862 Relays discovered via the AMTRELAY RR are source-specific relay 863 addresses, and may use different pseudo-interfaces from each other 864 and from relays discovered via DNS-SD or a non-source-specific 865 address, as described in Section 4.1.2.1 of [RFC7450]. 867 Restarting the discovery process for one pseudo-interface does not 868 require restarting the discovery process for other pseudo-interfaces. 869 Gateway heuristics about restarting the discovery process should 870 operate independently for different tunnels to relays, when 871 responding to events that are specific to the different tunnels. 873 2.6. DNS Configuration 875 Often an AMT gateway will only have access to the source and group IP 876 addresses of the desired traffic, and will not know any other name 877 for the source of the traffic. Because of this, typically the best 878 way of looking up AMTRELAY RRs will be by using the source IP address 879 as an index into one of the reverse mapping trees (in-addr.arpa for 880 IPv4, as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, 881 as described in Section 2.5 of [RFC3596]). 883 Therefore, it is RECOMMENDED that AMTRELAY RRs be added to reverse IP 884 zones as appropriate. AMTRELAY records MAY also appear in other 885 zones, but the primary intended use case requires a reverse IP 886 mapping for the source from an (S,G) in order to be useful to most 887 AMT gateways. 889 When performing the AMTRELAY RR lookup, any CNAMEs or DNAMEs found 890 MUST be followed. This is necessary to support zone delegation. 891 Some examples outlining this need are described in [RFC2317]. 893 See Section 4 and Section 4.3 for a detailed explanation of the 894 contents for a DNS Zone file. 896 2.7. Waiting for DNS resolution 898 The DNS query functionality is expected to follow ordinary standards 899 and best practices for DNS clients. A gateway MAY use an existing 900 DNS client implementation that does so, and MAY rely on that client's 901 retry logic to determine the timeouts between retries. 903 Otherwise, a gateway MAY re-send a DNS query if it does not receive 904 an appropriate DNS response within some timeout period. If the 905 gateway retries multiple times, the timeout period SHOULD be adjusted 906 to provide a random exponential back-off. 908 As with the waiting process for the Relay Advertisement message from 909 Section 5.2.3.4.3 of [RFC7450], the RECOMMENDED timeout is a random 910 value in the range [initial_timeout, MIN(initial_timeout * 911 2^retry_count, maximum_timeout)], with a RECOMMENDED initial_timeout 912 of 1 second and a RECOMMENDED maximum_timeout of 120 seconds. 914 3. Example Deployments 916 3.1. Example Receiving Networks 918 3.1.1. Tier 3 ISP 920 One example of a receiving network is an ISP that offers multicast 921 ingest services to its subscribers, illustrated in Figure 3. 923 In the example network below, subscribers can join (S,G)s with MLDv2 924 or IGMPv3 as described in [RFC4604], and the AMT gateway in this ISP 925 can receive and forward multicast traffic from one of the example 926 sending networks in Section 3.2 by discovering the appropriate AMT 927 relays with a DNS lookup for the AMTRELAY RR with the reverse IP of 928 the source in the (S,G). 930 Internet 931 ^ ^ Multicast-enabled 932 | | Receiving Network 933 +------|------------|-------------------------+ 934 | | | | 935 | +--------+ +--------+ +=========+ | 936 | | Border |---| Border | | AMT | | 937 | | Router | | Router | | gateway | | 938 | +--------+ +--------+ +=========+ | 939 | | | | | 940 | +-----+------+-----------+--+ | 941 | | | | 942 | +-------------+ +-------------+ | 943 | | Agg Routers | .. | Agg Routers | | 944 | +-------------+ +-------------+ | 945 | / \ \ / \ | 946 | +---------------+ +---------------+ | 947 | |Access Systems | ....... |Access Systems | | 948 | |(CMTS/OLT/etc.)| |(CMTS/OLT/etc.)| | 949 | +---------------+ +---------------+ | 950 | | | | 951 +--------|------------------------|-----------+ 952 | | 953 +---+-+-+---+---+ +---+-+-+---+---+ 954 | | | | | | | | | | 955 /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ 956 |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| 958 Subscribers 960 Figure 3: Receiving ISP Example 962 3.1.2. Small Office 964 Another example receiving network is a small branch office that 965 regularly accesses some multicast content, illustrated in Figure 4. 967 This office has desktop devices that need to receive some multicast 968 traffic, so an AMT gateway runs on a LAN with these devices, to pull 969 traffic in through a non-multicast next-hop. 971 The office also hosts some mobile devices that have AMT gateway 972 instances embedded inside apps, in order to receive multicast traffic 973 over their non-multicast wireless LAN. (Note that the "Legacy 974 Router" is a simplification that's meant to describe a variety of 975 possible conditions; for example it could be a device providing a 976 split-tunnel VPN as described in [RFC7359], deliberately excluding 977 multicast traffic for a VPN tunnel, rather than a device which is 978 incapable of multicast forwarding.) 980 Internet 981 (non-multicast) 982 ^ 983 | Office Network 984 +----------|----------------------------------+ 985 | | | 986 | +---------------+ (Wifi) Mobile apps | 987 | | Modem+ | Wifi | - - - - w/ embedded | 988 | | Router | AP | AMT gateways | 989 | +---------------+ | 990 | | | 991 | | | 992 | +----------------+ | 993 | | Legacy Router | | 994 | | (unicast) | | 995 | +----------------+ | 996 | / | \ | 997 | / | \ | 998 | +--------+ +--------+ +--------+=========+ | 999 | | Phones | | ConfRm | | Desks | AMT | | 1000 | | subnet | | subnet | | subnet | gateway | | 1001 | +--------+ +--------+ +--------+=========+ | 1002 | | 1003 +---------------------------------------------+ 1005 Figure 4: Small Office (no multicast up) 1007 By adding an AMT relay to this office network as in Figure 5, it's 1008 possible to make use of multicast services from the example 1009 multicast-capable ISP in Section 3.1.1. 1011 Multicast-capable ISP 1012 ^ 1013 | Office Network 1014 +----------|----------------------------------+ 1015 | | | 1016 | +---------------+ (Wifi) Mobile apps | 1017 | | Modem+ | Wifi | - - - - w/ embedded | 1018 | | Router | AP | AMT gateways | 1019 | +---------------+ | 1020 | | +=======+ | 1021 | +---Wired LAN---| AMT | | 1022 | | | relay | | 1023 | +----------------+ +=======+ | 1024 | | Legacy Router | | 1025 | | (unicast) | | 1026 | +----------------+ | 1027 | / | \ | 1028 | / | \ | 1029 | +--------+ +--------+ +--------+=========+ | 1030 | | Phones | | ConfRm | | Desks | AMT | | 1031 | | subnet | | subnet | | subnet | gateway | | 1032 | +--------+ +--------+ +--------+=========+ | 1033 | | 1034 +---------------------------------------------+ 1036 Figure 5: Small Office Example 1038 When multicast-capable networks are chained like this, with a network 1039 like the one in Figure 5 receiving internet services from a 1040 multicast-capable network like the one in Figure 3, it's important 1041 for AMT gateways to reach the more local AMT relay, in order to avoid 1042 accidentally tunneling multicast traffic from a more distant AMT 1043 relay with unicast, and failing to utilize the multicast transport 1044 capabilities of the network in Figure 3. 1046 3.2. Example Sending Networks 1048 3.2.1. Sender-controlled Relays 1050 When a sender network is also operating AMT relays to distribute 1051 multicast traffic, as in Figure 6, each address could appear as an 1052 AMTRELAY RR for the reverse IP of the sender, or one or more domain 1053 names could appear in AMTRELAY RRs, and the AMT relay addresses can 1054 be discovered by finding A or AAAA records from those domain names. 1056 Sender Network 1057 +-----------------------------------+ 1058 | | 1059 | +--------+ +=======+ +=======+ | 1060 | | Sender | | AMT | | AMT | | 1061 | +--------+ | relay | | relay | | 1062 | | +=======+ +=======+ | 1063 | | | | | 1064 | +-----+------+----------+ | 1065 | | | 1066 +-----------|-----------------------+ 1067 v 1068 Internet 1069 (non-multicast) 1071 Figure 6: Small Office Example 1073 3.2.2. Provider-controlled Relays 1075 When an ISP offers a service to transmit outbound multicast traffic 1076 through a forwarding network, it might also offer AMT relays in order 1077 to reach receivers without multicast connectivity to the forwarding 1078 network, as in Figure 7. In this case it's RECOMMENDED that the ISP 1079 also provide at least one domain name for the AMT relays for use with 1080 the AMTRELAY RR. 1082 When the sender wishes to use the relays provided by the ISP for 1083 forwarding multicast traffic, an AMTRELAY RR should be configured to 1084 use the domain name provided by the ISP, to allow for address 1085 reassignment of the relays without forcing the sender to reconfigure 1086 the corresponding AMTRELAY RRs. 1088 +--------+ 1089 | Sender | 1090 +---+----+ Multicast-enabled 1091 | Sending Network 1092 +-----------|-------------------------------+ 1093 | v | 1094 | +------------+ +=======+ +=======+ | 1095 | | Agg Router | | AMT | | AMT | | 1096 | +------------+ | relay | | relay | | 1097 | | +=======+ +=======+ | 1098 | | | | | 1099 | +-----+------+--------+---------+ | 1100 | | | | 1101 | +--------+ +--------+ | 1102 | | Border |---| Border | | 1103 | | Router | | Router | | 1104 | +--------+ +--------+ | 1105 +-----|------------|------------------------+ 1106 | | 1107 v v 1108 Internet 1109 (non-multicast) 1111 Figure 7: Sending ISP Example 1113 4. AMTRELAY Resource Record Definition 1115 4.1. AMTRELAY RRType 1117 The AMTRELAY RRType has the mnemonic AMTRELAY and type code 260 1118 (decimal). 1120 The AMTRELAY RR is class independent. 1122 4.2. AMTRELAY RData Format 1124 The AMTRELAY RData consists of a 8-bit precedence field, a 1-bit 1125 "Discovery Optional" field, a 7-bit type field, and a variable length 1126 relay field. 1128 0 1 2 3 1129 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 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 | precedence |D| type | | 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1133 ~ relay ~ 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 4.2.1. RData Format - Precedence 1138 This is an 8-bit precedence for this record. It is interpreted in 1139 the same way as the PREFERENCE field described in Section 3.3.9 of 1140 [RFC1035]. 1142 Relays listed in AMTRELAY records with a lower value for precedence 1143 are to be attempted first. 1145 4.2.2. RData Format - Discovery Optional (D-bit) 1147 The D bit is a "Discovery Optional" flag. 1149 If the D bit is set to 0, a gateway using this RR MUST perform AMT 1150 relay discovery as described in Section 4.2.1.1 of [RFC7450], rather 1151 than directly sending an AMT Request message to the relay. 1153 That is, the gateway MUST receive an AMT Relay Advertisement message 1154 (Section 5.1.2 of [RFC7450]) for an address before sending an AMT 1155 Request message (Section 5.1.3 of [RFC7450]) to that address. Before 1156 receiving the Relay Advertisement message, this record has only 1157 indicated that the address can be used for AMT relay discovery, not 1158 for a Request message. This is necessary for devices that are not 1159 fully functional AMT relays, but rather load balancers or brokers, as 1160 mentioned in Section 4.2.1.1 of [RFC7450]. 1162 If the D bit is set to 1, the gateway MAY send an AMT Request message 1163 directly to the discovered relay address without first sending an AMT 1164 Discovery message. 1166 This bit should be set according to advice from the AMT relay 1167 operator. The D bit MUST be set to zero when no information is 1168 available from the AMT relay operator about its suitability. 1170 4.2.3. RData Format - Type 1172 The type field indicates the format of the information that is stored 1173 in the relay field. 1175 The following values are defined: 1177 o type = 0: The relay field is empty (0 bytes). 1179 o type = 1: The relay field contains a 4-octet IPv4 address. 1181 o type = 2: The relay field contains a 16-octet IPv6 address. 1183 o type = 3: The relay field contains a wire-encoded domain name. 1184 The wire-encoded format is self-describing, so the length is 1185 implicit. The domain name MUST NOT be compressed. (See 1186 Section 3.3 of [RFC1035] and Section 4 of [RFC3597].) 1188 4.2.4. RData Format - Relay 1190 The relay field is the address or domain name of the AMT relay. It 1191 is formatted according to the type field. 1193 When the type field is 0, the length of the relay field is 0, and it 1194 indicates that no AMT relay should be used for multicast traffic from 1195 this source. 1197 When the type field is 1, the length of the relay field is 4 octets, 1198 and a 32-bit IPv4 address is present. This is an IPv4 address as 1199 described in Section 3.4.1 of [RFC1035]. This is a 32-bit number in 1200 network byte order. 1202 When the type field is 2, the length of the relay field is 16 octets, 1203 and a 128-bit IPv6 address is present. This is an IPv6 address as 1204 described in Section 2.2 of [RFC3596]. This is a 128-bit number in 1205 network byte order. 1207 When the type field is 3, the relay field is a normal wire-encoded 1208 domain name, as described in Section 3.3 of [RFC1035]. Compression 1209 MUST NOT be used, for the reasons given in Section 4 of [RFC3597]. 1211 For a type 3 record, the D-bit and preference fields carry over to 1212 all A or AAAA records for the domain name. There is no difference in 1213 the result of the discovery process when it's obtained by type 1 or 1214 type 2 AMTRELAY records with identical D-bit and preference fields, 1215 vs. when the result is obtained by a type 3 AMTRELAY record that 1216 resolves to the same set of IPv4 and IPv6 addresses via A and AAAA 1217 lookups. 1219 4.3. AMTRELAY Record Presentation Format 1221 4.3.1. Representation of AMTRELAY RRs 1223 AMTRELAY RRs may appear in a zone data master file. The precedence, 1224 D-bit, relay type, and relay fields are REQUIRED. 1226 If the relay type field is 0, the relay field MUST be ".". 1228 The presentation for the record is as follows: 1230 IN AMTRELAY precedence D-bit type relay 1232 4.3.2. Examples 1234 In a DNS authoritative nameserver that understands the AMTRELAY type, 1235 the zone might contain a set of entries like this: 1237 $ORIGIN 100.51.198.in-addr.arpa. 1238 10 IN AMTRELAY 10 0 1 203.0.113.15 1239 10 IN AMTRELAY 10 0 2 2001:DB8::15 1240 10 IN AMTRELAY 128 1 3 amtrelays.example.com. 1242 This configuration advertises an IPv4 discovery address, an IPv6 1243 discovery address, and a domain name for AMT relays which can receive 1244 traffic from the source 198.51.100.10. The IPv4 and IPv6 addresses 1245 are configured with a D-bit of 0 (meaning discovery is mandatory, as 1246 described in Section 4.2.2), and a precedence 10 (meaning they're 1247 preferred ahead of the last entry, which has precedence 128). 1249 For zone files in name servers that don't support the AMTRELAY RRType 1250 natively, it's possible to use the format for unknown RR types, as 1251 described in [RFC3597]. This approach would replace the AMTRELAY 1252 entries in the example above with the entries below: 1254 10 IN TYPE260 \# ( 1255 6 ; length 1256 0a ; precedence=10 1257 01 ; D=0, relay type=1, an IPv4 address 1258 cb00710f ) ; 203.0.113.15 1259 10 IN TYPE260 \# ( 1260 18 ; length 1261 0a ; precedence=10 1262 02 ; D=0, relay type=2, an IPv6 address 1263 20010db800000000000000000000000f ) ; 2001:db8::15 1264 10 IN TYPE260 \# ( 1265 24 ; length 1266 80 ; precedence=128 1267 83 ; D=1, relay type=3, a wire-encoded domain name 1268 09616d7472656c617973076578616d706c6503636f6d ) ; domain name 1270 See Appendix A for more details. 1272 5. IANA Considerations 1274 This document updates the IANA Registry for DNS Resource Record Types 1275 by assigning type 260 to the AMTRELAY record. 1277 This document creates a new registry named "AMTRELAY Resource Record 1278 Parameters", with a sub-registry for the "Relay Type Field". The 1279 initial values in the sub-registry are: 1281 +-------+---------------------------------------+ 1282 | Value | Description | 1283 +-------+---------------------------------------+ 1284 | 0 | No relay is present. | 1285 | 1 | A 4-byte IPv4 address is present | 1286 | 2 | A 16-byte IPv6 address is present | 1287 | 3 | A wire-encoded domain name is present | 1288 | 4-255 | Unassigned | 1289 +-------+---------------------------------------+ 1291 Values 0, 1, 2, and 3 are further explained in Section 4.2.3 and 1292 Section 4.2.4. Relay type numbers 4 through 255 can be assigned with 1293 a policy of Specification Required (as described in [RFC8126]). 1295 6. Security Considerations 1297 6.1. Use of AMT 1299 This document defines a mechanism that enables a more widespread and 1300 automated use of AMT, even without access to a multicast backbone. 1301 Operators of networks and applications that include a DRIAD-capable 1302 AMT gateway are advised to carefully consider the security 1303 considerations in Section 6 of [RFC7450]. 1305 AMT gateway operators also are encouraged to take appropriate steps 1306 to ensure the integrity of the data received via AMT, for example by 1307 the opportunistic use of IPSec [RFC4301] to secure traffic received 1308 from AMT relays, when IPSECKEY records [RFC4025] are available or 1309 when a trust relationship with the AMT relays can be otherwise 1310 established and secured. 1312 6.2. Record-spoofing 1314 The AMTRELAY resource record contains information that SHOULD be 1315 communicated to the DNS client without being modified. The method 1316 used to ensure the result was unmodified is up to the client. 1318 There must be a trust relationship between the end consumer of this 1319 resource record and the DNS server. This relationship may be end-to- 1320 end DNSSEC validation, a TSIG [RFC2845] or SIG(0) [RFC2931] channel 1321 to another secure source, a secure local channel on the host, DNS 1322 over TLS [RFC7858] or HTTPS [RFC8484], or some other secure 1323 mechanism. 1325 If an AMT gateway accepts a maliciously crafted AMTRELAY record, the 1326 result could be a Denial of Service, or receivers processing 1327 multicast traffic from a source under the attacker's control. 1329 6.3. Congestion 1331 Multicast traffic, particularly interdomain multicast traffic, 1332 carries some congestion risks, as described in Section 4 of 1333 [RFC8085]. 1335 Application implementors and network operators that use DRIAD-capable 1336 AMT gateways are advised to take precautions including monitoring of 1337 application traffic behavior, traffic authentication at ingest, rate- 1338 limiting of multicast traffic, and the use of circuit-breaker 1339 techniques such as those described in Section 3.1.10 of [RFC8085] and 1340 similar protections at the network level, in order to ensure network 1341 health in the event of misconfiguration, poorly written applications 1342 that don't follow UDP congestion control principles, or deliberate 1343 attack. 1345 7. Acknowledgements 1347 This specification was inspired by the previous work of Doug Nortz, 1348 Robert Sayko, David Segelstein, and Percy Tarapore, presented in the 1349 MBONED working group at IETF 93. 1351 Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny 1352 Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, Ben Kaduk, Bill 1353 Atwood, Tim Chown, and Warren Kumari for their very helpful comments. 1355 8. References 1357 8.1. Normative References 1359 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1360 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1361 . 1363 [RFC1035] Mockapetris, P., "Domain names - implementation and 1364 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1365 November 1987, . 1367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1368 Requirement Levels", BCP 14, RFC 2119, 1369 DOI 10.17487/RFC2119, March 1997, 1370 . 1372 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1373 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 1374 . 1376 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1377 specifying the location of services (DNS SRV)", RFC 2782, 1378 DOI 10.17487/RFC2782, February 2000, 1379 . 1381 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1382 Thyagarajan, "Internet Group Management Protocol, Version 1383 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 1384 . 1386 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1387 "DNS Extensions to Support IP Version 6", STD 88, 1388 RFC 3596, DOI 10.17487/RFC3596, October 2003, 1389 . 1391 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 1392 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 1393 2003, . 1395 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1396 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1397 DOI 10.17487/RFC3810, June 2004, 1398 . 1400 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 1401 Group Management Protocol Version 3 (IGMPv3) and Multicast 1402 Listener Discovery Protocol Version 2 (MLDv2) for Source- 1403 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 1404 August 2006, . 1406 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1407 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 1408 . 1410 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 1411 "Default Address Selection for Internet Protocol Version 6 1412 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 1413 . 1415 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1416 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1417 . 1419 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 1420 DOI 10.17487/RFC7450, February 2015, 1421 . 1423 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1424 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1425 March 2017, . 1427 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1428 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1429 May 2017, . 1431 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 1432 Better Connectivity Using Concurrency", RFC 8305, 1433 DOI 10.17487/RFC8305, December 2017, 1434 . 1436 8.2. Informative References 1438 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 1439 ADDR.ARPA delegation", BCP 20, RFC 2317, 1440 DOI 10.17487/RFC2317, March 1998, 1441 . 1443 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 1444 Wellington, "Secret Key Transaction Authentication for DNS 1445 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 1446 . 1448 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 1449 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 1450 2000, . 1452 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1453 Jacobson, "RTP: A Transport Protocol for Real-Time 1454 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1455 July 2003, . 1457 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 1458 Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March 1459 2005, . 1461 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1462 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1463 December 2005, . 1465 [RFC5110] Savola, P., "Overview of the Internet Multicast Routing 1466 Architecture", RFC 5110, DOI 10.17487/RFC5110, January 1467 2008, . 1469 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 1470 "FLUTE - File Delivery over Unidirectional Transport", 1471 RFC 6726, DOI 10.17487/RFC6726, November 2012, 1472 . 1474 [RFC7359] Gont, F., "Layer 3 Virtual Private Network (VPN) Tunnel 1475 Traffic Leakages in Dual-Stack Hosts/Networks", RFC 7359, 1476 DOI 10.17487/RFC7359, August 2014, 1477 . 1479 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 1480 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 1481 Multicast - Sparse Mode (PIM-SM): Protocol Specification 1482 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 1483 2016, . 1485 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1486 and P. Hoffman, "Specification for DNS over Transport 1487 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1488 2016, . 1490 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1491 Writing an IANA Considerations Section in RFCs", BCP 26, 1492 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1493 . 1495 [RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T., 1496 Ed., and R. Krishnan, "Use of Multicast across Inter- 1497 domain Peering Points", BCP 213, RFC 8313, 1498 DOI 10.17487/RFC8313, January 2018, 1499 . 1501 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1502 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1503 . 1505 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1506 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1507 January 2019, . 1509 Appendix A. Unknown RRType construction 1511 In a DNS resolver that understands the AMTRELAY type, the zone file 1512 might contain this line: 1514 IN AMTRELAY 128 0 3 amtrelays.example.com. 1516 In order to translate this example to appear as an unknown RRType as 1517 defined in [RFC3597], one could run the following program: 1519 1520 $ cat translate.py 1521 #!/usr/bin/env python3 1522 import sys 1523 name=sys.argv[1] 1524 wire='' 1525 for dn in name.split('.'): 1526 if len(dn) > 0: 1527 wire += ('%02x' % len(dn)) 1528 wire += (''.join('%02x'%ord(x) for x in dn)) 1529 print(len(wire)//2) + 2 1530 print(wire) 1532 $ ./translate.py amtrelays.example.com 1533 24 1534 09616d7472656c617973076578616d706c6503636f6d 1535 1537 The length and the hex string for the domain name 1538 "amtrelays.example.com" are the outputs of this program, yielding a 1539 length of 22 and the above hex string. 1541 22 is the length of the wire-encoded domain name, so to this we add 2 1542 (1 for the precedence field and 1 for the combined D-bit and relay 1543 type fields) to get the full length of the RData, and encode the 1544 precedence, D-bit, and relay type fields as octets, as described in 1545 Section 4. 1547 This results in a zone file entry like this: 1549 IN TYPE260 \# ( 24 ; length 1550 80 ; precedence = 128 1551 03 ; D-bit=0, relay type=3 (wire-encoded domain name) 1552 09616d7472656c617973076578616d706c6503636f6d ) ; domain name 1554 Author's Address 1556 Jake Holland 1557 Akamai Technologies, Inc. 1558 150 Broadway 1559 Cambridge, MA 02144 1560 United States of America 1562 Email: jakeholland.net@gmail.com