draft-ietf-mboned-driad-amt-discovery-02.txt   draft-ietf-mboned-driad-amt-discovery-03.txt 
Mboned J. Holland Mboned J. Holland
Internet-Draft Akamai Technologies, Inc. Internet-Draft Akamai Technologies, Inc.
Updates: 7450 (if approved) March 08, 2019 Updates: 7450 (if approved) April 04, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: September 9, 2019 Expires: October 6, 2019
DNS Reverse IP AMT Discovery DNS Reverse IP AMT Discovery
draft-ietf-mboned-driad-amt-discovery-02 draft-ietf-mboned-driad-amt-discovery-03
Abstract Abstract
This document updates RFC 7450 (Automatic Multicast Tunneling, or This document updates RFC 7450 (Automatic Multicast Tunneling, or
AMT) by extending the relay discovery process to use a new DNS AMT) by extending the relay discovery process to use a new DNS
resource record named AMTRELAY when discovering AMT relays for resource record named AMTRELAY when discovering AMT relays for
source-specific multicast channels. The reverse IP DNS zone for a source-specific multicast channels. The reverse IP DNS zone for a
multicast sender's IP address is configured to use AMTRELAY resource multicast sender's IP address is configured to use AMTRELAY resource
records to advertise a set of AMT relays that can receive and forward records to advertise a set of AMT relays that can receive and forward
multicast traffic from that sender over an AMT tunnel. multicast traffic from that sender over an AMT tunnel.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 9, 2019. This Internet-Draft will expire on October 6, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 4 1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 4
2. Relay Discovery Operation . . . . . . . . . . . . . . . . . . 5 2. Relay Discovery Operation . . . . . . . . . . . . . . . . . . 5
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Signaling and Discovery . . . . . . . . . . . . . . . . . 6 2.2. Signaling and Discovery . . . . . . . . . . . . . . . . . 6
2.3. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . . 8 2.3. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . . 8
2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 8 2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2. Connection Definition . . . . . . . . . . . . . . . . 9 2.3.2. Connection Definition . . . . . . . . . . . . . . . . 9
2.4. Optimal Relay Selection . . . . . . . . . . . . . . . . . 9 2.4. Optimal Relay Selection . . . . . . . . . . . . . . . . . 9
2.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 9 2.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 9
2.4.2. Preference Ordering . . . . . . . . . . . . . . . . . 10 2.4.2. Preference Ordering . . . . . . . . . . . . . . . . . 10
2.4.3. Connecting to Multiple Relays . . . . . . . . . . . . 12 2.4.3. Connecting to Multiple Relays . . . . . . . . . . . . 13
2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 13 2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 13
2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13 2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13
2.5.2. Updates to Restarting Events . . . . . . . . . . . . 13 2.5.2. Updates to Restarting Events . . . . . . . . . . . . 14
2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 14 2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 15
2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 15 2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 15
2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 16 2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 17
2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 17 2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 17
2.5.7. Independent Discovery Per Traffic Source . . . . . . 17 2.5.7. Independent Discovery Per Traffic Source . . . . . . 18
2.6. DNS Configuration . . . . . . . . . . . . . . . . . . . . 18 2.6. DNS Configuration . . . . . . . . . . . . . . . . . . . . 18
2.7. Waiting for DNS resolution . . . . . . . . . . . . . . . 18 2.7. Waiting for DNS resolution . . . . . . . . . . . . . . . 19
3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 19 3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 19
3.1. Example Receiving Networks . . . . . . . . . . . . . . . 19 3.1. Example Receiving Networks . . . . . . . . . . . . . . . 19
3.1.1. Tier 3 ISP . . . . . . . . . . . . . . . . . . . . . 19 3.1.1. Tier 3 ISP . . . . . . . . . . . . . . . . . . . . . 19
3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 20 3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 20
3.2. Example Sending Networks . . . . . . . . . . . . . . . . 21 3.2. Example Sending Networks . . . . . . . . . . . . . . . . 22
3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 21 3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 22
3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 22 3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 23
4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 23 4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 24
4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 23 4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 24
4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 23 4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 24
4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 24 4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 25
4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 24 4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 25
4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 24 4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 25
4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 25 4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 26
4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 25 4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 26
4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 25 4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 26
4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 26 4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 27
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6.1. Use of AMT . . . . . . . . . . . . . . . . . . . . . . . 27 6.1. Use of AMT . . . . . . . . . . . . . . . . . . . . . . . 28
6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 27 6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 28
6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 28 6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . 28 8.1. Normative References . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . 30 8.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Unknown RRType construction . . . . . . . . . . . . 31 Appendix A. Unknown RRType construction . . . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
This document defines DNS Reverse IP AMT Discovery (DRIAD), a This document defines DNS Reverse IP AMT Discovery (DRIAD), a
mechanism for AMT gateways to discover AMT relays that are capable of mechanism for AMT gateways to discover AMT relays that are capable of
forwarding multicast traffic from a known source IP address. forwarding multicast traffic from a known source IP address.
AMT (Automatic Multicast Tunneling) is defined in [RFC7450], and AMT (Automatic Multicast Tunneling) is defined in [RFC7450], and
provides a method to transport multicast traffic over a unicast provides a method to transport multicast traffic over a unicast
tunnel, in order to traverse non-multicast-capable network segments. tunnel, in order to traverse non-multicast-capable network segments.
skipping to change at page 10, line 24 skipping to change at page 10, line 24
multicast traffic from the source of the (S,G); and multicast traffic from the source of the (S,G); and
3. The gateway is not configured to use a particular IP address for 3. The gateway is not configured to use a particular IP address for
AMT discovery, or a relay discovered with that IP is not able to AMT discovery, or a relay discovered with that IP is not able to
forward traffic from the source of the (S,G); and forward traffic from the source of the (S,G); and
4. The gateway is not able to find an upstream AMT relay with DNS-SD 4. The gateway is not able to find an upstream AMT relay with DNS-SD
[RFC6763], using "_amt._udp" as the Service section of the [RFC6763], using "_amt._udp" as the Service section of the
queries, or a relay discovered this way is not able to forward queries, or a relay discovered this way is not able to forward
traffic from the source of the (S,G) (as described in traffic from the source of the (S,G) (as described in
Section 2.5.4.1 or Section 2.5.5). Section 2.5.4.1 or Section 2.5.5); and
5. The gateway is not able to find an upstream AMT relay with the
well-known anycast addresses from Section 7 of [RFC7450].
When the above conditions are met, the gateway has no path within its When the above conditions are met, the gateway has no path within its
local network that can receive multicast traffic from the source IP local network that can receive multicast traffic from the source IP
of the (S,G). of the (S,G).
In this situation, the best way to find a relay that can forward the In this situation, the best way to find a relay that can forward the
required traffic is to use information that comes from the operator required traffic is to use information that comes from the operator
of the sender. When the sender has configured an AMTRELAY RR, of the sender. When the sender has configured an AMTRELAY RR,
gateways can use the DRIAD mechanism defined in this document to gateways can use the DRIAD mechanism defined in this document to
discover the relay information provided by the sender. discover the relay information provided by the sender.
skipping to change at page 11, line 26 skipping to change at page 11, line 30
DNS-SD [RFC6763] for discovery strictly ahead of using the DNS-SD [RFC6763] for discovery strictly ahead of using the
AMTRELAY RR controlled by the sender for AMT discovery. AMTRELAY RR controlled by the sender for AMT discovery.
For this reason, it's RECOMMENDED that AMT gateways by default For this reason, it's RECOMMENDED that AMT gateways by default
perform service discovery using DNS Service Discovery (DNS-SD) perform service discovery using DNS Service Discovery (DNS-SD)
[RFC6763] for _amt._udp.<domain> (with <domain> chosen as [RFC6763] for _amt._udp.<domain> (with <domain> chosen as
described in Section 11 of [RFC6763]) and use the AMT relays described in Section 11 of [RFC6763]) and use the AMT relays
discovered that way in preference to AMT relays discoverable via discovered that way in preference to AMT relays discoverable via
the mechanism defined in this document (DRIAD). the mechanism defined in this document (DRIAD).
2. Let Sender Manage Relay Provisioning 2. Prefer Relays Managed by the Containing Network
When no local relay is discoverable with DNS-SD, it still may be
the case that a relay local to the receiver is operated by the
network providing transit services to the receiver.
In this case, when the network cannot make the relay discoverable
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.
3. Let Sender Manage Relay Provisioning
A related motivating example in the sending-side network is A related motivating example in the sending-side network is
provided by considering a sender which needs to instruct the provided by considering a sender which needs to instruct the
gateways on how to select between connecting to Figure 6 or gateways on how to select between connecting to Figure 6 or
Figure 7 (from Section 3.2), in order to manage load and failover Figure 7 (from Section 3.2), in order to manage load and failover
scenarios in a manner that operates well with the sender's scenarios in a manner that operates well with the sender's
provisioning strategy for horizontal scaling of AMT relays. provisioning strategy for horizontal scaling of AMT relays.
In this example about the sending-side network, the precedence In this example about the sending-side network, the precedence
field described in Section 4.2.1 is a critical method of control field described in Section 4.2.1 is a critical method of control
so that senders can provide the appropriate guidance to gateways so that senders can provide the appropriate guidance to gateways
during the discovery process. during the discovery process.
Therefore, after DNS-SD, the precedence from the RR MUST be used Therefore, after DNS-SD, the precedence from the RR MUST be used
for sorting preference ahead of the Destination Address Selection for sorting preference ahead of the Destination Address Selection
ordering from Section 6 of [RFC6724], so that only relay IPs with ordering from Section 6 of [RFC6724], so that only relay IPs with
the same precedence are directly compared according to the the same precedence are directly compared according to the
Destination Address Selection ordering. Destination Address Selection ordering.
3. Let Sender Manage Non-DRIAD discovery
It's also RECOMMENDED that if the well-known anycast IP addresses
defined in Section 7 of [RFC7450] are suitable for discovering an
AMT relay that can forward traffic from the source, that a DNS
record with the AMTRELAY RRType be published by the sender for
those IP addresses along with any other appropriate AMTRELAY RRs
to indicate the best relative precedences for receiving the
source traffic.
Accordingly, AMT gateways SHOULD by default prefer relays first by Accordingly, AMT gateways SHOULD by default prefer relays first by
DNS-SD if available, then by DRIAD as described in this document (in DNS-SD if available, then with the anycast addresses defined in
precedence order, as described in Section 4.2.1), then with the Section 7 of [RFC7450] (namely: 192.52.193.1 and 2001:3::1), then by
anycast addresses defined in Section 7 of [RFC7450] (namely: DRIAD as described in this document (in precedence order, as
192.52.193.1 and 2001:3::1) if those IPs weren't listed in the described in Section 4.2.1).
AMTRELAY RRs.
This default behavior MAY be overridden by administrative This default behavior MAY be overridden by administrative
configuration where other behavior is more appropriate for the configuration where other behavior is more appropriate for the
gateway within its network. gateway within its network.
Among relay addresses that have an equivalent preference as described Among relay addresses that have an equivalent preference as described
above, a Happy Eyeballs algorithm for AMT MUST use the Destination above, a Happy Eyeballs algorithm for AMT MUST use the Destination
Address Selection defined in Section 6 of [RFC6724], as required by Address Selection defined in Section 6 of [RFC6724], as required by
[RFC8305]. [RFC8305].
skipping to change at page 20, line 18 skipping to change at page 20, line 50
regularly accesses some multicast content, illustrated in Figure 4. regularly accesses some multicast content, illustrated in Figure 4.
This office has desktop devices that need to receive some multicast This office has desktop devices that need to receive some multicast
traffic, so an AMT gateway runs on a LAN with these devices, to pull traffic, so an AMT gateway runs on a LAN with these devices, to pull
traffic in through a non-multicast next-hop. traffic in through a non-multicast next-hop.
The office also hosts some mobile devices that have AMT gateway The office also hosts some mobile devices that have AMT gateway
instances embedded inside apps, in order to receive multicast traffic instances embedded inside apps, in order to receive multicast traffic
over their non-multicast wireless LAN. (Note that the "Legacy over their non-multicast wireless LAN. (Note that the "Legacy
Router" is a simplification that's meant to describe a variety of Router" is a simplification that's meant to describe a variety of
possible conditions- for example it could be a device providing a possible conditions; for example it could be a device providing a
split-tunnel VPN as described in [RFC7359], deliberately excluding split-tunnel VPN as described in [RFC7359], deliberately excluding
multicast traffic for a VPN tunnel, rather than a device which is multicast traffic for a VPN tunnel, rather than a device which is
incapable of multicast forwarding.) incapable of multicast forwarding.)
Internet Internet
(non-multicast) (non-multicast)
^ ^
| Office Network | Office Network
+----------|----------------------------------+ +----------|----------------------------------+
| | | | | |
 End of changes. 16 change blocks. 
52 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/