idnits 2.17.1 draft-ietf-mboned-driad-amt-discovery-13.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 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 (December 20, 2019) is 1588 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 normative reference: RFC 8499 (Obsoleted by RFC 9499) -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 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) December 20, 2019 5 Intended status: Standards Track 6 Expires: June 22, 2020 8 DNS Reverse IP AMT (Automatic Multicast Tunneling) Discovery 9 draft-ietf-mboned-driad-amt-discovery-13 11 Abstract 13 This document updates RFC 7450 (Automatic Multicast Tunneling, or 14 AMT) by modifying the relay discovery process. A new DNS resource 15 record named AMTRELAY is defined for publishing 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. Other 20 extensions and clarifications to the relay discovery process are also 21 defined. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 22, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2.1. Relays and Gateways . . . . . . . . . . . . . . . . . 4 61 1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 4 62 2. Relay Discovery Overview . . . . . . . . . . . . . . . . . . 6 63 2.1. Basic Mechanics . . . . . . . . . . . . . . . . . . . . . 6 64 2.2. Signaling and Discovery . . . . . . . . . . . . . . . . . 6 65 2.3. Example Deployments . . . . . . . . . . . . . . . . . . . 9 66 2.3.1. Example Receiving Networks . . . . . . . . . . . . . 9 67 2.3.2. Example Sending Networks . . . . . . . . . . . . . . 12 68 3. Relay Discovery Operation . . . . . . . . . . . . . . . . . . 14 69 3.1. Optimal Relay Selection . . . . . . . . . . . . . . . . . 14 70 3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 14 71 3.1.2. Preference Ordering . . . . . . . . . . . . . . . . . 15 72 3.1.3. Connecting to Multiple Relays . . . . . . . . . . . . 18 73 3.2. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . . 18 74 3.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 18 75 3.2.2. Algorithm Guidelines . . . . . . . . . . . . . . . . 19 76 3.2.3. Connection Definition . . . . . . . . . . . . . . . . 20 77 3.3. Guidelines for Restarting Discovery . . . . . . . . . . . 20 78 3.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 20 79 3.3.2. Updates to Restarting Events . . . . . . . . . . . . 21 80 3.3.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 22 81 3.3.4. Traffic Health . . . . . . . . . . . . . . . . . . . 22 82 3.3.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 24 83 3.3.6. Relay Discovery Messages vs. Restarting Discovery . . 24 84 3.3.7. Independent Discovery Per Traffic Source . . . . . . 25 85 3.4. DNS Configuration . . . . . . . . . . . . . . . . . . . . 25 86 3.5. Waiting for DNS resolution . . . . . . . . . . . . . . . 26 87 4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 26 88 4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 26 89 4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 27 90 4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 27 91 4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 27 92 4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 28 93 4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 28 94 4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 29 95 4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 29 96 4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 29 98 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 100 6.1. Use of AMT . . . . . . . . . . . . . . . . . . . . . . . 30 101 6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 31 102 6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 31 103 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 104 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 105 8.1. Normative References . . . . . . . . . . . . . . . . . . 32 106 8.2. Informative References . . . . . . . . . . . . . . . . . 34 107 Appendix A. Unknown RRType construction . . . . . . . . . . . . 35 108 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36 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 extends the relay discovery procedure described in 139 Section 5.2.3.4 of [RFC7450]. 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.4.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 | | | 210 | CMTS | Cable Modem Termination System | 211 | | | 212 | OLT | Optical Line Terminal | 213 +------------+------------------------------------------------------+ 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 217 "OPTIONAL" in this document are to be interpreted as described in BCP 218 14 [RFC2119] [RFC8174] when, and only when, they appear in all 219 capitals, as shown here. 221 2. Relay Discovery Overview 223 2.1. Basic Mechanics 225 The AMTRELAY resource record (RR) defined in this document is used to 226 publish the IP address or domain name of a set of AMT relays or 227 discovery brokers that can receive, encapsulate, and forward 228 multicast traffic from a particular sender. 230 The sender is the owner of the RR, and configures the zone so that it 231 contains a set of RRs that provide the addresses or domain names of 232 AMT relays (or discovery brokers that advertise relays) that can 233 receive multicast IP traffic from that sender. 235 This enables AMT gateways in remote networks to discover an AMT relay 236 that is capable of forwarding traffic from the sender. This in turn 237 enables those AMT gateways to receive the multicast traffic tunneled 238 over a unicast AMT tunnel from those relays, and then to pass the 239 multicast packets into networks or applications that are using the 240 gateway to subscribe to traffic from that sender. 242 This mechanism only works for source-specific multicast (SSM) 243 channels. The source address of the (S,G) is reversed and used as an 244 index into one of the reverse mapping trees (in-addr.arpa for IPv4, 245 as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, as 246 described in Section 2.5 of [RFC3596]). 248 This mechanism should be treated as an extension of the AMT relay 249 discovery procedure described in Section 5.2.3.4 of [RFC7450]. A 250 gateway that supports this method of AMT relay discovery SHOULD use 251 this method whenever it's performing the relay discovery procedure, 252 and the source IP addresses for desired (S,G)s are known to the 253 gateway, and conditions match the requirements outlined in 254 Section 3.1. 256 Some detailed example use cases are provided in Section 2.3, and 257 other applicable example topologies appear in Section 3.3 of 258 [RFC8313], Section 3.4 of [RFC8313], and Section 3.5 of [RFC8313]. 260 2.2. Signaling and Discovery 262 This section describes a typical example of the end-to-end process 263 for signaling a receiver's join of an SSM channel that relies on an 264 AMTRELAY RR. 266 The example in Figure 2 contains 2 multicast-enabled networks that 267 are both connected to the internet with non-multicast-capable links, 268 and which have no direct association with each other. 270 A content provider operates a sender, which is a source of multicast 271 traffic inside a multicast-capable network. 273 An end user who is a customer of the content provider has a 274 multicast-capable internet service provider, which operates a 275 receiving network that uses an AMT gateway. The AMT gateway is 276 DRIAD-capable. 278 The content provider provides the user with a receiving application 279 that tries to subscribe to at least one (S,G). This receiving 280 application could for example be a file transfer system using FLUTE 281 [RFC6726] or a live video stream using RTP [RFC3550], or any other 282 application that might subscribe to an SSM channel. 284 +---------------+ 285 | Sender | 286 | | | 2001:db8::a | 287 | | +---------------+ 288 |Data| | 289 |Flow| Multicast | 290 \| |/ Network | 291 \ / | 5: Propagate RPF for Join(S,G) 292 \ / +---------------+ 293 \/ | AMT Relay | 294 | 2001:db8:c::f | 295 +---------------+ 296 | 4: Gateway connects to Relay, 297 sends Join(S,G) over tunnel 298 | 299 Unicast 300 Tunnel | 3: --> DNS Query: type=AMTRELAY, 301 / a.0.0.0.0.0.0.0.0.0.0.0. 302 ^ | / 0.0.0.0.0.0.0.0.0.0.0.0. 303 | / 8.b.d.0.1.0.0.2.ip6.arpa 304 | | / <-- Response: 305 Join/Leave +-------------+ AMTRELAY=2001:db8:c::f 306 Signals | AMT gateway | 307 | +-------------+ 308 | | 2: Propagate RPF for Join(S,G) 309 | Multicast | 310 Network | 311 | 1: Join(S=2001:db8::a,G=ff3e::8000:d) 312 +-------------+ 313 | Receiver | 314 | (end user) | 315 +-------------+ 317 Figure 2: DRIAD Messaging 319 In this simple example, the sender IP is 2001:db8::a, it is sending 320 traffic to the group address ff3e::8000:d, and the relay IP is 321 2001:db8::c:f. 323 The content provider has previously configured the DNS zone that 324 contains the reverse IP domain name for the sender's IP address so 325 that it provides an AMTRELAY RR with the relay's IP address. (See 326 Section 4.3 for details about the AMTRELAY RR format and semantics.) 327 As described in Section 2.5 of [RFC3596], the reverse IP FQDN of the 328 sender's address "2001:db8::a" is: 330 a.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6. 331 arpa. 333 The sequence of events depicted in Figure 2 is as follows: 335 1. The end user starts the app, which issues a join to the (S,G): 336 (2001:db8::a, ff3e::8000:d). 338 2. The join propagates with RPF through the receiver's multicast- 339 enabled network with PIM [RFC7761] or another multicast routing 340 mechanism, until the AMT gateway receives a signal to join the 341 (S,G). 343 3. The AMT gateway performs a reverse DNS lookup for the AMTRELAY 344 RRType, by sending an AMTRELAY RRType query for the reverse IP 345 domain name for the sender's source IP address (the S from the 346 (S,G)). 348 The DNS resolver for the AMT gateway uses ordinary DNS recursive 349 resolution until it has the authoritative result that the content 350 provider configured, which informs the AMT gateway that the relay 351 address is 2001:db8::c:f. 353 4. The AMT gateway performs AMT handshakes with the AMT relay as 354 described in Section 4 of [RFC7450], then forwards a Membership 355 report to the relay indicating subscription to the (S,G). 357 5. The relay propagates the join through its network toward the 358 sender, then forwards the appropriate AMT-encapsulated traffic to 359 the gateway, which decapsulates and forwards it as native 360 multicast through its downstream network to the end user. 362 In the case of an IPv4 (S,G), the only difference in the AMT relay 363 discovery process is the use of the in-addr.arpa reverse IP domain 364 name, as described in Section 3.5 of [RFC1035], instead of the 365 in6.arpa domain name. For example, if the (S,G) is (198.51.100.12, 366 232.252.0.2), the reverse IP FQDN for the AMTRELAY query would be 367 "12.100.51.198.in-addr.arpa.". 369 Note that the address family of the AMT tunnel is independent of the 370 address family for the multicast traffic. 372 2.3. Example Deployments 374 2.3.1. Example Receiving Networks 376 2.3.1.1. Internet Service Provider 378 One example of a receiving network is an Internet Service Provider 379 (ISP) that offers multicast ingest services to its subscribers, 380 illustrated in Figure 3. 382 In the example network below, subscribers can join (S,G)s with MLDv2 383 or IGMPv3 as described in [RFC4604], and the AMT gateway in this ISP 384 can receive and forward multicast traffic from one of the example 385 sending networks in Section 2.3.2 by discovering the appropriate AMT 386 relays with a DNS lookup for the AMTRELAY RR with the reverse IP of 387 the source in the (S,G). 389 Internet 390 ^ ^ Multicast-enabled 391 | | Receiving Network 392 +------|------------|-------------------------+ 393 | | | | 394 | +--------+ +--------+ +=========+ | 395 | | Border |---| Border | | AMT | | 396 | | Router | | Router | | gateway | | 397 | +--------+ +--------+ +=========+ | 398 | | | | | 399 | +-----+------+-----------+--+ | 400 | | | | 401 | +-------------+ +-------------+ | 402 | | Agg Routers | .. | Agg Routers | | 403 | +-------------+ +-------------+ | 404 | / \ \ / \ | 405 | +---------------+ +---------------+ | 406 | |Access Systems | ....... |Access Systems | | 407 | |(CMTS/OLT/etc.)| |(CMTS/OLT/etc.)| | 408 | +---------------+ +---------------+ | 409 | | | | 410 +--------|------------------------|-----------+ 411 | | 412 +---+-+-+---+---+ +---+-+-+---+---+ 413 | | | | | | | | | | 414 /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ 415 |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| 417 Subscribers 419 Figure 3: Receiving ISP Example 421 2.3.1.2. Small Office 423 Another example receiving network is a small branch office that 424 regularly accesses some multicast content, illustrated in Figure 4. 426 This office has desktop devices that need to receive some multicast 427 traffic, so an AMT gateway runs on a LAN with these devices, to pull 428 traffic in through a non-multicast next-hop. 430 The office also hosts some mobile devices that have AMT gateway 431 instances embedded inside apps, in order to receive multicast traffic 432 over their non-multicast wireless LAN. (Note that the "Legacy 433 Router" is a simplification that's meant to describe a variety of 434 possible conditions; for example it could be a device providing a 435 split-tunnel VPN as described in [RFC7359], deliberately excluding 436 multicast traffic for a VPN tunnel, rather than a device which is 437 incapable of multicast forwarding.) 439 Internet 440 (non-multicast) 441 ^ 442 | Office Network 443 +----------|----------------------------------+ 444 | | | 445 | +---------------+ (Wifi) Mobile apps | 446 | | Modem+ | Wifi | - - - - w/ embedded | 447 | | Router | AP | AMT gateways | 448 | +---------------+ | 449 | | | 450 | | | 451 | +----------------+ | 452 | | Legacy Router | | 453 | | (unicast) | | 454 | +----------------+ | 455 | / | \ | 456 | / | \ | 457 | +--------+ +--------+ +--------+=========+ | 458 | | Phones | | ConfRm | | Desks | AMT | | 459 | | subnet | | subnet | | subnet | gateway | | 460 | +--------+ +--------+ +--------+=========+ | 461 | | 462 +---------------------------------------------+ 464 Figure 4: Small Office (no multicast up) 466 By adding an AMT relay to this office network as in Figure 5, it's 467 possible to make use of multicast services from the example 468 multicast-capable ISP in Section 2.3.1.1. 470 Multicast-capable ISP 471 ^ 472 | Office Network 473 +----------|----------------------------------+ 474 | | | 475 | +---------------+ (Wifi) Mobile apps | 476 | | Modem+ | Wifi | - - - - w/ embedded | 477 | | Router | AP | AMT gateways | 478 | +---------------+ | 479 | | +=======+ | 480 | +---Wired LAN---| AMT | | 481 | | | relay | | 482 | +----------------+ +=======+ | 483 | | Legacy Router | | 484 | | (unicast) | | 485 | +----------------+ | 486 | / | \ | 487 | / | \ | 488 | +--------+ +--------+ +--------+=========+ | 489 | | Phones | | ConfRm | | Desks | AMT | | 490 | | subnet | | subnet | | subnet | gateway | | 491 | +--------+ +--------+ +--------+=========+ | 492 | | 493 +---------------------------------------------+ 495 Figure 5: Small Office Example 497 When multicast-capable networks are chained like this, with a network 498 like the one in Figure 5 receiving internet services from a 499 multicast-capable network like the one in Figure 3, it's important 500 for AMT gateways to reach the more local AMT relay, in order to avoid 501 accidentally tunneling multicast traffic from a more distant AMT 502 relay with unicast, and failing to utilize the multicast transport 503 capabilities of the network in Figure 3. 505 2.3.2. Example Sending Networks 507 2.3.2.1. Sender-controlled Relays 509 When a sender network is also operating AMT relays to distribute 510 multicast traffic, as in Figure 6, each address could appear as an 511 AMTRELAY RR for the reverse IP of the sender, or one or more domain 512 names could appear in AMTRELAY RRs, and the AMT relay addresses can 513 be discovered by finding A or AAAA records from those domain names. 515 Sender Network 516 +-----------------------------------+ 517 | | 518 | +--------+ +=======+ +=======+ | 519 | | Sender | | AMT | | AMT | | 520 | +--------+ | relay | | relay | | 521 | | +=======+ +=======+ | 522 | | | | | 523 | +-----+------+----------+ | 524 | | | 525 +-----------|-----------------------+ 526 v 527 Internet 528 (non-multicast) 530 Figure 6: Small Office Example 532 2.3.2.2. Provider-controlled Relays 534 When an ISP offers a service to transmit outbound multicast traffic 535 through a forwarding network, it might also offer AMT relays in order 536 to reach receivers without multicast connectivity to the forwarding 537 network, as in Figure 7. In this case it's recommended that the ISP 538 also provide at least one domain name for the AMT relays for use with 539 the AMTRELAY RR. 541 When the sender wishes to use the relays provided by the ISP for 542 forwarding multicast traffic, an AMTRELAY RR should be configured to 543 use the domain name provided by the ISP, to allow for address 544 reassignment of the relays without forcing the sender to reconfigure 545 the corresponding AMTRELAY RRs. 547 +--------+ 548 | Sender | 549 +---+----+ Multicast-enabled 550 | Sending Network 551 +-----------|-------------------------------+ 552 | v | 553 | +------------+ +=======+ +=======+ | 554 | | Agg Router | | AMT | | AMT | | 555 | +------------+ | relay | | relay | | 556 | | +=======+ +=======+ | 557 | | | | | 558 | +-----+------+--------+---------+ | 559 | | | | 560 | +--------+ +--------+ | 561 | | Border |---| Border | | 562 | | Router | | Router | | 563 | +--------+ +--------+ | 564 +-----|------------|------------------------+ 565 | | 566 v v 567 Internet 568 (non-multicast) 570 Figure 7: Sending ISP Example 572 3. Relay Discovery Operation 574 3.1. Optimal Relay Selection 576 3.1.1. Overview 578 The reverse source IP DNS query of an AMTRELAY RR is a good way for a 579 gateway to discover a relay that is known to the sender. 581 However, it is NOT necessarily a good way to discover the best relay 582 for that gateway to use, because the RR will only provide information 583 about relays known to the source. 585 If there is an upstream relay in a network that is topologically 586 closer to the gateway and able to receive and forward multicast 587 traffic from the sender, that relay is better for the gateway to use, 588 since more of the network path uses native multicast, allowing more 589 chances for packet replication. But since that relay is not known to 590 the sender, it won't be advertised in the sender's reverse IP DNS 591 record. An example network that illustrates this scenario is 592 outlined in Figure 5 from Section 2.3.1.2. 594 It's only appropriate for an AMT gateway to discover an AMT relay by 595 querying an AMTRELAY RR owned by a sender when all of these 596 conditions are met: 598 1. The gateway needs to propagate a join of an (S,G) over AMT, 599 because in the gateway's network, no RPF next hop toward the 600 source can propagate a native multicast join of the (S,G); and 602 2. The gateway is not already connected to a relay that forwards 603 multicast traffic from the source of the (S,G); and 605 3. The gateway is not configured to use a particular IP address for 606 AMT discovery, or a relay discovered with that IP is not able to 607 forward traffic from the source of the (S,G); and 609 4. The gateway is not able to find an upstream AMT relay with DNS-SD 610 [RFC6763], using "_amt._udp" as the Service section of the 611 queries, or a relay discovered this way is not able to forward 612 traffic from the source of the (S,G) (as described in 613 Section 3.3.4.1 or Section 3.3.5); and 615 5. The gateway is not able to find an upstream AMT relay with the 616 well-known anycast addresses from Section 7 of [RFC7450]. 618 When the above conditions are met, the gateway has no path within its 619 local network that can receive multicast traffic from the source IP 620 of the (S,G). 622 In this situation, the best way to find a relay that can forward the 623 required traffic is to use information that comes from the operator 624 of the sender. When the sender has configured an AMTRELAY RR, 625 gateways can use the DRIAD mechanism defined in this document to 626 discover the relay information provided by the sender. 628 Note that the DNS-SD service is not source-specific, so even though 629 when available, several methods of finding a more local source of 630 multicast traffic connectivity are preferred to using a relay 631 provided by an AMTRELAY RR, a gateway further upstream would still be 632 using the AMTRELAY RR unless the upstream network has a peering that 633 provides an alternative end-to-end multicast transport path for the 634 (S,G)'s traffic. 636 3.1.2. Preference Ordering 638 This section defines a preference ordering for relay addresses during 639 the relay discovery process. Gateways are encouraged to implement a 640 Happy Eyeballs algorithm to try candidate relays concurrently, but 641 even gateways that do not implement a Happy Eyeballs algorithm SHOULD 642 use this ordering, except as noted. 644 When establishing an AMT tunnel to forward multicast data, it's very 645 important for the discovery process to prioritize the network 646 topology considerations ahead of address selection considerations, in 647 order to gain the packet replication benefits from using multicast 648 instead of unicast tunneling in the multicast-capable portions of the 649 network path. 651 The intent of the advice and requirements in this section is to 652 describe how a gateway should make use of the concurrency provided by 653 a Happy Eyeballs algorithm to reduce the join latency, while still 654 prioritizing network efficiency considerations over Address Selection 655 considerations. 657 Section 4 of [RFC8305] requires a Happy Eyeballs algorithm to sort 658 the addresses with the Destination Address Selection defined in 659 Section 6 of [RFC6724], but for the above reasons, that requirement 660 is superseded in the AMT discovery use case by the following 661 considerations: 663 o Prefer Local Relays 665 Figure 5 and Section 2.3.1.2 provide a motivating example to 666 prefer DNS-SD [RFC6763] for discovery strictly ahead of using the 667 AMTRELAY RR controlled by the sender for AMT discovery. 669 For this reason, it's RECOMMENDED that AMT gateways by default 670 perform service discovery using DNS Service Discovery (DNS-SD) 671 [RFC6763] for _amt._udp. (with chosen as 672 described in Section 11 of [RFC6763]) and use the AMT relays 673 discovered that way in preference to AMT relays discoverable via 674 the mechanism defined in this document (DRIAD). 676 o Prefer Relays Managed by the Containing Network 678 When no local relay is discoverable with DNS-SD, it still may be 679 the case that a relay local to the receiver is operated by the 680 network providing transit services to the receiver. 682 In this case, when the network cannot make the relay discoverable 683 via DNS-SD, the network SHOULD use the well-known anycast 684 addresses from Section 7 of [RFC7450] to route discovery traffic 685 to the relay most appropriate to the receiver's gateway. 687 Accordingly, the gateway SHOULD by default discover a relay with 688 the well-known AMT anycast addresses as the second preference 689 after DNS-SD when searching for a local relay. 691 o Let Sender Manage Relay Provisioning 693 A related motivating example is provided by considering a sender 694 whose traffic can be forwarded by relays in a sender-controlled 695 network like Figure 6 in Section 2.3.2.1, and also by relays in a 696 provider-controlled network like Figure 7 in Section 2.3.2.2, with 697 different cost and scalability profiles for the different options. 699 In this example about the sending-side network, the precedence 700 field described in Section 4.2.1 is a critical method of control 701 so that senders can provide the appropriate guidance to gateways 702 during the discovery process, in order to manage load and failover 703 scenarios in a manner that operates well with the sender's 704 provisioning strategy for horizontal scaling of AMT relays. 706 Therefore, after DNS-SD, the precedence from the RR MUST be used 707 for sorting preference ahead of the Destination Address Selection 708 ordering from Section 6 of [RFC6724], so that only relay IPs with 709 the same precedence are directly compared according to the 710 Destination Address Selection ordering. 712 Accordingly, AMT gateways SHOULD by default prefer relays in this 713 order: 715 1. DNS-SD 716 2. Anycast addresses from Section 7 of [RFC7450] 717 3. DRIAD 719 This default behavior MAY be overridden by administrative 720 configuration where other behavior is more appropriate for the 721 gateway within its network. 723 Among relay addresses that have an equivalent preference as described 724 above, a Happy Eyeballs algorithm for AMT SHOULD use the Destination 725 Address Selection defined in Section 6 of [RFC6724]. 727 Among relay addresses that still have an equivalent preference after 728 the above orderings, a gateway SHOULD make a non-deterministic choice 729 (such as a pseudorandom selection) for relay preference ordering, in 730 order to support load balancing by DNS configurations that provide 731 many relay options. 733 The gateway MAY introduce a bias in the non-deterministic choice 734 according to information obtained out of band or from a historical 735 record about network topology, timing information, or the response to 736 a probing mechanism, that indicates some expected benefits from 737 selecting some relays in preference to others. Details about the 738 structure and collection of this information are out of scope for 739 this document, but a gateway in possession of such information MAY 740 use it to prefer topologically closer relays. 742 Within the above constraints, gateways MAY make use of other 743 considerations from Section 4 of [RFC8305], such as the address 744 family interleaving strategies, to produce a final ordering of 745 candidate relay addresses. 747 Note also that certain relay addresses might be excluded from 748 consideration by the hold-down timers described in Section 3.3.4.1 or 749 Section 3.3.5. These relays constitute "unusable destinations" under 750 Rule 1 of the Destination Address Selection, and are also not part of 751 the superseding considerations described above. 753 The discovery and connection process for the relay addresses in the 754 above described ordering MAY operate in parallel, subject to delays 755 prescribed by the Happy Eyeballs requirements described in Section 5 756 of [RFC8305] for successively launched concurrent connection 757 attempts. 759 3.1.3. Connecting to Multiple Relays 761 In some deployments, it may be useful for a gateway to connect to 762 multiple upstream relays and subscribe to the same traffic, in order 763 to support an active/active failover model. A gateway SHOULD NOT be 764 configured to do so without guaranteeing that adequate bandwidth is 765 available. 767 A gateway configured to do this SHOULD still use the same preference 768 ordering logic from Section 3.1.2 for each connection. (Note that 769 this ordering allows for overriding by explicit administrative 770 configuration where required.) 772 3.2. Happy Eyeballs 774 3.2.1. Overview 776 Often, multiple choices of relay will exist for a gateway using DRIAD 777 for relay discovery. Happy Eyeballs [RFC8305] provides a widely 778 deployed and generalizable strategy for probing multiple possible 779 connections in parallel, therefore it is RECOMMENDED that DRIAD- 780 capable gateways implement a Happy Eyeballs algorithm to support fast 781 discovery of the most preferred available relay, by probing multiple 782 relays concurrently. 784 The parallel discovery logic of a Happy Eyeballs algorithm serves to 785 reduce join latency for the initial join of an SSM channel. This 786 section and the preference ordering of relays defined in 787 Section 3.1.2 taken together provide guidance on use of a Happy 788 Eyeballs algorithm for the case of establishing AMT connections. 790 Note that according to the definition in Section 3.2.3 of this 791 document, establishing the connection occurs before sending a 792 membership report. As described in Section 5 of [RFC8305], only one 793 of the successful connections will be used, and the others are all 794 canceled or ignored. In the context of an AMT connection, this means 795 the gateway will send the membership reports that subscribe to 796 traffic only for the chosen connection, after the Happy Eyeballs 797 algorithm resolves. 799 3.2.2. Algorithm Guidelines 801 During the "Initiation of asynchronous DNS queries" phase described 802 in Section 3 of [RFC8305]), a gateway attempts to resolve the domain 803 names listed in Section 3.1. This consists of resolving the SRV 804 queries for DNS-SD domains for the AMT service, as well as the 805 AMTRELAY query for the reverse IP domain defined in this document. 807 Each of the SRV and AMTRELAY responses might contain one or more IP 808 addresses, (as with type 1 or type 2 AMTRELAY responses, or when the 809 SRV Additional Data section of the SRV response contains the address 810 records for the target, as urged by [RFC2782]), or they might contain 811 only domain names (as with type 3 responses from Section 4.2.3, or an 812 SRV response without an additional data section). 814 When present, IP addresses in the initial response provide resolved 815 destination address candidates for the "Sorting of resolved 816 destination addresses" phase described in Section 4 of [RFC8305]), 817 whereas domain names without IP addresses in the initial response 818 result in another set of queries for AAAA and A records, whose 819 responses provide the candidate resolved destination addresses. 821 Since the SRV or AMTRELAY responses don't have a bound on the count 822 of queries that might be generated aside from the bounds imposed by 823 the DNS resolver, it's important for the gateway to provide a rate 824 limit on the DNS queries. The DNS query functionality is expected to 825 follow ordinary standards and best practices for DNS clients. A 826 gateway MAY use an existing DNS client implementation that does so, 827 and MAY rely on that client's rate limiting logic to avoid issuing 828 excessive queries. Otherwise, a gateway MUST provide a rate limit 829 for the DNS queries, and its default settings SHOULD NOT permit more 830 than 10 queries for any 100-millisecond period (though this MAY be 831 overridable by administrative configuration). 833 As the resolved IP addresses arrive, the Happy Eyeballs algorithm 834 sorts them according to the requirements and recommendations given in 835 Section 3.1.2, and attempts connections with the corresponding relays 836 under the algorithm restrictions and guidelines given in [RFC8305] 837 for the "Establishment of one connection, which cancels all other 838 attempts" phase. As described in Section 3 of [RFC8305], DNS 839 resolution is treated as asynchronous, and connection initiation does 840 not wait for lagging DNS responses. 842 3.2.3. Connection Definition 844 Section 5 of [RFC8305] non-normatively describes success at a 845 connection attempt as "generally when the TCP handshake completes". 847 There is no normative definition of a connection in the AMT 848 specification [RFC7450], and there is no TCP connection involved in 849 an AMT tunnel. 851 However, the concept of an AMT connection in the context of a Happy 852 Eyeballs algorithm is a useful one, and so this section provides the 853 following normative definition: 855 o An AMT connection is established successfully when the gateway 856 receives from a newly discovered relay a valid Membership Query 857 message (Section 5.1.4 of [RFC7450]) that does not have the L flag 858 set. 860 See Section 3.3.5 of this document for further information about the 861 relevance of the L flag to the establishment of a Happy Eyeballs 862 connection. See Section 3.3.4 for an overview of how to respond if 863 the connection does not provide multicast connectivity to the source. 865 To "cancel" this kind of AMT connection for the Happy Eyeballs 866 algorithm, a gateway that has not sent a membership report with a 867 subscription would simply stop sending AMT packets for that 868 connection. A gateway only sends a membership report to a connection 869 it has chosen as the most preferred available connection. 871 3.3. Guidelines for Restarting Discovery 873 3.3.1. Overview 875 It's expected that gateways deployed in different environments will 876 use a variety of heuristics to decide when it's appropriate to 877 restart the relay discovery process, in order to meet different 878 performance goals (for example, to fulfill different kinds of service 879 level agreements). 881 In general, restarting the discovery process is always safe for the 882 gateway and relay during any of the events listed in this section, 883 but may cause a disruption in the forwarded traffic if the discovery 884 process results in choosing a different relay, because this changes 885 the RPF forwarding tree for the multicast traffic upstream of the 886 gateway. This is likely to result in some dropped or duplicated 887 packets from channels actively being tunneled from the old relay to 888 the gateway. 890 The degree of impact on the traffic from choosing a different relay 891 may depend on network conditions between the gateway and the new 892 relay, as well as the network conditions and topology between the 893 sender and the new relay, as this may cause the relay to propagate a 894 new RPF join toward the sender. 896 Balancing the expected impact on the tunneled traffic against likely 897 or observed problems with an existing connection to the relay is the 898 goal of the heuristics that gateways use to determine when to restart 899 the discovery process. 901 The non-normative advice in this section should be treated as 902 guidelines to operators and implementors working with AMT systems 903 that can use DRIAD as part of the relay discovery process. 905 3.3.2. Updates to Restarting Events 907 Section 5.2.3.4.1 of [RFC7450] lists several events that may cause a 908 gateway to start or restart the discovery procedure. 910 This document provides some updates and recommendations regarding the 911 handling of these and similar events. The first 5 events are copied 912 here and numbered for easier reference, and the remaining 4 events 913 are newly added for consideration in this document: 915 1. When a gateway pseudo-interface is started (enabled). 917 2. When the gateway wishes to report a group subscription when none 918 currently exist. 920 3. Before sending the next Request message in a membership update 921 cycle. 923 4. After the gateway fails to receive a response to a Request 924 message. 926 5. After the gateway receives a Membership Query message with the L 927 flag set to 1. 929 6. When the gateway wishes to report an (S,G) subscription with a 930 source address that does not currently have other group 931 subscriptions. 933 7. When there is a network change detected, for example when a 934 gateway is operating inside an end user device or application, 935 and the device joins a different network, or when the domain 936 portion of a DNS-SD domain name changes in response to a DHCP 937 message or administrative configuration. 939 8. When substantial loss, persistent congestion, or network overload 940 is detected in the stream of AMT packets from a relay. 942 9. When the gateway has reported one or more (S,G) subscriptions, 943 but no traffic is received from the source for some timeout. 944 (See Section 3.3.4.1). 946 This list is not exhaustive, nor are any of the listed events 947 strictly required to always force a restart of the discovery process. 949 Note that during event #1, a gateway may use DNS-SD, but does not 950 have sufficient information to use DRIAD, since no source is known. 952 3.3.3. Tunnel Stability 954 In general, subscribers to active traffic flows that are being 955 forwarded by an AMT gateway are less likely to experience a 956 degradation in service (for example, from missing or duplicated 957 packets) when the gateway continues using the same relay, as long as 958 the relay is not overloaded and the network conditions remain stable. 960 Therefore, gateways SHOULD avoid performing a full restart of the 961 discovery process during routine cases of event #3 (sending a new 962 Request message), since it occurs frequently in normal operation. 964 However, see Section 3.3.4, Section 3.3.6, and Section 3.3.4.3 for 965 more information about exceptional cases when it may be appropriate 966 to use event #3. 968 3.3.4. Traffic Health 970 3.3.4.1. Absence of Traffic 972 If a gateway indicates one or more (S,G) subscriptions in a 973 Membership Update message, but no traffic for any of the (S,G)s is 974 received in a reasonable time, it's appropriate for the gateway to 975 restart the discovery process. 977 If the gateway restarts the discovery process multiple times 978 consecutively for this reason, the timeout period SHOULD be adjusted 979 to provide a random exponential back-off. 981 The RECOMMENDED timeout is a random value in the range 982 [initial_timeout, MIN(initial_timeout * 2^retry_count, 983 maximum_timeout)], with a RECOMMENDED initial_timeout of 4 seconds 984 and a RECOMMENDED maximum_timeout of 120 seconds (which is the 985 recommended minimum NAT mapping timeout described in [RFC4787]). 987 Note that the recommended initial_timeout is larger than the initial 988 timout recommended in the similar algorithm from Section 5.2.3.4.3 of 989 [RFC7450]. This is to provide time for RPF Join propagation in the 990 sending network. Although the timeout values may be administratively 991 adjusted to support performance requirements, operators are advised 992 to consider the possibility of join propagation delays between the 993 sender and the relay when choosing an appropriate timeout value. 995 Gateways restarting the discovery process because of an absence of 996 traffic MUST use a hold-down timer that removes this relay from 997 consideration during subsequent rounds of discovery while active. 998 The hold-down SHOULD last for no less than 3 minutes and no more than 999 10 minutes. 1001 3.3.4.2. Loss and Congestion 1003 In some gateway deployments, it is also feasible to monitor the 1004 health of traffic flows through the gateway, for example by detecting 1005 the rate of packet loss by communicating out of band with receivers, 1006 or monitoring the packets of known protocols with sequence numbers. 1007 Where feasible, it's encouraged for gateways to use such traffic 1008 health information to trigger a restart of the discovery process 1009 during event #3 (before sending a new Request message). 1011 However, to avoid synchronized rediscovery by many gateways 1012 simultaneously after a transient network event upstream of a relay 1013 results in many receivers detecting poor flow health at the same 1014 time, it's recommended to add a random delay before restarting the 1015 discovery process in this case. 1017 The span of the random portion of the delay should be no less than 10 1018 seconds by default, but may be administratively configured to support 1019 different performance requirements. 1021 3.3.4.3. Ancient Discovery Information 1023 In most cases, a gateway actively receiving healthy traffic from a 1024 relay that has not indicated load with the L flag should prefer to 1025 remain connected to the same relay, as described in Section 3.3.3. 1027 However, a relay that appears healthy but has been forwarding traffic 1028 for days or weeks may have an increased chance of becoming unstable. 1029 Gateways may benefit from restarting the discovery process during 1030 event #3 (before sending a Request message) after the expiration of a 1031 long-term timeout, on the order of multiple hours, or even days in 1032 some deployments. 1034 It may be beneficial for such timers to consider the amount of 1035 traffic currently being forwarded, and to give a higher probability 1036 of restarting discovery during periods with an unusually low data 1037 rate, to reduce the impact on active traffic while still avoiding 1038 relying on the results of a very old discovery. 1040 Other issues may also be worth considering as part of this heuristic; 1041 for example, if the DNS expiry time of the record that was used to 1042 discover the current relay has not passed, the long term timer might 1043 be restarted without restarting the discovery process. 1045 3.3.5. Relay Loaded or Shutting Down 1047 The L flag (see Section 5.1.4.4 of [RFC7450]) is the preferred 1048 mechanism for a relay to signal overloading or a graceful shutdown to 1049 gateways. 1051 A gateway that supports handling of the L flag should generally 1052 restart the discovery process when it processes a Membership Query 1053 packet with the L flag set. If an L flag is received while a 1054 concurrent Happy Eyeballs discovery process is under way for multiple 1055 candidate relays (Section 3.2), the relay sending the L flag SHOULD 1056 NOT be considered for the relay selection. 1058 It is also RECOMMENDED that gateways avoid choosing a relay that has 1059 recently sent an L flag, with approximately a 10-minute hold-down. 1060 Gateways SHOULD treat this hold-down timer in the same way as the 1061 hold-down in Section 3.3.4.1, so that the relay is removed from 1062 consideration for short-term subsequent rounds of discovery. 1064 3.3.6. Relay Discovery Messages vs. Restarting Discovery 1066 All AMT relays are required by [RFC7450] to support handling of Relay 1067 Discovery messages (e.g. in Section 5.3.3.2 of [RFC7450]). 1069 So a gateway with an existing connection to a relay can send a Relay 1070 Discovery message to the unicast address of that AMT relay. Under 1071 stable conditions with an unloaded relay, it's expected that the 1072 relay will return its own unicast address in the Relay Advertisement, 1073 in response to such a Relay Discovery message. Since this will not 1074 result in the gateway changing to another relay unless the relay 1075 directs the gateway away, this is a reasonable exception to the 1076 advice against handling event #3 described in Section 3.3.3. 1078 This behavior is discouraged for gateways that do support the L flag, 1079 to avoid sending unnecessary packets over the network. 1081 However, gateways that do not support the L flag may be able to avoid 1082 a disruption in the forwarded traffic by sending such Relay Discovery 1083 messages regularly. When a relay is under load or has started a 1084 graceful shutdown, it may respond with a different relay address, 1085 which the gateway can use to connect to a different relay. This kind 1086 of coordinated handoff will likely result in a smaller disruption to 1087 the traffic than if the relay simply stops responding to Request 1088 messages, and stops forwarding traffic. 1090 This style of Relay Discovery message (one sent to the unicast 1091 address of a relay that's already forwarding traffic to this gateway) 1092 SHOULD NOT be considered a full restart of the relay discovery 1093 process. It is RECOMMENDED for gateways to support the L flag, but 1094 for gateways that do not support the L flag, sending this message 1095 during event #3 may help mitigate service degradation when relays 1096 become unstable. 1098 3.3.7. Independent Discovery Per Traffic Source 1100 Relays discovered via the AMTRELAY RR are source-specific relay 1101 addresses, and may use different pseudo-interfaces from each other 1102 and from relays discovered via DNS-SD or a non-source-specific 1103 address, as described in Section 4.1.2.1 of [RFC7450]. 1105 Restarting the discovery process for one pseudo-interface does not 1106 require restarting the discovery process for other pseudo-interfaces. 1107 Gateway heuristics about restarting the discovery process should 1108 operate independently for different tunnels to relays, when 1109 responding to events that are specific to the different tunnels. 1111 3.4. DNS Configuration 1113 Often an AMT gateway will only have access to the source and group IP 1114 addresses of the desired traffic, and will not know any other name 1115 for the source of the traffic. Because of this, typically the best 1116 way of looking up AMTRELAY RRs will be by using the source IP address 1117 as an index into one of the reverse mapping trees (in-addr.arpa for 1118 IPv4, as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, 1119 as described in Section 2.5 of [RFC3596]). 1121 Therefore, it is RECOMMENDED that AMTRELAY RRs be added to reverse IP 1122 zones as appropriate. AMTRELAY records MAY also appear in other 1123 zones, since this may be necessary to perform delegation from the 1124 reverse zones (see for example Section 5.2 of [RFC2317]), but the use 1125 case enabled by this document requires a reverse IP mapping for the 1126 source from an (S,G) in order to be useful to most AMT gateways. 1127 This document does not define semantics for the use of AMTRELAY 1128 records obtained in a way other than by a reverse IP lookup. 1130 When performing the AMTRELAY RR lookup, any CNAMEs or DNAMEs found 1131 MUST be followed. This is necessary to support zone delegation. 1132 Some examples outlining this need are described in [RFC2317]. 1134 See Section 4 and Section 4.3 for a detailed explanation of the 1135 contents for a DNS Zone file. 1137 3.5. Waiting for DNS resolution 1139 The DNS query functionality is expected to follow ordinary standards 1140 and best practices for DNS clients. A gateway MAY use an existing 1141 DNS client implementation that does so, and MAY rely on that client's 1142 retry logic to determine the timeouts between retries. 1144 Otherwise, a gateway MAY re-send a DNS query if it does not receive 1145 an appropriate DNS response within some timeout period. If the 1146 gateway retries multiple times, the timeout period SHOULD be adjusted 1147 to provide a random exponential back-off. 1149 As with the waiting process for the Relay Advertisement message from 1150 Section 5.2.3.4.3 of [RFC7450], the RECOMMENDED timeout is a random 1151 value in the range [initial_timeout, MIN(initial_timeout * 1152 2^retry_count, maximum_timeout)], with a RECOMMENDED initial_timeout 1153 of 1 second and a RECOMMENDED maximum_timeout of 120 seconds. 1155 4. AMTRELAY Resource Record Definition 1157 4.1. AMTRELAY RRType 1159 The AMTRELAY RRType has the mnemonic AMTRELAY and type code 260 1160 (decimal). 1162 The AMTRELAY RR is class independent. 1164 4.2. AMTRELAY RData Format 1166 The AMTRELAY RData consists of a 8-bit precedence field, a 1-bit 1167 "Discovery Optional" field, a 7-bit type field, and a variable length 1168 relay field. 1170 0 1 2 3 1171 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 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 | precedence |D| type | | 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1175 ~ relay ~ 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 4.2.1. RData Format - Precedence 1180 This is an 8-bit precedence for this record. It is interpreted in 1181 the same way as the PREFERENCE field described in Section 3.3.9 of 1182 [RFC1035]. 1184 Relays listed in AMTRELAY records with a lower value for precedence 1185 are to be attempted first. 1187 4.2.2. RData Format - Discovery Optional (D-bit) 1189 The D bit is a "Discovery Optional" flag. 1191 If the D bit is set to 0, a gateway using this RR MUST perform AMT 1192 relay discovery as described in Section 4.2.1.1 of [RFC7450], rather 1193 than directly sending an AMT Request message to the relay. 1195 That is, the gateway MUST receive an AMT Relay Advertisement message 1196 (Section 5.1.2 of [RFC7450]) for an address before sending an AMT 1197 Request message (Section 5.1.3 of [RFC7450]) to that address. Before 1198 receiving the Relay Advertisement message, this record has only 1199 indicated that the address can be used for AMT relay discovery, not 1200 for a Request message. This is necessary for devices that are not 1201 fully functional AMT relays, but rather load balancers or brokers, as 1202 mentioned in Section 4.2.1.1 of [RFC7450]. 1204 If the D bit is set to 1, the gateway MAY send an AMT Request message 1205 directly to the discovered relay address without first sending an AMT 1206 Discovery message. 1208 This bit should be set according to advice from the AMT relay 1209 operator. The D bit MUST be set to zero when no information is 1210 available from the AMT relay operator about its suitability. 1212 4.2.3. RData Format - Type 1214 The type field indicates the format of the information that is stored 1215 in the relay field. 1217 The following values are defined: 1219 o type = 0: The relay field is empty (0 bytes). 1221 o type = 1: The relay field contains a 4-octet IPv4 address. 1223 o type = 2: The relay field contains a 16-octet IPv6 address. 1225 o type = 3: The relay field contains a wire-encoded domain name. 1226 The wire-encoded format is self-describing, so the length is 1227 implicit. The domain name MUST NOT be compressed. (See 1228 Section 3.3 of [RFC1035] and Section 4 of [RFC3597].) 1230 RRs with an undefined value in the Type field SHOULD NOT be 1231 considered by receiving gateways for AMT relay discovery. 1233 4.2.4. RData Format - Relay 1235 The relay field is the address or domain name of the AMT relay. It 1236 is formatted according to the type field. 1238 When the type field is 0, the length of the relay field is 0, and it 1239 indicates that no AMT relay should be used for multicast traffic from 1240 this source. 1242 When the type field is 1, the length of the relay field is 4 octets, 1243 and a 32-bit IPv4 address is present. This is an IPv4 address as 1244 described in Section 3.4.1 of [RFC1035]. This is a 32-bit number in 1245 network byte order. 1247 When the type field is 2, the length of the relay field is 16 octets, 1248 and a 128-bit IPv6 address is present. This is an IPv6 address as 1249 described in Section 2.2 of [RFC3596]. This is a 128-bit number in 1250 network byte order. 1252 When the type field is 3, the relay field is a normal wire-encoded 1253 domain name, as described in Section 3.3 of [RFC1035]. Compression 1254 MUST NOT be used, for the reasons given in Section 4 of [RFC3597]. 1256 For a type 3 record, the D-bit and preference fields carry over to 1257 all A or AAAA records for the domain name. There is no difference in 1258 the result of the discovery process when it's obtained by type 1 or 1259 type 2 AMTRELAY records with identical D-bit and preference fields, 1260 vs. when the result is obtained by a type 3 AMTRELAY record that 1261 resolves to the same set of IPv4 and IPv6 addresses via A and AAAA 1262 lookups. 1264 4.3. AMTRELAY Record Presentation Format 1266 4.3.1. Representation of AMTRELAY RRs 1268 AMTRELAY RRs may appear in a zone data master file. The precedence, 1269 D-bit, relay type, and relay fields are REQUIRED. 1271 If the relay type field is 0, the relay field MUST be ".". 1273 The presentation for the record is as follows: 1275 IN AMTRELAY precedence D-bit type relay 1277 4.3.2. Examples 1279 In a DNS authoritative nameserver that understands the AMTRELAY type, 1280 the zone might contain a set of entries like this: 1282 $ORIGIN 100.51.198.in-addr.arpa. 1283 12 IN AMTRELAY 10 0 1 203.0.113.15 1284 12 IN AMTRELAY 10 0 2 2001:db8::15 1285 12 IN AMTRELAY 128 1 3 amtrelays.example.com. 1287 This configuration advertises an IPv4 discovery address, an IPv6 1288 discovery address, and a domain name for AMT relays which can receive 1289 traffic from the source 198.51.100.12. The IPv4 and IPv6 addresses 1290 are configured with a D-bit of 0 (meaning discovery is mandatory, as 1291 described in Section 4.2.2), and a precedence 10 (meaning they're 1292 preferred ahead of the last entry, which has precedence 128). 1294 For zone files in name servers that don't support the AMTRELAY RRType 1295 natively, it's possible to use the format for unknown RR types, as 1296 described in [RFC3597]. This approach would replace the AMTRELAY 1297 entries in the example above with the entries below: 1299 10 IN TYPE260 \# ( 1300 6 ; length 1301 0a ; precedence=10 1302 01 ; D=0, relay type=1, an IPv4 address 1303 cb00710f ) ; 203.0.113.15 1304 10 IN TYPE260 \# ( 1305 18 ; length 1306 0a ; precedence=10 1307 02 ; D=0, relay type=2, an IPv6 address 1308 20010db800000000000000000000000f ) ; 2001:db8::15 1309 10 IN TYPE260 \# ( 1310 24 ; length 1311 80 ; precedence=128 1312 83 ; D=1, relay type=3, a wire-encoded domain name 1313 09616d7472656c617973076578616d706c6503636f6d ) ; domain name 1315 See Appendix A for more details. 1317 5. IANA Considerations 1319 This document updates the IANA Registry for DNS Resource Record Types 1320 by assigning type 260 to the AMTRELAY record. 1322 This document creates a new registry named "AMTRELAY Resource Record 1323 Parameters", with a sub-registry for the "Relay Type Field". The 1324 initial values in the sub-registry are: 1326 +-------+---------------------------------------+ 1327 | Value | Description | 1328 +-------+---------------------------------------+ 1329 | 0 | No relay is present. | 1330 | 1 | A 4-byte IPv4 address is present | 1331 | 2 | A 16-byte IPv6 address is present | 1332 | 3 | A wire-encoded domain name is present | 1333 | 4-255 | Unassigned | 1334 +-------+---------------------------------------+ 1336 Values 0, 1, 2, and 3 are further explained in Section 4.2.3 and 1337 Section 4.2.4. Relay type numbers 4 through 255 can be assigned with 1338 a policy of Specification Required (as described in [RFC8126]). 1340 6. Security Considerations 1342 6.1. Use of AMT 1344 This document defines a mechanism that enables a more widespread and 1345 automated use of AMT, even without access to a multicast backbone. 1346 Operators of networks and applications that include a DRIAD-capable 1347 AMT gateway are advised to carefully consider the security 1348 considerations in Section 6 of [RFC7450]. 1350 AMT gateway operators also are encouraged to take appropriate steps 1351 to ensure the integrity of the data received via AMT, for example by 1352 the opportunistic use of IPSec [RFC4301] to secure traffic received 1353 from AMT relays, when IPSECKEY records [RFC4025] are available or 1354 when a trust relationship with the AMT relays can be otherwise 1355 established and secured. 1357 Note that AMT does not itself provide any integrity protection on 1358 Multicast Data packets (Section 5.1.6 of [RFC7450]), so absent 1359 protections like those mentioned above, even an off-path attacker who 1360 discovers the gateway IP, the relay IP, and the relay source port for 1361 an active AMT connection can inject multicast data packets for a 1362 joined (S,G) into the data stream if he can get data packets 1363 delivered to the gateway IP that spoof the relay as the source. 1365 6.2. Record-spoofing 1367 The AMTRELAY resource record contains information that SHOULD be 1368 communicated to the DNS client without being modified. The method 1369 used to ensure the result was unmodified is up to the client. 1371 There must be a trust relationship between the end consumer of this 1372 resource record and the DNS server. This relationship may be end-to- 1373 end DNSSEC validation, or a secure connection to a trusted DNS server 1374 that provides end-to-end safety, to prevent record-spoofing of the 1375 response from the trusted server. The connection to the trusted 1376 server can use any secure channel, such as with a TSIG [RFC2845] or 1377 SIG(0) [RFC2931] channel, a secure local channel on the host, DNS 1378 over TLS [RFC7858], DNS over HTTPS [RFC8484], or some other mechanism 1379 that provides authentication of the RR. 1381 If an AMT gateway accepts a maliciously crafted AMTRELAY record, the 1382 result could be a Denial of Service, or receivers processing 1383 multicast traffic from a source under the attacker's control. 1385 6.3. Congestion 1387 Multicast traffic, particularly interdomain multicast traffic, 1388 carries some congestion risks, as described in Section 4 of 1389 [RFC8085]. 1391 Application implementors and network operators that use AMT gateways 1392 are advised to take precautions including monitoring of application 1393 traffic behavior, traffic authentication at ingest, rate-limiting of 1394 multicast traffic, and the use of circuit-breaker techniques such as 1395 those described in Section 3.1.10 of [RFC8085] and similar 1396 protections at the network level, in order to ensure network health 1397 in the event of misconfiguration, poorly written applications that 1398 don't follow UDP congestion control principles, or deliberate attack. 1400 Section 4.1.4.2 of [RFC7450] and Section 6.1 of [RFC7450] provide 1401 some further considerations and advice about mitigating congestion 1402 risk. 1404 7. Acknowledgements 1406 This specification was inspired by the previous work of Doug Nortz, 1407 Robert Sayko, David Segelstein, and Percy Tarapore, presented in the 1408 MBONED working group at IETF 93. 1410 Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny 1411 Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, Ben Kaduk, Bill 1412 Atwood, Tim Chown, Christian Worm Mortensen, Warren Kumari, Dan 1413 Romanescu, Bernard Aboba, Carlos Pignataro, Niclas Comstedt, Mirja 1414 Kuehlewind, Henning Rogge, Eric Vyncke, Barry Lieba, Roman Danyliw, 1415 Alissa Cooper, Suresh Krishnan, Adam Roach, and Daniel Franke for 1416 their very helpful reviews and comments. 1418 8. References 1420 8.1. Normative References 1422 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1423 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1424 . 1426 [RFC1035] Mockapetris, P., "Domain names - implementation and 1427 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1428 November 1987, . 1430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1431 Requirement Levels", BCP 14, RFC 2119, 1432 DOI 10.17487/RFC2119, March 1997, 1433 . 1435 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1436 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 1437 . 1439 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1440 specifying the location of services (DNS SRV)", RFC 2782, 1441 DOI 10.17487/RFC2782, February 2000, 1442 . 1444 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1445 Thyagarajan, "Internet Group Management Protocol, Version 1446 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 1447 . 1449 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1450 "DNS Extensions to Support IP Version 6", STD 88, 1451 RFC 3596, DOI 10.17487/RFC3596, October 2003, 1452 . 1454 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 1455 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 1456 2003, . 1458 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1459 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1460 DOI 10.17487/RFC3810, June 2004, 1461 . 1463 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 1464 Group Management Protocol Version 3 (IGMPv3) and Multicast 1465 Listener Discovery Protocol Version 2 (MLDv2) for Source- 1466 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 1467 August 2006, . 1469 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1470 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 1471 . 1473 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 1474 "Default Address Selection for Internet Protocol Version 6 1475 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 1476 . 1478 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1479 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1480 . 1482 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 1483 DOI 10.17487/RFC7450, February 2015, 1484 . 1486 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1487 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1488 March 2017, . 1490 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1491 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1492 May 2017, . 1494 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 1495 Better Connectivity Using Concurrency", RFC 8305, 1496 DOI 10.17487/RFC8305, December 2017, 1497 . 1499 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1500 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1501 January 2019, . 1503 8.2. Informative References 1505 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 1506 ADDR.ARPA delegation", BCP 20, RFC 2317, 1507 DOI 10.17487/RFC2317, March 1998, 1508 . 1510 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 1511 Wellington, "Secret Key Transaction Authentication for DNS 1512 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 1513 . 1515 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 1516 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 1517 2000, . 1519 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1520 Jacobson, "RTP: A Transport Protocol for Real-Time 1521 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1522 July 2003, . 1524 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 1525 Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March 1526 2005, . 1528 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1529 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1530 December 2005, . 1532 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 1533 Translation (NAT) Behavioral Requirements for Unicast 1534 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 1535 2007, . 1537 [RFC5110] Savola, P., "Overview of the Internet Multicast Routing 1538 Architecture", RFC 5110, DOI 10.17487/RFC5110, January 1539 2008, . 1541 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 1542 "FLUTE - File Delivery over Unidirectional Transport", 1543 RFC 6726, DOI 10.17487/RFC6726, November 2012, 1544 . 1546 [RFC7359] Gont, F., "Layer 3 Virtual Private Network (VPN) Tunnel 1547 Traffic Leakages in Dual-Stack Hosts/Networks", RFC 7359, 1548 DOI 10.17487/RFC7359, August 2014, 1549 . 1551 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 1552 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 1553 Multicast - Sparse Mode (PIM-SM): Protocol Specification 1554 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 1555 2016, . 1557 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1558 and P. Hoffman, "Specification for DNS over Transport 1559 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1560 2016, . 1562 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1563 Writing an IANA Considerations Section in RFCs", BCP 26, 1564 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1565 . 1567 [RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T., 1568 Ed., and R. Krishnan, "Use of Multicast across Inter- 1569 domain Peering Points", BCP 213, RFC 8313, 1570 DOI 10.17487/RFC8313, January 2018, 1571 . 1573 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1574 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1575 . 1577 Appendix A. Unknown RRType construction 1579 In a DNS resolver that understands the AMTRELAY type, the zone file 1580 might contain this line: 1582 IN AMTRELAY 128 0 3 amtrelays.example.com. 1584 In order to translate this example to appear as an unknown RRType as 1585 defined in [RFC3597], one could run the following program: 1587 1588 $ cat translate.py 1589 #!/usr/bin/env python3 1590 import sys 1591 name=sys.argv[1] 1592 wire='' 1593 for dn in name.split('.'): 1594 if len(dn) > 0: 1595 wire += ('%02x' % len(dn)) 1596 wire += (''.join('%02x'%ord(x) for x in dn)) 1597 print(len(wire)//2) + 2 1598 print(wire) 1600 $ ./translate.py amtrelays.example.com 1601 24 1602 09616d7472656c617973076578616d706c6503636f6d 1603 1605 The length of the RData and the hex string for the domain name 1606 "amtrelays.example.com" are the outputs of this program. 1608 22 is the length of the wire-encoded domain name, so 2 was added to 1609 that value (1 for the precedence field and 1 for the combined D-bit 1610 and relay type fields) to get the full length 24 of the RData. For 1611 the 2 octets ahead of the domain name, we encode the precedence, 1612 D-bit, and relay type fields, as described in Section 4. 1614 This results in a zone file entry like this: 1616 IN TYPE260 \# ( 24 ; length 1617 80 ; precedence = 128 1618 03 ; D-bit=0, relay type=3 (wire-encoded domain name) 1619 09616d7472656c617973076578616d706c6503636f6d ) ; domain name 1621 Author's Address 1623 Jake Holland 1624 Akamai Technologies, Inc. 1625 150 Broadway 1626 Cambridge, MA 02144 1627 United States of America 1629 Email: jakeholland.net@gmail.com