1.2.1.Relays and Gateways

When reading this document, it's especially helpful to recall that once an AMT tunnel is established, the relay receives native multicast traffic and sends unicast tunnel-encapsulated traffic to the gateway. The gateway receives the tunnel-encapsulated packets, decapsulates them, and forwards them as native multicast packets, as illustrated inFigure 1.¶

  Multicast  +-----------+  Unicast  +-------------+  Multicast >---------> | AMT relay | >=======> | AMT gateway | >--------->             +-----------+           +-------------+

1.2.2.Definitions

1.2.3.Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2.3.1.Example Receiving Networks

                     Internet                  ^            ^      Multicast-enabled                  |            |      Receiving Network           +------|------------|-------------------------+           |      |            |                         |           |  +--------+   +--------+    +=========+     |           |  | Border |---| Border |    |   AMT   |     |           |  | Router |   | Router |    | gateway |     |           |  +--------+   +--------+    +=========+     |           |      |            |              |          |           |      +-----+------+-----------+--+          |           |            |                  |             |           |      +-------------+    +-------------+     |           |      | Agg Routers | .. | Agg Routers |     |           |      +-------------+    +-------------+     |           |            /     \ \     /         \        |           | +---------------+         +---------------+ |           | |Access Systems | ....... |Access Systems | |           | |(CMTS/OLT/etc.)|         |(CMTS/OLT/etc.)| |           | +---------------+         +---------------+ |           |        |                        |           |           +--------|------------------------|-----------+                    |                        |              +---+-+-+---+---+        +---+-+-+---+---+              |   |   |   |   |        |   |   |   |   |             /-\ /-\ /-\ /-\ /-\      /-\ /-\ /-\ /-\ /-\             |_| |_| |_| |_| |_|      |_| |_| |_| |_| |_|                            Subscribers

                  Internet               (non-multicast)                      ^                      |                  Office Network           +----------|----------------------------------+           |          |                                  |           |    +---------------+ (Wifi)   Mobile apps   |           |    | Modem+ | Wifi | - - - -  w/ embedded   |           |    | Router |  AP  |          AMT gateways  |           |    +---------------+                        |           |          |                                  |           |          |                                  |           |     +----------------+                      |           |     | Legacy Router  |                      |           |     |   (unicast)    |                      |           |     +----------------+                      |           |      /        |      \                      |           |     /         |       \                     |           | +--------+ +--------+ +--------+=========+  |           | | Phones | | ConfRm | | Desks  |   AMT   |  |           | | subnet | | subnet | | subnet | gateway |  |           | +--------+ +--------+ +--------+=========+  |           |                                             |           +---------------------------------------------+

            Multicast-capable ISP                      ^                      |                  Office Network           +----------|----------------------------------+           |          |                                  |           |    +---------------+ (Wifi)   Mobile apps   |           |    | Modem+ | Wifi | - - - -  w/ embedded   |           |    | Router |  AP  |          AMT gateways  |           |    +---------------+                        |           |          |               +=======+          |           |          +---Wired LAN---|  AMT  |          |           |          |               | relay |          |           |     +----------------+   +=======+          |           |     | Legacy Router  |                      |           |     |   (unicast)    |                      |           |     +----------------+                      |           |      /        |      \                      |           |     /         |       \                     |           | +--------+ +--------+ +--------+=========+  |           | | Phones | | ConfRm | | Desks  |   AMT   |  |           | | subnet | | subnet | | subnet | gateway |  |           | +--------+ +--------+ +--------+=========+  |           |                                             |           +---------------------------------------------+

2.3.2.Example Sending Networks

                                       Sender Network                 +-----------------------------------+                 |                                   |                 | +--------+   +=======+  +=======+ |                 | | Sender |   |  AMT  |  |  AMT  | |                 | +--------+   | relay |  | relay | |                 |     |        +=======+  +=======+ |                 |     |            |          |     |                 |     +-----+------+----------+     |                 |           |                       |                 +-----------|-----------------------+                             v                          Internet                       (non-multicast)

                   +--------+                   | Sender |                   +---+----+        Multicast-enabled                       |              Sending Network           +-----------|-------------------------------+           |           v                               |           |    +------------+     +=======+ +=======+ |           |    | Agg Router |     |  AMT  | |  AMT  | |           |    +------------+     | relay | | relay | |           |           |           +=======+ +=======+ |           |           |               |         |     |           |     +-----+------+--------+---------+     |           |     |            |                        |           | +--------+   +--------+                   |           | | Border |---| Border |                   |           | | Router |   | Router |                   |           | +--------+   +--------+                   |           +-----|------------|------------------------+                 |            |                 v            v                    Internet                 (non-multicast)

3.1.1.Overview

The reverse source IP DNS query of an AMTRELAY RR is a good way for a gateway to discover a relay that is known to the sender.¶

However, it is *not* necessarily a good way to discover the best relay for that gateway to use, because the RR will only provide information about relays known to the source.¶

If there is an upstream relay in a network that is topologically closer to the gateway and is able to receive and forward multicast traffic from the sender, that relay is better for the gateway to use since more of the network path uses native multicast, allowing more 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 record. An example network that illustrates this scenario is outlined inFigure 5 fromSection 2.3.1.2.¶

It's only appropriate for an AMT gateway to discover an AMT relay by querying an AMTRELAY RR owned by a sender when all of these conditions are met:¶

1. The gateway needs to propagate a join of an (S,G) over AMT because in the gateway's network, no RPF next hop toward the source can propagate a native multicast join of the (S,G);¶
2. The gateway is not already connected to a relay that forwards multicast traffic from the source of the (S,G);¶
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 forward traffic from the source of the (S,G);¶
4. The gateway is not able to find an upstream AMT relay with DNS-based Service Discovery (DNS-SD)[RFC6763] using "_amt._udp" as the Service section of the queries, or a relay discovered this way is not able to forward traffic from the source of the (S,G) (as described inSection 3.3.4.1 and3.3.5); and¶
5. The gateway is not able to find an upstream AMT relay with the well-known anycast addresses fromSection 7 of [RFC7450].¶

When all of the above conditions are met, the gateway has no path within its local network that can receive multicast traffic from the source IP of the (S,G).¶

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 of the sender. When the sender has configured an AMTRELAY RR, gateways can use the DRIAD mechanism defined in this document to discover the relay information provided by the sender.¶

Note that the above conditions are designed to prefer the use of a local AMT relay if one can be discovered. However, note also that the network upstream of the locally discovered relay would still need to receive traffic from the sender of the (S,G) in order to forward it. Therefore, unless the upstream network contains the sender or has a multicast-capable peering with a network that can forward traffic from the sender, the upstream network might still use AMT to ingest the traffic from a network that can receive traffic from the sender. If this is the case, the upstream AMT gateway could still rely on the AMTRELAY RR provided by the sender, even though the AMTRELAY RR is not directly used by gateways topologically closer to the receivers. For a concrete example of such a situation, consider the network inFigure 5 connected as one of the customers to the network inFigure 3.¶

3.1.2.Preference Ordering

This section defines a preference ordering for relay addresses during the relay discovery process. Gateways are encouraged to implement a Happy Eyeballs[RFC8305] algorithm to try candidate relays concurrently (seeSection 3.2), but even gateways that do not implement a Happy Eyeballs algorithmSHOULD 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 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 inSection 6 of [RFC6724], but for the above reasons, that requirement is superseded in the AMT discovery use case by the following considerations:¶

• Prefer Local Relays¶

  Figure 5 andSection 2.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'sRECOMMENDED that AMT gateways by default perform service discovery using DNS Service Discovery (DNS-SD)[RFC6763] for _amt._udp.<domain> (with <domain> chosen as described inSection 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).¶

• Prefer Relays Managed by the Containing Network¶

  When no local relay is discoverable with DNS-SD, it still may be the case that a relay local to the receiver is operated by the network providing transit services to the receiver.¶

  In this case, when the network cannot make the relay discoverable via DNS-SD, the networkSHOULD use the well-known anycast addresses fromSection 7 of [RFC7450] to route discovery traffic to the relay most appropriate to the receiver's gateway.¶

  Accordingly, the gatewaySHOULD by default discover a relay with the well-known AMT anycast addresses as the next-best option after DNS-SD when searching for a local relay.¶

• Let Sender Manage Relay Provisioning¶

  A related motivating example is provided by considering a sender whose traffic can be forwarded by relays in a sender-controlled network likeFigure 6 inSection 2.3.2.1 and by relays in a provider-controlled network likeFigure 7 inSection 2.3.2.2, with different cost and scalability profiles for the different options.¶

  In this example about the sending-side network, the precedence field described inSection 4.2.1 is a critical method of control so that senders can provide the appropriate guidance to gateways 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 RRMUST be used for sorting preference ahead of the Destination Address Selection ordering fromSection 6 of [RFC6724] so that only relay IPs with the same precedence are directly compared according to the Destination Address Selection ordering.¶

Accordingly, AMT gatewaysSHOULD by default prefer relays in this order:¶

1. DNS-SD¶
2. Anycast addresses fromSection 7 of [RFC7450]¶
3. DRIAD¶

This default behaviorMAY 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 AMTSHOULD use the Destination Address Selection defined inSection 6 of [RFC6724].¶

Among relay addresses that still have an equivalent preference after the above orderings, a gatewaySHOULD make a non-deterministic choice (such as a pseudorandom selection) for relay preference ordering in order to support load balancing by DNS configurations that provide many relay options.¶

The gatewayMAY introduce a bias in the non-deterministic choice according to information that indicates expected benefits from selecting some relays in preference to others. Details about the structure and collection of this information are out of scope for this document but could, for example, be obtained by out-of-band methods or from a historical record about network topology, timing information, or the response to a probing mechanism. A gateway in possession of such informationMAY use it to prefer topologically closer relays.¶

Within the above constraints, gatewaysMAY make use of other considerations fromSection 4 of [RFC8305], such as the address family interleaving strategies, to produce a final ordering of candidate relay addresses.¶

Note also that certain relay addresses might be excluded from consideration by the hold-down timers described inSection 3.3.4.1 or3.3.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 orderingMAY operate in parallel, subject to delays prescribed by the Happy Eyeballs requirements described inSection 5 of [RFC8305] for successively launched concurrent connection attempts.¶

3.1.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 gatewaySHOULD NOT be configured to do so without guaranteeing that adequate bandwidth is available.¶

A gateway configured to do thisSHOULD still use the same preference-ordering logic fromSection 3.1.2 for each connection. (Note that this ordering allows for overriding by explicit administrative configuration where required.)¶

3.2.1.Overview

Often, multiple choices of relay will exist for a gateway using DRIAD for relay discovery. Happy Eyeballs[RFC8305] provides a widely deployed and generalizable strategy for probing multiple possible connections in parallel. Therefore, it isRECOMMENDED that DRIAD-capable gateways implement a Happy Eyeballs algorithm to support fast discovery of the most preferred available relay by probing multiple relays concurrently.¶

The parallel discovery logic of a Happy Eyeballs algorithm serves to reduce join latency for the initial join of an SSM channel. This section and the preference ordering of relays defined inSection 3.1.2 together provide guidance on use of a Happy Eyeballs algorithm for the case of establishing AMT connections.¶

Note that according to the definition inSection 3.2.3 of this document, establishing the connection occurs before sending a membership report. As described inSection 5 of [RFC8305], only one of the successful connections will be used, and the others are all canceled or ignored. In the context of an AMT connection, this means the gateway will send the membership reports that subscribe to traffic only for the chosen connection after the Happy Eyeballs algorithm resolves.¶

3.2.2.Algorithm Guidelines

During the "Initiation of asynchronous DNS queries" phase described inSection 3 of [RFC8305], a gateway attempts to resolve the domain names listed inSection 3.1. This consists of resolving the SRV queries for DNS-SD domains for the AMT service, as well as the AMTRELAY query for the reverse IP domain defined in this document.¶

Each of the SRV and AMTRELAY responses might contain:¶

• one or more IP addresses (as with type 1 or type 2 AMTRELAY responses or when the SRV Additional Data section of the SRV response contains the address records for the target, as urged by[RFC2782]), or¶
• only domain names (as with type 3 responses fromSection 4.2.3 or an SRV response without an additional data section).¶

When present, IP addresses in the initial response provide resolved destination address candidates for the "Sorting of resolved destination addresses" phase described inSection 4 of [RFC8305]), whereas domain names without IP addresses in the initial response result in another set of queries for AAAA and A records, whose responses provide the candidate resolved destination addresses.¶

Since the SRV or AMTRELAY responses don't have a bound on the count of queries that might be generated aside from the bounds imposed by the DNS resolver, it's important for the gateway to provide a rate limit on the DNS queries. The DNS query functionality is expected to follow ordinary standards and best practices for DNS clients. A gatewayMAY use an existing DNS client implementation that does so andMAY rely on that client's rate-limiting logic to avoid issuing excessive queries. Otherwise, a gatewayMUST provide a rate limit for the DNS queries, and its default settingsSHOULD NOT permit more than 10 queries for any 100-millisecond period (though thisMAY be overridable by the administrative configuration).¶

As the resolved IP addresses arrive, the Happy Eyeballs algorithm sorts them according to the requirements and recommendations given inSection 3.1.2 and attempts connections with the corresponding relays under the algorithm restrictions and guidelines given in[RFC8305] for the "Establishment of one connection, which cancels all other attempts" phase. As described inSection 3 of [RFC8305], DNS resolution is treated as asynchronous, and connection initiation does not wait for lagging DNS responses.¶

3.2.3.Connection Definition

Section 5 of [RFC8305] non-normatively describes a successful 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:¶

• An AMT connection is established 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.¶

SeeSection 3.3.5 of this document for further information about the relevance of the L flag to the establishment of a Happy Eyeballs connection. SeeSection 3.3.4 for an overview of how to respond if the connection does not provide multicast connectivity to the source.¶

To "cancel" this kind of AMT connection for the Happy Eyeballs algorithm, a gateway that has not sent a membership report with a subscription would simply stop sending AMT packets for that connection. A gateway only sends a membership report to a connection it has chosen as the most preferred available connection.¶

3.3.1.Overview

It's expected that gateways deployed in different environments will use a variety of heuristics to decide when it's appropriate to restart the relay discovery process in order to meet different performance goals (for example, to fulfill different kinds of service level agreements).¶

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 that can use DRIAD as part of the relay discovery process.¶

3.3.2.Updates to Restarting Events

Section 5.2.3.4.1 of [RFC7450] lists several events that may cause a gateway to start or restart the discovery procedure.¶

This document provides some updates and recommendations regarding the handling of these and similar events. The first five events are copied here and numbered for easier reference, and the remaining four events are newly added for consideration in this document:¶

1. When a gateway pseudo-interface is started (enabled).¶
2. When the gateway wishes to report a group subscription when none currently exists.¶
3. Before sending the next Request message in a membership update cycle.¶
4. After the gateway fails to receive a response to a Request message.¶
5. After the gateway receives a Membership Query message with the L flag set to 1.¶
6. When the gateway wishes to report an (S,G) subscription with a source address that does not currently have other group subscriptions.¶
7. When there is a network change detected; for example, when a gateway isoperating inside an end user device or application and the devicejoins a different network or when the domain portion of a DNS-SDdomain name changes in response to a DHCP message or administrativeconfiguration.¶
8. When substantial loss, persistent congestion, or network overload isdetected in the stream of AMT packets from a relay.¶
9. When the gateway has reported one or more (S,G) subscriptions butno traffic is received from the source for some timeout (seeSection 3.3.4.1).¶

This list is not exhaustive, nor are any of the listed events strictlyrequired to always force a restart of the discovery process.¶

Note that during event #1, a gateway may use DNS-SD but does nothave sufficient information to use DRIAD, since no source is known.¶

3.3.3.Tunnel Stability

In general, subscribers to active traffic flows that are being forwardedby an AMT gateway are less likely to experience a degradation in service(for example, from missing or duplicated packets) when the gateway continuesusing the same relay as long as the relay is not overloaded and the networkconditions remain stable.¶

Therefore, gatewaysSHOULD avoid performing a full restart of the discoveryprocess during routine cases of event #3 (sending a new Request message),since it occurs frequently in normal operation.¶

However, see Sections3.3.4,3.3.6, and3.3.4.3 for moreinformation about exceptional cases when it may be appropriate to useevent #3.¶

3.3.4.Traffic Health

3.3.5.Relay Loaded or Shutting Down

The L flag (seeSection 5.1.4.4 of [RFC7450]) is the preferred mechanism fora relay to signal overloading or a graceful shutdown to gateways.¶

A gateway that supports handling of the L flag should generally restart thediscovery process when it processes a Membership Query packet with theL flag set. If an L flag is received while a concurrent Happy Eyeballsdiscovery process is underway for multiple candidate relays (Section 3.2),the relay sending the L flagSHOULD NOT be considered for the relay selection.¶

It is alsoRECOMMENDED that gateways avoid choosing a relaythat has recently sent an L flag, with approximately a 10-minute hold-down.GatewaysSHOULD treat this hold-down timer in the same way as the hold-downinSection 3.3.4.1 so that the relay is removed from considerationfor subsequent short-term rounds of discovery.¶

3.3.6.Relay Discovery Messages vs. Restarting Discovery

All AMT relays are required by[RFC7450] to support handling ofRelay Discovery messages (e.g., inSection 5.3.3.2 of [RFC7450]).¶

So a gateway with an existing connection to a relay can send a RelayDiscovery message to the unicast address of that AMT relay. Under stableconditions with an unloaded relay, it's expected that the relay willreturn its own unicast address in the Relay Advertisement in responseto such a Relay Discovery message. Since this will not result in thegateway changing to another relay unless the relay directs the gatewayaway, this is a reasonable exception to the advice against handling event #3described inSection 3.3.3.¶

This behavior is discouraged for gateways that do support the L flag toavoid sending unnecessary packets over the network.¶

However, gateways that do not support the L flag may be able to avoid adisruption in the forwarded traffic by sending such Relay Discoverymessages regularly. When a relay is under load or has started a gracefulshutdown, it may respond with a different relay address, which the gatewaycan use to connect to a different relay. This kind of coordinated handoffwill likely result in a smaller disruption to the traffic than if the relaysimply stops responding to Request messages and stops forwarding traffic.¶

This style of Relay Discovery message (one sent to the unicast addressof a relay that's already forwarding traffic to this gateway)SHOULD NOT beconsidered a full restart of the relay discovery process. It isRECOMMENDEDthat gateways support the L flag, but for gateways that do not support theL flag, sending this message during event #3 may help mitigate servicedegradation when relays become unstable.¶

3.3.7.Independent Discovery per Traffic Source

Relays discovered via the AMTRELAY RR are source-specific relay addresses andmay use different pseudo-interfaces from each other and from relaysdiscovered via DNS-SD or via a non-source-specific address, as described inSection 4.1.2.1 of [RFC7450].¶

Restarting the discovery process for one pseudo-interface does not requirerestarting the discovery process for other pseudo-interfaces. Gatewayheuristics about restarting the discovery process should operateindependently for different tunnels to relays when responding to eventsthat are specific to the different tunnels.¶

4.2.1.RData Format - Precedence

This is an 8-bit precedence for this record. It is interpreted inthe same way as the PREFERENCE field described inSection 3.3.9 of [RFC1035].¶

Relays listed in AMTRELAY records with a lower value for precedence are to beattempted first.¶

4.2.2.RData Format - Discovery Optional (D-bit)

The D-bit is a "Discovery Optional" flag.¶

If the D-bit is set to 0, a gateway using this RRMUST perform AMT relaydiscovery as described inSection 4.2.1.1 of [RFC7450] rather than directlysending an AMT Request message to the relay.¶

That is, the gatewayMUST receive an AMT Relay Advertisement message (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 receiving the RelayAdvertisement message, this record has only indicated that the address can beused for AMT relay discovery, not for a Request message. This is necessary fordevices that are not fully functional AMT relays but rather load balancers orbrokers, as mentioned inSection 4.2.1.1 of [RFC7450].¶

If the D-bit is set to 1, the gatewayMAY send an AMT Request message directlyto the discovered relay address without first sending an AMT Discovery message.¶

This bit should be set according to advice from the AMT relay operator. TheD-bitMUST be set to zero when no information is available from the AMT relayoperator about its suitability.¶

4.2.3.RData Format - Type

The type field indicates the format of the information thatis stored in the relay field.¶

The following values are defined:¶

• type = 0:The relay field is empty (0 bytes).¶
• type = 1:The relay field contains a 4-octet IPv4 address.¶
• type = 2:The relay field contains a 16-octet IPv6 address.¶
• type = 3:The relay field contains a wire-encoded domain name. The wire-encodedformat is self-describing, so the length is implicit. The domain nameMUST NOT be compressed (seeSection 3.3 of [RFC1035] andSection 4 of [RFC3597]).¶

RRs with an undefined value in the Type fieldSHOULD NOT be consideredby receiving gateways for AMT relay discovery.¶

4.2.4.RData Format - Relay

The relay field is the address or domain name of the AMT relay. It isformatted according to the type field.¶

When the type field is 0, the length of the relay field is 0, and itindicates that no AMT relay should be used for multicast traffic from thissource.¶

When the type field is 1, the length of the relay field is 4 octets, and a32-bit IPv4 address is present. This is an IPv4 address as described inSection 3.4.1 of [RFC1035]. This is a 32-bit number in network byteorder.¶

When the type field is 2, the length of the relay field is 16 octets, anda 128-bit IPv6 address is present. This is an IPv6 address as described inSection 2.2 of [RFC3596]. This is a 128-bit number in network byte order.¶

When the type field is 3, the relay field is a normal wire-encoded domainname, as described inSection 3.3 of [RFC1035]. For the reasons given inSection 4 of [RFC3597], compressionMUST NOT beused.¶

For a type 3 record, the D-bit and preference fields carry over to allA or AAAA records for the domain name. There is no difference in theresult of the discovery process when it's obtained by type 1 or type 2AMTRELAY records with identical D-bit and preference fields vs. whenthe result is obtained by a type 3 AMTRELAY record that resolvesto the same set of IPv4 and IPv6 addresses via A and AAAA lookups.¶

4.3.1.Representation of AMTRELAY RRs

AMTRELAY RRs may appear in a zone data master file. The precedence, D-bit,relay type, and relay fields areREQUIRED.¶

If the relay type field is 0, the relay fieldMUST be ".".¶

The presentation for the record is as follows:¶

  IN AMTRELAY precedence D-bit type relay

4.3.2.Examples

In a DNS authoritative nameserver that understands the AMTRELAY type,the zone might contain a set of entries like this:¶

    $ORIGIN 100.51.198.in-addr.arpa.    12     IN AMTRELAY  10 0 1 203.0.113.15    12     IN AMTRELAY  10 0 2 2001:db8::15    12     IN AMTRELAY 128 1 3 amtrelays.example.com.

This configuration advertises an IPv4 discovery address, an IPv6discovery address, and a domain name for AMT relays that can receivetraffic from the source 198.51.100.12. The IPv4 and IPv6 addressesare configured with a D-bit of 0 (meaning discovery is mandatory, asdescribed inSection 4.2.2) and a precedence 10 (meaning they'repreferred ahead of the last entry, which has precedence 128).¶

For zone files in name servers that don't support the AMTRELAY RRTypenatively, it's possible to use the format for unknown RR types, asdescribed in[RFC3597]. This approach would replace the AMTRELAYentries in the example above with the entries below:¶

    10   IN TYPE260  \# (           6  ; length           0a ; precedence=10           01 ; D=0, relay type=1, an IPv4 address           cb00710f ) ; 203.0.113.15    10   IN TYPE260  \# (           18 ; length           0a ; precedence=10           02 ; D=0, relay type=2, an IPv6 address           20010db800000000000000000000000f ) ; 2001:db8::15    10   IN TYPE260  \# (           24 ; length           80 ; precedence=128           83 ; D=1, relay type=3, a wire-encoded domain name         09616d7472656c617973076578616d706c6503636f6d ) ; domain name

SeeAppendix A for more details.¶