--- 1/draft-ietf-mboned-driad-amt-discovery-11.txt 2019-12-19 12:13:15.324958677 -0800 +++ 2/draft-ietf-mboned-driad-amt-discovery-12.txt 2019-12-19 12:13:15.400960622 -0800 @@ -1,19 +1,19 @@ Mboned J. Holland Internet-Draft Akamai Technologies, Inc. -Updates: 7450 (if approved) December 18, 2019 +Updates: 7450 (if approved) December 19, 2019 Intended status: Standards Track -Expires: June 20, 2020 +Expires: June 21, 2020 DNS Reverse IP AMT (Automatic Multicast Tunneling) Discovery - draft-ietf-mboned-driad-amt-discovery-11 + draft-ietf-mboned-driad-amt-discovery-12 Abstract This document updates RFC 7450 (Automatic Multicast Tunneling, or AMT) by modifying the relay discovery process. A new DNS resource record named AMTRELAY is defined for publishing AMT relays for source-specific multicast channels. The reverse IP DNS zone for a multicast sender's IP address is configured to use AMTRELAY resource records to advertise a set of AMT relays that can receive and forward multicast traffic from that sender over an AMT tunnel. Other @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on June 20, 2020. + This Internet-Draft will expire on June 21, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -72,47 +72,47 @@ 2.4.3. Connection Definition . . . . . . . . . . . . . . . . 14 2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 15 2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 15 2.5.2. Updates to Restarting Events . . . . . . . . . . . . 16 2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 17 2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 17 2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 19 2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 19 2.5.7. Independent Discovery Per Traffic Source . . . . . . 20 2.6. DNS Configuration . . . . . . . . . . . . . . . . . . . . 20 - 2.7. Waiting for DNS resolution . . . . . . . . . . . . . . . 20 + 2.7. Waiting for DNS resolution . . . . . . . . . . . . . . . 21 3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 21 3.1. Example Receiving Networks . . . . . . . . . . . . . . . 21 3.1.1. Internet Service Provider . . . . . . . . . . . . . . 21 3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 22 3.2. Example Sending Networks . . . . . . . . . . . . . . . . 24 3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 24 3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 25 4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 26 4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 26 4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 26 4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 27 4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 27 4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 27 4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 28 4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 28 4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 28 4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 29 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6.1. Use of AMT . . . . . . . . . . . . . . . . . . . . . . . 30 6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 30 6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 31 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 31 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 32 8.2. Informative References . . . . . . . . . . . . . . . . . 33 Appendix A. Unknown RRType construction . . . . . . . . . . . . 35 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction This document defines DNS Reverse IP AMT Discovery (DRIAD), a mechanism for AMT gateways to discover AMT relays that are capable of forwarding multicast traffic from a known source IP address. @@ -131,22 +131,22 @@ solution. DRIAD is a DNS-based solution, as suggested there. This solution also addresses the relay discovery issues in the "Disadvantages" lists in Section 3.3 of [RFC8313] and Section 3.4 of [RFC8313]. The goal for DRIAD is to enable multicast connectivity between separate multicast-enabled networks when neither the sending nor the receiving network is connected to a multicast-enabled backbone, without pre-configuring any peering arrangement between the networks. - This document updates Section 5.2.3.4 of [RFC7450] by adding a new - extension to the relay discovery procedure. + This document extends the relay discovery procedure described in + Section 5.2.3.4 of [RFC7450]. 1.1. Background The reader is assumed to be familiar with the basic DNS concepts described in [RFC1034], [RFC1035], and the subsequent documents that update them, particularly [RFC2181]. The reader is also assumed to be familiar with the concepts and terminology regarding source-specific multicast as described in [RFC4607] and the use of IGMPv3 [RFC3376] and MLDv2 [RFC3810] for @@ -186,21 +186,21 @@ | broker | as mentioned in section 4.2.1.1 of [RFC7450]. | | | | | downstream | Further from the source of traffic, as described in | | | [RFC7450]. | | | | | FQDN | Fully Qualified Domain Name, as described in | | | [RFC8499] | | | | | gateway | An AMT gateway, as described in [RFC7450] | | | | - | L flag | The "Limit" flag described in Section 5.1.1.4 of | + | L flag | The "Limit" flag described in Section 5.1.4.4 of | | | [RFC7450] | | | | | relay | An AMT relay, as described in [RFC7450] | | | | | RPF | Reverse Path Forwarding, as described in [RFC5110] | | | | | RR | A DNS Resource Record, as described in [RFC1034] | | | | | RRType | A DNS Resource Record Type, as described in | | | [RFC1034] | @@ -210,22 +210,22 @@ | upstream | Closer to the source of traffic, as described in | | | [RFC7450]. | | | | | CMTS | Cable Modem Termination System | | | | | OLT | Optical Line Terminal | +------------+------------------------------------------------------+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in - [RFC2119] and [RFC8174] when, and only when, they appear in all + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Relay Discovery Operation 2.1. Overview The AMTRELAY resource record (RR) defined in this document is used to publish the IP address or domain name of a set of AMT relays or discovery brokers that can receive, encapsulate, and forward multicast traffic from a particular sender. @@ -279,103 +279,105 @@ DRIAD-capable. The content provider provides the user with a receiving application that tries to subscribe to at least one (S,G). This receiving application could for example be a file transfer system using FLUTE [RFC6726] or a live video stream using RTP [RFC3550], or any other application that might subscribe to an SSM channel. +---------------+ | Sender | - | | | 198.51.100.15 | + | | | 2001:db8::a | | | +---------------+ |Data| | |Flow| Multicast | \| |/ Network | \ / | 5: Propagate RPF for Join(S,G) \ / +---------------+ \/ | AMT Relay | - | 2001:db8::f | + | 2001:db8:c::f | +---------------+ | 4: Gateway connects to Relay, sends Join(S,G) over tunnel | - Unicast - Tunnel | - - ^ | 3: --> DNS Query: type=AMTRELAY, - | / 15.100.51.198.in-addr.arpa. + Unicast 3: --> DNS Query: type=AMTRELAY, + Tunnel | / a.0.0.0.0.0.0.0.0.0.0.0. + / 0.0.0.0.0.0.0.0.0.0.0.0. + ^ | / 8.b.d.0.1.0.0.2.ip6.arpa + | / | | / <-- Response: - Join/Leave +-------------+ AMTRELAY=2001:db8::f + Join/Leave +-------------+ AMTRELAY=2001:db8:c::f Signals | AMT gateway | | +-------------+ | | 2: Propagate RPF for Join(S,G) | Multicast | Network | - | 1: Join(S=198.51.100.15,G=232.252.0.2) + | 1: Join(S=2001:db8::a,G=ff3e::8000:d) +-------------+ | Receiver | | (end user) | +-------------+ Figure 2: DRIAD Messaging - In this simple example, the sender IP is 198.51.100.15, it is sending - traffic to the group address 232.252.0.2, and the relay IP is - 2001:db8::f. + In this simple example, the sender IP is 2001:db8::a, it is sending + traffic to the group address ff3e::8000:d, and the relay IP is + 2001:db8::c:f. The content provider has previously configured the DNS zone that - contains the domain name "15.100.51.198.in-addr.arpa.", which is the - reverse lookup domain name for his sender. The zone file contains an - AMTRELAY RR with the Relay's IP address. (See Section 4.3 for - details about the AMTRELAY RR format and semantics.) + contains the reverse IP domain name for the sender's IP address so + that it provides an AMTRELAY RR with the relay's IP address. (See + Section 4.3 for details about the AMTRELAY RR format and semantics.) + As described in Section 2.5 of [RFC3596], the reverse IP FQDN of the + sender's address "2001:db8::a" is: + + a.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6. + arpa. The sequence of events depicted in Figure 2 is as follows: 1. The end user starts the app, which issues a join to the (S,G): - (198.51.100.15, 232.252.0.2). + (2001:db8::a, ff3e::8000:d). 2. The join propagates with RPF through the receiver's multicast- enabled network with PIM [RFC7761] or another multicast routing mechanism, until the AMT gateway receives a signal to join the (S,G). 3. The AMT gateway performs a reverse DNS lookup for the AMTRELAY - RRType, by sending an AMTRELAY RRType query for the FQDN - "15.100.51.198.in-addr.arpa.", using the reverse IP domain name - for the sender's source IP address (the S from the (S,G)), as - described in Section 3.5 of [RFC1035]. + RRType, by sending an AMTRELAY RRType query for the reverse IP + domain name for the sender's source IP address (the S from the + (S,G)). The DNS resolver for the AMT gateway uses ordinary DNS recursive resolution until it has the authoritative result that the content provider configured, which informs the AMT gateway that the relay - address is 2001:db8::f. + address is 2001:db8::c:f. 4. The AMT gateway performs AMT handshakes with the AMT relay as described in Section 4 of [RFC7450], then forwards a Membership report to the relay indicating subscription to the (S,G). 5. The relay propagates the join through its network toward the sender, then forwards the appropriate AMT-encapsulated traffic to the gateway, which decapsulates and forwards it as native multicast through its downstream network to the end user. - In the case of an IPv6 (S,G), the only difference in the AMT relay - discovery process is the use of the ip6.arpa reverse IP domain name, - as described in Section 2.5 of [RFC3596]), instead of the in- - addr.arpa domain name. - - For example, if the (S,G) is (2001:db8:c::f, ffe3::80fc:2), the - reverse domain name for the AMTRELAY query would be: + In the case of an IPv4 (S,G), the only difference in the AMT relay + discovery process is the use of the in-addr.arpa reverse IP domain + name, as described in Section 3.5 of [RFC1035], instead of the + in6.arpa domain name. For example, if the (S,G) is (198.51.100.12, + 232.252.0.2), the reverse IP FQDN for the AMTRELAY query would be + "12.100.51.198.in-addr.arpa.". - f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.0.0.0.8.b.d.0.1.0.0.2.ip6. - arpa. + Note that the address family of the AMT tunnel is independent of the + address family for the multicast traffic. 2.3. Optimal Relay Selection 2.3.1. Overview The reverse source IP DNS query of an AMTRELAY RR is a good way for a gateway to discover a relay that is known to the sender. However, it is NOT necessarily a good way to discover the best relay for that gateway to use, because the RR will only provide information @@ -481,52 +484,53 @@ via DNS-SD, the network SHOULD use the well-known anycast addresses from Section 7 of [RFC7450] to route discovery traffic to the relay most appropriate to the receiver's gateway. Accordingly, the gateway SHOULD by default discover a relay with the well-known AMT anycast addresses as the second preference after DNS-SD when searching for a local relay. o Let Sender Manage Relay Provisioning - A related motivating example in the sending-side network is - provided by considering a sender that needs to instruct the - gateways on how to select between connecting to Figure 6 or - Figure 7 (from Section 3.2), in order to manage load and failover - scenarios in a manner that operates well with the sender's - provisioning strategy for horizontal scaling of AMT relays. + A related motivating example is provided by considering a sender + whose traffic can be forwarded by relays in a sender-controlled + network like Figure 6 in Section 3.2.1, and also by relays in a + provider-controlled network like Figure 7 in Section 3.2.2, with + different cost and scalability profiles for the different options. In this example about the sending-side network, the precedence field described in Section 4.2.1 is a critical method of control so that senders can provide the appropriate guidance to gateways - during the discovery process. + during the discovery process, in order to manage load and failover + scenarios in a manner that operates well with the sender's + provisioning strategy for horizontal scaling of AMT relays. Therefore, after DNS-SD, the precedence from the RR MUST be used for sorting preference ahead of the Destination Address Selection ordering from Section 6 of [RFC6724], so that only relay IPs with the same precedence are directly compared according to the Destination Address Selection ordering. Accordingly, AMT gateways SHOULD by default prefer relays in this order: 1. DNS-SD 2. Anycast addresses from Section 7 of [RFC7450] 3. DRIAD This default behavior MAY be overridden by administrative configuration where other behavior is more appropriate for the gateway within its network. Among relay addresses that have an equivalent preference as described - above, a Happy Eyeballs algorithm for AMT SHOULD use use the - Destination Address Selection defined in Section 6 of [RFC6724]. + above, a Happy Eyeballs algorithm for AMT SHOULD use the Destination + Address Selection defined in Section 6 of [RFC6724]. Among relay addresses that still have an equivalent preference after the above orderings, a gateway SHOULD make a non-deterministic choice (such as a pseudorandom selection) for relay preference ordering, in order to support load balancing by DNS configurations that provide many relay options. The gateway MAY introduce a bias in the non-deterministic choice according to information obtained out of band or from a historical record about network topology, timing information, or the response to @@ -914,20 +918,22 @@ as an index into one of the reverse mapping trees (in-addr.arpa for IPv4, as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, as described in Section 2.5 of [RFC3596]). Therefore, it is RECOMMENDED that AMTRELAY RRs be added to reverse IP zones as appropriate. AMTRELAY records MAY also appear in other zones, since this may be necessary to perform delegation from the reverse zones (see for example Section 5.2 of [RFC2317]), but the use case enabled by this document requires a reverse IP mapping for the source from an (S,G) in order to be useful to most AMT gateways. + This document does not define semantics for the use of AMTRELAY + records obtained in a way other than by a reverse IP lookup. When performing the AMTRELAY RR lookup, any CNAMEs or DNAMEs found MUST be followed. This is necessary to support zone delegation. Some examples outlining this need are described in [RFC2317]. See Section 4 and Section 4.3 for a detailed explanation of the contents for a DNS Zone file. 2.7. Waiting for DNS resolution @@ -1215,20 +1221,23 @@ o type = 1: The relay field contains a 4-octet IPv4 address. o type = 2: The relay field contains a 16-octet IPv6 address. o type = 3: The relay field contains a wire-encoded domain name. The wire-encoded format is self-describing, so the length is implicit. The domain name MUST NOT be compressed. (See Section 3.3 of [RFC1035] and Section 4 of [RFC3597].) + RRs with an undefined value in the Type field SHOULD NOT be + considered by receiving gateways for AMT relay discovery. + 4.2.4. RData Format - Relay The relay field is the address or domain name of the AMT relay. It is formatted according to the type field. When the type field is 0, the length of the relay field is 0, and it indicates that no AMT relay should be used for multicast traffic from this source. When the type field is 1, the length of the relay field is 4 octets, @@ -1265,27 +1274,27 @@ The presentation for the record is as follows: IN AMTRELAY precedence D-bit type relay 4.3.2. Examples In a DNS authoritative nameserver that understands the AMTRELAY type, the zone might contain a set of entries like this: $ORIGIN 100.51.198.in-addr.arpa. - 10 IN AMTRELAY 10 0 1 203.0.113.15 - 10 IN AMTRELAY 10 0 2 2001:db8::15 - 10 IN AMTRELAY 128 1 3 amtrelays.example.com. + 12 IN AMTRELAY 10 0 1 203.0.113.15 + 12 IN AMTRELAY 10 0 2 2001:db8::15 + 12 IN AMTRELAY 128 1 3 amtrelays.example.com. This configuration advertises an IPv4 discovery address, an IPv6 discovery address, and a domain name for AMT relays which can receive - traffic from the source 198.51.100.10. The IPv4 and IPv6 addresses + traffic from the source 198.51.100.12. The IPv4 and IPv6 addresses are configured with a D-bit of 0 (meaning discovery is mandatory, as described in Section 4.2.2), and a precedence 10 (meaning they're preferred ahead of the last entry, which has precedence 128). For zone files in name servers that don't support the AMTRELAY RRType natively, it's possible to use the format for unknown RR types, as described in [RFC3597]. This approach would replace the AMTRELAY entries in the example above with the entries below: 10 IN TYPE260 \# ( @@ -1389,21 +1398,22 @@ This specification was inspired by the previous work of Doug Nortz, Robert Sayko, David Segelstein, and Percy Tarapore, presented in the MBONED working group at IETF 93. Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, Ben Kaduk, Bill Atwood, Tim Chown, Warren Kumari, Dan Romanescu, Bernard Aboba, Carlos Pignataro, Niclas Comstedt, Mirja Kuehlewind, Henning Rogge, Eric Vyncke, Barry Lieba, Roman Danyliw, Alissa Cooper, Suresh - Krishnan, and Adam Roach for their very helpful reviews and comments. + Krishnan, Adam Roach, and Daniel Franke for their very helpful + reviews and comments. 8. References 8.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and @@ -1472,20 +1482,24 @@ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, . + [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS + Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, + January 2019, . + 8.2. Informative References [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/RFC2317, March 1998, . [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, @@ -1546,24 +1560,20 @@ [RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T., Ed., and R. Krishnan, "Use of Multicast across Inter- domain Peering Points", BCP 213, RFC 8313, DOI 10.17487/RFC8313, January 2018, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . - [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS - Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, - January 2019, . - Appendix A. Unknown RRType construction In a DNS resolver that understands the AMTRELAY type, the zone file might contain this line: IN AMTRELAY 128 0 3 amtrelays.example.com. In order to translate this example to appear as an unknown RRType as defined in [RFC3597], one could run the following program: @@ -1577,30 +1587,28 @@ if len(dn) > 0: wire += ('%02x' % len(dn)) wire += (''.join('%02x'%ord(x) for x in dn)) print(len(wire)//2) + 2 print(wire) $ ./translate.py amtrelays.example.com 24 09616d7472656c617973076578616d706c6503636f6d + The length of the RData and the hex string for the domain name + "amtrelays.example.com" are the outputs of this program. - The length and the hex string for the domain name - "amtrelays.example.com" are the outputs of this program, yielding a - length of 22 and the above hex string. - - 22 is the length of the wire-encoded domain name, so to this we add 2 - (1 for the precedence field and 1 for the combined D-bit and relay - type fields) to get the full length of the RData, and encode the - precedence, D-bit, and relay type fields as octets, as described in - Section 4. + 22 is the length of the wire-encoded domain name, so 2 was added to + that value (1 for the precedence field and 1 for the combined D-bit + and relay type fields) to get the full length 24 of the RData. For + the 2 octets ahead of the domain name, we encode the precedence, + D-bit, and relay type fields, as described in Section 4. This results in a zone file entry like this: IN TYPE260 \# ( 24 ; length 80 ; precedence = 128 03 ; D-bit=0, relay type=3 (wire-encoded domain name) 09616d7472656c617973076578616d706c6503636f6d ) ; domain name Author's Address