idnits 2.17.1 draft-ietf-mboned-driad-amt-discovery-00.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 2 instances 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 == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. 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 (January 25, 2019) is 1908 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 4 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) January 25, 2019 5 Intended status: Standards Track 6 Expires: July 29, 2019 8 DNS Reverse IP AMT Discovery 9 draft-ietf-mboned-driad-amt-discovery-00 11 Abstract 13 This document updates RFC 7450 (AMT) by extending the relay discovery 14 process to use a new DNS resource record for source-specific AMT 15 relay discovery when joining source-specific multicast channels. A 16 multicast sender configures a reverse IP DNS zone with the new 17 AMTRELAY RR (defined in this document) to advertise a set of relays 18 that can receive and forward multicast traffic from that sender 19 inside a unicast AMT tunnel, in order to transit non-multicast- 20 capable network segments. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 29, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.2.1. Relays and Gateways . . . . . . . . . . . . . . . . . 4 60 1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 4 61 2. Relay Discovery Operation . . . . . . . . . . . . . . . . . . 5 62 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2. Signaling and Discovery . . . . . . . . . . . . . . . . . 6 64 2.3. Optimal Relay Selection . . . . . . . . . . . . . . . . . 8 65 2.4. Guidelines for Restarting Discovery . . . . . . . . . . . 9 66 2.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 9 67 2.4.2. Tunnel Stability . . . . . . . . . . . . . . . . . . 11 68 2.4.3. Flow Health . . . . . . . . . . . . . . . . . . . . . 11 69 2.4.4. Relay Loading and Shutdown . . . . . . . . . . . . . 11 70 2.4.5. Relay Discovery Messages vs. Restarting Discovery . . 12 71 2.4.6. Connecting to Multiple Relays . . . . . . . . . . . . 13 72 2.5. DNS Configuration . . . . . . . . . . . . . . . . . . . . 13 73 2.6. Waiting for DNS resolution . . . . . . . . . . . . . . . 13 74 3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 14 75 3.1. Example Receiving Networks . . . . . . . . . . . . . . . 14 76 3.1.1. Tier 3 ISP . . . . . . . . . . . . . . . . . . . . . 14 77 3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 15 78 3.2. Example Sending Networks . . . . . . . . . . . . . . . . 18 79 3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 18 80 3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 19 81 4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 20 82 4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 20 83 4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 20 84 4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 21 85 4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 21 86 4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 22 87 4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 22 88 4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 22 89 4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 22 90 4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 23 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 93 6.1. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 24 94 6.2. Local Override . . . . . . . . . . . . . . . . . . . . . 24 95 6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 25 96 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 97 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 98 8.1. Normative References . . . . . . . . . . . . . . . . . . 25 99 8.2. Informative References . . . . . . . . . . . . . . . . . 26 100 Appendix A. New RRType Request Form . . . . . . . . . . . . . . 28 101 Appendix B. Unknown RRType construction . . . . . . . . . . . . 29 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 104 1. Introduction 106 This document defines DNS Reverse IP AMT Discovery (DRIAD), a 107 mechanism for AMT gateways to discover AMT relays which are capable 108 of forwarding multicast traffic from a known source IP address. 110 AMT (Automatic Multicast Tunneling) is defined in [RFC7450], and 111 provides a method to transport multicast traffic over a unicast 112 tunnel, in order to traverse non-multicast-capable network segments. 114 Section 4.1.5 of [RFC7450] explains that relay selection might need 115 to depend on the source of the multicast traffic, since a relay must 116 be able to receive multicast traffic from the desired source in order 117 to forward it. 119 That section suggests DNS-based queries as a possible solution. 120 DRIAD is a DNS-based solution, as suggested there. This solution 121 also addresses the relay discovery issues in the "Disadvantages" 122 lists in Section 3.3 of [RFC8313] and Section 3.4 of [RFC8313]. 124 The goal for DRIAD is to enable multicast connectivity between 125 separate multicast-enabled networks when neither the sending nor the 126 receiving network is connected to a multicast-enabled backbone, 127 without pre-configuring any peering arrangement between the networks. 129 This document updates Section 5.2.3.4 of [RFC7450] by adding a new 130 extension to the relay discovery procedure. 132 1.1. Background 134 The reader is assumed to be familiar with the basic DNS concepts 135 described in [RFC1034], [RFC1035], and the subsequent documents that 136 update them, particularly [RFC2181]. 138 The reader is also assumed to be familiar with the concepts and 139 terminology regarding source-specific multicast as described in 140 [RFC4607] and the use of IGMPv3 [RFC3376] and MLDv2 [RFC3810] for 141 group management of source-specific multicast channels, as described 142 in [RFC4604]. 144 The reader should also be familiar with AMT, particularly the 145 terminology listed in Section 3.2 of [RFC7450] and Section 3.3 of 146 [RFC7450]. 148 1.2. Terminology 150 1.2.1. Relays and Gateways 152 When reading this document, it's especially helpful to recall that 153 once an AMT tunnel is established, the relay receives native 154 multicast traffic and sends unicast tunnel-encapsulated traffic to 155 the gateway, and the gateway receives the tunnel-encapsulated 156 packets, decapsulates them, and forwards them as native multicast 157 packets, as illustrated in Figure 1. 159 Multicast +-----------+ Unicast +-------------+ Multicast 160 >---------> | AMT relay | >=======> | AMT gateway | >---------> 161 +-----------+ +-------------+ 163 Figure 1: AMT Tunnel Illustration 165 1.2.2. Definitions 166 +------------+------------------------------------------------------+ 167 | Term | Definition | 168 +------------+------------------------------------------------------+ 169 | (S,G) | A source-specific multicast channel, as described in | 170 | | [RFC4607]. A pair of IP addresses with a source host | 171 | | IP and destination group IP. | 172 | | | 173 | downstream | Further from the source of traffic. | 174 | | | 175 | FQDN | Fully Qualified Domain Name, as described in | 176 | | [RFC8499] | 177 | | | 178 | gateway | An AMT gateway, as described in [RFC7450] | 179 | | | 180 | L flag | The "Limit" flag described in Section 5.1.1.4 of | 181 | | [RFC7450] | 182 | | | 183 | relay | An AMT relay, as described in [RFC7450] | 184 | | | 185 | RPF | Reverse Path Forwarding, as described in [RFC5110] | 186 | | | 187 | RR | A DNS Resource Record, as described in [RFC1034] | 188 | | | 189 | RRType | A DNS Resource Record Type, as described in | 190 | | [RFC1034] | 191 | | | 192 | SSM | Source-specific multicast, as described in [RFC4607] | 193 | | | 194 | upstream | Closer to the source of traffic. | 195 +------------+------------------------------------------------------+ 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 199 "OPTIONAL" in this document are to be interpreted as described in 200 [RFC2119] and [RFC8174] when, and only when, they appear in all 201 capitals, as shown here. 203 2. Relay Discovery Operation 205 2.1. Overview 207 The AMTRELAY resource record (RR) defined in this document is used to 208 publish the IP address or domain name of an AMT relay that can 209 receive, encapsulate, and forward multicast traffic from a particular 210 sender. 212 The sender is the owner of the RR, and configures the RR so that it 213 contains the address or domain name of an AMT relay that can receive 214 multicast IP traffic from that sender. 216 This enables AMT gateways in remote networks to discover an AMT relay 217 that is capable of forwarding traffic from the sender. This in turn 218 enables those AMT gateways to receive the multicast traffic tunneled 219 over a unicast AMT tunnel from those relays, and then to pass the 220 multicast packets into networks or applications that are using the 221 gateway to subscribe to traffic from that sender. 223 This mechanism only works for source-specific multicast (SSM) 224 channels. The source address of the (S,G) is reversed and used as an 225 index into one of the reverse mapping trees (in-addr.arpa for IPv4, 226 as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, as 227 described in Section 2.5 of [RFC3596]). 229 This mechanism should be treated as an extension of the AMT relay 230 discovery procedure described in section 5.2.3.4 of [RFC7450]. A 231 gateway that supports this method of AMT relay discovery SHOULD use 232 this method whenever it's performing the relay discovery procedure, 233 and the source IP addresses for desired (S,G)s are known to the 234 gateway, and conditions match the requirements outlined in 235 Section 2.3. 237 Some detailed example use cases are provided in Section 3, and other 238 applicable example topologies appear in Section 3.3 of [RFC8313], 239 Section 3.4 of [RFC8313], and Section 3.5 of [RFC8313]. 241 2.2. Signaling and Discovery 243 This section describes a typical example of the end-to-end process 244 for signaling a receiver's join of a SSM channel that relies on an 245 AMTRELAY RR. 247 The example in Figure 2 contains 2 multicast-enabled networks that 248 are both connected to the internet with non-multicast-capable links, 249 and which have no direct association with each other. 251 A content provider operates a sender, which is a source of multicast 252 traffic inside a multicast-capable network. 254 An end user who is a customer of the content provider has a 255 multicast-capable internet service provider, which operates a 256 receiving network that uses an AMT gateway. The AMT gateway is 257 DRIAD-capable. 259 The content provider provides the user with a receiving application 260 that tries to subscribe to at least one (S,G). This receiving 261 application could for example be a file transfer system using FLUTE 262 [RFC6726] or a live video stream using RTP [RFC3550], or any other 263 application that might subscribe to a SSM channel. 265 +---------------+ 266 | Sender | 267 | | | 198.51.100.15 | 268 | | +---------------+ 269 |Data| | 270 |Flow| Multicast | 271 \| |/ Network | 272 \ / | 5: Propagate RPF for Join(S,G) 273 \ / +---------------+ 274 \/ | AMT Relay | 275 | 203.0.113.15 | 276 +---------------+ 277 | 4: Gateway connects to Relay, 278 sends Join(S,G) over tunnel 279 | 280 Unicast 281 Tunnel | 283 ^ | 3: --> DNS Query: type=AMTRELAY, 284 | / 15.100.51.198.in-addr.arpa. 285 | | / <-- Response: 286 Join/Leave +-------------+ AMTRELAY=203.0.113.15 287 Signals | AMT gateway | 288 | +-------------+ 289 | | 2: Propagate RPF for Join(S,G) 290 | Multicast | 291 Network | 292 | 1: Join(S=198.51.100.15, G) 293 +-------------+ 294 | Receiver | 295 | (end user) | 296 +-------------+ 298 Figure 2: DRIAD Messaging 300 In this simple example, the sender IP is 198.51.100.15, and the relay 301 IP is 203.0.113.15. 303 The content provider has previously configured the DNS zone that 304 contains the domain name "15.100.51.198.in-addr.arpa.", which is the 305 reverse lookup domain name for his sender. The zone file contains an 306 AMTRELAY RR with the Relay's IP address. (See Section 4.3 for 307 details about the AMTRELAY RR format and semantics.) 309 The sequence of events depicted in Figure 2 is as follows: 311 1. The end user starts the app, which issues a join to the (S,G): 312 (198.51.100.15, 232.252.0.2). 314 2. The join propagates with RPF through the multicast-enabled 315 network with PIM [RFC7761] or another multicast routing 316 mechanism, until the AMT gateway receives a signal to join the 317 (S,G). 319 3. The AMT gateway performs a reverse DNS lookup for the AMTRELAY 320 RRType, by sending an AMTRELAY RRType query for the FQDN 321 "15.100.51.198.in-addr.arpa.", using the reverse IP domain name 322 for the sender's source IP address (the S from the (S,G)), as 323 described in Section 3.5 of [RFC1035]. 325 The DNS resolver for the AMT gateway uses ordinary DNS recursive 326 resolution until it has the authoritative result that the content 327 provider configured, which informs the AMT gateway that the relay 328 address is 203.0.113.15. 330 4. The AMT gateway performs AMT handshakes with the AMT relay as 331 described in Section 4 of [RFC7450], then forwards a Membership 332 report to the relay indicating subscription to the (S,G). 334 5. The relay propagates the join through its network toward the 335 sender, then forwards the appropriate AMT-encapsulated traffic to 336 the gateway, which decapsulates and forwards it as native 337 multicast through its downstream network to the end user. 339 2.3. Optimal Relay Selection 341 The reverse source IP DNS query of an AMTRELAY RR is a good way for a 342 gateway to discover a relay that is known to the sender. 344 However, it is NOT necessarily a good way to discover the best relay 345 for that gateway to use, because the RR IP will only provide 346 information about relays known to the source. 348 If there is an upstream relay in a network that is topologically 349 closer to the gateway and able to receive and forward multicast 350 traffic from the sender, that relay is better for the gateway to use, 351 since more of the network path uses native multicast, allowing more 352 chances for packet replication. But since that relay is not known to 353 the sender, it won't be advertised in the sender's reverse IP DNS 354 record. An example network that illustrates this scenario is 355 outlined in Section 3.1.2. 357 It's only appropriate for an AMT gateway to discover an AMT relay by 358 querying an AMTRELAY RR owned by a sender when all of these 359 conditions are met: 361 1. The gateway needs to propagate a join of an (S,G) over AMT, 362 because in the gateway's network, no RPF next hop toward the 363 source can propagate a native multicast join of the (S,G); and 365 2. The gateway is not already connected to a relay that forwards 366 multicast traffic from the source of the (S,G); and 368 3. The gateway is not configured to use a particular IP address for 369 AMT discovery, or a relay discovered with that IP is not able to 370 forward traffic from the source of the (S,G); and 372 4. The gateway is not able to find an upstream AMT relay with DNS-SD 373 [RFC6763], using "_amt._udp" as the Service section of the 374 queries, or a relay discovered this way is not able to forward 375 traffic from the source of the (S,G) 377 When the above conditions are met, the gateway has no path within its 378 local network that can receive multicast traffic from the source IP 379 of the (S,G). 381 In this situation, the best way to find a relay that can forward the 382 required traffic is to use information that comes from the operator 383 of the sender. When the sender has configured the AMTRELAY RR 384 defined in this document, gateways can use the DRIAD mechanism 385 defined in this document to discover the relay information provided 386 by the sender. 388 2.4. Guidelines for Restarting Discovery 390 2.4.1. Overview 392 It's expected that gateways deployed in different environments will 393 use a variety of heuristics to decide when it's appropriate to 394 restart the relay discovery process, in order to meet different 395 performance goals (for example, to fulfill different kinds of service 396 level agreements). 398 The advice in this section should be treated as non-normative 399 guidelines to operators and implementors working with AMT systems 400 that can use DRIAD as part of the relay discovery process. 402 Section 5.2.3.4.1 of [RFC7450] lists several events that may cause a 403 gateway to start or restart the discovery procedure. 405 This document provides some updates and recommendations regarding the 406 handling of these and similar events. The events are copied here and 407 numbered for easier reference: 409 1. When a gateway pseudo-interface is started (enabled). 411 2. When the gateway wishes to report a group subscription when none 412 currently exist. 414 3. Before sending the next Request message in a membership update 415 cycle. 417 4. After the gateway fails to receive a response to a Request 418 message. 420 5. After the gateway receives a Membership Query message with the L 421 flag set to 1. 423 There are several new events that gateway heuristics may 424 appropriately use to restart the discovery process, including: 426 1. When the gateway wishes to report a (S,G) subscription with a 427 source address that does not currently have other group 428 subscriptions. 430 2. When the DNS TTL expires for an AMTRELAY RR or for a domain name 431 contained within the AMTRELAY RR. 433 3. When there is a network change detected, for example when a 434 gateway is operating inside an end user device or application, 435 and the device joins a different network, or when the domain 436 portion of a DNS-SD domain name changes in response to a DHCP 437 message or administrative configuration. 439 4. When loss or congestion is detected in the stream of AMT packets 440 from a relay. 442 This list is not exhaustive, nor are any of the listed events always 443 strictly required to force a restart of the discovery process. 445 Note that during event #1, a gateway may use DNS-SD, but does not 446 have sufficient information to use DRIAD, since no source is known. 448 2.4.2. Tunnel Stability 450 In general, subscribers to active traffic flows that are being 451 forwarded by an AMT gateway are less likely to experience a 452 degradation in service (for example, from missing or duplicated 453 packets) when the gateway continues using the same relay, as long the 454 relay is not overloaded and the network conditions remain stable. 456 Therefore, gateways should avoid performing a full restart of the 457 discovery process during routine cases of event #3 (sending a new 458 Request message), but see Section 2.4.3 and Section 2.4.5 for more 459 information about exceptions when it may be appropriate to use this 460 event. 462 Likewise, some operators might use a short DNS TTL expiration (event 463 #7) to allow for more responsive load balancing. If a gateway 464 frequently sees short DNS TTLs (for example, under approximately 15 465 minutes) for some sources, a helpful heuristic may be to avoid 466 restarting the discovery process for those sources, for example with 467 an exponential backoff, or a hold-down timer that depends on the 468 health or bit-rate of the active and subscribed traffic currently 469 being forwarded through the tunnel. 471 2.4.3. Flow Health 473 In some gateway deployments, it is feasible to monitor the health of 474 traffic flows through the gateway, for example by detecting the rate 475 of packet loss by communicating out of band with clients, or 476 monitoring packets of known protocols with sequence numbers. Where 477 feasible, it's encouraged for gateways to use such traffic health 478 information to trigger a restart of the discovery process during 479 event #3 (before sending a new Request message). 481 However, to avoid synchronized rediscovery by many gateways 482 simultaneously after a transient network event upstream of a relay 483 results in many receivers detecting poor flow health at the same 484 time, it's recommended to add a random delay before restarting the 485 discovery process in this case. 487 The span of the random portion of the delay should be no less than 10 488 seconds by default, but may be administratively configured to support 489 different performance requirements. 491 2.4.4. Relay Loading and Shutdown 493 The L flag (see Section 5.1.4.4 of [RFC7450] is the preferred 494 mechanism for a relay to signal overloading or a graceful shutdown to 495 gateways. 497 A gateway that supports handling of the L flag should generally 498 restart the discovery process when it processes a Membership Query 499 packet with the L flag set. It is also recommended that gateways 500 avoid choosing a relay that has recently sent an L flag, with 501 approximately a 10-minute hold-down. Gateways MAY use heuristics 502 such as this hold-down to override selection of a relay preferred by 503 the precedence field in the AMTRELAY RR (see Section 4.2.1). 505 2.4.5. Relay Discovery Messages vs. Restarting Discovery 507 A gateway should only send DNS queries with the AMTRELAY RRType or 508 the DNS-SD DNS queries for an AMT service as part of starting or 509 restarting the discovery process. 511 However, all AMT relays are required to support handling of Relay 512 Discovery messages (e.g. in Section 5.3.3.2 of [RFC7450]). 514 So a gateway with an existing connection to a relay can send a Relay 515 Discovery message to the unicast address of that AMT relay. Under 516 stable conditions with an unloaded relay, it's expected that the 517 relay will return its own unicast address in the Relay Advertisement, 518 in response to such a Relay Discovery message. Since this will not 519 result in the gateway changing to another relay unless the relay 520 directs the gateway away, this is a reasonable exception to the 521 advice against handling event #3 described in Section 2.4.2. 523 This behavior is discouraged for gateways that do support the L flag, 524 to avoid sending unnecessary packets over the network. 526 However, gateways that do not support the L flag may be able to avoid 527 a disruption in the forwarded traffic by sending such Relay Discovery 528 messages regularly. When a relay is under load or has started a 529 graceful shutdown, it may respond with a different relay address, 530 which the gateway can use to connect to a different relay. This kind 531 of coordinated handoff will likely result in a smaller disruption to 532 the traffic than if the relay simply stops responding to Request 533 messages, and stops forwarding traffic. 535 This style of Relay Discovery message (one sent to the unicast 536 address of a relay that's already forwarding traffic to this gateway) 537 should not be considered a full restart of the relay discovery 538 process. It is recommended for gateways to support the L flag, but 539 for gateways that do not support the L flag, sending this message 540 during event #3 may help mitigate service degradation when relays 541 become unstable. 543 2.4.6. Connecting to Multiple Relays 545 Relays discovered via the AMTRELAY RR are source-specific relay 546 addresses, and may use different pseudo-interfaces from each other 547 and from relays discovered via DNS-SD or a non-source-specific 548 address, as described in Section 4.1.2.1 of [RFC7450]. 550 Restarting the discovery process for one pseudo-interface does not 551 require restarting the discovery process for other pseudo-interfaces. 552 Gateway heuristics about restarting the discovery process should 553 operate independently for different tunnels to relays, when 554 responding to events that are specific to the different tunnels. 556 2.5. DNS Configuration 558 Often an AMT gateway will only have access to the source and group IP 559 addresses of the desired traffic, and will not know any other name 560 for the source of the traffic. Because of this, typically the best 561 way of looking up AMTRELAY RRs will be by using the source IP address 562 as an index into one of the reverse mapping trees (in-addr.arpa for 563 IPv4, as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, 564 as described in Section 2.5 of [RFC3596]). 566 Therefore, it is RECOMMENDED that AMTRELAY RRs be added to reverse IP 567 zones as appropriate. AMTRELAY records MAY also appear in other 568 zones, but the primary intended use case requires a reverse IP 569 mapping for the source from an (S,G) in order to be useful to most 570 AMT gateways. 572 When performing the AMTRELAY RR lookup, any CNAMEs or DNAMEs found 573 MUST be followed. This is necessary to support zone delegation. 574 Some examples outlining this need are described in [RFC2317]. 576 See Section 4 and Section 4.3 for a detailed explanation of the 577 contents for a DNS Zone file. 579 2.6. Waiting for DNS resolution 581 The DNS query functionality is expected to follow ordinary standards 582 and best practices for DNS clients. A gateway MAY use an existing 583 DNS client implementation that does so, and MAY rely on that client's 584 retry logic to determine the timeouts between retries. 586 Otherwise, a gateway MAY re-send a DNS query if it does not receive 587 an appropriate DNS response within some timeout period. If the 588 gateway retries multiple times, the timeout period SHOULD be adjusted 589 to provide a random exponential back-off. 591 As with the waiting process for the Relay Advertisement message from 592 Section 5.2.3.4.3 of [RFC7450], the RECOMMENDED timeout is a random 593 value in the range [initial_timeout, MIN(initial_timeout * 594 2^retry_count, maximum_timeout)], with a RECOMMENDED initial_timeout 595 of 1 second and a RECOMMENDED maximum_timeout of 120 seconds. 597 3. Example Deployments 599 3.1. Example Receiving Networks 601 3.1.1. Tier 3 ISP 603 One example of a receiving network is an ISP that offers multicast 604 ingest services to its subscribers, illustrated in Figure 3. 606 In the example network below, subscribers can join (S,G)s with MLDv2 607 or IGMPv3 as described in [RFC4604], and the AMT gateway in this ISP 608 can receive and forward multicast traffic from one of the example 609 sending networks in Section 3.2 by discovering the appropriate AMT 610 relays with a DNS lookup for the AMTRELAY RR with the reverse IP of 611 the source in the (S,G). 613 Internet 614 ^ ^ Multicast-enabled 615 | | Receiving Network 616 +------|------------|-------------------------+ 617 | | | | 618 | +--------+ +--------+ +=========+ | 619 | | Border |---| Border | | AMT | | 620 | | Router | | Router | | gateway | | 621 | +--------+ +--------+ +=========+ | 622 | | | | | 623 | +-----+------+-----------+--+ | 624 | | | | 625 | +-------------+ +-------------+ | 626 | | Agg Routers | .. | Agg Routers | | 627 | +-------------+ +-------------+ | 628 | / \ \ / \ | 629 | +---------------+ +---------------+ | 630 | |Access Systems | ....... |Access Systems | | 631 | |(CMTS/OLT/etc.)| |(CMTS/OLT/etc.)| | 632 | +---------------+ +---------------+ | 633 | | | | 634 +--------|------------------------|-----------+ 635 | | 636 +---+-+-+---+---+ +---+-+-+---+---+ 637 | | | | | | | | | | 638 /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ 639 |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| 641 Subscribers 643 Figure 3: Receiving ISP Example 645 3.1.2. Small Office 647 Another example receiving network is a small branch office that 648 regularly accesses some multicast content, illustrated in Figure 4. 650 This office has desktop devices that need to receive some multicast 651 traffic, so an AMT gateway runs on a LAN with these devices, to pull 652 traffic in through a non-multicast next-hop. 654 The office also hosts some mobile devices that have AMT gateway 655 instances embedded inside apps, in order to receive multicast traffic 656 over their non-multicast wireless LAN. (Note that the "Legacy 657 Router" is a simplification that's meant to describe a variety of 658 possible conditions- for example it could be a device providing a 659 split-tunnel VPN as described in [RFC7359], deliberately excluding 660 multicast traffic for a VPN tunnel, rather than a device which is 661 incapable of multicast forwarding.) 663 Internet 664 (non-multicast) 665 ^ 666 | Office Network 667 +----------|----------------------------------+ 668 | | | 669 | +---------------+ (Wifi) Mobile apps | 670 | | Modem+ | Wifi | - - - - w/ embedded | 671 | | Router | AP | AMT gateways | 672 | +---------------+ | 673 | | | 674 | | | 675 | +----------------+ | 676 | | Legacy Router | | 677 | | (unicast) | | 678 | +----------------+ | 679 | / | \ | 680 | / | \ | 681 | +--------+ +--------+ +--------+=========+ | 682 | | Phones | | ConfRm | | Desks | AMT | | 683 | | subnet | | subnet | | subnet | gateway | | 684 | +--------+ +--------+ +--------+=========+ | 685 | | 686 +---------------------------------------------+ 688 Figure 4: Small Office (no multicast up) 690 By adding an AMT relay to this office network as in Figure 5, it's 691 possible to make use of multicast services from the example 692 multicast-capable ISP in Section 3.1.1. 694 Multicast-capable ISP 695 ^ 696 | Office Network 697 +----------|----------------------------------+ 698 | | | 699 | +---------------+ (Wifi) Mobile apps | 700 | | Modem+ | Wifi | - - - - w/ embedded | 701 | | Router | AP | AMT gateways | 702 | +---------------+ | 703 | | +=======+ | 704 | +---Wired LAN---| AMT | | 705 | | | relay | | 706 | +----------------+ +=======+ | 707 | | Legacy Router | | 708 | | (unicast) | | 709 | +----------------+ | 710 | / | \ | 711 | / | \ | 712 | +--------+ +--------+ +--------+=========+ | 713 | | Phones | | ConfRm | | Desks | AMT | | 714 | | subnet | | subnet | | subnet | gateway | | 715 | +--------+ +--------+ +--------+=========+ | 716 | | 717 +---------------------------------------------+ 719 Figure 5: Small Office Example 721 When multicast-capable networks are chained like this, with a network 722 like the one in Figure 5 receiving internet services from a 723 multicast-capable network like the one in Figure 3, it's important 724 for AMT gateways to reach the more local AMT relay, in order to avoid 725 accidentally tunneling multicast traffic from a more distant AMT 726 relay with unicast, and failing to utilize the multicast transport 727 capabilities of the network in Figure 3. 729 For this reason, it's RECOMMENDED that AMT gateways by default 730 perform service discovery using DNS Service Discovery (DNS-SD) 731 [RFC6763] for _amt._udp. (with chosen as described 732 in Section 11 of [RFC6763]) and use the AMT relays discovered that 733 way in preference to AMT relays discoverable via the mechanism 734 defined in this document (DRIAD). 736 It's also RECOMMENDED that when the well-known anycast IP addresses 737 defined in Section 7 of [RFC7450] are suitable for discovering an AMT 738 relay that can forward traffic from the source, that a DNS record 739 with the AMTRELAY RRType be published for those IP addresses along 740 with any other appropriate AMTRELAY RRs to indicate the best relative 741 precedences for receiving the source traffic. 743 Accordingly, AMT gateways SHOULD by default discover the most- 744 preferred relay first by DNS-SD, then by DRIAD as described in this 745 document (in precedence order, as described in Section 4.2.1), then 746 with the anycast addresses defined in Section 7 of [RFC7450] (namely: 747 192.52.193.1 and 2001:3::1) if those IPs weren't listed in the 748 AMTRELAY RRs. This default behavior MAY be overridden by 749 administrative configuration where other behavior is more appropriate 750 for the gateway within its network. 752 The discovery and connection process for multiple relays MAY operate 753 in parallel, but when forwarding multicast group membership reports 754 with new joins from an AMT gateway, membership reports SHOULD be 755 forwarded to the most-preferred relays first, falling back to less 756 preferred relays only after failing to receive traffic for an 757 appropriate timeout, and only after reporting a leave to any more- 758 preferred connected relays that have failed to subscribe to the 759 traffic. 761 It is RECOMMENDED that the default timeout for receiving traffic be 762 no less than 3 seconds, but the value MAY be overridden by 763 administrative configuration, where known groups or channels need a 764 different timeout for successful application performance. 766 3.2. Example Sending Networks 768 3.2.1. Sender-controlled Relays 770 When a sender network is also operating AMT relays to distribute 771 multicast traffic, as in Figure 6, each address could appear as an 772 AMTRELAY RR for the reverse IP of the sender, or one or more domain 773 names could appear in AMTRELAY RRs, and the AMT relay addresses can 774 be discovered by finding an A or AAAA record from those domain names. 776 Sender Network 777 +-----------------------------------+ 778 | | 779 | +--------+ +=======+ +=======+ | 780 | | Sender | | AMT | | AMT | | 781 | +--------+ | relay | | relay | | 782 | | +=======+ +=======+ | 783 | | | | | 784 | +-----+------+----------+ | 785 | | | 786 +-----------|-----------------------+ 787 v 788 Internet 789 (non-multicast) 791 Figure 6: Small Office Example 793 3.2.2. Provider-controlled Relays 795 When an ISP offers a service to transmit outbound multicast traffic 796 through a forwarding network, it might also offer AMT relays in order 797 to reach receivers without multicast connectivity to the forwarding 798 network, as in Figure 7. In this case it's RECOMMENDED that the ISP 799 also provide a domain name for the AMT relays for use with the 800 discovery process defined in this document. 802 When the sender wishes to use the relays provided by the ISP for 803 forwarding multicast traffic, an AMTRELAY RR should be configured to 804 use the domain name provided by the ISP, to allow for address 805 reassignment of the relays without forcing the sender to reconfigure 806 the corresponding AMTRELAY RRs. 808 +--------+ 809 | Sender | 810 +---+----+ Multicast-enabled 811 | Sending Network 812 +-----------|-------------------------------+ 813 | v | 814 | +------------+ +=======+ +=======+ | 815 | | Agg Router | | AMT | | AMT | | 816 | +------------+ | relay | | relay | | 817 | | +=======+ +=======+ | 818 | | | | | 819 | +-----+------+--------+---------+ | 820 | | | | 821 | +--------+ +--------+ | 822 | | Border |---| Border | | 823 | | Router | | Router | | 824 | +--------+ +--------+ | 825 +-----|------------|------------------------+ 826 | | 827 v v 828 Internet 829 (non-multicast) 831 Figure 7: Sending ISP Example 833 4. AMTRELAY Resource Record Definition 835 4.1. AMTRELAY RRType 837 The AMTRELAY RRType has the mnemonic AMTRELAY and type code TBD1 838 (decimal). 840 4.2. AMTRELAY RData Format 842 The AMTRELAY RData consists of a 8-bit precedence field, a 1-bit 843 "Discovery Optional" field, a 7-bit type field, and a variable length 844 relay field. 846 0 1 2 3 847 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 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | precedence |D| type | | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 851 ~ relay ~ 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 4.2.1. RData Format - Precedence 856 This is an 8-bit precedence for this record. It is interpreted in 857 the same way as the PREFERENCE field described in Section 3.3.9 of 858 [RFC1035]. 860 Relays listed in AMTRELAY records with a lower value for precedence 861 are to be attempted first. 863 Where there is a tie in precedence, the default choice of relay MUST 864 be non-deterministic, to support load balancing. The AMT gateway 865 operator MAY override this default choice with explicit configuration 866 when it's necessary for administrative purposes. 868 For example, one network might prefer to tunnel IPv6 multicast 869 traffic over IPv6 AMT and IPv4 multicast traffic over IPv4 AMT to 870 avoid routeability problems in IPv6 from affecting IPv4 traffic and 871 vice versa, while another network might prefer to tunnel both kinds 872 of traffic over IPv6 to reduce the IPv4 space used by its AMT 873 gateways. In this example scenario or other cases where there is an 874 administrative preference that requires explicit configuration, a 875 receiving network MAY make systematically different precedence 876 choices among records with the same precedence value. 878 4.2.2. RData Format - Discovery Optional (D-bit) 880 The D bit is a "Discovery Optional" flag. 882 If the D bit is set to 0, a gateway using this RR MUST perform AMT 883 relay discovery as described in Section 4.2.1.1 of [RFC7450], rather 884 than directly sending an AMT request message to the relay. 886 That is, the gateway MUST receive an AMT relay advertisement message 887 (Section 5.1.2 of [RFC7450]) for an address before sending an AMT 888 request message (Section 5.1.3 of [RFC7450]) to that address. Before 889 receiving the relay advertisement message, this record has only 890 indicated that the address can be used for AMT relay discovery, not 891 for a request message. This is necessary for devices that are not 892 fully functional AMT relays, but rather load balancers or brokers, as 893 mentioned in Section 4.2.1.1 of [RFC7450]. 895 If the D bit is set to 1, the gateway MAY send an AMT request message 896 directly to the discovered relay address without first sending an AMT 897 discovery message. 899 This bit should be set according to advice from the AMT relay 900 operator. The D bit MUST be set to zero when no information is 901 available from the AMT relay operator about its suitability. 903 4.2.3. RData Format - Type 905 The type field indicates the format of the information that is stored 906 in the relay field. 908 The following values are defined: 910 o type = 0: The relay field is empty (0 bytes). 912 o type = 1: The relay field contains a 4-octet IPv4 address. 914 o type = 2: The relay field contains a 16-octet IPv6 address. 916 o type = 3: The relay field contains a wire-encoded domain name. 917 The wire-encoded format is self-describing, so the length is 918 implicit. The domain name MUST NOT be compressed. (See 919 Section 3.3 of [RFC1035] and Section 4 of [RFC3597].) 921 4.2.4. RData Format - Relay 923 The relay field is the address or domain name of the AMT relay. It 924 is formatted according to the type field. 926 When the type field is 0, the length of the relay field is 0, and it 927 indicates that no AMT relay should be used for multicast traffic from 928 this source. 930 When the type field is 1, the length of the relay field is 4 octets, 931 and a 32-bit IPv4 address is present. This is an IPv4 address as 932 described in Section 3.4.1 of [RFC1035]. This is a 32-bit number in 933 network byte order. 935 When the type field is 2, the length of the relay field is 16 octets, 936 and a 128-bit IPv6 address is present. This is an IPv6 address as 937 described in Section 2.2 of [RFC3596]. This is a 128-bit number in 938 network byte order. 940 When the type field is 3, the relay field is a normal wire-encoded 941 domain name, as described in Section 3.3 of [RFC1035]. Compression 942 MUST NOT be used, for the reasons given in Section 4 of [RFC3597]. 944 4.3. AMTRELAY Record Presentation Format 946 4.3.1. Representation of AMTRELAY RRs 948 AMTRELAY RRs may appear in a zone data master file. The precedence, 949 D-bit, relay type, and relay fields are REQUIRED. 951 If the relay type field is 0, the relay field MUST be ".". 953 The presentation for the record is as follows: 955 IN AMTRELAY precedence D-bit type relay 957 4.3.2. Examples 959 In a DNS authoritative nameserver that understands the AMTRELAY type, 960 the zone might contain a set of entries like this: 962 $ORIGIN 100.51.198.in-addr.arpa. 963 10 IN AMTRELAY 10 0 1 203.0.113.15 964 10 IN AMTRELAY 10 0 2 2001:DB8::15 965 10 IN AMTRELAY 128 1 3 amtrelays.example.com. 967 This configuration advertises an IPv4 discovery address, an IPv6 968 discovery address, and a domain name for AMT relays which can receive 969 traffic from the source 198.51.100.10. The IPv4 and IPv6 addresses 970 are configured with a D-bit of 0 (meaning discovery is mandatory, as 971 described in Section 4.2.2), and a precedence 10 (meaning they're 972 preferred ahead of the last entry, which has precedence 128). 974 For zone files in name servers that don't support the AMTRELAY RRType 975 natively, it's possible to use the format for unknown RR types, as 976 described in [RFC3597]. This approach would replace the AMTRELAY 977 entries in the example above with the entries below: 979 [To be removed (TBD): replace 65280 with the IANA-assigned value 980 TBD1, here and in Appendix B. ] 982 10 IN TYPE65280 \# ( 983 6 ; length 984 0a ; precedence=10 985 01 ; D=0, relay type=1, an IPv4 address 986 cb00710f ) ; 203.0.113.15 987 10 IN TYPE65280 \# ( 988 18 ; length 989 0a ; precedence=10 990 02 ; D=0, relay type=2, an IPv6 address 991 20010db800000000000000000000000f ) ; 2001:db8::15 992 10 IN TYPE65280 \# ( 993 24 ; length 994 80 ; precedence=128 995 83 ; D=1, relay type=3, a wire-encoded domain name 996 09616d7472656c617973076578616d706c6503636f6d ) ; domain name 998 See Appendix B for more details. 1000 5. IANA Considerations 1002 This document updates the IANA Registry for DNS Resource Record Types 1003 by assigning type TBD1 to the AMTRELAY record. 1005 This document creates a new registry named "AMTRELAY Resource Record 1006 Parameters", with a sub-registry for the "Relay Type Field". The 1007 initial values in the sub-registry are: 1009 +-------+---------------------------------------+ 1010 | Value | Description | 1011 +-------+---------------------------------------+ 1012 | 0 | No relay is present. | 1013 | 1 | A 4-byte IPv4 address is present | 1014 | 2 | A 16-byte IPv6 address is present | 1015 | 3 | A wire-encoded domain name is present | 1016 | 4-255 | Unassigned | 1017 +-------+---------------------------------------+ 1019 Values 0, 1, 2, and 3 are further explained in Section 4.2.3 and 1020 Section 4.2.4. Relay type numbers 4 through 255 can be assigned with 1021 a policy of Specification Required (as described in [RFC8126]). 1023 6. Security Considerations 1025 [ TBD: these 3 are just the first few most obvious issues, with just 1026 sketches of the problem. Explain better, and look for trickier 1027 issues. ] 1029 6.1. Record-spoofing 1031 If AMT is used to ingest multicast traffic, providing a false 1032 AMTRELAY record to a gateway using it for discovery can result in 1033 Denial of Service, or artificial multicast traffic from a source 1034 under an attacker's control. 1036 Therefore, it is important to ensure that the AMTRELAY record is 1037 authentic, with DNSSEC [RFC4033] or other operational safeguards that 1038 can provide assurance of the authenticity of the record contents. 1040 6.2. Local Override 1042 The local relays, while important for overall network performance, 1043 can't be secured by DNSSEC. 1045 6.3. Congestion 1047 Multicast traffic, particularly interdomain multicast traffic, 1048 carries some congestion risks, as described in Section 4 of 1049 [RFC8085]. Network operators are advised to take precautions 1050 including monitoring of application traffic behavior, traffic 1051 authentication, and rate-limiting of multicast traffic, in order to 1052 ensure network health. 1054 7. Acknowledgements 1056 This specification was inspired by the previous work of Doug Nortz, 1057 Robert Sayko, David Segelstein, and Percy Tarapore, presented in the 1058 MBONED working group at IETF 93. 1060 Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny 1061 Giuliano, and Mark Andrews for their very helpful comments. 1063 8. References 1065 8.1. Normative References 1067 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1068 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1069 . 1071 [RFC1035] Mockapetris, P., "Domain names - implementation and 1072 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1073 November 1987, . 1075 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1076 Requirement Levels", BCP 14, RFC 2119, 1077 DOI 10.17487/RFC2119, March 1997, 1078 . 1080 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1081 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 1082 . 1084 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1085 Thyagarajan, "Internet Group Management Protocol, Version 1086 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 1087 . 1089 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1090 "DNS Extensions to Support IP Version 6", STD 88, 1091 RFC 3596, DOI 10.17487/RFC3596, October 2003, 1092 . 1094 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 1095 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 1096 2003, . 1098 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1099 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1100 DOI 10.17487/RFC3810, June 2004, 1101 . 1103 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 1104 Group Management Protocol Version 3 (IGMPv3) and Multicast 1105 Listener Discovery Protocol Version 2 (MLDv2) for Source- 1106 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 1107 August 2006, . 1109 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1110 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 1111 . 1113 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1114 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1115 . 1117 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 1118 DOI 10.17487/RFC7450, February 2015, 1119 . 1121 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1122 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1123 March 2017, . 1125 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1126 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1127 May 2017, . 1129 8.2. Informative References 1131 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 1132 ADDR.ARPA delegation", BCP 20, RFC 2317, 1133 DOI 10.17487/RFC2317, March 1998, 1134 . 1136 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1137 Jacobson, "RTP: A Transport Protocol for Real-Time 1138 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1139 July 2003, . 1141 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 1142 Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March 1143 2005, . 1145 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1146 Rose, "DNS Security Introduction and Requirements", 1147 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1148 . 1150 [RFC5110] Savola, P., "Overview of the Internet Multicast Routing 1151 Architecture", RFC 5110, DOI 10.17487/RFC5110, January 1152 2008, . 1154 [RFC5507] IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch, 1155 Ed., "Design Choices When Expanding the DNS", RFC 5507, 1156 DOI 10.17487/RFC5507, April 2009, 1157 . 1159 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 1160 "FLUTE - File Delivery over Unidirectional Transport", 1161 RFC 6726, DOI 10.17487/RFC6726, November 2012, 1162 . 1164 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 1165 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 1166 April 2013, . 1168 [RFC7359] Gont, F., "Layer 3 Virtual Private Network (VPN) Tunnel 1169 Traffic Leakages in Dual-Stack Hosts/Networks", RFC 7359, 1170 DOI 10.17487/RFC7359, August 2014, 1171 . 1173 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 1174 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 1175 Multicast - Sparse Mode (PIM-SM): Protocol Specification 1176 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 1177 2016, . 1179 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1180 Writing an IANA Considerations Section in RFCs", BCP 26, 1181 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1182 . 1184 [RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T., 1185 Ed., and R. Krishnan, "Use of Multicast across Inter- 1186 domain Peering Points", BCP 213, RFC 8313, 1187 DOI 10.17487/RFC8313, January 2018, 1188 . 1190 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1191 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1192 January 2019, . 1194 Appendix A. New RRType Request Form 1196 This is the template for requesting a new RRType recommended in 1197 Appendix A of [RFC6895]. 1199 A. Submission Date: 1201 B.1 Submission Type: 1202 [x] New RRTYPE [ ] Modification to RRTYPE 1203 B.2 Kind of RR: 1204 [x] Data RR [ ] Meta-RR 1206 C. Contact Information for submitter (will be publicly posted): 1207 Name: Jake Holland 1208 Email Address: jakeholland.net@gmail.com 1209 International telephone number: +1-626-486-3706 1210 Other contact handles: jholland@akamai.com 1212 D. Motivation for the new RRTYPE application. 1213 It provides a bootstrap so AMT (RFC 7450) gateways can discover 1214 an AMT relay that can receive multicast traffic from a specific source, 1215 in order to signal multicast group membership and receive multicast 1216 traffic over a unicast tunnel using AMT. 1218 E. Description of the proposed RR type. 1219 This description can be provided in-line in the template, as an 1220 attachment, or with a publicly available URL. 1221 Please see draft-ietf-mboned-driad-amt-discovery. 1223 F. What existing RRTYPE or RRTYPEs come closest to filling that need 1224 and why are they unsatisfactory? 1225 Some similar concepts appear in IPSECKEY, as described in 1226 Section 1.2 of [RFC4025]. The IPSECKEY RRType is unsatisfactory 1227 because it refers to IPSec Keys instead of to AMT relays, but 1228 the motivating considerations for using reverse IP and for 1229 providing a precedence are similar--an AMT gateway often 1230 has access to a source address for a multicast (S,G), but does 1231 not have access to a relay address that can receive multicast 1232 traffic from the source, without administrative configuration. 1234 Defining a format for a TXT record could serve the need for AMT 1235 relay discovery semantics, but Section 5 of [RFC5507] provides a 1236 compelling argument for requesting a new RRType instead. 1238 G. What mnemonic is requested for the new RRTYPE (optional)? 1239 AMTRELAY 1241 H. Does the requested RRTYPE make use of any existing IANA registry 1242 or require the creation of a new IANA subregistry in DNS 1243 Parameters? 1244 Yes, IANA is requested to create a subregistry named "AMT Relay 1245 Type Field" in a "AMTRELAY Resource Record Parameters" registry. 1246 The field values are defined in Section 4.2.3 and Section 4.2.4, 1247 and a summary table is given in Section 5. 1249 I. Does the proposal require/expect any changes in DNS 1250 servers/resolvers that prevent the new type from being processed 1251 as an unknown RRTYPE (see RFC3597)? 1252 No. 1254 J. Comments: 1255 It may be worth noting that the gateway type field from Section 2.3 of 1256 [RFC4025] and Section 2.5 of [RFC4025] is very similar to the 1257 Relay Type field in this request. I tentatively assume that trying to 1258 re-use that sub-registry is a worse idea than duplicating it, but I'll 1259 invite others to consider the question and voice an opinion, in case 1260 there is a different consensus. 1261 https://www.ietf.org/assignments/ 1262 ipseckey-rr-parameters/ipseckey-rr-parameters.xml 1264 Appendix B. Unknown RRType construction 1266 In a DNS resolver that understands the AMTRELAY type, the zone file 1267 might contain this line: 1269 IN AMTRELAY 128 0 3 amtrelays.example.com. 1271 In order to translate this example to appear as an unknown RRType as 1272 defined in [RFC3597], one could run the following program: 1274 1275 $ cat translate.py 1276 #!/usr/bin/env python3 1277 import sys 1278 name=sys.argv[1] 1279 wire='' 1280 for dn in name.split('.'): 1281 if len(dn) > 0: 1282 wire += ('%02x' % len(dn)) 1283 wire += (''.join('%02x'%ord(x) for x in dn)) 1284 print(len(wire)//2) 1285 print(wire) 1287 $ ./translate.py amtrelays.example.com 1288 22 1289 09616d7472656c617973076578616d706c6503636f6d 1290 1292 The length and the hex string for the domain name 1293 "amtrelays.example.com" are the outputs of this program, yielding a 1294 length of 22 and the above hex string. 1296 22 is the length of the wire-encoded domain name, so to this we add 2 1297 (1 for the precedence field and 1 for the combined D-bit and relay 1298 type fields) to get the full length of the RData. 1300 This results in a zone file entry like this: 1302 IN TYPE65280 \# ( 24 ; length 1303 80 ; precedence = 128 1304 03 ; D-bit=0, relay type=3 (wire-encoded domain name) 1305 09616d7472656c617973076578616d706c6503636f6d ) ; domain name 1307 Author's Address 1309 Jake Holland 1310 Akamai Technologies, Inc. 1311 150 Broadway 1312 Cambridge, MA 02144 1313 United States of America 1315 Email: jakeholland.net@gmail.com