idnits 2.17.1 draft-jholland-mboned-driad-amt-discovery-03.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 -- The document date (January 13, 2019) is 1930 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 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 Intended status: Standards Track January 13, 2019 5 Expires: July 17, 2019 7 DNS Reverse IP AMT Discovery 8 draft-jholland-mboned-driad-amt-discovery-03 10 Abstract 12 This document defines a new DNS resource record (RR) used to 13 advertise addresses for Automatic Multicast Tunneling (AMT) relays 14 capable of receiving multicast traffic from the owner of the RR. The 15 new AMTRELAY RR makes possible a source-specific method for AMT 16 gateways to discover appropriate AMT relays, in order to ingest 17 traffic for source-specific multicast channels into multicast-capable 18 receiving networks when no multicast connectivity is directly 19 available between the sending and receiving networks. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 17, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2.1. Relays and Gateways . . . . . . . . . . . . . . . . . 3 59 1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 4 60 2. Relay Discovery Operation . . . . . . . . . . . . . . . . . . 5 61 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.2. Signaling and Discovery . . . . . . . . . . . . . . . . . 5 63 2.3. Optimal Relay Selection . . . . . . . . . . . . . . . . . 7 64 2.4. DNS Configuration . . . . . . . . . . . . . . . . . . . . 8 65 3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 9 66 3.1. Example Receiving Networks . . . . . . . . . . . . . . . 9 67 3.1.1. Tier 3 ISP . . . . . . . . . . . . . . . . . . . . . 9 68 3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 10 69 3.2. Example Sending Networks . . . . . . . . . . . . . . . . 13 70 3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 13 71 3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 14 72 4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 15 73 4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 15 74 4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 15 75 4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 16 76 4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 16 77 4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 17 78 4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 17 79 4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 17 80 4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 17 81 4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 18 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 84 6.1. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 19 85 6.2. Local Override . . . . . . . . . . . . . . . . . . . . . 19 86 6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 20 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 90 8.2. Informative References . . . . . . . . . . . . . . . . . 21 91 Appendix A. New RRType Request Form . . . . . . . . . . . . . . 23 92 Appendix B. Unknown RRType construction . . . . . . . . . . . . 24 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 95 1. Introduction 97 This document defines DNS Reverse IP AMT Discovery (DRIAD), a 98 mechanism for AMT gateways to discover AMT relays which are capable 99 of forwarding multicast traffic from a known source IP address. 101 AMT (Automatic Multicast Tunneling) is defined in [RFC7450], and 102 provides a method to transport multicast traffic over a unicast 103 tunnel, in order to traverse non-multicast-capable network segments. 105 Section 4.1.5 of [RFC7450] explains that relay selection might need 106 to depend on the source of the multicast traffic, since a relay must 107 be able to receive multicast traffic from the desired source in order 108 to forward it. 110 That section suggests DNS-based queries as a possible solution. 111 DRIAD is a DNS-based solution, as suggested there. This solution 112 also addresses the relay discovery issues in the "Disadvantages" 113 lists in Section 3.3 of [RFC8313] and Section 3.4 of [RFC8313]. 115 The goal for DRIAD is to enable multicast connectivity between 116 separate multicast-enabled networks when neither the sending nor the 117 receiving network is connected to a multicast-enabled backbone, 118 without pre-configuring any peering arrangement between the networks. 120 1.1. Background 122 The reader is assumed to be familiar with the basic DNS concepts 123 described in [RFC1034], [RFC1035], and the subsequent documents that 124 update them, particularly [RFC2181]. 126 The reader is also assumed to be familiar with the concepts and 127 terminology regarding source-specific multicast as described in 128 [RFC4607] and the use of IGMPv3 [RFC3376] and MLDv2 [RFC3810] for 129 group management of source-specific multicast channels, as described 130 in [RFC4604]. 132 The reader should also be familiar with AMT, particularly the 133 terminology listed in Section 3.2 of [RFC7450] and Section 3.3 of 134 [RFC7450]. 136 1.2. Terminology 138 1.2.1. Relays and Gateways 140 When reading this document, it's especially helpful to recall that 141 once an AMT tunnel is established, the relay receives native 142 multicast traffic and sends unicast tunnel-encapsulated traffic to 143 the gateway, and the gateway receives the tunnel-encapsulated 144 packets, decapsulates them, and forwards them as native multicast 145 packets, as illustrated in Figure 1. 147 Multicast +-----------+ Unicast +-------------+ Multicast 148 >---------> | AMT relay | >=======> | AMT gateway | >---------> 149 +-----------+ +-------------+ 151 Figure 1: AMT Tunnel Illustration 153 1.2.2. Definitions 155 +------------+------------------------------------------------------+ 156 | Term | Definition | 157 +------------+------------------------------------------------------+ 158 | (S,G) | A source-specific multicast channel, as described in | 159 | | [RFC4607]. A pair of IP addresses with a source host | 160 | | IP and destination group IP. | 161 | | | 162 | downstream | Further from the source of traffic. | 163 | | | 164 | FQDN | Fully Qualified Domain Name, as described in | 165 | | [RFC8499] | 166 | | | 167 | gateway | An AMT gateway, as described in [RFC7450] | 168 | | | 169 | relay | An AMT relay, as described in [RFC7450] | 170 | | | 171 | RPF | Reverse Path Forwarding, as described in [RFC5110] | 172 | | | 173 | RR | A DNS Resource Record, as described in [RFC1034] | 174 | | | 175 | RRType | A DNS Resource Record Type, as described in | 176 | | [RFC1034] | 177 | | | 178 | SSM | Source-specific multicast, as described in [RFC4607] | 179 | | | 180 | upstream | Closer to the source of traffic. | 181 +------------+------------------------------------------------------+ 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 185 "OPTIONAL" in this document are to be interpreted as described in 186 [RFC2119] and [RFC8174] when, and only when, they appear in all 187 capitals, as shown here. 189 2. Relay Discovery Operation 191 2.1. Overview 193 The AMTRELAY resource record (RR) defined in this document is used to 194 publish the IP address or domain name of an AMT relay that can 195 receive, encapsulate, and forward multicast traffic from a particular 196 sender. 198 The sender is the owner of the RR, and configures the RR so that it 199 contains the address or domain name of an AMT relay that can receive 200 multicast IP traffic from that sender. 202 This enables AMT gateways in remote networks to discover an AMT relay 203 that is capable of forwarding traffic from the sender. This in turn 204 enables those AMT gateways to receive the multicast traffic tunneled 205 over a unicast AMT tunnel from those relays, and then to pass the 206 multicast packets into networks or applications that are using the 207 gateway to subscribe to traffic from that sender. 209 This mechanism only works for source-specific multicast (SSM) 210 channels. The source address of the (S,G) is reversed and used as an 211 index into one of the reverse mapping trees (in-addr.arpa for IPv4, 212 as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, as 213 described in Section 2.5 of [RFC3596]). 215 Some detailed example use cases are provided in Section 3, and other 216 applicable example topologies appear in Section 3.3 of [RFC8313], 217 Section 3.4 of [RFC8313], and Section 3.5 of [RFC8313]. 219 2.2. Signaling and Discovery 221 This section describes a typical example of the end-to-end process 222 for signaling a receiver's join of a SSM channel that relies on an 223 AMTRELAY RR. 225 The example in Figure 2 contains 2 multicast-enabled networks that 226 are both connected to the internet with non-multicast-capable links, 227 and which have no direct association with each other. 229 A content provider operates a sender, which is a source of multicast 230 traffic inside a multicast-capable network. 232 An end user who is a customer of the content provider has a 233 multicast-capable internet service provider, which operates a 234 receiving network that uses an AMT gateway. The AMT gateway is 235 DRIAD-capable. 237 The content provider provides the user with a receiving application 238 that tries to subscribe to at least one (S,G). This receiving 239 application could for example be a file transfer system using FLUTE 240 [RFC6726] or a live video stream using RTP [RFC3550], or any other 241 application that might subscribe to a SSM channel. 243 +---------------+ 244 | Sender | 245 | | | 198.51.100.15 | 246 | | +---------------+ 247 |Data| | 248 |Flow| Multicast | 249 \| |/ Network | 250 \ / | 5: Propagate RPF for Join(S,G) 251 \ / +---------------+ 252 \/ | AMT Relay | 253 | 203.0.113.15 | 254 +---------------+ 255 | 4: Gateway connects to Relay, 256 sends Join(S,G) over tunnel 257 | 258 Unicast 259 Tunnel | 261 ^ | 3: --> DNS Query: type=AMTRELAY, 262 | / 15.100.51.198.in-addr.arpa. 263 | | / <-- Response: 264 Join/Leave +-------------+ AMTRELAY=203.0.113.15 265 Signals | AMT gateway | 266 | +-------------+ 267 | | 2: Propagate RPF for Join(S,G) 268 | Multicast | 269 Network | 270 | 1: Join(S=198.51.100.15, G) 271 +-------------+ 272 | Receiver | 273 | (end user) | 274 +-------------+ 276 Figure 2: DRIAD Messaging 278 In this simple example, the sender IP is 198.51.100.15, and the relay 279 IP is 203.0.113.15. 281 The content provider has previously configured the DNS zone that 282 contains the domain name "15.100.51.198.in-addr.arpa.", which is the 283 reverse lookup domain name for his sender. The zone file contains an 284 AMTRELAY RR with the Relay's IP address. (See Section 4.3 for 285 details about the AMTRELAY RR format and semantics.) 287 The sequence of events depicted in Figure 2 is as follows: 289 1. The end user starts the app, which issues a join to the (S,G): 290 (198.51.100.15, 232.252.0.2). 292 2. The join propagates with RPF through the multicast-enabled 293 network with PIM [RFC7761] or another multicast routing 294 mechanism, until the AMT gateway receives a signal to join the 295 (S,G). 297 3. The AMT gateway performs a reverse DNS lookup for the AMTRELAY 298 RRType, by sending an AMTRELAY RRType query for the FQDN 299 "15.100.51.198.in-addr.arpa.", using the reverse IP domain name 300 for the sender's source IP address (the S from the (S,G)), as 301 described in Section 3.5 of [RFC1035]. 303 The DNS resolver for the AMT gateway uses ordinary DNS recursive 304 resolution until it has the authoritative result that the content 305 provider configured, which informs the AMT gateway that the relay 306 address is 203.0.113.15. 308 4. The AMT gateway performs AMT handshakes with the AMT relay as 309 described in Section 4 of [RFC7450], then forwards a Membership 310 report to the relay indicating subscription to the (S,G). 312 5. The relay propagates the join through its network toward the 313 sender, then forwards the appropriate AMT-encapsulated traffic to 314 the gateway, which decapsulates and forwards it as native 315 multicast through its downstream network to the end user. 317 2.3. Optimal Relay Selection 319 The reverse source IP DNS query of an AMTRELAY RR is a good way for a 320 gateway to discover a relay that is known to the sender. 322 However, it is NOT necessarily a good way to discover the best relay 323 for that gateway to use, because the RR IP will only provide 324 information about relays known to the source. 326 If there is an upstream relay in a network that is more local to the 327 gateway and able to receive and forward multicast traffic from the 328 sender, that relay is better for the gateway to use, since more of 329 the network path uses native multicast, allowing more chances for 330 packet replication. But since that relay is not known to the sender, 331 it won't be advertised in the sender's reverse IP DNS record. An 332 example network with this scenario is outlined in Section 3.1.2. 334 It's only appropriate for an AMT gateway to discover an AMT relay by 335 querying an AMTRELAY RR owned by a sender when all of these 336 conditions are met: 338 1. The gateway needs to propagate a join of an (S,G) over AMT, 339 because in the gateway's network, no RPF next hop toward the 340 source can propagate a native multicast join of the (S,G); and 342 2. The gateway is not already connected to a relay that forwards 343 multicast traffic from the source of the (S,G); and 345 3. The gateway is not configured to use a particular IP address for 346 AMT discovery, or a relay discovered with that IP is not able to 347 forward traffic from the source of the (S,G); and 349 4. The gateway is not able to find an upstream AMT relay with DNS-SD 350 [RFC6763], using "_amt._udp" as the Service section of the 351 queries, or a relay discovered this way is not able to forward 352 traffic from the source of the (S,G) 354 When the above conditions are met, the gateway has no path within its 355 local network that can receive multicast traffic from the source IP 356 of the (S,G). 358 In this situation, the best way to find a relay that can forward the 359 required traffic is to use information that comes from the operator 360 of the sender. When the sender has configured the AMTRELAY RR 361 defined in this document, gateways can use the DRIAD mechanism 362 defined in this document to discover the relay information provided 363 by the sender. 365 2.4. DNS Configuration 367 Often an AMT gateway will only have access to the source and group IP 368 addresses of the desired traffic, and will not know any other name 369 for the source of the traffic. Because of this, typically the best 370 way of looking up AMTRELAY RRs will be by using the source IP address 371 as an index into one of the reverse mapping trees (in-addr.arpa for 372 IPv4, as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, 373 as described in Section 2.5 of [RFC3596]). 375 Therefore, it is RECOMMENDED that AMTRELAY RRs be added to reverse IP 376 zones as appropriate. AMTRELAY records MAY also appear in other 377 zones, but the primary intended use case requires a reverse IP 378 mapping for the source from an (S,G) in order to be useful to most 379 AMT gateways. 381 383 Please can a DNS expert review the following paragraph and perhaps 384 help construct an equivalent and more clear explanation? 386 I borrowed the language from https://tools.ietf.org/html/ 387 rfc4025#section-1.2, but I'm not actually sure what "the fashion 388 usual for PTR records" means, precisely... 390 PTR gives a domain name, and then we do what, an A/AAAA record 391 lookup, and then a AMTRELAY lookup on the final name that has a valid 392 A/AAAA after any CNAME/DNAME chain? - jake 2019-01-13 394 396 When the reverse IP mapping has no AMTRELAY RR but does have a PTR 397 record, the lookup is done in the fashion usual for PTR records. The 398 IP address' octets (IPv4) or nibbles (IPv6) are reversed and looked 399 up with the appropriate suffix. Any CNAMEs or DNAMEs found MUST be 400 followed, and finally the AMTRELAY RR is queried with the resulting 401 domain name. 403 See Section 4 and Section 4.3 for a detailed explanation of the 404 contents for a DNS Zone file. 406 3. Example Deployments 408 3.1. Example Receiving Networks 410 3.1.1. Tier 3 ISP 412 One example of a receiving network is an ISP that offers multicast 413 ingest services to its subscribers, illustrated in Figure 3. 415 In the example network below, subscribers can join (S,G)s with MLDv2 416 or IGMPv3 as described in [RFC4604], and the AMT gateway in this ISP 417 can receive and forward multicast traffic from one of the example 418 sending networks in Section 3.2 by discovering the appropriate AMT 419 relays with a DNS lookup for the AMTRELAY RR with the reverse IP of 420 the source in the (S,G). 422 Internet 423 ^ ^ Multicast-enabled 424 | | Receiving Network 425 +------|------------|-------------------------+ 426 | | | | 427 | +--------+ +--------+ +=========+ | 428 | | Border |---| Border | | AMT | | 429 | | Router | | Router | | gateway | | 430 | +--------+ +--------+ +=========+ | 431 | | | | | 432 | +-----+------+-----------+--+ | 433 | | | | 434 | +-------------+ +-------------+ | 435 | | Agg Routers | .. | Agg Routers | | 436 | +-------------+ +-------------+ | 437 | / \ \ / \ | 438 | +---------------+ +---------------+ | 439 | |Access Systems | ....... |Access Systems | | 440 | |(CMTS/OLT/etc.)| |(CMTS/OLT/etc.)| | 441 | +---------------+ +---------------+ | 442 | | | | 443 +--------|------------------------|-----------+ 444 | | 445 +---+-+-+---+---+ +---+-+-+---+---+ 446 | | | | | | | | | | 447 /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ 448 |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| 450 Subscribers 452 Figure 3: Receiving ISP Example 454 3.1.2. Small Office 456 Another example receiving network is a small branch office that 457 regularly accesses some multicast content, illustrated in Figure 4. 459 This office has desktop devices that need to receive some multicast 460 traffic, so an AMT gateway runs on a LAN with these devices, to pull 461 traffic in through a non-multicast next-hop. 463 The office also hosts some mobile devices that have AMT gateway 464 instances embedded inside apps, in order to receive multicast traffic 465 over their non-multicast wireless LAN. (Note that the "Legacy 466 Router" is a simplification that's meant to describe a variety of 467 possible conditions- for example it could be a device providing a 468 split-tunnel VPN as described in [RFC7359], deliberately excluding 469 multicast traffic for a VPN tunnel, rather than a device which is 470 incapable of multicast forwarding.) 472 Internet 473 (non-multicast) 474 ^ 475 | Office Network 476 +----------|----------------------------------+ 477 | | | 478 | +---------------+ (Wifi) Mobile apps | 479 | | Modem+ | Wifi | - - - - w/ embedded | 480 | | Router | AP | AMT gateways | 481 | +---------------+ | 482 | | | 483 | | | 484 | +----------------+ | 485 | | Legacy Router | | 486 | | (unicast) | | 487 | +----------------+ | 488 | / | \ | 489 | / | \ | 490 | +--------+ +--------+ +--------+=========+ | 491 | | Phones | | ConfRm | | Desks | AMT | | 492 | | subnet | | subnet | | subnet | gateway | | 493 | +--------+ +--------+ +--------+=========+ | 494 | | 495 +---------------------------------------------+ 497 Figure 4: Small Office (no multicast up) 499 By adding an AMT relay to this office network as in Figure 5, it's 500 possible to make use of multicast services from the example 501 multicast-capable ISP in Section 3.1.1. 503 Multicast-capable ISP 504 ^ 505 | Office Network 506 +----------|----------------------------------+ 507 | | | 508 | +---------------+ (Wifi) Mobile apps | 509 | | Modem+ | Wifi | - - - - w/ embedded | 510 | | Router | AP | AMT gateways | 511 | +---------------+ | 512 | | +=======+ | 513 | +---Wired LAN---| AMT | | 514 | | | relay | | 515 | +----------------+ +=======+ | 516 | | Legacy Router | | 517 | | (unicast) | | 518 | +----------------+ | 519 | / | \ | 520 | / | \ | 521 | +--------+ +--------+ +--------+=========+ | 522 | | Phones | | ConfRm | | Desks | AMT | | 523 | | subnet | | subnet | | subnet | gateway | | 524 | +--------+ +--------+ +--------+=========+ | 525 | | 526 +---------------------------------------------+ 528 Figure 5: Small Office Example 530 When multicast-capable networks are chained like this, with a network 531 like the one in Figure 5 receiving internet services from a 532 multicast-capable network like the one in Figure 3, it's important 533 for AMT gateways to reach the more local AMT relay, in order to avoid 534 accidentally tunneling multicast traffic from a more distant AMT 535 relay with unicast, and failing to utilize the multicast transport 536 capabilities of the network in Figure 3. 538 For this reason, it's RECOMMENDED that AMT gateways by default 539 perform service discovery using DNS Service Discovery (DNS-SD) 540 [RFC6763] for _amt._udp. (with chosen as described 541 in Section 11 of [RFC6763]) and use the AMT relays discovered that 542 way in preference to AMT relays discoverable via the mechanism 543 defined in this document (DRIAD). 545 It's also RECOMMENDED that when the well-known anycast IP addresses 546 defined in Section 7 of [RFC7450] are suitable for discovering an AMT 547 relay that can forward traffic from the source, that a DNS record 548 with the AMTRELAY RRType be published for those IP addresses along 549 with any other appropriate AMTRELAY RRs to indicate the best relative 550 precedences for receiving the source traffic. 552 Accordingly, AMT gateways SHOULD by default discover the most- 553 preferred relay first by DNS-SD, then by DRIAD as described in this 554 document (in precedence order, as described in Section 4.2.1), then 555 with the anycast addresses defined in Section 7 of [RFC7450] (namely: 556 192.52.193.1 and 2001:3::1) if those IPs weren't listed in the 557 AMTRELAY RRs. This default behavior MAY be overridden by 558 administrative configuration where other behavior is more appropriate 559 for the gateway within its network. 561 The discovery and connection process for multiple relays MAY operate 562 in parallel, but when forwarding multicast group membership reports 563 with new joins from an AMT gateway, membership reports SHOULD be 564 forwarded to the most-preferred relays first, falling back to less 565 preferred relays only after failing to receive traffic for an 566 appropriate timeout, and only after reporting a leave to any more- 567 preferred connected relays that have failed to subscribe to the 568 traffic. 570 It is RECOMMENDED that the default timeout be no less than 3 seconds, 571 but the value MAY be overridden by administrative configuration, 572 where known groups or channels need a different timeout for 573 successful application performance. 575 3.2. Example Sending Networks 577 3.2.1. Sender-controlled Relays 579 When a sender network is also operating AMT relays to distribute 580 multicast traffic, as in Figure 6, each address could appear as an 581 AMTRELAY RR for the reverse IP of the sender, or one or more domain 582 names could appear in AMTRELAY RRs, and the AMT relay addresses can 583 be discovered by finding an A or AAAA record from those domain names. 585 Sender Network 586 +-----------------------------------+ 587 | | 588 | +--------+ +=======+ +=======+ | 589 | | Sender | | AMT | | AMT | | 590 | +--------+ | relay | | relay | | 591 | | +=======+ +=======+ | 592 | | | | | 593 | +-----+------+----------+ | 594 | | | 595 +-----------|-----------------------+ 596 v 597 Internet 598 (non-multicast) 600 Figure 6: Small Office Example 602 3.2.2. Provider-controlled Relays 604 When an ISP offers a service to transmit outbound multicast traffic 605 through a forwarding network, it might also offer AMT relays in order 606 to reach receivers without multicast connectivity to the forwarding 607 network, as in Figure 7. In this case it's RECOMMENDED that the ISP 608 also provide a domain name for the AMT relays for use with the 609 discovery process defined in this document. 611 When the sender wishes to use the relays provided by the ISP for 612 forwarding multicast traffic, an AMTRELAY RR should be configured to 613 use the domain name provided by the ISP, to allow for address 614 reassignment of the relays without forcing the sender to reconfigure 615 the corresponding AMTRELAY RRs. 617 +--------+ 618 | Sender | 619 +---+----+ Multicast-enabled 620 | Sending Network 621 +-----------|-------------------------------+ 622 | v | 623 | +------------+ +=======+ +=======+ | 624 | | Agg Router | | AMT | | AMT | | 625 | +------------+ | relay | | relay | | 626 | | +=======+ +=======+ | 627 | | | | | 628 | +-----+------+--------+---------+ | 629 | | | | 630 | +--------+ +--------+ | 631 | | Border |---| Border | | 632 | | Router | | Router | | 633 | +--------+ +--------+ | 634 +-----|------------|------------------------+ 635 | | 636 v v 637 Internet 638 (non-multicast) 640 Figure 7: Sending ISP Example 642 4. AMTRELAY Resource Record Definition 644 4.1. AMTRELAY RRType 646 The AMTRELAY RRType has the mnemonic AMTRELAY and type code TBD1 647 (decimal). 649 4.2. AMTRELAY RData Format 651 The AMTRELAY RData consists of a 8-bit precedence field, a 1-bit 652 "Discovery Optional" field, a 7-bit type field, and a variable length 653 relay field. 655 0 1 2 3 656 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 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | precedence |D| type | | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 660 ~ relay ~ 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 4.2.1. RData Format - Precedence 665 This is an 8-bit precedence for this record. It is interpreted in 666 the same way as the PREFERENCE field described in Section 3.3.9 of 667 [RFC1035]. 669 Relays listed in AMTRELAY records with a lower value for precedence 670 are to be attempted first. 672 Where there is a tie in precedence, the default choice of relay MUST 673 be non-deterministic, to support load balancing. The AMT gateway 674 operator MAY override this default choice with explicit configuration 675 when it's necessary for administrative purposes. 677 For example, one network might prefer to tunnel IPv6 multicast 678 traffic over IPv6 AMT and IPv4 multicast traffic over IPv4 AMT to 679 avoid routeability problems in IPv6 from affecting IPv4 traffic and 680 vice versa, while another network might prefer to tunnel both kinds 681 of traffic over IPv6 to reduce the IPv4 space used by its AMT 682 gateways. In this example scenario or other cases where there is an 683 administrative preference that requires explicit configuration, a 684 receiving network MAY make systematically different precedence 685 choices among records with the same precedence value. 687 4.2.2. RData Format - Discovery Optional (D-bit) 689 The D bit is a "Discovery Optional" flag. 691 If the D bit is set to 0, a gateway using this RR MUST perform AMT 692 relay discovery as described in Section 4.2.1.1 of [RFC7450], rather 693 than directly sending an AMT request message to the relay. 695 That is, the gateway MUST receive an AMT relay advertisement message 696 (Section 5.1.2 of [RFC7450]) for an address before sending an AMT 697 request message (Section 5.1.3 of [RFC7450]) to that address. Before 698 receiving the relay advertisement message, this record has only 699 indicated that the address can be used for AMT relay discovery, not 700 for a request message. This is necessary for devices that are not 701 fully functional AMT relays, but rather load balancers or brokers, as 702 mentioned in Section 4.2.1.1 of [RFC7450]. 704 If the D bit is set to 1, the gateway MAY send an AMT request message 705 directly to the discovered relay address without first sending an AMT 706 discovery message. 708 This bit should be set according to advice from the AMT relay 709 operator. The D bit MUST be set to zero when no information is 710 available from the AMT relay operator about its suitability. 712 4.2.3. RData Format - Type 714 The type field indicates the format of the information that is stored 715 in the relay field. 717 The following values are defined: 719 o type = 0: The relay field is empty (0 bytes). 721 o type = 1: The relay field contains a 4-octet IPv4 address. 723 o type = 2: The relay field contains a 16-octet IPv6 address. 725 o type = 3: The relay field contains a wire-encoded domain name. 726 The wire-encoded format is self-describing, so the length is 727 implicit. The domain name MUST NOT be compressed. (See 728 Section 3.3 of [RFC1035] and Section 4 of [RFC3597].) 730 4.2.4. RData Format - Relay 732 The relay field is the address or domain name of the AMT relay. It 733 is formatted according to the type field. 735 When the type field is 0, the length of the relay field is 0, and it 736 indicates that no AMT relay should be used for multicast traffic from 737 this source. 739 When the type field is 1, the length of the relay field is 4 octets, 740 and a 32-bit IPv4 address is present. This is an IPv4 address as 741 described in Section 3.4.1 of [RFC1035]. This is a 32-bit number in 742 network byte order. 744 When the type field is 2, the length of the relay field is 16 octets, 745 and a 128-bit IPv6 address is present. This is an IPv6 address as 746 described in Section 2.2 of [RFC3596]. This is a 128-bit number in 747 network byte order. 749 When the type field is 3, the relay field is a normal wire-encoded 750 domain name, as described in Section 3.3 of [RFC1035]. Compression 751 MUST NOT be used, for the reasons given in Section 4 of [RFC3597]. 753 4.3. AMTRELAY Record Presentation Format 755 4.3.1. Representation of AMTRELAY RRs 757 AMTRELAY RRs may appear in a zone data master file. The precedence, 758 D-bit, relay type, and relay fields are REQUIRED. 760 If the relay type field is 0, the relay field MUST be ".". 762 The presentation for the record is as follows: 764 IN AMTRELAY precedence D-bit type relay 766 4.3.2. Examples 768 In a DNS resolver that understands the AMTRELAY type, the zone might 769 contain a set of entries like this: 771 $ORIGIN 100.51.198.in-addr.arpa. 772 10 IN AMTRELAY 10 0 1 203.0.113.15 773 10 IN AMTRELAY 10 0 2 2001:DB8::15 774 10 IN AMTRELAY 128 1 3 amtrelays.example.com. 776 This configuration advertises an IPv4 discovery address, an IPv6 777 discovery address, and a domain name for AMT relays which can receive 778 traffic from the source 198.51.100.10. The IPv4 and IPv6 addresses 779 are configured with a D-bit of 0 (meaning discovery is mandatory, as 780 described in Section 4.2.2), and a precedence 10 (meaning they're 781 preferred ahead of the last entry, which has precedence 128). 783 For zone files in resolvers that don't support the AMTRELAY RRType 784 natively, it's possible to use the format for unknown RR types, as 785 described in [RFC3597]. This approach would replace the AMTRELAY 786 entries in the example above with the entries below: 788 [To be removed (TBD): replace 65280 with the IANA-assigned value 789 TBD1, here and in Appendix B. ] 791 10 IN TYPE65280 \# ( 792 6 ; length 793 0a ; precedence=10 794 01 ; D=0, relay type=1, an IPv4 address 795 cb00710f ) ; 203.0.113.15 796 10 IN TYPE65280 \# ( 797 18 ; length 798 0a ; precedence=10 799 02 ; D=0, relay type=2, an IPv6 address 800 20010db800000000000000000000000f ) ; 2001:db8::15 801 10 IN TYPE65280 \# ( 802 24 ; length 803 80 ; precedence=128 804 83 ; D=1, relay type=3, a wire-encoded domain name 805 616d7472656c6179732e6578616d706c652e636f6d2e ) ; domain name 807 See Appendix B for more details. 809 5. IANA Considerations 811 This document updates the IANA Registry for DNS Resource Record Types 812 by assigning type TBD1 to the AMTRELAY record. 814 This document creates a new registry named "AMTRELAY Resource Record 815 Parameters", with a sub-registry for the "Relay Type Field". The 816 initial values in the sub-registry are: 818 +-------+---------------------------------------+ 819 | Value | Description | 820 +-------+---------------------------------------+ 821 | 0 | No relay is present. | 822 | 1 | A 4-byte IPv4 address is present | 823 | 2 | A 16-byte IPv6 address is present | 824 | 3 | A wire-encoded domain name is present | 825 | 4-255 | Unassigned | 826 +-------+---------------------------------------+ 828 Values 0, 1, 2, and 3 are further explained in Section 4.2.3 and 829 Section 4.2.4. Relay type numbers 4 through 255 can be assigned with 830 a policy of Specification Required (as described in [RFC8126]). 832 6. Security Considerations 834 [ TBD: these 3 are just the first few most obvious issues, with just 835 sketches of the problem. Explain better, and look for trickier 836 issues. ] 838 6.1. Record-spoofing 840 If AMT is used to ingest multicast traffic, providing a false 841 AMTRELAY record to a gateway using it for discovery can result in 842 Denial of Service, or artificial multicast traffic from a source 843 under an attacker's control. 845 Therefore, it is important to ensure that the AMTRELAY record is 846 authentic, with DNSSEC [RFC4033] or other operational safeguards that 847 can provide assurance of the authenticity of the record contents. 849 6.2. Local Override 851 The local relays, while important for overall network performance, 852 can't be secured by DNSSEC. 854 6.3. Congestion 856 Multicast traffic, particularly interdomain multicast traffic, 857 carries some congestion risks, as described in Section 4 of 858 [RFC8085]. Network operators are advised to take precautions 859 including monitoring of application traffic behavior, traffic 860 authentication, and rate-limiting of multicast traffic, in order to 861 ensure network health. 863 7. Acknowledgements 865 This specification was inspired by the previous work of Doug Nortz, 866 Robert Sayko, David Segelstein, and Percy Tarapore, presented in the 867 MBONED working group at IETF 93. 869 Thanks also to Jeff Goldsmith and Lenny Giuliano for helpful reviews 870 and feedback. 872 8. References 874 8.1. Normative References 876 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 877 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 878 . 880 [RFC1035] Mockapetris, P., "Domain names - implementation and 881 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 882 November 1987, . 884 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 885 Requirement Levels", BCP 14, RFC 2119, 886 DOI 10.17487/RFC2119, March 1997, 887 . 889 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 890 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 891 . 893 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 894 Thyagarajan, "Internet Group Management Protocol, Version 895 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 896 . 898 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 899 "DNS Extensions to Support IP Version 6", STD 88, 900 RFC 3596, DOI 10.17487/RFC3596, October 2003, 901 . 903 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 904 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 905 2003, . 907 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 908 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 909 DOI 10.17487/RFC3810, June 2004, 910 . 912 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 913 Group Management Protocol Version 3 (IGMPv3) and Multicast 914 Listener Discovery Protocol Version 2 (MLDv2) for Source- 915 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 916 August 2006, . 918 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 919 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 920 . 922 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 923 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 924 . 926 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 927 DOI 10.17487/RFC7450, February 2015, 928 . 930 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 931 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 932 March 2017, . 934 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 935 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 936 May 2017, . 938 8.2. Informative References 940 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 941 Jacobson, "RTP: A Transport Protocol for Real-Time 942 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 943 July 2003, . 945 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 946 Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March 947 2005, . 949 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 950 Rose, "DNS Security Introduction and Requirements", 951 RFC 4033, DOI 10.17487/RFC4033, March 2005, 952 . 954 [RFC5110] Savola, P., "Overview of the Internet Multicast Routing 955 Architecture", RFC 5110, DOI 10.17487/RFC5110, January 956 2008, . 958 [RFC5507] IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch, 959 Ed., "Design Choices When Expanding the DNS", RFC 5507, 960 DOI 10.17487/RFC5507, April 2009, 961 . 963 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 964 "FLUTE - File Delivery over Unidirectional Transport", 965 RFC 6726, DOI 10.17487/RFC6726, November 2012, 966 . 968 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 969 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 970 April 2013, . 972 [RFC7359] Gont, F., "Layer 3 Virtual Private Network (VPN) Tunnel 973 Traffic Leakages in Dual-Stack Hosts/Networks", RFC 7359, 974 DOI 10.17487/RFC7359, August 2014, 975 . 977 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 978 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 979 Multicast - Sparse Mode (PIM-SM): Protocol Specification 980 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 981 2016, . 983 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 984 Writing an IANA Considerations Section in RFCs", BCP 26, 985 RFC 8126, DOI 10.17487/RFC8126, June 2017, 986 . 988 [RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T., 989 Ed., and R. Krishnan, "Use of Multicast across Inter- 990 domain Peering Points", BCP 213, RFC 8313, 991 DOI 10.17487/RFC8313, January 2018, 992 . 994 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 995 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 996 January 2019, . 998 Appendix A. New RRType Request Form 1000 This is the template for requesting a new RRType recommended in 1001 Appendix A of [RFC6895]. 1003 A. Submission Date: 1005 B.1 Submission Type: 1006 [x] New RRTYPE [ ] Modification to RRTYPE 1007 B.2 Kind of RR: 1008 [x] Data RR [ ] Meta-RR 1010 C. Contact Information for submitter (will be publicly posted): 1011 Name: Jake Holland 1012 Email Address: jakeholland.net@gmail.com 1013 International telephone number: +1-626-486-3706 1014 Other contact handles: jholland@akamai.com 1016 D. Motivation for the new RRTYPE application. 1017 It provides a bootstrap so AMT (RFC 7450) gateways can discover 1018 an AMT relay that can receive multicast traffic from a specific source, 1019 in order to signal multicast group membership and receive multicast 1020 traffic over a unicast tunnel using AMT. 1022 E. Description of the proposed RR type. 1023 This description can be provided in-line in the template, as an 1024 attachment, or with a publicly available URL. 1025 Please see draft-jholland-mboned-driad-amt-discovery. 1027 F. What existing RRTYPE or RRTYPEs come closest to filling that need 1028 and why are they unsatisfactory? 1029 Some similar concepts appear in IPSECKEY, as described in 1030 Section 1.2 of [RFC4025]. The IPSECKEY RRType is unsatisfactory 1031 because it refers to IPSec Keys instead of to AMT relays, but 1032 the motivating considerations for using reverse IP and for 1033 providing a precedence are similar--an AMT gateway often 1034 has access to a source address for a multicast (S,G), but does 1035 not have access to a relay address that can receive multicast 1036 traffic from the source, without administrative configuration. 1038 Defining a format for a TXT record could serve the need for AMT 1039 relay discovery semantics, but Section 5 of [RFC5507] provides a 1040 compelling argument for requesting a new RRType instead. 1042 G. What mnemonic is requested for the new RRTYPE (optional)? 1043 AMTRELAY 1045 H. Does the requested RRTYPE make use of any existing IANA registry 1046 or require the creation of a new IANA subregistry in DNS 1047 Parameters? 1048 Yes, IANA is requested to create a subregistry named "AMT Relay 1049 Type Field" in a "AMTRELAY Resource Record Parameters" registry. 1050 The field values are defined in Section 4.2.3 and Section 4.2.4, 1051 and a summary table is given in Section 5. 1053 I. Does the proposal require/expect any changes in DNS 1054 servers/resolvers that prevent the new type from being processed 1055 as an unknown RRTYPE (see RFC3597)? 1056 No. 1058 J. Comments: 1059 It may be worth noting that the gateway type field from Section 2.3 of 1060 [RFC4025] and Section 2.5 of [RFC4025] is very similar to the 1061 Relay Type field in this request. I tentatively assume that trying to 1062 re-use that sub-registry is a worse idea than duplicating it, but I'll 1063 invite others to consider the question and voice an opinion, in case 1064 there is a different consensus. 1065 https://www.ietf.org/assignments/ 1066 ipseckey-rr-parameters/ipseckey-rr-parameters.xml 1068 Appendix B. Unknown RRType construction 1070 In a DNS resolver that understands the AMTRELAY type, the zone file 1071 might contain this line: 1073 IN AMTRELAY 128 0 3 amtrelays.example.com. 1075 In order to translate this example to appear as an unknown RRType as 1076 defined in [RFC3597], one could run the following program: 1078 1079 $ cat translate.py 1080 #!/usr/bin/python3 1081 import sys 1082 name=sys.argv[1] 1083 print(len(name)) 1084 print(''.join('%02x'%ord(x) for x in name)) 1086 $ ./translate.py amtrelays.example.com. 1087 22 1088 616d7472656c6179732e6578616d706c652e636f6d2e 1089 1091 The length and the hex string for the domain name 1092 "amtrelays.example.com." are the outputs of this program, yielding a 1093 length of 22 and the above hex string. 1095 22 is the length of the domain name, so to this we add 2 (1 for the 1096 precedence field and 1 for the combined D-bit and relay type fields) 1097 to get the full length of the RData. 1099 This results in a zone file entry like this: 1101 IN TYPE65280 \# ( 24 ; length 1102 80 ; precedence = 128 1103 03 ; D-bit=0, relay type=3 (wire-encoded domain name) 1104 616d7472656c6179732e6578616d706c652e636f6d2e ) ; domain name 1106 Author's Address 1108 Jake Holland 1109 Akamai Technologies, Inc. 1110 150 Broadway 1111 Cambridge, MA 02144 1112 United States of America 1114 Email: jakeholland.net@gmail.com