< draft-ietf-mboned-driad-amt-discovery-05.txt   draft-ietf-mboned-driad-amt-discovery-06.txt >
Mboned J. Holland Mboned J. Holland
Internet-Draft Akamai Technologies, Inc. Internet-Draft Akamai Technologies, Inc.
Updates: 7450 (if approved) April 25, 2019 Updates: 7450 (if approved) May 06, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: October 27, 2019 Expires: November 7, 2019
DNS Reverse IP AMT Discovery DNS Reverse IP AMT Discovery
draft-ietf-mboned-driad-amt-discovery-05 draft-ietf-mboned-driad-amt-discovery-06
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 October 27, 2019. This Internet-Draft will expire on November 7, 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 12, line 42 skipping to change at page 12, line 42
Among relay addresses that still have an equivalent preference after Among relay addresses that still have an equivalent preference after
the above orderings, a gateway MUST make a non-deterministic choice the above orderings, a gateway MUST make a non-deterministic choice
for relay preference ordering, in order to support load balancing by for relay preference ordering, in order to support load balancing by
DNS configurations that provide many relay options. DNS configurations that provide many relay options.
The gateway MAY introduce a bias in the non-deterministic choice The gateway MAY introduce a bias in the non-deterministic choice
according to information obtained out of band or from a historical according to information obtained out of band or from a historical
record about network topology, timing information, or the response to record about network topology, timing information, or the response to
a probing mechanism, that indicates some expected benefits from a probing mechanism, that indicates some expected benefits from
selecting some relays in preference to others. Details about the selecting some relays in preference to others. Details about the
structure and collection of this information is out of scope for this structure and collection of this information are out of scope for
document, but a gateway in possession of such information MAY use it this document, but a gateway in possession of such information MAY
to prefer topologically closer relays. use it to prefer topologically closer relays.
Note also that certain relay addresses may be excluded from Note also that certain relay addresses may be excluded from
consideration by the hold-down timers described in Section 2.5.4.1 or consideration by the hold-down timers described in Section 2.5.4.1 or
Section 2.5.5. These relays constitute "unusable destinations" under Section 2.5.5. These relays constitute "unusable destinations" under
Rule 1 of the Destination Address Selection, and are also not part of Rule 1 of the Destination Address Selection, and are also not part of
the superseding considerations described above. the superseding considerations described above.
The discovery and connection process for the relay addresses in the The discovery and connection process for the relay addresses in the
above described ordering MAY operate in parallel, subject to delays above described ordering MAY operate in parallel, subject to delays
prescribed by the Happy Eyeballs requirements described in Section 5 prescribed by the Happy Eyeballs requirements described in Section 5
skipping to change at page 28, line 29 skipping to change at page 28, line 29
6. Security Considerations 6. Security Considerations
6.1. Use of AMT 6.1. Use of AMT
This document defines a mechanism that enables a more widespread and This document defines a mechanism that enables a more widespread and
automated use of AMT, even without access to a multicast backbone. automated use of AMT, even without access to a multicast backbone.
Operators of networks and applications that include a DRIAD-capable Operators of networks and applications that include a DRIAD-capable
AMT gateway are advised to carefully consider the security AMT gateway are advised to carefully consider the security
considerations in Section 6 of [RFC7450]. considerations in Section 6 of [RFC7450].
AMT gateway operators also are encouraged to implement the AMT gateway operators also are encouraged to take appropriate steps
opportunistic use of IPSec [RFC4301] when IPSECKEY records [RFC4025] to ensure the integrity of the data received via AMT, for example by
are available to secure traffic from AMT relays, or when a trust the opportunistic use of IPSec [RFC4301] to secure traffic received
relationship with the AMT relays can be otherwise secured. from AMT relays, when IPSECKEY records [RFC4025] are available or
when a trust relationship with the AMT relays can be otherwise
established and secured.
6.2. Record-spoofing 6.2. Record-spoofing
The AMTRELAY resource record contains information that SHOULD be The AMTRELAY resource record contains information that SHOULD be
communicated to the DNS client without being modified. The method communicated to the DNS client without being modified. The method
used to ensure the result was unmodified is up to the client. used to ensure the result was unmodified is up to the client.
There must be a trust relationship between the end consumer of this There must be a trust relationship between the end consumer of this
resource record and the DNS server. This relationship may be end-to- resource record and the DNS server. This relationship may be end-to-
end DNSSEC validation, a TSIG [RFC2845] or SIG(0) [RFC2931] channel end DNSSEC validation, a TSIG [RFC2845] or SIG(0) [RFC2931] channel
 End of changes. 6 change blocks. 
11 lines changed or deleted 13 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/