idnits 2.17.1 draft-jholland-mboned-driad-amt-discovery-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with 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 (November 13, 2018) is 1984 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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 November 13, 2018 5 Expires: May 17, 2019 7 DNS Reverse IP AMT Discovery 8 draft-jholland-mboned-driad-amt-discovery-02 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 May 17, 2019. 38 Copyright Notice 40 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Background and Terminology . . . . . . . . . . . . . . . 3 57 1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4 58 2. Relay Discovery Operation . . . . . . . . . . . . . . . . . . 4 59 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Example Receiving Networks . . . . . . . . . . . . . . . 5 61 2.2.1. Tier 3 ISP . . . . . . . . . . . . . . . . . . . . . 5 62 2.2.2. Small Office . . . . . . . . . . . . . . . . . . . . 6 63 2.3. Example Sending Networks . . . . . . . . . . . . . . . . 9 64 2.3.1. Sender-controlled Relays . . . . . . . . . . . . . . 9 65 2.3.2. Provider-controlled Relays . . . . . . . . . . . . . 10 66 3. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 10 67 3.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 10 68 3.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 11 69 3.2.1. RData Format - Precedence . . . . . . . . . . . . . . 11 70 3.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 11 71 3.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 12 72 3.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 12 73 3.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 13 74 3.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 13 75 3.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 13 76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 5.1. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 5.2. Local Override . . . . . . . . . . . . . . . . . . . . . 14 80 5.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 14 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 84 7.2. Informative References . . . . . . . . . . . . . . . . . 16 85 Appendix A. Appendix A . . . . . . . . . . . . . . . . . . . . . 17 86 Appendix B. Appendix B . . . . . . . . . . . . . . . . . . . . . 18 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 89 1. Introduction 91 AMT (Automatic Multicast Tunneling) is defined in [RFC7450], and 92 provides a method to transport multicast traffic in a unicast tunnel, 93 in order to traverse non-multicast capable network segments. 95 Section 4.1.5 of [RFC7450] explains that relay selection might need 96 to be source dependent, since a relay must be able to receive 97 multicast traffic from the desired source in order to forward it. It 98 suggests DNS-based queries as a possible approach. This document 99 defines a DNS-based solution, as suggested there. This solution also 100 addresses the relay discovery issues in the "Disadvantages" lists in 101 Section 3.3 of [RFC8313] and Section 3.4 of [RFC8313]. 103 The goal is to enable multicast connectivity between separate 104 multicast-enabled networks when neither the sending nor the receiving 105 network is connected to a multicast-enabled backbone, without 106 requiring any peering arrangement between the networks. 108 1.1. Background and Terminology 110 The reader is assumed to be familiar with the basic DNS concepts 111 described in [RFC1034], [RFC1035], and the subsequent documents that 112 update them, particularly [RFC2181]. 114 The reader is also assumed to be familiar with the concepts and 115 terminology regarding source-specific multicast as described in 116 [RFC4607] and the usage of group management protocols for source- 117 specific multicast as described in [RFC4604]. 119 The reader should also be familiar with AMT, particularly the 120 terminology listed in Section 3.2 of [RFC7450] and Section 3.3 of 121 [RFC7450]. 123 It's especially helpful to recall that once an AMT tunnel is 124 established, the relay receives native multicast traffic and 125 encapsulates it into the unicast tunnel, and the gateway receives the 126 unicast tunnel traffic, unencapsulates it, and forwards it as native 127 multicast: 129 | 130 Multicast | 131 v 132 +-----------+ 133 | AMT relay | 134 +-----------+ 135 | 136 Unicast | 137 Tunnel | 138 v 139 +-------------+ 140 | AMT gateway | 141 +-------------+ 142 | 143 Multicast | 144 v 146 1.2. Requirements Notation 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 150 "OPTIONAL" in this document are to be interpreted as described in 151 [RFC2119] and [RFC8174] when, and only when, they appear in all 152 capitals, as shown here. 154 2. Relay Discovery Operation 156 2.1. Overview 158 The AMTRELAY resource record (RR) is used to publish the address or 159 host name of an AMT relay that can forward multicast traffic from a 160 particular source host. The owner of the RR is the sender of native 161 multicast traffic, and the RR provides the address or hostname of an 162 AMT relay that can receive traffic from it. 164 The primary use case for the AMTRELAY RR is when a router that can 165 act as an AMT gateway gets a signal indicating that a client in its 166 receiving network has joined a new source-specific multicast channel, 167 (hereafter called an (S,G), as defined in [RFC4607]), for example by 168 receiving a PIM-SM (S,G) join message as described in Section 4.5.2 169 of [RFC7761]. 171 When the source of a newly joined (S,G) is not reachable via a 172 multicast-enabled next hop, the AMT gateway can connect to an AMT 173 relay and propagate the join signal to that relay. The goal for 174 source-specific relay discovery in this situation is to ensure that 175 the AMT relay chosen is able to receive multicast traffic from the 176 given source. More detailed example use cases are provided in 177 Section 2.2 and Section 2.3, and other applicable examples appear in 178 Section 3.3 of [RFC8313], Section 3.4 of [RFC8313], and Section 3.5 179 of [RFC8313]. 181 Often an AMT gateway will only have access to the source and group IP 182 addresses of the desired traffic, and will not know any other name 183 for the source of the traffic. Because of this, typically the best 184 way of looking up AMTRELAY RRs will be by using the source IP address 185 as an index into one of the reverse mapping trees (in-addr.arpa for 186 IPv4, as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, 187 as described in Section 2.5 of [RFC3596]). 189 Therefore, it is RECOMMENDED that AMTRELAY RRs be added to reverse IP 190 zones as appropriate. AMTRELAY records MAY also appear in other 191 zones, but the primary intended use case requires a reverse IP 192 mapping for the source from an (S,G) in order to be useful to most 193 AMT gateways. 195 When the reverse IP mapping has no AMTRELAY RR but does have a PTR 196 record, the lookup is done in the fashion usual for PTR records. The 197 IP address' octets (IPv4) or nibbles (IPv6) are reversed and looked 198 up with the appropriate suffix. Any CNAMEs or DNAMEs found MUST be 199 followed, and finally the AMTRELAY RR is queried with the resulting 200 domain name. 202 2.2. Example Receiving Networks 204 2.2.1. Tier 3 ISP 206 One example of a receiving network is an ISP that offers multicast 207 ingest services to its subscribers, illustrated in Figure 1. 209 In the example network below, subscribers can join (S,G)s with MLDv2 210 or IGMPv3 as described in [RFC4604], and the AMT gateway in this ISP 211 can receive and forward multicast traffic from one of the example 212 sending networks in Section 2.3 by discovering the appropriate AMT 213 relays with a DNS lookup for the AMTRELAY RR with the reverse IP of 214 the source in the (S,G). 216 Internet 217 ^ ^ Multicast-enabled 218 | | Receiving Network 219 +------|------------|-------------------------+ 220 | | | | 221 | +--------+ +--------+ +=========+ | 222 | | Border |---| Border | | AMT | | 223 | | Router | | Router | | gateway | | 224 | +--------+ +--------+ +=========+ | 225 | | | | | 226 | +-----+------+-----------+--+ | 227 | | | | 228 | +-------------+ +-------------+ | 229 | | Agg Routers | .. | Agg Routers | | 230 | +-------------+ +-------------+ | 231 | / \ \ / \ | 232 | +---------------+ +---------------+ | 233 | |Access Systems | ....... |Access Systems | | 234 | |(CMTS/OLT/etc.)| |(CMTS/OLT/etc.)| | 235 | +---------------+ +---------------+ | 236 | | | | 237 +--------|------------------------|-----------+ 238 | | 239 +---+-+-+---+---+ +---+-+-+---+---+ 240 | | | | | | | | | | 241 /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ 242 |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| 244 Subscribers 246 Figure 1: Receiving ISP Example 248 2.2.2. Small Office 250 Another example receiving network is a small branch office that 251 regularly accesses some multicast content, illustrated in Figure 2. 253 This office has desktop devices that need to receive some multicast 254 traffic, so an AMT gateway runs on a LAN with these devices, to pull 255 traffic in through a non-multicast next-hop. 257 The office also hosts some mobile devices that have AMT gateway 258 instances embedded in apps, in order to receive multicast traffic 259 over their non-multicast wireless LAN. (Note that the "Legacy 260 Router" is a simplification that's meant to describe a variety of 261 possible conditions- for example it could be a device providing a 262 split-tunnel VPN as described in [RFC7359], deliberately excluding 263 multicast traffic for a VPN tunnel, rather than a device which is 264 incapable of multicast forwarding.) 266 Internet 267 (non-multicast) 268 ^ 269 | Office Network 270 +----------|----------------------------------+ 271 | | | 272 | +---------------+ (Wifi) Mobile apps | 273 | | Modem+ | Wifi | - - - - w/ embedded | 274 | | Router | AP | AMT gateways | 275 | +---------------+ | 276 | | | 277 | | | 278 | +----------------+ | 279 | | Legacy Router | | 280 | | (unicast) | | 281 | +----------------+ | 282 | / | \ | 283 | / | \ | 284 | +--------+ +--------+ +--------+=========+ | 285 | | Phones | | ConfRm | | Desks | AMT | | 286 | | subnet | | subnet | | subnet | gateway | | 287 | +--------+ +--------+ +--------+=========+ | 288 | | 289 +---------------------------------------------+ 291 Figure 2: Small Office (no multicast up) 293 By adding an AMT relay to this office network as in Figure 3, it's 294 possible to make use of multicast services from the example 295 multicast-capable ISP in Section 2.2.1. 297 Multicast-capable ISP 298 ^ 299 | Office Network 300 +----------|----------------------------------+ 301 | | | 302 | +---------------+ (Wifi) Mobile apps | 303 | | Modem+ | Wifi | - - - - w/ embedded | 304 | | Router | AP | AMT gateways | 305 | +---------------+ | 306 | | +=======+ | 307 | +---Wired LAN---| AMT | | 308 | | | relay | | 309 | +----------------+ +=======+ | 310 | | Legacy Router | | 311 | | (unicast) | | 312 | +----------------+ | 313 | / | \ | 314 | / | \ | 315 | +--------+ +--------+ +--------+=========+ | 316 | | Phones | | ConfRm | | Desks | AMT | | 317 | | subnet | | subnet | | subnet | gateway | | 318 | +--------+ +--------+ +--------+=========+ | 319 | | 320 +---------------------------------------------+ 322 Figure 3: Small Office Example 324 When multicast-capable networks are chained like this, with a network 325 like the one in Figure 3 receiving internet services from a 326 multicast-capable network like the one in Figure 1, it's important 327 for AMT gateways to reach the more local AMT relay, in order to avoid 328 accidentally replicating multicast traffic from a more distant AMT 329 relay, and failing to utilize the multicast transport capabilities of 330 the network in Figure 1. 332 For this reason, it's RECOMMENDED that AMT gateways by default 333 perform service discovery using DNS Service Discovery (DNS-SD) 334 [RFC6763] for _amt._udp. (with chosen as described 335 in Section 11 of [RFC6763]) and use the AMT relays discovered that 336 way in preference to AMT relays discoverable via the mechanism 337 defined in this document (DRIAD). 339 It's also RECOMMENDED that when the well-known anycast IP addresses 340 defined in Section 7 of [RFC7450] are suitable for discovering an AMT 341 relay that can forward traffic from the source, that a DNS record 342 with the AMTRELAY RRType be published for those IP addresses along 343 with any other appropriate AMTRELAY RRs to indicate the best relative 344 precedences for receiving the source traffic. 346 Accordingly, AMT gateways SHOULD by default discover the most- 347 preferred relay first by DNS-SD, then by DRIAD as described in this 348 document (in precedence order, as described in Section 3.2.1), then 349 with the anycast addresses defined in Section 7 of [RFC7450] (namely: 350 192.52.193.1 and 2001:3::1) if those IPs weren't listed in the 351 AMTRELAY RRs. This default behavior MAY be overridden by 352 administrative configuration where other behavior is more appropriate 353 for the network. 355 The discovery and connection process for multiple relays MAY operate 356 in parallel, but when forwarding multicast group membership 357 information from the AMT gateway, it SHOULD be provided to the most- 358 preferred relays first, falling back to less preferred relays only 359 after failing to receive traffic for an appropriate timeout, and only 360 after reporting a leave to any more- preferred connected relays that 361 have failed to subscribe to the traffic. It is RECOMMENDED that the 362 default timeout be no less than 3 seconds, but the value MAY be 363 overridden by administrative configuration, where known groups or 364 channels need a different timeout for successful application 365 performance. 367 2.3. Example Sending Networks 369 2.3.1. Sender-controlled Relays 371 When a sender network is also operating AMT relays to distribute 372 multicast traffic, as in Figure 4, each address could appear as an 373 AMTRELAY RR for the reverse IP of the sender, or one or more domain 374 names could appear in AMTRELAY RRs, and the AMT relay addresses can 375 be discovered by finding an A or AAAA record from those domain names. 377 Sender Network 378 +-----------------------------------+ 379 | | 380 | +--------+ +=======+ +=======+ | 381 | | Sender | | AMT | | AMT | | 382 | +--------+ | relay | | relay | | 383 | | +=======+ +=======+ | 384 | | | | | 385 | +-----+------+----------+ | 386 | | | 387 +-----------|-----------------------+ 388 v 389 Internet 390 (non-multicast) 392 Figure 4: Small Office Example 394 2.3.2. Provider-controlled Relays 396 When an ISP offers a service to transmit outbound multicast traffic 397 through a forwarding network, they might also offer AMT relays in 398 order to reach receivers without multicast connectivity to the 399 forwarding network, as in Figure 5. In this case it's RECOMMENDED 400 that a domain name for the AMT relays also be provided for use with 401 the discovery process defined in this document. 403 When the sender wishes to use the relays provided by the ISP for 404 forwarding multicast traffic, an AMTRELAY RR should be configured to 405 use the domain name provided by the ISP, to allow for address 406 reassignment of the relays without forcing the sender to reconfigure 407 the corresponding AMTRELAY RRs. 409 +--------+ 410 | Sender | 411 +---+----+ Multicast-enabled 412 | Sending Network 413 +-----------|-------------------------------+ 414 | v | 415 | +------------+ +=======+ +=======+ | 416 | | Agg Router | | AMT | | AMT | | 417 | +------------+ | relay | | relay | | 418 | | +=======+ +=======+ | 419 | | | | | 420 | +-----+------+--------+---------+ | 421 | | | | 422 | +--------+ +--------+ | 423 | | Border |---| Border | | 424 | | Router | | Router | | 425 | +--------+ +--------+ | 426 +-----|------------|------------------------+ 427 | | 428 v v 429 Internet 430 (non-multicast) 432 Figure 5: Sending ISP Example 434 3. AMTRELAY Resource Record Definition 436 3.1. AMTRELAY RRType 438 The AMTRELAY RRType has the mnemonic AMTRELAY and type code 68 439 (decimal). 441 3.2. AMTRELAY RData Format 443 The AMTRELAY RData consists of a 8-bit precedence field, a 1-bit 444 "Discovery Optional" field, a 7-bit type field, and a variable length 445 relay field. 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | precedence |D| type | | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 452 ~ relay ~ 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 3.2.1. RData Format - Precedence 457 This is an 8-bit precedence for this record. It is interpreted in 458 the same way as the PREFERENCE field described in Section 3.3.9 of 459 [RFC1035]. 461 Relays listed in AMTRELAY records with a lower value for precedence 462 are to be attempted first. 464 Where there is a tie in precedence, the default choice of relay MUST 465 be non-deterministic, to support load balancing. The AMT gateway 466 operator MAY override this default choice with explicit configuration 467 when it's necessary for administrative purposes. 469 For example, one network might prefer to tunnel IPv6 multicast 470 traffic over IPv6 AMT and IPv4 multicast traffic over IPv4 AMT to 471 avoid routeability problems in IPv6 from affecting IPv4 traffic and 472 vice versa, while another network might prefer to tunnel both kinds 473 of traffic over IPv6 to reduce the IPv4 space used by its AMT 474 gateways. In this example scenario or other cases where there is an 475 administrative preference that requires explicit configuration, a 476 receiving network MAY make systematically different precedence 477 choices among records with the same precedence value. 479 3.2.2. RData Format - Discovery Optional (D-bit) 481 The D bit is a "Discovery Optional" flag. 483 If the D bit is set to 0, a gateway using this RR MUST perform AMT 484 relay discovery as described in Section 4.2.1.1 of [RFC7450], rather 485 than directly sending an AMT request message to the relay. 487 That is, the gateway MUST receive an AMT relay advertisement message 488 (Section 5.1.2 of [RFC7450]) for an address before sending an AMT 489 request message (Section 5.1.3 of [RFC7450]) to that address. Before 490 receiving the relay advertisement message, this record has only 491 indicated that the address can be used for AMT relay discovery, not 492 for a request message. This is necessary for devices that are not 493 fully functional AMT relays, but rather load balancers or brokers, as 494 mentioned in Section 4.2.1.1 of [RFC7450]. 496 If the D bit is set to 1, the gateway MAY send an AMT request message 497 directly to the discovered relay address without first sending an AMT 498 discovery message. 500 This bit should be set according to advice from the AMT relay 501 operator. The D bit MUST be set to zero when no information is 502 available from the AMT relay operator about its suitability. 504 3.2.3. RData Format - Type 506 The type field indicates the format of the information that is stored 507 in the relay field. 509 The following values are defined: 511 o type = 0: 512 The relay field is empty (0 bytes). 514 o type = 1: 515 The relay field contains a 4-octet IPv4 address. 517 o type = 2: 518 The relay field contains a 16-octet IPv6 address. 520 o type = 3: 521 The relay field contains a wire-encoded domain name. The wire- 522 encoded format is self-describing, so the length is implicit. The 523 domain name MUST NOT be compressed. (See Section 3.3 of [RFC1035] 524 and Section 4 of [RFC3597].) 526 3.2.4. RData Format - Relay 528 The relay field is the address or domain name of the AMT relay. It 529 is formatted according to the type field. 531 When the type field is 0, the length of the relay field is 0, and it 532 indicates that no AMT relay should be used for multicast traffic from 533 this source. 535 When the type field is 1, the length of the relay field is 4 octets, 536 and a 32-bit IPv4 address is present. This is an IPv4 address as 537 described in Section 3.4.1 of [RFC1035]. This is a 32-bit number in 538 network byte order. 540 When the type field is 2, the length of the relay field is 16 octets, 541 and a 128-bit IPv6 address is present. This is an IPv6 address as 542 described in Section 2.2 of [RFC3596]. This is a 128-bit number in 543 network byte order. 545 When the type field is 3, the relay field is a normal wire-encoded 546 domain name, as described in Section 3.3 of [RFC1035]. Compression 547 MUST NOT be used, for the reasons given in Section 4 of [RFC3597]. 549 3.3. AMTRELAY Record Presentation Format 551 3.3.1. Representation of AMTRELAY RRs 553 AMTRELAY RRs may appear in a zone data master file. The precedence, 554 D-bit, relay type, and relay fields are REQUIRED. 556 If the relay type field is 0, the relay field MUST be ".". 558 The presentation for the record is as follows: 560 IN AMTRELAY precedence D-bit type relay 562 3.3.2. Examples 564 For zone files in resolvers that don't support the value natively, 565 it's possible as a transition path to use the format for unknown RR 566 types, as described in [RFC3597]. 568 IN AMTRELAY 128 0 3 amtrelays.example.com. 570 or (see Appendix B): 572 IN TYPE68 \# ( 24 ; length 573 80 ; precedence 574 83 ; D=1, relay type=3 575 616d7472656c6179732e6578616d706c652e636f6d2e ) ; relay 577 4. IANA Considerations 579 This document updates the IANA Registry for DNS Resource Record Types 580 by assigning type 68 to the AMTRELAY record. 582 [ To be removed (TBD): 583 Dear IANA, we request 68, since 68 is unassigned and easier to 584 remember than other valid numbers, because the AMT UDP port number 585 is 2268. 587 Registry URI: 588 https://www.iana.org/assignments/ 589 dns-parameters/dns-parameters.xhtml#dns-parameters-4 590 ] 592 This document creates a new IANA registry specific to the AMTRELAY 593 for the relay type field. 595 Values 0, 1, 2, and 3 are defined in Section 3.2.3. Relay type 596 numbers 4 through 255 can be assigned with a policy of Specification 597 Required (see [RFC8126]). 599 [TBD: should the relay type registry try to combine with the 600 gateway type from Section 2.3 of [RFC4025] and 601 Section 2.5 of [RFC4025]? They are semantically very similar. 602 https://www.ietf.org/assignments/ 603 ipseckey-rr-parameters/ipseckey-rr-parameters.xml 604 ] 606 5. Security Considerations 608 [TBD: these 3 are just the first few most obvious issues, with just 609 sketches of the problem. Explain better, and look for trickier issues.] 611 5.1. DNSSEC 613 If AMT is used to ingest multicast traffic, spoofing this record can 614 enable spoofed multicast traffic. 616 Depending on service model, spoofing the relay may also be an attempt 617 to steal services or induce extra charges. 619 5.2. Local Override 621 The local relays, while important for overall network performance, 622 can't be secured by DNSSEC. 624 5.3. Congestion 626 Multicast traffic, particularly interdomain multicast traffic, 627 carries some congestion risks, as described in Section 4 of 628 [RFC8085]. Network operators are advised to take precautions 629 including monitoring of application traffic behavior, traffic 630 authentication, and rate-limiting of multicast traffic, in order to 631 ensure network health. 633 6. Acknowledgements 635 This specification was inspired by the previous work of Doug Nortz, 636 Robert Sayko, David Segelstein, and Percy Tarapore, presented in the 637 MBONED working group at IETF 93. 639 Thanks also to Jeff Goldsmith for his helpful review and feedback. 641 7. References 643 7.1. Normative References 645 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 646 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 647 . 649 [RFC1035] Mockapetris, P., "Domain names - implementation and 650 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 651 November 1987, . 653 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 654 Requirement Levels", BCP 14, RFC 2119, 655 DOI 10.17487/RFC2119, March 1997, 656 . 658 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 659 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 660 . 662 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 663 "DNS Extensions to Support IP Version 6", STD 88, 664 RFC 3596, DOI 10.17487/RFC3596, October 2003, 665 . 667 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 668 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 669 2003, . 671 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 672 Group Management Protocol Version 3 (IGMPv3) and Multicast 673 Listener Discovery Protocol Version 2 (MLDv2) for Source- 674 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 675 August 2006, . 677 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 678 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 679 . 681 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 682 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 683 . 685 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 686 DOI 10.17487/RFC7450, February 2015, 687 . 689 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 690 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 691 March 2017, . 693 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 694 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 695 May 2017, . 697 7.2. Informative References 699 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 700 Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March 701 2005, . 703 [RFC5507] IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch, 704 Ed., "Design Choices When Expanding the DNS", RFC 5507, 705 DOI 10.17487/RFC5507, April 2009, 706 . 708 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 709 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 710 April 2013, . 712 [RFC7359] Gont, F., "Layer 3 Virtual Private Network (VPN) Tunnel 713 Traffic Leakages in Dual-Stack Hosts/Networks", RFC 7359, 714 DOI 10.17487/RFC7359, August 2014, 715 . 717 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 718 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 719 Multicast - Sparse Mode (PIM-SM): Protocol Specification 720 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 721 2016, . 723 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 724 Writing an IANA Considerations Section in RFCs", BCP 26, 725 RFC 8126, DOI 10.17487/RFC8126, June 2017, 726 . 728 [RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T., 729 Ed., and R. Krishnan, "Use of Multicast across Inter- 730 domain Peering Points", BCP 213, RFC 8313, 731 DOI 10.17487/RFC8313, January 2018, 732 . 734 Appendix A. Appendix A 736 This is the template for requesting a new RRType recommended in 737 Appendix A of [RFC6895]. 739 A. Submission Date: 741 B.1 Submission Type: 742 [x] New RRTYPE [ ] Modification to RRTYPE 743 B.2 Kind of RR: 744 [x] Data RR [ ] Meta-RR 746 C. Contact Information for submitter (will be publicly posted): 747 Name: Jake Holland 748 Email Address: jakeholland.net@gmail.com 749 International telephone number: +1-626-486-3706 750 Other contact handles: none 752 D. Motivation for the new RRTYPE application. 753 It provides a bootstrap so that AMT (RFC 7450) gateways can find the 754 specific AMT relays that can receive multicast traffic from a 755 known source, in order to signal multicast group membership and 756 receive multicast traffic over a unicast tunnel using AMT. 758 E. Description of the proposed RR type. 759 This description can be provided in-line in the template, as an 760 attachment, or with a publicly available URL. 761 https://datatracker.ietf.org/doc/ 762 draft-jholland-mboned-driad-amt-discovery 764 F. What existing RRTYPE or RRTYPEs come closest to filling that need 765 and why are they unsatisfactory? 766 Some similar concepts appear in IPSECKEY, as described in 767 Section 1.2 of [RFC4025]. The IPSECKEY RRType is unsatisfactory 768 because it refers to IPSec Keys instead of to AMT relays, but 769 the motivating considerations for using reverse IP and for 770 providing a precedence are similar--an AMT gateway often 771 has access to a source address for a multicast (S,G), but does 772 not have access to a domain name or a good relay address, without 773 administrative configuration. 775 Defining a format for a TXT record could serve the need for AMT 776 relay discovery semantics, but Section 5 of [RFC5507] provides a 777 compelling argument for requesting a new RRType instead. 779 G. What mnemonic is requested for the new RRTYPE (optional)? 780 AMTRELAY 782 H. Does the requested RRTYPE make use of any existing IANA registry 783 or require the creation of a new IANA subregistry in DNS 784 Parameters? 785 No. 787 I. Does the proposal require/expect any changes in DNS 788 servers/resolvers that prevent the new type from being processed 789 as an unknown RRTYPE (see RFC3597)? 790 No. 792 J. Comments: 793 None. 795 Appendix B. Appendix B 797 In a DNS resolver that understands the AMTRELAY type, the zone file 798 might contain this line: 800 IN AMTRELAY 128 0 3 amtrelays.example.com. 802 In order to translate this example to appear as an unknown RRType as 803 defined in [RFC3597], one could run the following program: 805 806 $ cat translate.py 807 #!/usr/bin/python3 808 import sys 809 name=sys.argv[1] 810 print(len(name)) 811 print(''.join('%02x'%ord(x) for x in name)) 813 $ ./translate.py amtrelays.example.com. 814 22 815 616d7472656c6179732e6578616d706c652e636f6d2e 816 817 The length and the hex string for the domain name 818 "amtrelays.example.com" are the outputs of this program, yielding a 819 length of 22 and the above hex string. 821 22 is the length of the domain name, so to this we add 2 (1 for the 822 precedence field and 1 for the combined D-bit and relay type fields) 823 to get the length of the unknown RData. 825 This results in a zone file line for an unknown resolver of: 827 IN TYPE68 \# ( 24 ; length 828 80 ; precedence 829 03 ; relay type=domain 830 616d7472656c6179732e6578616d706c652e636f6d2e ) ; relay 832 Author's Address 834 Jake Holland 835 Akamai Technologies, Inc. 836 150 Broadway 837 Cambridge, MA 02144 838 United States of America 840 Email: jakeholland.net@gmail.com