draft-ietf-mboned-driad-amt-discovery-00.txt   draft-ietf-mboned-driad-amt-discovery-01.txt 
Mboned J. Holland Mboned J. Holland
Internet-Draft Akamai Technologies, Inc. Internet-Draft Akamai Technologies, Inc.
Updates: 7450 (if approved) January 25, 2019 Updates: 7450 (if approved) February 14, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: July 29, 2019 Expires: August 18, 2019
DNS Reverse IP AMT Discovery DNS Reverse IP AMT Discovery
draft-ietf-mboned-driad-amt-discovery-00 draft-ietf-mboned-driad-amt-discovery-01
Abstract Abstract
This document updates RFC 7450 (AMT) by extending the relay discovery This document updates RFC 7450 (Automatic Multicast Tunneling, or
process to use a new DNS resource record for source-specific AMT AMT) by extending the relay discovery process to use a new DNS
relay discovery when joining source-specific multicast channels. A resource record named AMTRELAY when discovering AMT relays for
multicast sender configures a reverse IP DNS zone with the new source-specific multicast channels. The reverse IP DNS zone for a
AMTRELAY RR (defined in this document) to advertise a set of relays multicast sender's IP address is configured to use AMTRELAY resource
that can receive and forward multicast traffic from that sender records to advertise a set of AMT relays that can receive and forward
inside a unicast AMT tunnel, in order to transit non-multicast- multicast traffic from that sender over an AMT tunnel.
capable network segments.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 July 29, 2019. This Internet-Draft will expire on August 18, 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 17 skipping to change at page 2, line 16
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1. Relays and Gateways . . . . . . . . . . . . . . . . . 4 1.2.1. Relays and Gateways . . . . . . . . . . . . . . . . . 4
1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 4 1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 4
2. Relay Discovery Operation . . . . . . . . . . . . . . . . . . 5 2. Relay Discovery Operation . . . . . . . . . . . . . . . . . . 5
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Signaling and Discovery . . . . . . . . . . . . . . . . . 6 2.2. Signaling and Discovery . . . . . . . . . . . . . . . . . 6
2.3. Optimal Relay Selection . . . . . . . . . . . . . . . . . 8 2.3. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . . 8
2.4. Guidelines for Restarting Discovery . . . . . . . . . . . 9 2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2. Connection Definition . . . . . . . . . . . . . . . . 9
2.4. Optimal Relay Selection . . . . . . . . . . . . . . . . . 9
2.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 9 2.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 9
2.4.2. Tunnel Stability . . . . . . . . . . . . . . . . . . 11 2.4.2. Preference Ordering . . . . . . . . . . . . . . . . . 10
2.4.3. Flow Health . . . . . . . . . . . . . . . . . . . . . 11 2.4.3. Connecting to Multiple Relays . . . . . . . . . . . . 12
2.4.4. Relay Loading and Shutdown . . . . . . . . . . . . . 11 2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 13
2.4.5. Relay Discovery Messages vs. Restarting Discovery . . 12 2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13
2.4.6. Connecting to Multiple Relays . . . . . . . . . . . . 13 2.5.2. Updates to Restarting Events . . . . . . . . . . . . 13
2.5. DNS Configuration . . . . . . . . . . . . . . . . . . . . 13 2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 14
2.6. Waiting for DNS resolution . . . . . . . . . . . . . . . 13 2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 15
3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 14 2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 16
3.1. Example Receiving Networks . . . . . . . . . . . . . . . 14 2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 17
3.1.1. Tier 3 ISP . . . . . . . . . . . . . . . . . . . . . 14 2.5.7. Independent Discovery Per Traffic Source . . . . . . 17
3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 15 2.6. DNS Configuration . . . . . . . . . . . . . . . . . . . . 18
3.2. Example Sending Networks . . . . . . . . . . . . . . . . 18 2.7. Waiting for DNS resolution . . . . . . . . . . . . . . . 18
3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 18 3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 19
3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 19 3.1. Example Receiving Networks . . . . . . . . . . . . . . . 19
4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 20 3.1.1. Tier 3 ISP . . . . . . . . . . . . . . . . . . . . . 19
4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 20 3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 20
4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 20 3.2. Example Sending Networks . . . . . . . . . . . . . . . . 21
4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 21 3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 21
4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 21 3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 22
4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 22 4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 23
4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 22 4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 23
4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 22 4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 23
4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 22 4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 24
4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 23 4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 24
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 24
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 25
6.1. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 24 4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 25
6.2. Local Override . . . . . . . . . . . . . . . . . . . . . 24 4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 25
6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 25 4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 26
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8.1. Normative References . . . . . . . . . . . . . . . . . . 25 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8.2. Informative References . . . . . . . . . . . . . . . . . 26 6.1. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 27
Appendix A. New RRType Request Form . . . . . . . . . . . . . . 28 6.2. Local Override . . . . . . . . . . . . . . . . . . . . . 27
Appendix B. Unknown RRType construction . . . . . . . . . . . . 29 6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Normative References . . . . . . . . . . . . . . . . . . 28
8.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Unknown RRType construction . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31
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 which are capable mechanism for AMT gateways to discover AMT relays that are capable of
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.
Section 4.1.5 of [RFC7450] explains that relay selection might need Section 4.1.5 of [RFC7450] explains that the relay selection process
to depend on the source of the multicast traffic, since a relay must for AMT is intended to be more flexible than the particular discovery
be able to receive multicast traffic from the desired source in order method described in that document, and further explains that the
to forward it. selection process might need to depend on the source of the multicast
traffic in some deployments, since a relay must be able to receive
multicast traffic from the desired source in order to forward it.
That section suggests DNS-based queries as a possible solution. That section goes on to suggest DNS-based queries as a possible
DRIAD is a DNS-based solution, as suggested there. This solution solution. DRIAD is a DNS-based solution, as suggested there. This
also addresses the relay discovery issues in the "Disadvantages" solution also addresses the relay discovery issues in the
lists in Section 3.3 of [RFC8313] and Section 3.4 of [RFC8313]. "Disadvantages" lists in Section 3.3 of [RFC8313] and Section 3.4 of
[RFC8313].
The goal for DRIAD is to enable multicast connectivity between The goal for DRIAD is to enable multicast connectivity between
separate multicast-enabled networks when neither the sending nor the separate multicast-enabled networks when neither the sending nor the
receiving network is connected to a multicast-enabled backbone, receiving network is connected to a multicast-enabled backbone,
without pre-configuring any peering arrangement between the networks. without pre-configuring any peering arrangement between the networks.
This document updates Section 5.2.3.4 of [RFC7450] by adding a new This document updates Section 5.2.3.4 of [RFC7450] by adding a new
extension to the relay discovery procedure. extension to the relay discovery procedure.
1.1. Background 1.1. Background
skipping to change at page 5, line 11 skipping to change at page 5, line 11
Figure 1: AMT Tunnel Illustration Figure 1: AMT Tunnel Illustration
1.2.2. Definitions 1.2.2. Definitions
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| Term | Definition | | Term | Definition |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| (S,G) | A source-specific multicast channel, as described in | | (S,G) | A source-specific multicast channel, as described in |
| | [RFC4607]. A pair of IP addresses with a source host | | | [RFC4607]. A pair of IP addresses with a source host |
| | IP and destination group IP. | | | IP and destination group IP. |
| | | | | |
| downstream | Further from the source of traffic. | | discovery | A broker or load balancer for AMT relay discovery, |
| 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 | | FQDN | Fully Qualified Domain Name, as described in |
| | [RFC8499] | | | [RFC8499] |
| | | | | |
| gateway | An AMT gateway, as described in [RFC7450] | | 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.1.4 of |
| | [RFC7450] | | | [RFC7450] |
| | | | | |
| relay | An AMT relay, as described in [RFC7450] | | relay | An AMT relay, as described in [RFC7450] |
| | | | | |
| RPF | Reverse Path Forwarding, as described in [RFC5110] | | RPF | Reverse Path Forwarding, as described in [RFC5110] |
| | | | | |
| RR | A DNS Resource Record, as described in [RFC1034] | | RR | A DNS Resource Record, as described in [RFC1034] |
| | | | | |
| RRType | A DNS Resource Record Type, as described in | | RRType | A DNS Resource Record Type, as described in |
| | [RFC1034] | | | [RFC1034] |
| | | | | |
| SSM | Source-specific multicast, as described in [RFC4607] | | SSM | Source-specific multicast, as described in [RFC4607] |
| | | | | |
| upstream | Closer to the source of traffic. | | upstream | Closer to the source of traffic, as described in |
| | [RFC7450]. |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119] and [RFC8174] when, and only when, they appear in all [RFC2119] and [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Relay Discovery Operation 2. Relay Discovery Operation
2.1. Overview 2.1. Overview
The AMTRELAY resource record (RR) defined in this document is used to The AMTRELAY resource record (RR) defined in this document is used to
publish the IP address or domain name of an AMT relay that can publish the IP address or domain name of a set of AMT relays or
receive, encapsulate, and forward multicast traffic from a particular discovery brokers that can receive, encapsulate, and forward
sender. multicast traffic from a particular sender.
The sender is the owner of the RR, and configures the RR so that it The sender is the owner of the RR, and configures the zone so that it
contains the address or domain name of an AMT relay that can receive contains a set of RRs that provide the addresses or domain names of
multicast IP traffic from that sender. AMT relays (or discovery brokers that advertise relays) that can
receive multicast IP traffic from that sender.
This enables AMT gateways in remote networks to discover an AMT relay This enables AMT gateways in remote networks to discover an AMT relay
that is capable of forwarding traffic from the sender. This in turn that is capable of forwarding traffic from the sender. This in turn
enables those AMT gateways to receive the multicast traffic tunneled enables those AMT gateways to receive the multicast traffic tunneled
over a unicast AMT tunnel from those relays, and then to pass the over a unicast AMT tunnel from those relays, and then to pass the
multicast packets into networks or applications that are using the multicast packets into networks or applications that are using the
gateway to subscribe to traffic from that sender. gateway to subscribe to traffic from that sender.
This mechanism only works for source-specific multicast (SSM) This mechanism only works for source-specific multicast (SSM)
channels. The source address of the (S,G) is reversed and used as an channels. The source address of the (S,G) is reversed and used as an
index into one of the reverse mapping trees (in-addr.arpa for IPv4, 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 as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, as
described in Section 2.5 of [RFC3596]). described in Section 2.5 of [RFC3596]).
This mechanism should be treated as an extension of the AMT relay This mechanism should be treated as an extension of the AMT relay
discovery procedure described in section 5.2.3.4 of [RFC7450]. A discovery procedure described in Section 5.2.3.4 of [RFC7450]. A
gateway that supports this method of AMT relay discovery SHOULD use gateway that supports this method of AMT relay discovery SHOULD use
this method whenever it's performing the relay discovery procedure, this method whenever it's performing the relay discovery procedure,
and the source IP addresses for desired (S,G)s are known to the and the source IP addresses for desired (S,G)s are known to the
gateway, and conditions match the requirements outlined in gateway, and conditions match the requirements outlined in
Section 2.3. Section 2.4.
Some detailed example use cases are provided in Section 3, and other Some detailed example use cases are provided in Section 3, and other
applicable example topologies appear in Section 3.3 of [RFC8313], applicable example topologies appear in Section 3.3 of [RFC8313],
Section 3.4 of [RFC8313], and Section 3.5 of [RFC8313]. Section 3.4 of [RFC8313], and Section 3.5 of [RFC8313].
2.2. Signaling and Discovery 2.2. Signaling and Discovery
This section describes a typical example of the end-to-end process This section describes a typical example of the end-to-end process
for signaling a receiver's join of a SSM channel that relies on an for signaling a receiver's join of a SSM channel that relies on an
AMTRELAY RR. AMTRELAY RR.
skipping to change at page 8, line 37 skipping to change at page 8, line 44
4. The AMT gateway performs AMT handshakes with the AMT relay as 4. The AMT gateway performs AMT handshakes with the AMT relay as
described in Section 4 of [RFC7450], then forwards a Membership described in Section 4 of [RFC7450], then forwards a Membership
report to the relay indicating subscription to the (S,G). report to the relay indicating subscription to the (S,G).
5. The relay propagates the join through its network toward the 5. The relay propagates the join through its network toward the
sender, then forwards the appropriate AMT-encapsulated traffic to sender, then forwards the appropriate AMT-encapsulated traffic to
the gateway, which decapsulates and forwards it as native the gateway, which decapsulates and forwards it as native
multicast through its downstream network to the end user. multicast through its downstream network to the end user.
2.3. Optimal Relay Selection 2.3. Happy Eyeballs
2.3.1. Overview
Often, multiple choices of relay will exist for a gateway using DRIAD
for relay discovery. It is RECOMMENDED that DRIAD-capable gateways
implement a Happy Eyeballs [RFC8305] algorithm to support connecting
to multiple relays in parallel.
The parallel discovery logic of a Happy Eyeballs algorithm serves to
reduce join latency for the initial join of a SSM channel. This
section and Section 2.4.2 taken together provide guidance on use of a
Happy Eyeballs algorithm for the case of establishing AMT
connections.
2.3.2. Connection Definition
Section 5 of [RFC8305] non-normatively describes success at a
connection attempt as "generally when the TCP handshake completes".
There is no normative definition of a connection in the AMT
specification [RFC7450], and there is no TCP connection involved in
an AMT tunnel.
However, the concept of an AMT connection in the context of a Happy
Eyeballs algorithm is a useful one, and so this section provides the
following normative definition:
o An AMT connection is completed successfully when the gateway
receives from a newly discovered relay a valid Membership Query
message (Section 5.1.4 of [RFC7450]) that does not have the L flag
set.
See Section 2.5.5 for further information about the relevance of the
L flag to the establishment of a Happy Eyeballs connection.
2.4. Optimal Relay Selection
2.4.1. Overview
The reverse source IP DNS query of an AMTRELAY RR is a good way for a 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. gateway to discover a relay that is known to the sender.
However, it is NOT necessarily a good way to discover the best relay However, it is NOT necessarily a good way to discover the best relay
for that gateway to use, because the RR IP will only provide for that gateway to use, because the RR will only provide information
information about relays known to the source. about relays known to the source.
If there is an upstream relay in a network that is topologically If there is an upstream relay in a network that is topologically
closer to the gateway and able to receive and forward multicast closer to the gateway and able to receive and forward multicast
traffic from the sender, that relay is better for the gateway to use, traffic from the sender, that relay is better for the gateway to use,
since more of the network path uses native multicast, allowing more since more of the network path uses native multicast, allowing more
chances for packet replication. But since that relay is not known to chances for packet replication. But since that relay is not known to
the sender, it won't be advertised in the sender's reverse IP DNS the sender, it won't be advertised in the sender's reverse IP DNS
record. An example network that illustrates this scenario is record. An example network that illustrates this scenario is
outlined in Section 3.1.2. outlined in Section 3.1.2.
skipping to change at page 9, line 25 skipping to change at page 10, line 23
2. The gateway is not already connected to a relay that forwards 2. The gateway is not already connected to a relay that forwards
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) traffic from the source of the (S,G) (as described in
Section 2.5.4.1 or Section 2.5.5).
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 the AMTRELAY RR of the sender. When the sender has configured an AMTRELAY RR,
defined in this document, gateways can use the DRIAD mechanism gateways can use the DRIAD mechanism defined in this document to
defined in this document to discover the relay information provided discover the relay information provided by the sender.
by the sender.
2.4. Guidelines for Restarting Discovery 2.4.2. Preference Ordering
2.4.1. Overview This section defines a preference ordering for relay addresses during
the relay discovery process. Gateways are encouraged to implement a
Happy Eyeballs algorithm, but even gateways that do not implement a
Happy Eyeballs algorithm SHOULD use this ordering, except as noted.
When establishing an AMT tunnel to forward multicast data, it's very
important for the discovery process to prioritize the network
topology considerations ahead of address selection considerations, in
order to gain the packet replication benefits from using multicast
instead of unicast tunneling in the multicast-capable portions of the
network path.
The intent of the advice and requirements in this section is to
describe how a gateway should make use of the concurrency provided by
a Happy Eyeballs algorithm to reduce the join latency, while still
prioritizing network efficiency considerations over Address Selection
considerations.
Section 4 of [RFC8305] requires a Happy Eyeballs algorithm to sort
the addresses with the Destination Address Selection defined in
Section 6 of [RFC6724], but for the above reasons, that requirement
is superseded in the AMT discovery use case by the following
considerations:
1. Prefer Local Relays
Figure 5 and Section 3.1.2 provide a motivating example to prefer
DNS-SD [RFC6763] for discovery strictly ahead of using the
AMTRELAY RR controlled by the sender for AMT discovery.
For this reason, it's RECOMMENDED that AMT gateways by default
perform service discovery using DNS Service Discovery (DNS-SD)
[RFC6763] for _amt._udp.<domain> (with <domain> chosen as
described in Section 11 of [RFC6763]) and use the AMT relays
discovered that way in preference to AMT relays discoverable via
the mechanism defined in this document (DRIAD).
2. Let Sender Manage Relay Provisioning
A related motivating example in the sending-side network is
provided by considering a sender which 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.
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.
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.
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
DNS-SD if available, then by DRIAD as described in this document (in
precedence order, as described in Section 4.2.1), then with the
anycast addresses defined in Section 7 of [RFC7450] (namely:
192.52.193.1 and 2001:3::1) if those IPs weren't listed in the
AMTRELAY RRs.
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 MUST use the Destination
Address Selection defined in Section 6 of [RFC6724], as required by
[RFC8305].
Among relay addresses that still have an equivalent preference after
the above orderings, a gateway MUST make a non-deterministic choice
for relay preference ordering, in order to support load balancing by
DNS configurations that provide many relay options. (Note that
gateways not implementing a Happy Eyeballs algorithm are not required
to use the Destination Address Selection ordering, but are still
required to use non-deterministic ordering among equally preferred
relays.)
Note also that certain relay addresses may be excluded from
consideration by the hold-down timers described in Section 2.5.4.1 or
Section 2.5.5. These relays constitute "unusable destinations" under
Rule 1 of the Destination Address Selection, and are also not part of
the superseding considerations described above.
The discovery and connection process for the relay addresses in the
above described ordering MAY operate in parallel, subject to delays
prescribed by the Happy Eyeballs requirements described in Section 5
of [RFC8305] for successively launched concurrent connection
attempts.
2.4.3. Connecting to Multiple Relays
In some deployments, it may be useful for a gateway to connect to
multiple upstream relays and subscribe to the same traffic, in order
to support an active/active failover model. A gateway SHOULD NOT be
configured to do so without guaranteeing that adequate bandwidth is
available.
A gateway configured to do this SHOULD still use the same preference
ordering logic from Section 2.4.2 for both connections. (Note that
this ordering allows for overriding by explicit administrative
configuration where required.)
2.5. Guidelines for Restarting Discovery
2.5.1. Overview
It's expected that gateways deployed in different environments will It's expected that gateways deployed in different environments will
use a variety of heuristics to decide when it's appropriate to use a variety of heuristics to decide when it's appropriate to
restart the relay discovery process, in order to meet different restart the relay discovery process, in order to meet different
performance goals (for example, to fulfill different kinds of service performance goals (for example, to fulfill different kinds of service
level agreements). level agreements).
The advice in this section should be treated as non-normative In general, restarting the discovery process is always safe for the
gateway and relay during any of the events listed in this section,
but may cause a disruption in the forwarded traffic if the discovery
process results in choosing a different relay, because this changes
the RPF forwarding tree for the multicast traffic upstream of the
gateway. This is likely to result in some dropped or duplicated
packets from channels actively being tunneled from the old relay to
the gateway.
The degree of impact on the traffic from choosing a different relay
may depend on network conditions between the gateway and the new
relay, as well as the network conditions and topology between the
sender and the new relay, as this may cause the relay to propagate a
new RPF join toward the sender.
Balancing the expected impact on the tunneled traffic against likely
or observed problems with an existing connection to the relay is the
goal of the heuristics that gateways use to determine when to restart
the discovery process.
The non-normative advice in this section should be treated as
guidelines to operators and implementors working with AMT systems guidelines to operators and implementors working with AMT systems
that can use DRIAD as part of the relay discovery process. that can use DRIAD as part of the relay discovery process.
2.5.2. Updates to Restarting Events
Section 5.2.3.4.1 of [RFC7450] lists several events that may cause a Section 5.2.3.4.1 of [RFC7450] lists several events that may cause a
gateway to start or restart the discovery procedure. gateway to start or restart the discovery procedure.
This document provides some updates and recommendations regarding the This document provides some updates and recommendations regarding the
handling of these and similar events. The events are copied here and handling of these and similar events. The first 5 events are copied
numbered for easier reference: here and numbered for easier reference, and the following events are
newly added for consideration in this document:
1. When a gateway pseudo-interface is started (enabled). 1. When a gateway pseudo-interface is started (enabled).
2. When the gateway wishes to report a group subscription when none 2. When the gateway wishes to report a group subscription when none
currently exist. currently exist.
3. Before sending the next Request message in a membership update 3. Before sending the next Request message in a membership update
cycle. cycle.
4. After the gateway fails to receive a response to a Request 4. After the gateway fails to receive a response to a Request
message. message.
5. After the gateway receives a Membership Query message with the L 5. After the gateway receives a Membership Query message with the L
flag set to 1. flag set to 1.
There are several new events that gateway heuristics may 6. When the gateway wishes to report a (S,G) subscription with a
appropriately use to restart the discovery process, including:
1. When the gateway wishes to report a (S,G) subscription with a
source address that does not currently have other group source address that does not currently have other group
subscriptions. subscriptions.
2. When the DNS TTL expires for an AMTRELAY RR or for a domain name 7. When there is a network change detected, for example when a
contained within the AMTRELAY RR.
3. When there is a network change detected, for example when a
gateway is operating inside an end user device or application, gateway is operating inside an end user device or application,
and the device joins a different network, or when the domain and the device joins a different network, or when the domain
portion of a DNS-SD domain name changes in response to a DHCP portion of a DNS-SD domain name changes in response to a DHCP
message or administrative configuration. message or administrative configuration.
4. When loss or congestion is detected in the stream of AMT packets 8. When congestion or substantial loss is detected in the stream of
from a relay. AMT packets from a relay.
This list is not exhaustive, nor are any of the listed events always 9. When the gateway has reported one or more (S,G) subscriptions,
strictly required to force a restart of the discovery process. but no traffic is received from the source for some timeout.
(See Section 2.5.4.1).
This list is not exhaustive, nor are any of the listed events
strictly required to always force a restart of the discovery process.
Note that during event #1, a gateway may use DNS-SD, but does not Note that during event #1, a gateway may use DNS-SD, but does not
have sufficient information to use DRIAD, since no source is known. have sufficient information to use DRIAD, since no source is known.
2.4.2. Tunnel Stability 2.5.3. Tunnel Stability
In general, subscribers to active traffic flows that are being In general, subscribers to active traffic flows that are being
forwarded by an AMT gateway are less likely to experience a forwarded by an AMT gateway are less likely to experience a
degradation in service (for example, from missing or duplicated degradation in service (for example, from missing or duplicated
packets) when the gateway continues using the same relay, as long the packets) when the gateway continues using the same relay, as long the
relay is not overloaded and the network conditions remain stable. relay is not overloaded and the network conditions remain stable.
Therefore, gateways should avoid performing a full restart of the Therefore, gateways SHOULD avoid performing a full restart of the
discovery process during routine cases of event #3 (sending a new discovery process during routine cases of event #3 (sending a new
Request message), but see Section 2.4.3 and Section 2.4.5 for more Request message), since it occurs frequently in normal operation.
information about exceptions when it may be appropriate to use this
event.
Likewise, some operators might use a short DNS TTL expiration (event However, see Section 2.5.4, Section 2.5.6, and Section 2.5.4.3 for
#7) to allow for more responsive load balancing. If a gateway more information about exceptional cases when it may be appropriate
frequently sees short DNS TTLs (for example, under approximately 15 to use event #3.
minutes) for some sources, a helpful heuristic may be to avoid
restarting the discovery process for those sources, for example with
an exponential backoff, or a hold-down timer that depends on the
health or bit-rate of the active and subscribed traffic currently
being forwarded through the tunnel.
2.4.3. Flow Health 2.5.4. Traffic Health
In some gateway deployments, it is feasible to monitor the health of 2.5.4.1. Absence of Traffic
traffic flows through the gateway, for example by detecting the rate
of packet loss by communicating out of band with clients, or If a gateway indicates one or more (S,G) subscriptions in a
monitoring packets of known protocols with sequence numbers. Where Membership Update message, but no traffic for any of the (S,G)s is
feasible, it's encouraged for gateways to use such traffic health received in a reasonable time, it's appropriate for the gateway to
information to trigger a restart of the discovery process during restart the discovery process.
event #3 (before sending a new Request message).
If the gateway restarts the discovery process multiple times
consecutively for this reason, the timeout period SHOULD be adjusted
to provide a random exponential back-off.
The RECOMMENDED timeout is a random value in the range
[initial_timeout, MIN(initial_timeout * 2^retry_count,
maximum_timeout)], with a RECOMMENDED initial_timeout of 4 seconds
and a RECOMMENDED maximum_timeout of 120 seconds.
Note that the recommended initial_timeout is larger than the initial
timout recommended in the similar algorithm from Section 5.2.3.4.3 of
[RFC7450]. This is to provide time for RPF Join propagation in the
sending network. Although the timeout values may be administratively
adjusted to support performance requirements, operators are advised
to consider the possibility of join propagation delays between the
sender and the relay when choosing an appropriate timeout value.
Gateways restarting the discovery process because of an absence of
traffic MUST use a hold-down timer that removes this relay from
consideration during subsequent rounds of discovery while active.
The hold-down SHOULD last for no less than 3 minutes and no more than
10 minutes.
2.5.4.2. Loss and Congestion
In some gateway deployments, it is also feasible to monitor the
health of traffic flows through the gateway, for example by detecting
the rate of packet loss by communicating out of band with receivers,
or monitoring the packets of known protocols with sequence numbers.
Where feasible, it's encouraged for gateways to use such traffic
health information to trigger a restart of the discovery process
during event #3 (before sending a new Request message).
However, to avoid synchronized rediscovery by many gateways However, to avoid synchronized rediscovery by many gateways
simultaneously after a transient network event upstream of a relay simultaneously after a transient network event upstream of a relay
results in many receivers detecting poor flow health at the same results in many receivers detecting poor flow health at the same
time, it's recommended to add a random delay before restarting the time, it's recommended to add a random delay before restarting the
discovery process in this case. discovery process in this case.
The span of the random portion of the delay should be no less than 10 The span of the random portion of the delay should be no less than 10
seconds by default, but may be administratively configured to support seconds by default, but may be administratively configured to support
different performance requirements. different performance requirements.
2.4.4. Relay Loading and Shutdown 2.5.4.3. Ancient Discovery Information
The L flag (see Section 5.1.4.4 of [RFC7450] is the preferred In most cases, a gateway actively receiving healthy traffic from a
relay that has not indicated load with the L flag should prefer to
remain connected to the same relay, as described in Section 2.5.3.
However, a relay that appears healthy but has been forwarding traffic
for days or weeks may have an increased chance of becoming unstable.
Gateways may benefit from restarting the discovery process during
event #3 (before sending a Request message) after the expiration of a
long-term timeout, on the order of multiple hours, or even days in
some deployments.
It may be beneficial for such timers to consider the amount of
traffic currently being forwarded, and to give a higher probability
of restarting discovery during periods with an unusually low data
rate, to reduce the impact on active traffic while still avoiding
relying on the results of a very old discovery.
Other issues may also be worth considering as part of this heuristic;
for example, if the DNS expiry time of the record that was used to
discover the current relay has not passed, the long term timer might
be restarted without restarting the discovery process.
2.5.5. Relay Loaded or Shutting Down
The L flag (see Section 5.1.4.4 of [RFC7450]) is the preferred
mechanism for a relay to signal overloading or a graceful shutdown to mechanism for a relay to signal overloading or a graceful shutdown to
gateways. gateways.
A gateway that supports handling of the L flag should generally A gateway that supports handling of the L flag should generally
restart the discovery process when it processes a Membership Query restart the discovery process when it processes a Membership Query
packet with the L flag set. It is also recommended that gateways packet with the L flag set. If an L flag is received while a
avoid choosing a relay that has recently sent an L flag, with concurrent Happy Eyeballs discovery process is under way for multiple
approximately a 10-minute hold-down. Gateways MAY use heuristics candidate relays (Section 2.3), the relay sending the L flag SHOULD
such as this hold-down to override selection of a relay preferred by NOT be considered for the relay selection.
the precedence field in the AMTRELAY RR (see Section 4.2.1).
2.4.5. Relay Discovery Messages vs. Restarting Discovery It is also RECOMMENDED that gateways avoid choosing a relay that has
recently sent an L flag, with approximately a 10-minute hold-down.
Gateways SHOULD treat this hold-down timer in the same way as the
hold-down in Section 2.5.4.1, so that the relay is removed from
consideration for short-term subsequent rounds of discovery.
2.5.6. Relay Discovery Messages vs. Restarting Discovery
A gateway should only send DNS queries with the AMTRELAY RRType or A gateway should only send DNS queries with the AMTRELAY RRType or
the DNS-SD DNS queries for an AMT service as part of starting or the DNS-SD DNS queries for an AMT service as part of starting or
restarting the discovery process. restarting the discovery process.
However, all AMT relays are required to support handling of Relay However, all AMT relays are required to support handling of Relay
Discovery messages (e.g. in Section 5.3.3.2 of [RFC7450]). Discovery messages (e.g. in Section 5.3.3.2 of [RFC7450]).
So a gateway with an existing connection to a relay can send a Relay So a gateway with an existing connection to a relay can send a Relay
Discovery message to the unicast address of that AMT relay. Under Discovery message to the unicast address of that AMT relay. Under
stable conditions with an unloaded relay, it's expected that the stable conditions with an unloaded relay, it's expected that the
relay will return its own unicast address in the Relay Advertisement, relay will return its own unicast address in the Relay Advertisement,
in response to such a Relay Discovery message. Since this will not in response to such a Relay Discovery message. Since this will not
result in the gateway changing to another relay unless the relay result in the gateway changing to another relay unless the relay
directs the gateway away, this is a reasonable exception to the directs the gateway away, this is a reasonable exception to the
advice against handling event #3 described in Section 2.4.2. advice against handling event #3 described in Section 2.5.3.
This behavior is discouraged for gateways that do support the L flag, This behavior is discouraged for gateways that do support the L flag,
to avoid sending unnecessary packets over the network. to avoid sending unnecessary packets over the network.
However, gateways that do not support the L flag may be able to avoid However, gateways that do not support the L flag may be able to avoid
a disruption in the forwarded traffic by sending such Relay Discovery a disruption in the forwarded traffic by sending such Relay Discovery
messages regularly. When a relay is under load or has started a messages regularly. When a relay is under load or has started a
graceful shutdown, it may respond with a different relay address, graceful shutdown, it may respond with a different relay address,
which the gateway can use to connect to a different relay. This kind which the gateway can use to connect to a different relay. This kind
of coordinated handoff will likely result in a smaller disruption to of coordinated handoff will likely result in a smaller disruption to
skipping to change at page 13, line 5 skipping to change at page 17, line 45
messages, and stops forwarding traffic. messages, and stops forwarding traffic.
This style of Relay Discovery message (one sent to the unicast This style of Relay Discovery message (one sent to the unicast
address of a relay that's already forwarding traffic to this gateway) address of a relay that's already forwarding traffic to this gateway)
should not be considered a full restart of the relay discovery should not be considered a full restart of the relay discovery
process. It is recommended for gateways to support the L flag, but process. It is recommended for gateways to support the L flag, but
for gateways that do not support the L flag, sending this message for gateways that do not support the L flag, sending this message
during event #3 may help mitigate service degradation when relays during event #3 may help mitigate service degradation when relays
become unstable. become unstable.
2.4.6. Connecting to Multiple Relays 2.5.7. Independent Discovery Per Traffic Source
Relays discovered via the AMTRELAY RR are source-specific relay Relays discovered via the AMTRELAY RR are source-specific relay
addresses, and may use different pseudo-interfaces from each other addresses, and may use different pseudo-interfaces from each other
and from relays discovered via DNS-SD or a non-source-specific and from relays discovered via DNS-SD or a non-source-specific
address, as described in Section 4.1.2.1 of [RFC7450]. address, as described in Section 4.1.2.1 of [RFC7450].
Restarting the discovery process for one pseudo-interface does not Restarting the discovery process for one pseudo-interface does not
require restarting the discovery process for other pseudo-interfaces. require restarting the discovery process for other pseudo-interfaces.
Gateway heuristics about restarting the discovery process should Gateway heuristics about restarting the discovery process should
operate independently for different tunnels to relays, when operate independently for different tunnels to relays, when
responding to events that are specific to the different tunnels. responding to events that are specific to the different tunnels.
2.5. DNS Configuration 2.6. DNS Configuration
Often an AMT gateway will only have access to the source and group IP Often an AMT gateway will only have access to the source and group IP
addresses of the desired traffic, and will not know any other name addresses of the desired traffic, and will not know any other name
for the source of the traffic. Because of this, typically the best for the source of the traffic. Because of this, typically the best
way of looking up AMTRELAY RRs will be by using the source IP address way of looking up AMTRELAY RRs will be by using the source IP address
as an index into one of the reverse mapping trees (in-addr.arpa for 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, IPv4, as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6,
as described in Section 2.5 of [RFC3596]). as described in Section 2.5 of [RFC3596]).
Therefore, it is RECOMMENDED that AMTRELAY RRs be added to reverse IP Therefore, it is RECOMMENDED that AMTRELAY RRs be added to reverse IP
skipping to change at page 13, line 41 skipping to change at page 18, line 34
mapping for the source from an (S,G) in order to be useful to most mapping for the source from an (S,G) in order to be useful to most
AMT gateways. AMT gateways.
When performing the AMTRELAY RR lookup, any CNAMEs or DNAMEs found When performing the AMTRELAY RR lookup, any CNAMEs or DNAMEs found
MUST be followed. This is necessary to support zone delegation. MUST be followed. This is necessary to support zone delegation.
Some examples outlining this need are described in [RFC2317]. Some examples outlining this need are described in [RFC2317].
See Section 4 and Section 4.3 for a detailed explanation of the See Section 4 and Section 4.3 for a detailed explanation of the
contents for a DNS Zone file. contents for a DNS Zone file.
2.6. Waiting for DNS resolution 2.7. Waiting for DNS resolution
The DNS query functionality is expected to follow ordinary standards The DNS query functionality is expected to follow ordinary standards
and best practices for DNS clients. A gateway MAY use an existing and best practices for DNS clients. A gateway MAY use an existing
DNS client implementation that does so, and MAY rely on that client's DNS client implementation that does so, and MAY rely on that client's
retry logic to determine the timeouts between retries. retry logic to determine the timeouts between retries.
Otherwise, a gateway MAY re-send a DNS query if it does not receive Otherwise, a gateway MAY re-send a DNS query if it does not receive
an appropriate DNS response within some timeout period. If the an appropriate DNS response within some timeout period. If the
gateway retries multiple times, the timeout period SHOULD be adjusted gateway retries multiple times, the timeout period SHOULD be adjusted
to provide a random exponential back-off. to provide a random exponential back-off.
skipping to change at page 17, line 40 skipping to change at page 21, line 40
Figure 5: Small Office Example Figure 5: Small Office Example
When multicast-capable networks are chained like this, with a network When multicast-capable networks are chained like this, with a network
like the one in Figure 5 receiving internet services from a like the one in Figure 5 receiving internet services from a
multicast-capable network like the one in Figure 3, it's important multicast-capable network like the one in Figure 3, it's important
for AMT gateways to reach the more local AMT relay, in order to avoid for AMT gateways to reach the more local AMT relay, in order to avoid
accidentally tunneling multicast traffic from a more distant AMT accidentally tunneling multicast traffic from a more distant AMT
relay with unicast, and failing to utilize the multicast transport relay with unicast, and failing to utilize the multicast transport
capabilities of the network in Figure 3. capabilities of the network in Figure 3.
For this reason, it's RECOMMENDED that AMT gateways by default
perform service discovery using DNS Service Discovery (DNS-SD)
[RFC6763] for _amt._udp.<domain> (with <domain> chosen as described
in Section 11 of [RFC6763]) and use the AMT relays discovered that
way in preference to AMT relays discoverable via the mechanism
defined in this document (DRIAD).
It's also RECOMMENDED that when 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 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 discover the most-
preferred relay first by DNS-SD, then by DRIAD as described in this
document (in precedence order, as described in Section 4.2.1), then
with the anycast addresses defined in Section 7 of [RFC7450] (namely:
192.52.193.1 and 2001:3::1) if those IPs weren't listed in the
AMTRELAY RRs. This default behavior MAY be overridden by
administrative configuration where other behavior is more appropriate
for the gateway within its network.
The discovery and connection process for multiple relays MAY operate
in parallel, but when forwarding multicast group membership reports
with new joins from an AMT gateway, membership reports SHOULD be
forwarded to the most-preferred relays first, falling back to less
preferred relays only after failing to receive traffic for an
appropriate timeout, and only after reporting a leave to any more-
preferred connected relays that have failed to subscribe to the
traffic.
It is RECOMMENDED that the default timeout for receiving traffic be
no less than 3 seconds, but the value MAY be overridden by
administrative configuration, where known groups or channels need a
different timeout for successful application performance.
3.2. Example Sending Networks 3.2. Example Sending Networks
3.2.1. Sender-controlled Relays 3.2.1. Sender-controlled Relays
When a sender network is also operating AMT relays to distribute When a sender network is also operating AMT relays to distribute
multicast traffic, as in Figure 6, each address could appear as an multicast traffic, as in Figure 6, each address could appear as an
AMTRELAY RR for the reverse IP of the sender, or one or more domain AMTRELAY RR for the reverse IP of the sender, or one or more domain
names could appear in AMTRELAY RRs, and the AMT relay addresses can names could appear in AMTRELAY RRs, and the AMT relay addresses can
be discovered by finding an A or AAAA record from those domain names. be discovered by finding a A or AAAA records from those domain names.
Sender Network Sender Network
+-----------------------------------+ +-----------------------------------+
| | | |
| +--------+ +=======+ +=======+ | | +--------+ +=======+ +=======+ |
| | Sender | | AMT | | AMT | | | | Sender | | AMT | | AMT | |
| +--------+ | relay | | relay | | | +--------+ | relay | | relay | |
| | +=======+ +=======+ | | | +=======+ +=======+ |
| | | | | | | | | |
| +-----+------+----------+ | | +-----+------+----------+ |
skipping to change at page 19, line 28 skipping to change at page 22, line 28
(non-multicast) (non-multicast)
Figure 6: Small Office Example Figure 6: Small Office Example
3.2.2. Provider-controlled Relays 3.2.2. Provider-controlled Relays
When an ISP offers a service to transmit outbound multicast traffic When an ISP offers a service to transmit outbound multicast traffic
through a forwarding network, it might also offer AMT relays in order through a forwarding network, it might also offer AMT relays in order
to reach receivers without multicast connectivity to the forwarding to reach receivers without multicast connectivity to the forwarding
network, as in Figure 7. In this case it's RECOMMENDED that the ISP network, as in Figure 7. In this case it's RECOMMENDED that the ISP
also provide a domain name for the AMT relays for use with the also provide at least one domain name for the AMT relays for use with
discovery process defined in this document. the AMTRELAY RR.
When the sender wishes to use the relays provided by the ISP for When the sender wishes to use the relays provided by the ISP for
forwarding multicast traffic, an AMTRELAY RR should be configured to forwarding multicast traffic, an AMTRELAY RR should be configured to
use the domain name provided by the ISP, to allow for address use the domain name provided by the ISP, to allow for address
reassignment of the relays without forcing the sender to reconfigure reassignment of the relays without forcing the sender to reconfigure
the corresponding AMTRELAY RRs. the corresponding AMTRELAY RRs.
+--------+ +--------+
| Sender | | Sender |
+---+----+ Multicast-enabled +---+----+ Multicast-enabled
skipping to change at page 20, line 34 skipping to change at page 23, line 34
v v v v
Internet Internet
(non-multicast) (non-multicast)
Figure 7: Sending ISP Example Figure 7: Sending ISP Example
4. AMTRELAY Resource Record Definition 4. AMTRELAY Resource Record Definition
4.1. AMTRELAY RRType 4.1. AMTRELAY RRType
The AMTRELAY RRType has the mnemonic AMTRELAY and type code TBD1 The AMTRELAY RRType has the mnemonic AMTRELAY and type code 260
(decimal). (decimal).
The AMTRELAY RR is class independent.
4.2. AMTRELAY RData Format 4.2. AMTRELAY RData Format
The AMTRELAY RData consists of a 8-bit precedence field, a 1-bit The AMTRELAY RData consists of a 8-bit precedence field, a 1-bit
"Discovery Optional" field, a 7-bit type field, and a variable length "Discovery Optional" field, a 7-bit type field, and a variable length
relay field. relay field.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| precedence |D| type | | | precedence |D| type | |
skipping to change at page 21, line 14 skipping to change at page 24, line 14
4.2.1. RData Format - Precedence 4.2.1. RData Format - Precedence
This is an 8-bit precedence for this record. It is interpreted in This is an 8-bit precedence for this record. It is interpreted in
the same way as the PREFERENCE field described in Section 3.3.9 of the same way as the PREFERENCE field described in Section 3.3.9 of
[RFC1035]. [RFC1035].
Relays listed in AMTRELAY records with a lower value for precedence Relays listed in AMTRELAY records with a lower value for precedence
are to be attempted first. are to be attempted first.
Where there is a tie in precedence, the default choice of relay MUST
be non-deterministic, to support load balancing. The AMT gateway
operator MAY override this default choice with explicit configuration
when it's necessary for administrative purposes.
For example, one network might prefer to tunnel IPv6 multicast
traffic over IPv6 AMT and IPv4 multicast traffic over IPv4 AMT to
avoid routeability problems in IPv6 from affecting IPv4 traffic and
vice versa, while another network might prefer to tunnel both kinds
of traffic over IPv6 to reduce the IPv4 space used by its AMT
gateways. In this example scenario or other cases where there is an
administrative preference that requires explicit configuration, a
receiving network MAY make systematically different precedence
choices among records with the same precedence value.
4.2.2. RData Format - Discovery Optional (D-bit) 4.2.2. RData Format - Discovery Optional (D-bit)
The D bit is a "Discovery Optional" flag. The D bit is a "Discovery Optional" flag.
If the D bit is set to 0, a gateway using this RR MUST perform AMT If the D bit is set to 0, a gateway using this RR MUST perform AMT
relay discovery as described in Section 4.2.1.1 of [RFC7450], rather relay discovery as described in Section 4.2.1.1 of [RFC7450], rather
than directly sending an AMT request message to the relay. than directly sending an AMT Request message to the relay.
That is, the gateway MUST receive an AMT relay advertisement message That is, the gateway MUST receive an AMT Relay Advertisement message
(Section 5.1.2 of [RFC7450]) for an address before sending an AMT (Section 5.1.2 of [RFC7450]) for an address before sending an AMT
request message (Section 5.1.3 of [RFC7450]) to that address. Before Request message (Section 5.1.3 of [RFC7450]) to that address. Before
receiving the relay advertisement message, this record has only receiving the Relay Advertisement message, this record has only
indicated that the address can be used for AMT relay discovery, not indicated that the address can be used for AMT relay discovery, not
for a request message. This is necessary for devices that are not for a Request message. This is necessary for devices that are not
fully functional AMT relays, but rather load balancers or brokers, as fully functional AMT relays, but rather load balancers or brokers, as
mentioned in Section 4.2.1.1 of [RFC7450]. mentioned in Section 4.2.1.1 of [RFC7450].
If the D bit is set to 1, the gateway MAY send an AMT request message If the D bit is set to 1, the gateway MAY send an AMT Request message
directly to the discovered relay address without first sending an AMT directly to the discovered relay address without first sending an AMT
discovery message. Discovery message.
This bit should be set according to advice from the AMT relay This bit should be set according to advice from the AMT relay
operator. The D bit MUST be set to zero when no information is operator. The D bit MUST be set to zero when no information is
available from the AMT relay operator about its suitability. available from the AMT relay operator about its suitability.
4.2.3. RData Format - Type 4.2.3. RData Format - Type
The type field indicates the format of the information that is stored The type field indicates the format of the information that is stored
in the relay field. in the relay field.
skipping to change at page 22, line 46 skipping to change at page 25, line 33
When the type field is 2, the length of the relay field is 16 octets, When the type field is 2, the length of the relay field is 16 octets,
and a 128-bit IPv6 address is present. This is an IPv6 address as and a 128-bit IPv6 address is present. This is an IPv6 address as
described in Section 2.2 of [RFC3596]. This is a 128-bit number in described in Section 2.2 of [RFC3596]. This is a 128-bit number in
network byte order. network byte order.
When the type field is 3, the relay field is a normal wire-encoded When the type field is 3, the relay field is a normal wire-encoded
domain name, as described in Section 3.3 of [RFC1035]. Compression domain name, as described in Section 3.3 of [RFC1035]. Compression
MUST NOT be used, for the reasons given in Section 4 of [RFC3597]. MUST NOT be used, for the reasons given in Section 4 of [RFC3597].
For a type 3 record, the D-bit and preference fields carry over to
all A or AAAA records for the domain name. There is no difference in
the result of the discovery process when it's obtained by type 1 or
type 2 AMTRELAY records with identical D-bit and preference fields,
vs. when the result is obtained by a type 3 AMTRELAY record that
resolves to the same set of IPv4 and IPv6 addresses via A and AAAA
lookups.
4.3. AMTRELAY Record Presentation Format 4.3. AMTRELAY Record Presentation Format
4.3.1. Representation of AMTRELAY RRs 4.3.1. Representation of AMTRELAY RRs
AMTRELAY RRs may appear in a zone data master file. The precedence, AMTRELAY RRs may appear in a zone data master file. The precedence,
D-bit, relay type, and relay fields are REQUIRED. D-bit, relay type, and relay fields are REQUIRED.
If the relay type field is 0, the relay field MUST be ".". If the relay type field is 0, the relay field MUST be ".".
The presentation for the record is as follows: The presentation for the record is as follows:
skipping to change at page 23, line 33 skipping to change at page 26, line 27
traffic from the source 198.51.100.10. The IPv4 and IPv6 addresses traffic from the source 198.51.100.10. The IPv4 and IPv6 addresses
are configured with a D-bit of 0 (meaning discovery is mandatory, as 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 described in Section 4.2.2), and a precedence 10 (meaning they're
preferred ahead of the last entry, which has precedence 128). preferred ahead of the last entry, which has precedence 128).
For zone files in name servers that don't support the AMTRELAY RRType 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 natively, it's possible to use the format for unknown RR types, as
described in [RFC3597]. This approach would replace the AMTRELAY described in [RFC3597]. This approach would replace the AMTRELAY
entries in the example above with the entries below: entries in the example above with the entries below:
[To be removed (TBD): replace 65280 with the IANA-assigned value 10 IN TYPE260 \# (
TBD1, here and in Appendix B. ]
10 IN TYPE65280 \# (
6 ; length 6 ; length
0a ; precedence=10 0a ; precedence=10
01 ; D=0, relay type=1, an IPv4 address 01 ; D=0, relay type=1, an IPv4 address
cb00710f ) ; 203.0.113.15 cb00710f ) ; 203.0.113.15
10 IN TYPE65280 \# ( 10 IN TYPE260 \# (
18 ; length 18 ; length
0a ; precedence=10 0a ; precedence=10
02 ; D=0, relay type=2, an IPv6 address 02 ; D=0, relay type=2, an IPv6 address
20010db800000000000000000000000f ) ; 2001:db8::15 20010db800000000000000000000000f ) ; 2001:db8::15
10 IN TYPE65280 \# ( 10 IN TYPE260 \# (
24 ; length 24 ; length
80 ; precedence=128 80 ; precedence=128
83 ; D=1, relay type=3, a wire-encoded domain name 83 ; D=1, relay type=3, a wire-encoded domain name
09616d7472656c617973076578616d706c6503636f6d ) ; domain name 09616d7472656c617973076578616d706c6503636f6d ) ; domain name
See Appendix B for more details. See Appendix A for more details.
5. IANA Considerations 5. IANA Considerations
This document updates the IANA Registry for DNS Resource Record Types This document updates the IANA Registry for DNS Resource Record Types
by assigning type TBD1 to the AMTRELAY record. by assigning type 260 to the AMTRELAY record.
This document creates a new registry named "AMTRELAY Resource Record This document creates a new registry named "AMTRELAY Resource Record
Parameters", with a sub-registry for the "Relay Type Field". The Parameters", with a sub-registry for the "Relay Type Field". The
initial values in the sub-registry are: initial values in the sub-registry are:
+-------+---------------------------------------+ +-------+---------------------------------------+
| Value | Description | | Value | Description |
+-------+---------------------------------------+ +-------+---------------------------------------+
| 0 | No relay is present. | | 0 | No relay is present. |
| 1 | A 4-byte IPv4 address is present | | 1 | A 4-byte IPv4 address is present |
skipping to change at page 26, line 24 skipping to change at page 29, line 15
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source- Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, Specific Multicast", RFC 4604, DOI 10.17487/RFC4604,
August 2006, <https://www.rfc-editor.org/info/rfc4604>. August 2006, <https://www.rfc-editor.org/info/rfc4604>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<https://www.rfc-editor.org/info/rfc4607>. <https://www.rfc-editor.org/info/rfc4607>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/info/rfc6763>.
[RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450,
DOI 10.17487/RFC7450, February 2015, DOI 10.17487/RFC7450, February 2015,
<https://www.rfc-editor.org/info/rfc7450>. <https://www.rfc-editor.org/info/rfc7450>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>.
8.2. Informative References 8.2. Informative References
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
ADDR.ARPA delegation", BCP 20, RFC 2317, ADDR.ARPA delegation", BCP 20, RFC 2317,
DOI 10.17487/RFC2317, March 1998, DOI 10.17487/RFC2317, March 1998,
<https://www.rfc-editor.org/info/rfc2317>. <https://www.rfc-editor.org/info/rfc2317>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying
Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March
2005, <https://www.rfc-editor.org/info/rfc4025>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
[RFC5110] Savola, P., "Overview of the Internet Multicast Routing [RFC5110] Savola, P., "Overview of the Internet Multicast Routing
Architecture", RFC 5110, DOI 10.17487/RFC5110, January Architecture", RFC 5110, DOI 10.17487/RFC5110, January
2008, <https://www.rfc-editor.org/info/rfc5110>. 2008, <https://www.rfc-editor.org/info/rfc5110>.
[RFC5507] IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch,
Ed., "Design Choices When Expanding the DNS", RFC 5507,
DOI 10.17487/RFC5507, April 2009,
<https://www.rfc-editor.org/info/rfc5507>.
[RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen,
"FLUTE - File Delivery over Unidirectional Transport", "FLUTE - File Delivery over Unidirectional Transport",
RFC 6726, DOI 10.17487/RFC6726, November 2012, RFC 6726, DOI 10.17487/RFC6726, November 2012,
<https://www.rfc-editor.org/info/rfc6726>. <https://www.rfc-editor.org/info/rfc6726>.
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
April 2013, <https://www.rfc-editor.org/info/rfc6895>.
[RFC7359] Gont, F., "Layer 3 Virtual Private Network (VPN) Tunnel [RFC7359] Gont, F., "Layer 3 Virtual Private Network (VPN) Tunnel
Traffic Leakages in Dual-Stack Hosts/Networks", RFC 7359, Traffic Leakages in Dual-Stack Hosts/Networks", RFC 7359,
DOI 10.17487/RFC7359, August 2014, DOI 10.17487/RFC7359, August 2014,
<https://www.rfc-editor.org/info/rfc7359>. <https://www.rfc-editor.org/info/rfc7359>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>. 2016, <https://www.rfc-editor.org/info/rfc7761>.
skipping to change at page 28, line 9 skipping to change at page 30, line 45
[RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T., [RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T.,
Ed., and R. Krishnan, "Use of Multicast across Inter- Ed., and R. Krishnan, "Use of Multicast across Inter-
domain Peering Points", BCP 213, RFC 8313, domain Peering Points", BCP 213, RFC 8313,
DOI 10.17487/RFC8313, January 2018, DOI 10.17487/RFC8313, January 2018,
<https://www.rfc-editor.org/info/rfc8313>. <https://www.rfc-editor.org/info/rfc8313>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
Appendix A. New RRType Request Form Appendix A. Unknown RRType construction
This is the template for requesting a new RRType recommended in
Appendix A of [RFC6895].
A. Submission Date:
B.1 Submission Type:
[x] New RRTYPE [ ] Modification to RRTYPE
B.2 Kind of RR:
[x] Data RR [ ] Meta-RR
C. Contact Information for submitter (will be publicly posted):
Name: Jake Holland
Email Address: jakeholland.net@gmail.com
International telephone number: +1-626-486-3706
Other contact handles: jholland@akamai.com
D. Motivation for the new RRTYPE application.
It provides a bootstrap so AMT (RFC 7450) gateways can discover
an AMT relay that can receive multicast traffic from a specific source,
in order to signal multicast group membership and receive multicast
traffic over a unicast tunnel using AMT.
E. Description of the proposed RR type.
This description can be provided in-line in the template, as an
attachment, or with a publicly available URL.
Please see draft-ietf-mboned-driad-amt-discovery.
F. What existing RRTYPE or RRTYPEs come closest to filling that need
and why are they unsatisfactory?
Some similar concepts appear in IPSECKEY, as described in
Section 1.2 of [RFC4025]. The IPSECKEY RRType is unsatisfactory
because it refers to IPSec Keys instead of to AMT relays, but
the motivating considerations for using reverse IP and for
providing a precedence are similar--an AMT gateway often
has access to a source address for a multicast (S,G), but does
not have access to a relay address that can receive multicast
traffic from the source, without administrative configuration.
Defining a format for a TXT record could serve the need for AMT
relay discovery semantics, but Section 5 of [RFC5507] provides a
compelling argument for requesting a new RRType instead.
G. What mnemonic is requested for the new RRTYPE (optional)?
AMTRELAY
H. Does the requested RRTYPE make use of any existing IANA registry
or require the creation of a new IANA subregistry in DNS
Parameters?
Yes, IANA is requested to create a subregistry named "AMT Relay
Type Field" in a "AMTRELAY Resource Record Parameters" registry.
The field values are defined in Section 4.2.3 and Section 4.2.4,
and a summary table is given in Section 5.
I. Does the proposal require/expect any changes in DNS
servers/resolvers that prevent the new type from being processed
as an unknown RRTYPE (see RFC3597)?
No.
J. Comments:
It may be worth noting that the gateway type field from Section 2.3 of
[RFC4025] and Section 2.5 of [RFC4025] is very similar to the
Relay Type field in this request. I tentatively assume that trying to
re-use that sub-registry is a worse idea than duplicating it, but I'll
invite others to consider the question and voice an opinion, in case
there is a different consensus.
https://www.ietf.org/assignments/
ipseckey-rr-parameters/ipseckey-rr-parameters.xml
Appendix B. Unknown RRType construction
In a DNS resolver that understands the AMTRELAY type, the zone file In a DNS resolver that understands the AMTRELAY type, the zone file
might contain this line: might contain this line:
IN AMTRELAY 128 0 3 amtrelays.example.com. IN AMTRELAY 128 0 3 amtrelays.example.com.
In order to translate this example to appear as an unknown RRType as In order to translate this example to appear as an unknown RRType as
defined in [RFC3597], one could run the following program: defined in [RFC3597], one could run the following program:
<CODE BEGINS> <CODE BEGINS>
$ cat translate.py $ cat translate.py
#!/usr/bin/env python3 #!/usr/bin/env python3
import sys import sys
name=sys.argv[1] name=sys.argv[1]
wire='' wire=''
for dn in name.split('.'): for dn in name.split('.'):
if len(dn) > 0: if len(dn) > 0:
wire += ('%02x' % len(dn)) wire += ('%02x' % len(dn))
wire += (''.join('%02x'%ord(x) for x in dn)) wire += (''.join('%02x'%ord(x) for x in dn))
print(len(wire)//2) print(len(wire)//2) + 2
print(wire) print(wire)
$ ./translate.py amtrelays.example.com $ ./translate.py amtrelays.example.com
22 24
09616d7472656c617973076578616d706c6503636f6d 09616d7472656c617973076578616d706c6503636f6d
<CODE ENDS> <CODE ENDS>
The length and the hex string for the domain name The length and the hex string for the domain name
"amtrelays.example.com" are the outputs of this program, yielding a "amtrelays.example.com" are the outputs of this program, yielding a
length of 22 and the above hex string. length of 22 and the above hex string.
22 is the length of the wire-encoded domain name, so to this we add 2 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 (1 for the precedence field and 1 for the combined D-bit and relay
type fields) to get the full length of the RData. 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.
This results in a zone file entry like this: This results in a zone file entry like this:
IN TYPE65280 \# ( 24 ; length IN TYPE260 \# ( 24 ; length
80 ; precedence = 128 80 ; precedence = 128
03 ; D-bit=0, relay type=3 (wire-encoded domain name) 03 ; D-bit=0, relay type=3 (wire-encoded domain name)
09616d7472656c617973076578616d706c6503636f6d ) ; domain name 09616d7472656c617973076578616d706c6503636f6d ) ; domain name
Author's Address Author's Address
Jake Holland Jake Holland
Akamai Technologies, Inc. Akamai Technologies, Inc.
150 Broadway 150 Broadway
Cambridge, MA 02144 Cambridge, MA 02144
 End of changes. 73 change blocks. 
289 lines changed or deleted 419 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/