4. Protocol Overview
This section provides an informative description of the protocol. A
normative description of the protocol and implementation requirements
may be found in Section 5.
4.1. General Architecture
Isolated Site | Unicast Network | Native Multicast
| (Internet) |
| Group Membership |
+-------+ =========================> +-------+ Multicast +------+
|Gateway| | | | Relay |<----//----|Source|
+-------+ <========================= +-------+ +------+
| Multicast Data |
Figure 1: Basic AMT Architecture
The AMT protocol employs a client-server model in which a "gateway"
sends requests to receive specific multicast traffic to a "relay"
that responds by delivering the requested multicast traffic back to
Gateways are generally deployed within networks that lack multicast
support or lack connectivity to a multicast-enabled network
containing multicast sources of interest.
Relays are deployed within multicast-enabled networks that contain,
or have connectivity to, multicast sources.
4.1.1. Relationship to IGMP and MLD Protocols
AMT relies on the Internet Group Management Protocol (IGMP) [RFC3376]
and the Multicast Listener Discovery (MLD) protocol [RFC3810] to
provide the functionality required to manage, communicate, and act on
changes in multicast group membership. A gateway or relay
implementation does not necessarily require a fully functional,
conforming implementation of IGMP or MLD to adhere to this
specification, but the protocol description that appears in this
document assumes that this is the case. The minimum functional and
behavioral requirements for the IGMP and MLD protocols are described
in Sections 5.2.1 and 5.3.1.
General _____ _____
___________ Query | | | | Query ___________
| |<------| | | |<------| |
| Host-Mode | | AMT | | AMT | |Router-Mode|
| IGMP/MLD | | | UDP | | | IGMP/MLD |
|___________|------>| |<----->| |------>|___________|
Report | | | | Report
Leave/Done | | | | Leave/Done
| | | |
IP Multicast <------| | | |<------ IP Multicast
Figure 2: Multicast Reception State Managed by IGMP/MLD
A gateway runs the host portion of the IGMP and MLD protocols to
generate group membership updates that are sent via AMT messages to a
relay. A relay runs the router portion of the IGMP and MLD protocols
to process the group membership updates to produce the required
changes in multicast forwarding state. A relay uses AMT messages to
send incoming multicast IP datagrams to gateways according to their
current group membership state.
The primary function of AMT is to provide the handshaking,
encapsulation, and decapsulation required to transport the IGMP and
MLD messages and multicast IP datagrams between the gateways and
relays. The IGMP and MLD messages that are exchanged between
gateways and relays are encapsulated as complete IP datagrams within
AMT control messages. Multicast IP datagrams are replicated and
encapsulated in AMT data messages. All AMT messages are sent via
The downstream side of a gateway services one or more receivers --
the gateway accepts group membership requests from receivers and
forwards requested multicast traffic back to those receivers. The
gateway functionality may be directly implemented in the host
requesting the multicast service or within an application running on
The upstream side of a gateway connects to relays. A gateway sends
encapsulated IGMP and MLD messages to a relay to indicate an interest
in receiving specific multicast traffic.
Each gateway possesses a logical pseudo-interface:
join/leave ---+ +----------+
| | |
V IGMPv3/MLDv2 | |
+---------+ General Query| | AMT
|IGMP/MLD |<-------------| AMT | Messages +------+
|Host-Mode| | Gateway |<-------->|UDP/IP|
|Protocol |------------->|Pseudo-I/F| +------+
+---------+ IGMP/MLD | | ^
Report | | |
Leave/Done | | V
IP Multicast <---------------------| | +---+
Figure 3: AMT Gateway Pseudo-Interface
The pseudo-interface is conceptually a network interface on which the
gateway executes the host portion of the IPv4/IGMP (v2 or v3) and
IPv6/MLD (v1 or v2) protocols. The multicast reception state of the
pseudo-interface is manipulated using the IGMP or MLD service
interface. The IGMP and MLD host protocols produce IP datagrams
containing group membership messages that the gateway will send to
the relay. The IGMP and MLD protocols also supply the retransmission
and timing behavior required for protocol robustness.
All AMT encapsulation, decapsulation, and relay interaction are
assumed to occur within the pseudo-interface.
A gateway host or application may create separate interfaces for
IPv4/IGMP and IPv6/MLD. A gateway host or application may also
require additional pseudo-interfaces for each source or domain-
specific relay address.
Within this document, the term "gateway" may be used as a generic
reference to an entity executing the gateway protocol, a gateway
pseudo-interface, or a gateway device that has one or more interfaces
connected to a unicast internetwork and one or more AMT gateway
22.214.171.124. Use Cases
Use cases for gateway functionality include the following:
An IGMP/MLD proxy that runs AMT on an upstream interface and
router-mode IGMP/MLD on downstream interfaces to provide host
access to multicast traffic via the IGMP and MLD protocols.
Virtual Network Interface
A virtual network interface or pseudo-network device driver that
runs AMT on a physical network interface to provide socket-layer
access to multicast traffic via the IGMP/MLD service interface
provided by the host IP stack.
An application or application component that implements and
executes IGMP/MLD and AMT internally to gain access to multicast
The downstream side of a relay services gateways -- the relay accepts
encapsulated IGMP and MLD group membership messages from gateways and
encapsulates and forwards the requested multicast traffic back to
The upstream side of a relay communicates with a native multicast
infrastructure -- the relay sends join and prune/leave requests
towards multicast sources and accepts requested multicast traffic
from those sources.
Each relay possesses a logical pseudo-interface:
+--------+ | Multicast Control Plane |
| |IGMP/MLD| |
| | Query* | +------------+ +----------+ |
| |<---//----|IGMPv3/MLDv2| |Multicast | |
AMT | | | |Router-Mode |->|Routing |<->
+------+ Messages | AMT |----//--->|Protocol | |Protocol | |
|UDP/IP|<-------->| Relay |IGMP/MLD| +------------+ +----------+ |
+------+ | Pseudo-| Report | | | |
^ | I/F | Leave/ +------|---------------|-------+
| | | Done | |
| | | v |
V | | IP +-----------+ |
+---+ | | Multicast |Multicast |<------+
|I/F| | |<---//-----|Forwarding |
+---+ +--------+ |Plane |<--- IP Multicast
* Queries, if generated, are consumed by the pseudo-interface.
Figure 5: AMT Relay Pseudo-Interface (Router-Based)
The pseudo-interface is conceptually a network interface on which the
relay runs the router portion of the IPv4/IGMPv3 and IPv6/MLDv2
protocols. Relays do not send unsolicited IGMPv3/MLDv2 query
messages to gateways so relays must consume or discard any local
queries normally generated by IGMPv3 or MLDv2. Note that the
protocol mandates the use of IGMPv3 and MLDv2 for query messages.
The AMT protocol is primarily intended for use in SSM applications
and relies on several values provided by IGMPv3/MLDv2 to control
A relay maintains group membership state for each gateway connected
through the pseudo-interface as well as for the entire
pseudo-interface (if multiple gateways are managed via a single
interface). Multicast packets received on upstream interfaces on the
relay are routed to the pseudo-interface where they are replicated,
encapsulated, and sent to interested gateways. Changes in the
pseudo-interface group membership state may trigger the transmission
of multicast protocol requests upstream towards a given source or
rendezvous point and cause changes in internal routing/forwarding
The relay pseudo-interface is an architectural abstraction used to
describe AMT protocol operation. For the purposes of this document,
the pseudo-interface is most easily viewed as an interface to a
single gateway -- encapsulation, decapsulation, and other
AMT-specific processing occurs "within" the pseudo-interface while
forwarding and replication occur outside of it.
An alternative view is to treat the pseudo-interface as a
non-broadcast multi-access (NBMA) network interface whose link layer
is the unicast-only network over which AMT messages are exchanged
with gateways. Individual gateways are conceptually treated as
logical NBMA links on the interface. In this architectural model,
group membership tracking, replication, and forwarding functions
occur in the pseudo-interface.
This document does not specify any particular architectural solution
-- a relay developer may choose to implement and distribute protocol
functionality as required to take advantage of existing relay
platform services and architecture.
Within this document, the term "relay" may be used as a generic
reference to an entity executing the relay protocol, a relay
pseudo-interface, or a relay device that has one or more network
interfaces with multicast connectivity to a native multicast
infrastructure, zero or more interfaces connected to a unicast
internetwork, and one or more relay pseudo-interfaces.
126.96.36.199. Use Cases
Use cases for relay functionality include the following:
A multicast router that runs AMT on a downstream interface to
provide gateway access to multicast traffic. A "relay router"
uses a multicast routing protocol (e.g., PIM-SM [RFC4601]) to
construct a forwarding path for multicast traffic by sending join
and prune messages to neighboring routers to join or leave
multicast distribution trees for a given SSM source or ASM
IGMP/MLD Proxy Router
An IGMP/MLD proxy that runs AMT on a downstream interface and
host-mode IGMPv3/MLDv2 on an upstream interface. This "relay
proxy" sends group membership reports to a local, multicast-
enabled router to join and leave specific SSM or ASM groups.
The AMT protocol calls for a relay deployment model that uses anycast
addressing [RFC1546] [RFC4291] to pair gateways with relays.
Under this approach, one or more relays advertise a route for the
same IP address prefix. To find a relay with which to communicate, a
gateway sends a message to an anycast IP address within that prefix.
This message is routed to the topologically nearest relay that has
advertised the prefix. The relay that receives the message responds
by sending its unicast address back to the gateway. The gateway uses
this address as the destination address for any messages it
subsequently sends to the relay.
The use of anycast addressing provides the following benefits:
o Relays may be deployed at multiple locations within a single
multicast-enabled network. Relays might be installed "near"
gateways to reduce bandwidth requirements and latency and to limit
the number of gateways that might be serviced by a single relay.
o Relays may be added or removed at any time, thereby allowing
staged deployment, scaling, and hot-swapping -- the relay
discovery process will always return the nearest operational
o Relays may take themselves offline when they exhaust resources
required to service additional gateways. Existing gateway
connections may be preserved, but new gateway requests would be
routed to the next-nearest relay.
188.8.131.52. Public versus Private
Ideally, the AMT protocol would provide a universal solution for
connecting receivers to multicast sources, so that any gateway could
be used to access any globally advertised multicast source via
publicly accessible, widely deployed relays. Unfortunately, today's
Internet does not yet allow this, because many relays will lack
native multicast access to sources even though they may be globally
accessible via unicast.
In these cases, a provider may deploy relays within their own source
network to allow for multicast distribution within that network.
Gateways that use these relays must use a provider-specific relay
discovery mechanism or a private anycast address to obtain access to
184.108.40.206. Congestion Considerations
AMT relies on UDP to provide best-effort delivery of multicast data
to gateways. Neither AMT nor UDP provides the congestion control
mechanisms required to regulate the flow of data messages passing
through a network. While congestion remediation might be provided by
multicast receiver applications via multicast group selection or
upstream reporting mechanisms, there are no means by which to ensure
that such mechanisms are employed. To limit the possible congestion
across a network or wider Internet, AMT service providers are
expected to deploy AMT relays near the provider's network border and
its interface with edge routers. The provider must limit relay
address advertisements to those edges to prevent distant gateways
from being able to access a relay and potentially generate flows that
consume or exceed the capacity of intervening links.
To execute the gateway portion of the protocol, a gateway requires a
unicast IP address of an operational relay. This address may be
obtained using a number of methods -- it may be statically assigned
or dynamically chosen via some form of relay discovery process.
As described in the previous section, the AMT protocol provides a
relay discovery method that relies on anycast addressing. Gateways
are not required to use AMT relay discovery, but all relay
implementations must support it.
The AMT protocol uses the following terminology when describing the
Relay Discovery Address Prefix:
The anycast address prefix used to route discovery messages to a
Relay Discovery Address:
The anycast destination address used when sending discovery
The unicast IP address obtained as a result of the discovery
220.127.116.11. Relay Discovery Address Selection
The selection of an anycast Relay Discovery Address may be source
dependent, as a relay located via relay discovery must have multicast
connectivity to a desired source.
Similarly, the selection of a unicast Relay Address may be source
dependent, as a relay contacted by a gateway to supply multicast
traffic must have native multicast connectivity to the traffic
Methods that might be used to perform source-specific or
group-specific relay selection are highly implementation dependent
and are not further addressed by this document. Possible approaches
include the use of static lookup tables, DNS-based queries, or a
provision of a service interface that accepts join requests on
(S,G,relay-discovery-address) or (S,G,relay-address) tuples.
18.104.22.168. Relay Discovery Address Prefix
IANA has assigned IPv4 and IPv6 address prefixes for use in
advertising and discovering publicly accessible relays.
A Relay Discovery Address is constructed from an address prefix by
setting the low-order octet of the prefix address to 1 (for both IPv4
and IPv6). All remaining addresses within each prefix are reserved
for future use.
Public relays must advertise a route to the address prefix (e.g., via
BGP [RFC4271]) and configure an interface to respond to the Relay
The discovery address prefixes are described in Section 7.
4.2. General Operation
4.2.1. Message Sequences
The AMT protocol defines the following messages for control and
encapsulation. These messages are exchanged as UDP/IP datagrams, one
message per datagram.
Sent by gateways to solicit a Relay Advertisement from any relay.
Used to find a relay with which to communicate.
Sent by relays as a response to a Relay Discovery message. Used
to deliver a Relay Address to a gateway.
Sent by gateways to solicit a Membership Query message from a
Sent by relays as a response to a Request message. Used to
deliver an encapsulated IGMPv3 or MLDv2 query message to the
Sent by gateways to deliver an encapsulated IGMP or MLD
report/leave/done message to a relay.
Sent by relays to deliver an encapsulated IP multicast datagram or
datagram fragment to a gateway.
Sent by gateways to stop the delivery of Multicast Data messages
requested in an earlier Membership Update message.
The following sections describe how these messages are exchanged to
execute the protocol.
22.214.171.124. Relay Discovery Sequence
 |Relay Discovery |
| Relay Advertisement| 
 | |
Figure 6: AMT Relay Discovery Sequence
The following sequence describes how the Relay Discovery and Relay
Advertisement messages are used to find a relay with which to
1. The gateway sends a Relay Discovery message containing a random
nonce to the Relay Discovery Address. If the Relay Discovery
Address is an anycast address, the message is routed to the
topologically nearest network node that advertises that address.
2. The node receiving the Relay Discovery message sends a Relay
Advertisement message back to the source of the Relay Discovery
message. The message carries a copy of the nonce contained in
the Relay Discovery message and the unicast IP address of a
3. When the gateway receives the Relay Advertisement message, it
verifies that the nonce matches the one sent in the Relay
Discovery message and, if it does, uses the Relay Address carried
by the Relay Advertisement as the destination address for
subsequent AMT messages.
Note that the responder need not be a relay -- the responder may
obtain a Relay Address by some other means and return the result in
the Relay Advertisement (i.e., the responder is a load-balancer or
126.96.36.199. Membership Update Sequence
There exists a significant difference between normal IGMP and MLD
behavior and that required by AMT. An IGMP/MLD router acting as a
querier normally transmits query messages on a network interface to
construct and refresh group membership state for the connected
network. These query messages are multicast to all IGMP/MLD-enabled
hosts on the network. Each host responds by multicasting report
messages that describe their current multicast reception state.
However, AMT does not allow relays to send unsolicited query messages
to gateways, as the set of active gateways may be unknown to the
relay and potentially quite large. Instead, AMT requires each
gateway to periodically send a message to a relay to solicit a query
response. A gateway accomplishes this by sending a Request message
to a relay. The relay responds by sending a Membership Query message
back to the gateway. The Membership Query message carries an
encapsulated query that is processed by the IGMP or MLD protocol
implementation on the gateway to produce a membership/listener
report. Each time the gateway receives a Membership Query message,
it starts a timer whose expiration will trigger the start of a new
Request->Membership Query message exchange. This timer-driven
sequence is used to mimic the transmission of a periodic query by an
IGMP/MLD router. This query cycle may continue indefinitely once
started by sending the initial Request message.
A membership update occurs when an IGMP or MLD report, leave, or done
message is passed to the gateway pseudo-interface. These messages
may be produced as a result of the aforementioned query processing or
as a result of receiver interaction with the IGMP/MLD service
interface. Each report is encapsulated and sent to the relay after
the gateway has successfully established communication with the relay
via a Request and Membership Query message exchange. If a report is
passed to the pseudo-interface before the gateway has received a
Membership Query message from the relay, the gateway may discard the
report or queue the report for delivery after a Membership Query is
received. Subsequent IGMP/MLD report/leave/done messages that are
passed to the pseudo-interface are immediately encapsulated and
transmitted to the relay.
The following sequence describes how the Request, Membership Query,
and Membership Update messages are used to report current group
membership state or changes in group membership state:
1. A gateway sends a Request message to the relay that contains a
random nonce and a flag indicating whether the relay should
return an IGMPv3 or MLDv2 General Query.
2. When the relay receives a Request message, it generates a
message authentication code (MAC), typically, by computing a
hash digest from the message source IP address, source UDP port,
request nonce, and a private secret. The relay then sends a
Membership Query message to the gateway that contains the
request nonce, the MAC, and an IGMPv3 or MLDv2 General Query.
3. When the gateway receives a Membership Query message, it
verifies that the request nonce matches the one sent in the last
Request, and if it does, the gateway saves the request nonce and
MAC for use in sending subsequent Membership Update messages.
The gateway starts a timer whose expiration will trigger the
transmission of a new Request message and extracts the
encapsulated General Query message for processing by the IGMP or
MLD protocol. The query timer duration is specified by the
relay in the Querier's Query Interval Code (QQIC) field in the
IGMPv3 or MLDv2 General Query. The QQIC field is defined in
Section 4.1.7 of [RFC3376] and Section 5.1.9 of [RFC3810]).
4. The gateway's IGMP or MLD protocol implementation processes the
General Query to produce a current-state report.
5. When an IGMP or MLD report is passed to the pseudo-interface,
the gateway encapsulates the report in a Membership Update
message and sends it to the relay. The request nonce and MAC
fields in the Membership Update are assigned the values from the
last Membership Query message received for the corresponding
group membership protocol (IGMPv3 or MLDv2).
6. When the relay receives a Membership Update message, it computes
a MAC from the message source IP address, source UDP port,
request nonce, and a private secret. The relay accepts the
Membership Update message if the received MAC matches the
computed MAC; otherwise, the message is ignored. If the message
is accepted, the relay may proceed to allocate, refresh, or
modify tunnel state. This includes making any group membership,
routing, and forwarding state changes, and also issuing any
upstream protocol requests required to satisfy the state change.
The diagram illustrates two scenarios:
A. The gateway has not previously reported any group
subscriptions and the report does not contain any group
subscriptions, so the relay takes no action.
B. The gateway has previously reported a group subscription, so
the current-state report lists all current subscriptions.
The relay responds by refreshing tunnel or group state and
resetting any related timers.
7. A receiver indicates to the gateway that it wishes to join
(allow) or leave (block) specific multicast traffic. This
request is typically made using some form of IGMP/MLD service
interface (as described in Section 2 of [RFC3376] and Section 3
of [RFC3810]). The IGMP/MLD protocol responds by generating an
IGMP or MLD state-change message.
8. When an IGMP or MLD report/leave/done message is passed to the
pseudo-interface, the gateway encapsulates the message in a
Membership Update message and sends it to the relay. The
request nonce and MAC fields in the Membership Update are
assigned the values from the last Membership Query message
received for the corresponding group membership protocol (IGMP
The IGMP and MLD protocols may generate multiple messages to
provide robustness against packet loss -- each of these must be
encapsulated in a new Membership Update message and sent to the
relay. The Querier's Robustness Variable (QRV) field in the
last IGMP/MLD query delivered to the IGMP/MLD protocol is
typically used to specify the number of repetitions (i.e., the
host adopts the QRV value as its own Robustness Variable value).
The QRV field is defined in Section 4.1.6 of [RFC3376] and
Section 5.1.8 of [RFC3810].
9. When the relay receives a Membership Update message, it again
computes a MAC from the message source IP address, source UDP
port, request nonce, and a private secret. The relay accepts
the Membership Update message if the received MAC matches the
computed MAC; otherwise, the message is ignored. If the message
is accepted, the relay processes the encapsulated IGMP/MLD and
allocates, modifies, or deletes tunnel state accordingly. This
includes making any group membership, routing, and forwarding
state changes, and also issuing any upstream protocol requests
required to satisfy the state change. The diagram illustrates
A. The gateway wishes to add a group subscription.
B. The gateway wishes to delete a previously reported group
10. Multicast datagrams transmitted from a source travel through the
native multicast infrastructure to the relay. When the relay
receives a multicast IP datagram that carries a source and
destination address for which a gateway has expressed an
interest in receiving (via the Membership Update message), it
encapsulates the datagram into a Multicast Data message and
sends it to the gateway using the source IP address and UDP port
carried by the Membership Update message as the destination
11. When the gateway receives a Multicast Data message, it extracts
the multicast packet from the message and passes it on to the
12. When the query timer expires, the gateway sends a new Request
message to the relay to start a new membership update cycle.
The MAC-based source-authentication mechanism described above
provides a simple defense against malicious attempts to exhaust relay
resources via source-address spoofing. Flooding a relay with spoofed
Request or Membership Update messages may consume computational
resources and network bandwidth but will not result in the allocation
of state, because the Request message is stateless and spoofed
Membership Update messages will fail source authentication and be
rejected by the relay.
A relay will only allocate new tunnel state if the IGMP/MLD report
carried by the Membership Update message creates one or more group
A relay deallocates tunnel state after one of the following events:
the gateway sends a Membership Update message containing a report
that results in the deletion of all remaining group subscriptions,
the IGMP/MLD state expires (due to lack of refresh by the gateway),
or the relay receives a valid Teardown message from the gateway (see
A gateway that accepts or reports group subscriptions for both IPv4
and IPv6 addresses will send separate Request and Membership Update
messages for each protocol (IPv4/IGMP and IPv6/MLD).
188.8.131.52. Teardown Sequence
A gateway sends a Teardown message to a relay to request that it stop
delivering Multicast Data messages to a tunnel endpoint created by an
earlier Membership Update message. This message is intended to be
used following a gateway address change (see Section 184.108.40.206) to stop
the transmission of undeliverable or duplicate Multicast Data
messages. Gateway support for the Teardown message is RECOMMENDED.
Gateways are not required to send them and may instead rely on group
membership to expire on the relay.
The following sequence describes how the Membership Query and
Teardown messages are used to detect an address change and stop the
delivery of Multicast Data messages to an address:
1. A gateway sends a Request message containing a random nonce to
2. The relay sends a Membership Query message to the gateway that
contains the source IP address (gADDR) and source UDP port
(gPORT) values from the Request message. These values will be
used to identify the tunnel should one be created by a subsequent
Membership Update message.
3. When the gateway receives a Membership Query message that carries
the gateway address fields, it compares the gateway IP address
and UDP port number values with those received in the previous
Membership Query (if any). If these values do not match, this
indicates that the Request message arrived at the relay carrying
a different source address than the one sent previously. At this
point in the sequence, no change in source address or port has
4. The gateway sends a new Request message to the relay. However,
this Request message arrives at the relay carrying a different
source address than that of the previous Request due to some
change in network interface, address assignment, network
topology, or NAT mapping.
5. The relay again responds by sending a Membership Query message to
the gateway that contains the new source IP address (gADDR') and
source UDP port (gPORT') values from the Request message.
6. When the gateway receives the Membership Query message, it
compares the gateway address and port number values against those
returned in the previous Membership Query message.
7. If the reported address or port has changed, the gateway sends a
Teardown message to the relay that contains the request nonce,
MAC, gateway IP address, and gateway port number returned in the
earlier Membership Query message. The gateway may send the
Teardown message multiple times where the number of repetitions
is governed by the Querier's Robustness Variable (QRV) value
contained in the IGMPv3/MLDv2 General Query carried by the
original Membership Query (see Section 4.1.6 of [RFC3376] and
Section 5.1.8 of [RFC3810]). The gateway continues to process
the new Membership Query message as usual.
8. When the relay receives a Teardown message, it computes a MAC
from the message source IP address, source UDP port, request
nonce, and a private secret. The relay accepts the Teardown
message if the received MAC matches the computed MAC; otherwise,
the message is ignored. If the message is accepted, the relay
makes any group membership, routing, and forwarding state changes
required to stop the transmission of Multicast Data messages to
220.127.116.11. Timeout and Retransmission
The AMT protocol does not establish any requirements regarding what
actions a gateway should take if it fails to receive a response from
a relay. A gateway implementation may wait for an indefinite period
of time to receive a response, may set a time limit on how long to
wait for a response, may retransmit messages should the time limit be
reached, may limit the number of retransmissions, or may simply
report an error.
For example, a gateway may retransmit a Request message if it fails
to receive a Membership Query or expected Multicast Data messages
within some time period. If the gateway fails to receive any
response to a Request after several retransmissions or within some
maximum period of time, it may reenter the relay discovery phase in
an attempt to find a new relay. This topic is addressed in more
detail in Section 5.2.
From the standpoint of a relay, an AMT "tunnel" is identified by the
IP address and UDP port pair used as the destination address for
sending encapsulated multicast IP datagrams to a gateway. In this
document, we refer to this address as the tunnel endpoint address.
A gateway sends a Membership Update message to a relay to add or
remove group subscriptions to a tunnel endpoint. The tunnel endpoint
is identified by the source IP address and source UDP port carried by
the Membership Update message when it arrives at a relay (this
address may differ from that carried by the message when it exited
the gateway as a result of network address translation).
The Membership Update messages sent by a single gateway host may
originate from several source addresses or ports -- each unique
combination represents a unique tunnel endpoint. A single gateway
host may legitimately create and accept traffic on multiple tunnel
endpoints, e.g., the gateway may use separate ports for the IPv4/IGMP
and IPv6/MLD protocols.
A tunnel is "created" when a gateway sends a Membership Update
message containing an IGMP or MLD membership report that creates one
or more group subscriptions when none currently existed for that
tunnel endpoint address.
A tunnel ceases to exist when all group subscriptions for a tunnel
endpoint are deleted. This may occur as a result of the following
o The gateway sends an IGMP or MLD report, leave, or done message to
the relay that deletes the last group subscription linked to the
o The gateway sends a Teardown message to the relay that causes it
to delete any and all subscriptions bound to the tunnel endpoint.
o The relay stops receiving updates from the gateway until such time
that per-group or per-tunnel timers expire, causing the relay to
delete the subscriptions.
The tunneling approach described above conceptually transforms a
unicast-only internetwork into an NBMA link layer, over which
multicast traffic may be delivered. Each relay, plus the set of all
gateways using the relay, together may be thought of as being on a
separate logical NBMA link, where the "link layer" address is a UDP/
IP address-port pair provided by the Membership Update message.
18.104.22.168. Address Roaming
As described above, each time a relay receives a Membership Update
message from a new source address-port pair, the group subscriptions
described by that message apply to the tunnel endpoint identified by
This can cause problems for a gateway if the address carried by the
messages it sends to a relay changes unexpectedly. These changes may
cause the relay to transmit duplicate, undeliverable, or unrequested
traffic back towards the gateway or an intermediate device. This may
create congestion and have negative consequences for the gateway, its
network, or multicast receivers and in some cases may also produce a
significant amount of ICMP traffic directed back towards the relay by
a NAT, router, or gateway host.
There are several scenarios in which the address carried by messages
sent by a gateway may change without that gateway's knowledge -- for
o The message originates from a different interface on a gateway
that possesses multiple interfaces.
o The DHCP assignment for a gateway interface changes.
o The gateway roams to a different wireless network.
o The address mapping applied by an intervening network-translation
device (NAT) changes as a result of mapping expiration or routing
changes in a multihomed network.
In the case where the address change occurs between the transmission
of a Request message and subsequent Membership Update messages, the
relay will simply ignore any Membership Update messages from the new
address because MAC authentication will fail (see Section 22.214.171.124).
The relay may continue to transmit previously requested traffic, but
no duplication will occur, i.e., the possibility for the delivery of
duplicate traffic does not arise until a Request message is received
from the new address.
The protocol provides a method for a gateway to detect an address
change and explicitly request that the relay stop sending traffic to
a previous address. This process involves the Membership Query and
Teardown messages and is described in Section 126.96.36.199.
188.8.131.52. Network Address Translation
The messages sent by a gateway to a relay may be subject to network
address translation (NAT) -- the source IP address and UDP port
carried by an IP packet sent by the gateway may be modified multiple
times before arriving at the relay. In the most restrictive form of
NAT, the NAT device will create a new mapping for each combination of
source and destination IP address and UDP port. In this case,
bidirectional communication can only be conducted by sending outgoing
packets to the source address and port carried by the last incoming
Membership Update Membership Update
src: iADDR:iPORT src: eADDR:ePORT
dst: rADDR:rPORT dst: rADDR:rPORT
| NAT |
+---------+ +-----------+ +---------+
| |---------->| |--------->| |
| Gateway | | Mapping | | Relay |
| |<----------| |<---------| |
+---------+ +-----------+ +---------+
Multicast Data Multicast Data
src: rADDR:rPORT src: rADDR:rPORT
dst: iADDR:iPORT dst: eADDR:ePORT
Figure 9: Network Address Translation in AMT
AMT provides automatic NAT traversal by using the source IP address
and UDP port carried by the Membership Update message as received at
the relay as the destination address for any Multicast Data messages
the relay sends back as a result.
The NAT mapping created by a Membership Update message will
eventually expire unless it is refreshed by a passing message. This
refresh will occur each time the gateway performs the periodic update
required to refresh group state within the relay (see
184.108.40.206. UDP Encapsulation
| AMT:IP:IGMP AMT:IP:IGMP |
| | | |
| | IP:UDP:AMT:IP:IGMP | |
_______ | ___ | ______ | ______ | ___ | _______
|IGMP|IP| v |AMT| v |UDP|IP| v |IP|UDP| v |AMT| v |IP|IGMP|
| | | | | | | | | | | | | | | |
| |<------------------------------------------------------->| |
|____| | | | | | | | | | | | | |____|
| |<--------------------------------------------------| |
|_______| ^ |___| ^ |___|__| ^ |__|___| ^ |___| ^ |_______|
| | | | |
IP AMT:IP IP:UDP:AMT:IP AMT:IP IP
Figure 10: AMT Encapsulation
The IGMP and MLD messages used in AMT are exchanged as complete IP
datagrams. These IP datagrams are encapsulated in AMT messages that
are transmitted using UDP. The same holds true for multicast traffic
-- each multicast IP datagram or datagram fragment that arrives at
the relay is encapsulated in an AMT message and transmitted to one or
more gateways via UDP.
The IP protocol of the encapsulated packets need not match the IP
protocol used to send the AMT messages. AMT messages sent via IPv4
may carry IPv6/MLD packets, and AMT messages sent via IPv6 may carry
The Checksum field contained in the UDP header of the messages
requires special consideration. Of primary concern is the cost of
computing a checksum on each replicated multicast packet after it is
encapsulated for delivery to a gateway. Many routing/forwarding
platforms do not possess the capability to compute checksums on
UDP-encapsulated packets, as they may not have access to the entire
To avoid placing an undue burden on the relay platform, the protocol
specifically allows zero-valued UDP checksums on the Multicast Data
messages. This is not an issue in UDP over IPv4, as the UDP Checksum
field may be set to zero. However, this is a problem for UDP over
IPv6, as that protocol requires a valid, non-zero checksum in UDP
datagrams [RFC2460]. Messages sent over IPv6 with a UDP checksum of
zero may fail to reach the gateway. This is a well-known issue for
UDP-based tunneling protocols and is described in [RFC6936]. A
recommended solution is described in [RFC6935].
220.127.116.11. UDP Fragmentation
Naive encapsulation of multicast IP datagrams within AMT data
messages may produce UDP datagrams that might require fragmentation
if their size exceeds the MTU of the network path between the relay
and a gateway. Many multicast applications, especially those related
to media streaming, are designed to deliver independent data samples
in separate packets, without fragmentation, to ensure that some
number of complete samples can be delivered even in the presence of
packet loss. To prevent or reduce undesirable fragmentation, the AMT
protocol describes specific procedures for handling multicast
datagrams whose encapsulation might exceed the Path MTU. These
procedures are described in Section 18.104.22.168.