draft-ietf-mboned-driad-amt-discovery-11.txt   draft-ietf-mboned-driad-amt-discovery-12.txt 
Mboned J. Holland Mboned J. Holland
Internet-Draft Akamai Technologies, Inc. Internet-Draft Akamai Technologies, Inc.
Updates: 7450 (if approved) December 18, 2019 Updates: 7450 (if approved) December 19, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: June 20, 2020 Expires: June 21, 2020
DNS Reverse IP AMT (Automatic Multicast Tunneling) Discovery DNS Reverse IP AMT (Automatic Multicast Tunneling) Discovery
draft-ietf-mboned-driad-amt-discovery-11 draft-ietf-mboned-driad-amt-discovery-12
Abstract Abstract
This document updates RFC 7450 (Automatic Multicast Tunneling, or This document updates RFC 7450 (Automatic Multicast Tunneling, or
AMT) by modifying the relay discovery process. A new DNS resource AMT) by modifying the relay discovery process. A new DNS resource
record named AMTRELAY is defined for publishing AMT relays for record named AMTRELAY is defined for publishing 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. Other multicast traffic from that sender over an AMT tunnel. Other
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 June 20, 2020. This Internet-Draft will expire on June 21, 2020.
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 37 skipping to change at page 2, line 37
2.4.3. Connection Definition . . . . . . . . . . . . . . . . 14 2.4.3. Connection Definition . . . . . . . . . . . . . . . . 14
2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 15 2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 15
2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 15 2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 15
2.5.2. Updates to Restarting Events . . . . . . . . . . . . 16 2.5.2. Updates to Restarting Events . . . . . . . . . . . . 16
2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 17 2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 17
2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 17 2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 17
2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 19 2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 19
2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 19 2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 19
2.5.7. Independent Discovery Per Traffic Source . . . . . . 20 2.5.7. Independent Discovery Per Traffic Source . . . . . . 20
2.6. DNS Configuration . . . . . . . . . . . . . . . . . . . . 20 2.6. DNS Configuration . . . . . . . . . . . . . . . . . . . . 20
2.7. Waiting for DNS resolution . . . . . . . . . . . . . . . 20 2.7. Waiting for DNS resolution . . . . . . . . . . . . . . . 21
3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 21 3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 21
3.1. Example Receiving Networks . . . . . . . . . . . . . . . 21 3.1. Example Receiving Networks . . . . . . . . . . . . . . . 21
3.1.1. Internet Service Provider . . . . . . . . . . . . . . 21 3.1.1. Internet Service Provider . . . . . . . . . . . . . . 21
3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 22 3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 22
3.2. Example Sending Networks . . . . . . . . . . . . . . . . 24 3.2. Example Sending Networks . . . . . . . . . . . . . . . . 24
3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 24 3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 24
3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 25 3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 25
4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 26 4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 26
4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 26 4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 26
4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 26 4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 26
4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 27 4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 27
4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 27 4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 27
4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 27 4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 27
4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 28 4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 28
4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 28 4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 28
4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 28 4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 28
4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 29 4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 29
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
6.1. Use of AMT . . . . . . . . . . . . . . . . . . . . . . . 30 6.1. Use of AMT . . . . . . . . . . . . . . . . . . . . . . . 30
6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 30 6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 30
6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 31 6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 31
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Normative References . . . . . . . . . . . . . . . . . . 31 8.1. Normative References . . . . . . . . . . . . . . . . . . 32
8.2. Informative References . . . . . . . . . . . . . . . . . 33 8.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Unknown RRType construction . . . . . . . . . . . . 35 Appendix A. Unknown RRType construction . . . . . . . . . . . . 35
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36
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.
skipping to change at page 3, line 48 skipping to change at page 3, line 48
solution. DRIAD is a DNS-based solution, as suggested there. This solution. DRIAD is a DNS-based solution, as suggested there. This
solution also addresses the relay discovery issues in the solution also addresses the relay discovery issues in the
"Disadvantages" lists in Section 3.3 of [RFC8313] and Section 3.4 of "Disadvantages" lists in Section 3.3 of [RFC8313] and Section 3.4 of
[RFC8313]. [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 extends the relay discovery procedure described in
extension to the relay discovery procedure. Section 5.2.3.4 of [RFC7450].
1.1. Background 1.1. Background
The reader is assumed to be familiar with the basic DNS concepts The reader is assumed to be familiar with the basic DNS concepts
described in [RFC1034], [RFC1035], and the subsequent documents that described in [RFC1034], [RFC1035], and the subsequent documents that
update them, particularly [RFC2181]. update them, particularly [RFC2181].
The reader is also assumed to be familiar with the concepts and The reader is also assumed to be familiar with the concepts and
terminology regarding source-specific multicast as described in terminology regarding source-specific multicast as described in
[RFC4607] and the use of IGMPv3 [RFC3376] and MLDv2 [RFC3810] for [RFC4607] and the use of IGMPv3 [RFC3376] and MLDv2 [RFC3810] for
skipping to change at page 5, line 22 skipping to change at page 5, line 22
| broker | as mentioned in section 4.2.1.1 of [RFC7450]. | | broker | as mentioned in section 4.2.1.1 of [RFC7450]. |
| | | | | |
| downstream | Further from the source of traffic, as described in | | downstream | Further from the source of traffic, as described in |
| | [RFC7450]. | | | [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.4.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] |
skipping to change at page 5, line 46 skipping to change at page 5, line 46
| upstream | Closer to the source of traffic, as described in | | upstream | Closer to the source of traffic, as described in |
| | [RFC7450]. | | | [RFC7450]. |
| | | | | |
| CMTS | Cable Modem Termination System | | CMTS | Cable Modem Termination System |
| | | | | |
| OLT | Optical Line Terminal | | OLT | Optical Line Terminal |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
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 BCP
[RFC2119] and [RFC8174] when, and only when, they appear in all 14 [RFC2119] [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 a set of AMT relays or publish the IP address or domain name of a set of AMT relays or
discovery brokers that can receive, encapsulate, and forward discovery brokers that can receive, encapsulate, and forward
multicast traffic from a particular sender. multicast traffic from a particular sender.
skipping to change at page 7, line 19 skipping to change at page 7, line 19
multicast-capable internet service provider, which operates a multicast-capable internet service provider, which operates a
receiving network that uses an AMT gateway. The AMT gateway is receiving network that uses an AMT gateway. The AMT gateway is
DRIAD-capable. DRIAD-capable.
The content provider provides the user with a receiving application The content provider provides the user with a receiving application
that tries to subscribe to at least one (S,G). This receiving that tries to subscribe to at least one (S,G). This receiving
application could for example be a file transfer system using FLUTE application could for example be a file transfer system using FLUTE
[RFC6726] or a live video stream using RTP [RFC3550], or any other [RFC6726] or a live video stream using RTP [RFC3550], or any other
application that might subscribe to an SSM channel. application that might subscribe to an SSM channel.
+---------------+ +---------------+
| Sender | | Sender |
| | | 198.51.100.15 | | | | 2001:db8::a |
| | +---------------+ | | +---------------+
|Data| | |Data| |
|Flow| Multicast | |Flow| Multicast |
\| |/ Network | \| |/ Network |
\ / | 5: Propagate RPF for Join(S,G) \ / | 5: Propagate RPF for Join(S,G)
\ / +---------------+ \ / +---------------+
\/ | AMT Relay | \/ | AMT Relay |
| 2001:db8::f | | 2001:db8:c::f |
+---------------+ +---------------+
| 4: Gateway connects to Relay, | 4: Gateway connects to Relay,
sends Join(S,G) over tunnel sends Join(S,G) over tunnel
| |
Unicast Unicast 3: --> DNS Query: type=AMTRELAY,
Tunnel | Tunnel | / a.0.0.0.0.0.0.0.0.0.0.0.
/ 0.0.0.0.0.0.0.0.0.0.0.0.
^ | 3: --> DNS Query: type=AMTRELAY, ^ | / 8.b.d.0.1.0.0.2.ip6.arpa
| / 15.100.51.198.in-addr.arpa. | /
| | / <-- Response: | | / <-- Response:
Join/Leave +-------------+ AMTRELAY=2001:db8::f Join/Leave +-------------+ AMTRELAY=2001:db8:c::f
Signals | AMT gateway | Signals | AMT gateway |
| +-------------+ | +-------------+
| | 2: Propagate RPF for Join(S,G) | | 2: Propagate RPF for Join(S,G)
| Multicast | | Multicast |
Network | Network |
| 1: Join(S=198.51.100.15,G=232.252.0.2) | 1: Join(S=2001:db8::a,G=ff3e::8000:d)
+-------------+ +-------------+
| Receiver | | Receiver |
| (end user) | | (end user) |
+-------------+ +-------------+
Figure 2: DRIAD Messaging Figure 2: DRIAD Messaging
In this simple example, the sender IP is 198.51.100.15, it is sending In this simple example, the sender IP is 2001:db8::a, it is sending
traffic to the group address 232.252.0.2, and the relay IP is traffic to the group address ff3e::8000:d, and the relay IP is
2001:db8::f. 2001:db8::c:f.
The content provider has previously configured the DNS zone that The content provider has previously configured the DNS zone that
contains the domain name "15.100.51.198.in-addr.arpa.", which is the contains the reverse IP domain name for the sender's IP address so
reverse lookup domain name for his sender. The zone file contains an that it provides an AMTRELAY RR with the relay's IP address. (See
AMTRELAY RR with the Relay's IP address. (See Section 4.3 for Section 4.3 for details about the AMTRELAY RR format and semantics.)
details about the AMTRELAY RR format and semantics.) As described in Section 2.5 of [RFC3596], the reverse IP FQDN of the
sender's address "2001:db8::a" is:
a.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.
arpa.
The sequence of events depicted in Figure 2 is as follows: The sequence of events depicted in Figure 2 is as follows:
1. The end user starts the app, which issues a join to the (S,G): 1. The end user starts the app, which issues a join to the (S,G):
(198.51.100.15, 232.252.0.2). (2001:db8::a, ff3e::8000:d).
2. The join propagates with RPF through the receiver's multicast- 2. The join propagates with RPF through the receiver's multicast-
enabled network with PIM [RFC7761] or another multicast routing enabled network with PIM [RFC7761] or another multicast routing
mechanism, until the AMT gateway receives a signal to join the mechanism, until the AMT gateway receives a signal to join the
(S,G). (S,G).
3. The AMT gateway performs a reverse DNS lookup for the AMTRELAY 3. The AMT gateway performs a reverse DNS lookup for the AMTRELAY
RRType, by sending an AMTRELAY RRType query for the FQDN RRType, by sending an AMTRELAY RRType query for the reverse IP
"15.100.51.198.in-addr.arpa.", using the reverse IP domain name domain name for the sender's source IP address (the S from the
for the sender's source IP address (the S from the (S,G)), as (S,G)).
described in Section 3.5 of [RFC1035].
The DNS resolver for the AMT gateway uses ordinary DNS recursive The DNS resolver for the AMT gateway uses ordinary DNS recursive
resolution until it has the authoritative result that the content resolution until it has the authoritative result that the content
provider configured, which informs the AMT gateway that the relay provider configured, which informs the AMT gateway that the relay
address is 2001:db8::f. address is 2001:db8::c:f.
4. The AMT gateway performs AMT handshakes with the AMT relay as 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.
In the case of an IPv6 (S,G), the only difference in the AMT relay In the case of an IPv4 (S,G), the only difference in the AMT relay
discovery process is the use of the ip6.arpa reverse IP domain name, discovery process is the use of the in-addr.arpa reverse IP domain
as described in Section 2.5 of [RFC3596]), instead of the in- name, as described in Section 3.5 of [RFC1035], instead of the
addr.arpa domain name. in6.arpa domain name. For example, if the (S,G) is (198.51.100.12,
232.252.0.2), the reverse IP FQDN for the AMTRELAY query would be
For example, if the (S,G) is (2001:db8:c::f, ffe3::80fc:2), the "12.100.51.198.in-addr.arpa.".
reverse domain name for the AMTRELAY query would be:
f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.0.0.0.8.b.d.0.1.0.0.2.ip6. Note that the address family of the AMT tunnel is independent of the
arpa. address family for the multicast traffic.
2.3. Optimal Relay Selection 2.3. Optimal Relay Selection
2.3.1. Overview 2.3.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 will only provide information for that gateway to use, because the RR will only provide information
skipping to change at page 11, line 32 skipping to change at page 11, line 35
via DNS-SD, the network SHOULD use the well-known anycast via DNS-SD, the network SHOULD use the well-known anycast
addresses from Section 7 of [RFC7450] to route discovery traffic addresses from Section 7 of [RFC7450] to route discovery traffic
to the relay most appropriate to the receiver's gateway. to the relay most appropriate to the receiver's gateway.
Accordingly, the gateway SHOULD by default discover a relay with Accordingly, the gateway SHOULD by default discover a relay with
the well-known AMT anycast addresses as the second preference the well-known AMT anycast addresses as the second preference
after DNS-SD when searching for a local relay. after DNS-SD when searching for a local relay.
o Let Sender Manage Relay Provisioning o Let Sender Manage Relay Provisioning
A related motivating example in the sending-side network is A related motivating example is provided by considering a sender
provided by considering a sender that needs to instruct the whose traffic can be forwarded by relays in a sender-controlled
gateways on how to select between connecting to Figure 6 or network like Figure 6 in Section 3.2.1, and also by relays in a
Figure 7 (from Section 3.2), in order to manage load and failover provider-controlled network like Figure 7 in Section 3.2.2, with
scenarios in a manner that operates well with the sender's different cost and scalability profiles for the different options.
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, in order to manage load and failover
scenarios in a manner that operates well with the sender's
provisioning strategy for horizontal scaling of AMT relays.
Therefore, after DNS-SD, the precedence from the RR MUST be used 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.
Accordingly, AMT gateways SHOULD by default prefer relays in this Accordingly, AMT gateways SHOULD by default prefer relays in this
order: order:
1. DNS-SD 1. DNS-SD
2. Anycast addresses from Section 7 of [RFC7450] 2. Anycast addresses from Section 7 of [RFC7450]
3. DRIAD 3. DRIAD
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 SHOULD use use the above, a Happy Eyeballs algorithm for AMT SHOULD use the Destination
Destination Address Selection defined in Section 6 of [RFC6724]. Address Selection defined in Section 6 of [RFC6724].
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 SHOULD make a non-deterministic choice the above orderings, a gateway SHOULD make a non-deterministic choice
(such as a pseudorandom selection) for relay preference ordering, in (such as a pseudorandom selection) for relay preference ordering, in
order to support load balancing by DNS configurations that provide order to support load balancing by DNS configurations that provide
many relay options. 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
skipping to change at page 20, line 38 skipping to change at page 20, line 38
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
zones as appropriate. AMTRELAY records MAY also appear in other zones as appropriate. AMTRELAY records MAY also appear in other
zones, since this may be necessary to perform delegation from the zones, since this may be necessary to perform delegation from the
reverse zones (see for example Section 5.2 of [RFC2317]), but the use reverse zones (see for example Section 5.2 of [RFC2317]), but the use
case enabled by this document requires a reverse IP mapping for the case enabled by this document requires a reverse IP mapping for the
source from an (S,G) in order to be useful to most AMT gateways. source from an (S,G) in order to be useful to most AMT gateways.
This document does not define semantics for the use of AMTRELAY
records obtained in a way other than by a reverse IP lookup.
When performing the AMTRELAY RR lookup, any CNAMEs or DNAMEs found 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.7. Waiting for DNS resolution 2.7. Waiting for DNS resolution
skipping to change at page 28, line 10 skipping to change at page 28, line 10
o type = 1: The relay field contains a 4-octet IPv4 address. o type = 1: The relay field contains a 4-octet IPv4 address.
o type = 2: The relay field contains a 16-octet IPv6 address. o type = 2: The relay field contains a 16-octet IPv6 address.
o type = 3: The relay field contains a wire-encoded domain name. o type = 3: The relay field contains a wire-encoded domain name.
The wire-encoded format is self-describing, so the length is The wire-encoded format is self-describing, so the length is
implicit. The domain name MUST NOT be compressed. (See implicit. The domain name MUST NOT be compressed. (See
Section 3.3 of [RFC1035] and Section 4 of [RFC3597].) Section 3.3 of [RFC1035] and Section 4 of [RFC3597].)
RRs with an undefined value in the Type field SHOULD NOT be
considered by receiving gateways for AMT relay discovery.
4.2.4. RData Format - Relay 4.2.4. RData Format - Relay
The relay field is the address or domain name of the AMT relay. It The relay field is the address or domain name of the AMT relay. It
is formatted according to the type field. is formatted according to the type field.
When the type field is 0, the length of the relay field is 0, and it When the type field is 0, the length of the relay field is 0, and it
indicates that no AMT relay should be used for multicast traffic from indicates that no AMT relay should be used for multicast traffic from
this source. this source.
When the type field is 1, the length of the relay field is 4 octets, When the type field is 1, the length of the relay field is 4 octets,
skipping to change at page 29, line 11 skipping to change at page 29, line 15
The presentation for the record is as follows: The presentation for the record is as follows:
IN AMTRELAY precedence D-bit type relay IN AMTRELAY precedence D-bit type relay
4.3.2. Examples 4.3.2. Examples
In a DNS authoritative nameserver that understands the AMTRELAY type, In a DNS authoritative nameserver that understands the AMTRELAY type,
the zone might contain a set of entries like this: the zone might contain a set of entries like this:
$ORIGIN 100.51.198.in-addr.arpa. $ORIGIN 100.51.198.in-addr.arpa.
10 IN AMTRELAY 10 0 1 203.0.113.15 12 IN AMTRELAY 10 0 1 203.0.113.15
10 IN AMTRELAY 10 0 2 2001:db8::15 12 IN AMTRELAY 10 0 2 2001:db8::15
10 IN AMTRELAY 128 1 3 amtrelays.example.com. 12 IN AMTRELAY 128 1 3 amtrelays.example.com.
This configuration advertises an IPv4 discovery address, an IPv6 This configuration advertises an IPv4 discovery address, an IPv6
discovery address, and a domain name for AMT relays which can receive discovery address, and a domain name for AMT relays which can receive
traffic from the source 198.51.100.10. The IPv4 and IPv6 addresses traffic from the source 198.51.100.12. The IPv4 and IPv6 addresses
are configured with a D-bit of 0 (meaning discovery is mandatory, as 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:
10 IN TYPE260 \# ( 10 IN TYPE260 \# (
skipping to change at page 31, line 39 skipping to change at page 31, line 46
This specification was inspired by the previous work of Doug Nortz, This specification was inspired by the previous work of Doug Nortz,
Robert Sayko, David Segelstein, and Percy Tarapore, presented in the Robert Sayko, David Segelstein, and Percy Tarapore, presented in the
MBONED working group at IETF 93. MBONED working group at IETF 93.
Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny
Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, Ben Kaduk, Bill Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, Ben Kaduk, Bill
Atwood, Tim Chown, Warren Kumari, Dan Romanescu, Bernard Aboba, Atwood, Tim Chown, Warren Kumari, Dan Romanescu, Bernard Aboba,
Carlos Pignataro, Niclas Comstedt, Mirja Kuehlewind, Henning Rogge, Carlos Pignataro, Niclas Comstedt, Mirja Kuehlewind, Henning Rogge,
Eric Vyncke, Barry Lieba, Roman Danyliw, Alissa Cooper, Suresh Eric Vyncke, Barry Lieba, Roman Danyliw, Alissa Cooper, Suresh
Krishnan, and Adam Roach for their very helpful reviews and comments. Krishnan, Adam Roach, and Daniel Franke for their very helpful
reviews and comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
skipping to change at page 33, line 26 skipping to change at page 33, line 41
[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: [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>. <https://www.rfc-editor.org/info/rfc8305>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
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>.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
skipping to change at page 35, line 5 skipping to change at page 35, line 25
[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>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
Appendix A. Unknown RRType construction Appendix A. 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:
skipping to change at page 35, line 36 skipping to change at page 36, line 4
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) + 2 print(len(wire)//2) + 2
print(wire) print(wire)
$ ./translate.py amtrelays.example.com $ ./translate.py amtrelays.example.com
24 24
09616d7472656c617973076578616d706c6503636f6d 09616d7472656c617973076578616d706c6503636f6d
<CODE ENDS> <CODE ENDS>
The length of the RData and the hex string for the domain name
"amtrelays.example.com" are the outputs of this program.
The length and the hex string for the domain name 22 is the length of the wire-encoded domain name, so 2 was added to
"amtrelays.example.com" are the outputs of this program, yielding a that value (1 for the precedence field and 1 for the combined D-bit
length of 22 and the above hex string. and relay type fields) to get the full length 24 of the RData. For
the 2 octets ahead of the domain name, we encode the precedence,
22 is the length of the wire-encoded domain name, so to this we add 2 D-bit, and relay type fields, as described in Section 4.
(1 for the precedence field and 1 for the combined D-bit and relay
type fields) to get the full length of the RData, and encode the
precedence, D-bit, and relay type fields as octets, as described in
Section 4.
This results in a zone file entry like this: This results in a zone file entry like this:
IN TYPE260 \# ( 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
 End of changes. 30 change blocks. 
94 lines changed or deleted 101 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/