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