One document matched: draft-ietf-mboned-auto-multicast-12.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no"?>
<rfc category="std" docName="draft-ietf-mboned-auto-multicast-12"
ipr="pre5378Trust200902">
<front>
<title abbrev="AMT">Automatic Multicast Tunneling</title>
<author fullname="Gregory Bumgardner" initials="G." surname="Bumgardner">
<organization>Cisco</organization>
<address>
<postal>
<street>3700 Cisco Way</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 408 853 4993</phone>
<email>gbumgard@cisco.com</email>
</address>
</author>
<author fullname="Thomas Morin" initials="T." surname="Morin">
<organization>France Telecom - Orange</organization>
<address>
<postal>
<street>2, avenue Pierre Marzin</street>
<city>Lannion</city>
<code>22300</code>
<country>France</country>
</postal>
<phone>+33 2 96 05 3734</phone>
<email>thomas.morin@orange.com</email>
</address>
</author>
<date day="16" month="February" year="2012" />
<abstract>
<t>This document describes Automatic Multicast Tunneling (AMT), a
protocol for delivering multicast traffic from sources in a
multicast-enabled network to receivers that lack multicast connectivity
to the source network. The protocol uses UDP encapsulation and unicast
replication to provide this functionality.</t>
<t>The AMT protocol is specifically designed to support rapid deployment
by requiring minimal changes to existing network infrastructure.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The advantages and benefits provided by multicast technologies are
well known. There are a number of application areas that are ideal
candidates for the use of multicast, including media broadcasting, video
conferencing, collaboration, real-time data feeds, data replication, and
software updates. Unfortunately, many of these applications must
currently rely on unicast replication at or near sources because most
clients lack multicast connectivity to the network containing the
sources. The reasons for the lack of connectivity vary, but are
primarily the result of service provider policies and network
limitations.</t>
<t>Automatic Multicast Tunneling (AMT) is a protocol that uses UDP-based
encapsulation to overcome the aforementioned lack of multicast
connectivity. AMT enables sites, hosts or applications that do not have
native multicast access to a multicast source network to request and
receive SSM <xref target="RFC4607"></xref> and ASM <xref
target="RFC1112"></xref> multicast traffic from sources in that
network.</t>
</section>
<section title="Applicability">
<t>This document describes a protocol that may be used to deliver
multicast traffic from sources in a multicast enabled network to sites
that lack multicast connectivity to the source network. This document
does not describe any methods for sourcing multicast traffic from
isolated sites as this topic is out of scope.</t>
<t>AMT is not intended to be used as a substitute for native multicast,
especially in conditions or environments requiring high traffic flow.
AMT uses unicast replication to reach multiple receivers and the
bandwidth cost for this replication will be higher than that required if
the receivers were reachable via native multicast.</t>
</section>
<section title="Terminology">
<section title="Requirements Notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
<section title="Definitions">
<t>This document adopts the following definitions for use in
describing the protocol:<list style="hanging">
<t hangText="Downstream:"><vspace blankLines="0" />A downstream
interface or connection that faces away from the multicast
distribution root or towards multicast receivers.</t>
<t hangText="Upstream:"><vspace blankLines="0" />An upstream
interface or connection that faces a multicast distribution root
or source.</t>
<t hangText="Non-Broadcast Multi-Access (NMBA):"><vspace
blankLines="0" />A non-broadcast multiple-access (NBMA) network or
interface is one to which multiple network nodes (hosts or
routers) are attached, but where packets are transmitted directly
from one node to another node over a virtual circuit or physical
link. NBMA networks do not support multicast or broadcast traffic
- a node that sources multicast traffic must replicate the
multicast packets for separate transmission to each node that has
requested the multicast traffic.</t>
<t hangText="Multicast Receiver:"><vspace blankLines="0" />An
entity that requests and receives multicast traffic. A receiver
may be a router, host, application, or application component. The
method by which a receiver transmits group membership requests and
receives multicast traffic varies according to receiver type.</t>
<t hangText="Group Membership Database:"><vspace
blankLines="0" />A group membership database describes the current
multicast subscription/reception sate for an interface or
system.</t>
<t hangText="Reception State:"><vspace blankLines="0" />The
multicast subscription state of a pseudo, virtual or physical
network interface. See group membership database.</t>
<t hangText="Subscription:"><vspace blankLines="0" />A group or
state entry in a group membership database or reception state
table.</t>
<t hangText="Group Membership Protocol:"><vspace
blankLines="0" />The term "group membership protocol" is used as a
generic reference to the Internet Group Management (IGMP) (<xref
target="RFC1112"></xref>, <xref target="RFC2236"></xref>, <xref
target="RFC3376"></xref>) or Multicast Listener Discovery (<xref
target="RFC2710"></xref>, <xref target="RFC3810"></xref>)
protocols.</t>
<t hangText="Multicast Protocol:"><vspace blankLines="0" />The
term "multicast protocol" is used as a generic reference to
multicast routing protocols used to join or leave multicast
distribution trees such as PIM-SM <xref
target="RFC4601"></xref>.</t>
<t hangText="Network Address Translation (NAT):"><vspace
blankLines="0" />Network Address Translation is the process of
modifying the source IP address and port numbers carried by an IP
packet while transiting a network node (See <xref
target="RFC2663"></xref>). Intervening NAT devices may change the
source address and port carried by messages sent from an AMT
gateway to an AMT relay, possibly producing changes in protocol
state and behavior.</t>
<t hangText="Anycast:"><vspace blankLines="0" />A network
addressing and routing method in which packets from a single
sender are routed to the topologically nearest node in a group of
potential receivers all identified by the same destination
address. See <xref target="RFC4786"></xref>.</t>
</list></t>
</section>
<section title="Abbreviations">
<t><list style="empty">
<t>AMT - Automatic Multicast Tunneling Protocol.</t>
<t>ASM - Any-Source Multicast.</t>
<t>DoS - Denial-of-Service (attack) and DDoS for
distributed-DoS.</t>
<t>IGMP - Internet Group Management Protocol (v1, v2 and v3).</t>
<t>IP - Internet Protocol (v4 and v6).</t>
<t>MAC - Message Authentication Code (or Cookie).</t>
<t>MLD - Multicast Listener Discovery protocol (v1 and v2).</t>
<t>NAT - Network Address Translation (or translation node).</t>
<t>NBMA - Non-Broadcast Multi-Access (network, interface or
mode)</t>
<t>SSM - Source-Specific Multicast.</t>
<t>PIM - Protocol Independent Multicast.</t>
</list></t>
</section>
</section>
<section title="Protocol Overview">
<t>This section provides an informative description of the protocol. A
normative description of the protocol and implementation requirements
may be found in section <xref target="protocol-description"></xref>.</t>
<section anchor="general-architecture" title="General Architecture">
<figure anchor="basic-amt-architecture-figure"
title="Basic AMT Architecture">
<artwork><![CDATA[
Isolated Site | Unicast Network | Native Multicast
| (Internet) |
| |
| |
| Group Membership |
+-------+ ===========================> +-------+ Multicast +------+
|Gateway| | | | Relay |<----//----|Source|
+-------+ <=========================== +-------+ +------+
| Multicast Data |
| |
| |]]></artwork>
</figure>
<t>The AMT protocol employs a client-server model in which a "gateway"
sends requests to receive specific multicast traffic to a "relay"
which responds by delivering the requested multicast traffic back to
the gateway.</t>
<t>Gateways are generally deployed within networks that lack multicast
support or lack connectivity to a multicast-enabled network containing
multicast sources of interest.</t>
<t>Relays are deployed within multicast-enabled networks that contain,
or have connectivity to, multicast sources.</t>
<section title="Relationship to IGMP and MLD Protocols" toc="exclude">
<t>AMT relies on the <xref target="RFC3376">Internet Group
Management (IGMP)</xref> and <xref target="RFC3810">Multicast
Listener Discovery (MLD)</xref> protocols 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 <xref
target="gateway-igmp-mld-protocol-requirements"></xref> and <xref
target="relay-igmp-mld-protocol-requirements"></xref>.</t>
<figure title="Multicast Reception State Managed By IGMP/MLD">
<artwork><![CDATA[
Gateway Relay
General _____ _____
___________ Query | | | | Query ___________
| |<------| | | |<------| |
| Host Mode | | AMT | | AMT | |Router Mode|
| IGMP/MLD | | | UDP | | | IGMP/MLD |
|___________|------>| |<----->| |------>|___________|
Report | | | | Report
Leave/Done | | | | Leave/Done
| | | |
IP Multicast <------| | | |<------ IP Multicast
|_____| |_____|
]]></artwork>
</figure>
<t>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.</t>
<t>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
unicast UDP/IP.</t>
</section>
<section title="Gateways" toc="exclude">
<t>The downstream side of a gateway services multicast receivers -
the gateway accepts group membership requests from receivers and
forwards requested multicast traffic back to those receivers.</t>
<t>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.</t>
<section title="Architecture">
<figure anchor="amt-gateway-pseudo-interface-figure"
title="AMT Gateway Pseudo-Interface">
<preamble>Each gateway possesses a logical
pseudo-interface:</preamble>
<artwork><![CDATA[
join/leave ---+ +----------+
| | |
V IGMPv3/MLDv2 | |
+---------+ General Query| | AMT
|IGMP/MLD |<-------------| AMT | Messages +------+
|Host Mode| | Gateway |<-------->|UPD/IP|
|Protocol |------------->|Pseudo I/F| +------+
+---------+ IGMP/MLD | | ^
Report | | |
Leave/Done | | V
IP Multicast <---------------------| | +---+
+----------+ |I/F|
+---+
]]></artwork>
</figure>
<t>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.</t>
<t>All AMT encapsulation, decapsulation and relay interaction is
assumed to occur within the pseudo-interface.</t>
<t>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.</t>
<t>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 inter-network and one or more
AMT gateway pseudo-interfaces.</t>
<figure title="Virtual Interface Implementation Example">
<preamble>The following diagram illustrates how an existing host
IP stack implementation might be used to provide AMT gateway
functionality to a multicast application:</preamble>
<artwork><![CDATA[
+-----------------------------------------------------+
|Host |
| ______________________________________ |
| | | |
| | ___________________________ | |
| | | | | |
| | | v | |
| | | +-----------+ +--------------+ |
| | | |Application| | AMT Daemon | |
| | | +-----------+ +--------------+ |
| | | join/leave | ^ data ^ AMT |
| | | | | | |
| | | +----|---|-------------|-+ |
| | | | __| |_________ | | |
| | | | | | | | |
| | | | | Sockets | | | |
| | | +-|------+-------+-|---|-+ |
| | | | | IGMP | TCP | |UDP| | |
| | | +-|------+-------+-|---|-+ |
| | | | | ^ IP | | | |
| | | | | | ____________| | | |
| | | | | | | | | |
| | | +-|-|-|----------------|-+ |
| | | | | | | |
| | | IP(IGMP)| | |IP(UDP(data)) |IP(UDP(AMT)) |
| | | v | | v |
| | | +-----------+ +---+ |
| | | |Virtual I/F| |I/F| |
| | | +-----------+ +---+ |
| | | | ^ ^ |
| | | IP(IGMP)| |IP(UDP(data)) | |
| | |_________| |IP(IGMP) | |
| | | | |
| |_________________| | |
| | |
+--------------------------------------|--------------+
v
AMT Relay
]]></artwork>
</figure>
<t>In this example, the host IP stack uses a virtual network
interface to interact with a gateway pseudo-interface
implementation.</t>
</section>
<section title="Use-Cases">
<t>Use-cases for gateway functionality include:<list
style="hanging">
<t hangText="IGMP/MLD Proxy"><vspace blankLines="0" />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.</t>
<t hangText="Virtual Network Interface"><vspace
blankLines="0" />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.</t>
<t hangText="Application"><vspace blankLines="0" />An
application or application component that implements and
executes IGMP/MLD and AMT internally to gain access to
multicast traffic.</t>
</list></t>
</section>
</section>
<section title="Relays" toc="exclude">
<t>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 those gateways.</t>
<t>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.</t>
<section title="Architecture">
<figure title="AMT Relay Pseudo-Interface (Router-Based)">
<preamble>Each relay possesses a logical
pseudo-interface:</preamble>
<artwork><![CDATA[
+------------------------------+
+--------+ | Multicast Control Plane |
| |IGMP/MLD| |
| | Query* | +------------+ +----------+ |
| |<---//----|IGMPv3/MLDv2| | | |
AMT | | | |Router Mode |->| PIM-SM |<-->
+------+ Messages | AMT |----//--->|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.
]]></artwork>
</figure>
<t>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.</t>
<t>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 state.</t>
<t>The relay pseudo-interface is a 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.</t>
<t>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.</t>
<t>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.</t>
<t>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
inter-network, and one or more relay pseudo-interfaces.</t>
</section>
<section title="Use-Cases">
<t>Use-cases for relay functionality include:<list style="hanging">
<t hangText="Multicast Router"><vspace blankLines="0" />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 <xref
target="RFC4601"> RFC4601</xref>) 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 rendezvous point.</t>
<t hangText="IGMP/MLD Proxy Router"><vspace
blankLines="0" />An IGMP/MLD proxy that runs AMT on a
downstream interface and host-mode IGMPv3/MLDv2 on a upstream
interface. This "relay proxy" sends group membership reports
to a local, multicast-enabled router to join and leave
specific SSM or ASM groups.</t>
</list></t>
</section>
</section>
<section anchor="overview-deployment" title="Deployment" toc="exclude">
<t>The AMT protocol calls for a relay deployment model that uses
anycast addressing <xref target="RFC1546"></xref><xref
target="RFC4291"></xref> to pair gateways with relays.</t>
<t>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.</t>
<t>The use of anycast addressing provides the following benefits:
<list style="symbols">
<t>Relays may be deployed at multiple locations within a single
multicast-enabled network. Relays might be installed "near"
gateways to reduce bandwidth requirements, latency and limit the
number of gateways that might be serviced by a single relay.</t>
<t>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
relay.</t>
<t>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.</t>
</list></t>
<section title="Public Versus Private" toc="exclude">
<t>Ideally, the AMT protocol would provide a universal solution
for connecting gateways to multicast sources - that any gateway
would be able to access any globally advertised multicast source
via publicly-accessible, widely-deployed relays. Unfortunately,
today's internet does not yet allow this, as many relays will lack
native multicast access to sources even though they may be
globally accessible via unicast.</t>
<t>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 these relays.</t>
</section>
</section>
<section anchor="overview-discovery" title="Discovery" toc="exclude">
<t>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.</t>
<t>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.</t>
<t>The AMT protocol uses the following terminology when describing
the discovery process:<list style="hanging">
<t hangText="Relay Discovery Address Prefix:"><vspace
blankLines="0" />The anycast address prefix used to route
discovery messages to a relay.</t>
<t hangText="Relay Discovery Address:"><vspace
blankLines="0" />The anycast destination address used when
sending discovery messages.</t>
<t hangText="Relay Address:"><vspace blankLines="0" />The
unicast IP address obtained as a result of the discovery
process.</t>
</list></t>
<section title="Relay Discovery Address Selection" toc="exclude">
<t>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.</t>
<t>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 source</t>
<t>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.</t>
</section>
<section title="IANA-Assigned Relay Discovery Address Prefix"
toc="exclude">
<t>This document calls for IANA to allocate an anycast address
prefix for use in advertising and discovering publicly accessible
relays.</t>
<t>A relay discovery address is constructed from the anycast
address prefix by setting the low-order octet of the prefix
address to 1 (for both IPv4 and IPv6).</t>
<t>Public relays must advertise a route to the anycast address
prefix and configure an interface to respond to the relay
discovery address.</t>
<t>The IANA address assignments are discussed in <xref
target="iana-considerations"></xref>.</t>
</section>
</section>
</section>
<section anchor="general-operation" title="General Operation">
<section title="Message Sequences" toc="exclude">
<t>The AMT protocol defines the following messages for control and
encapsulation. These messages are exchanged as UDP/IP datagrams, one
message per datagram.<list style="hanging">
<t hangText="Relay Discovery:"><vspace blankLines="0" />Sent by
gateways to solicit a Relay Advertisement from any relay in
order to find a relay with which to communicate.</t>
<t hangText="Relay Advertisement:"><vspace blankLines="0" />Sent
by relays as a response to a Relay Discovery message. Used to
deliver a relay address to a gateway.</t>
<t hangText="Request:"><vspace blankLines="0" />Sent by gateways
to solicit a Membership Query message from a relay.</t>
<t hangText="Membership Query:"><vspace blankLines="0" />Sent by
relays as a response to a Request message. Used to deliver an
encapsulated IGMPv3 or MLDv2 query message to the gateway.</t>
<t hangText="Membership Update:"><vspace blankLines="0" />Sent
by gateways to deliver an encapsulated IGMP or MLD
report/leave/done message to a relay.</t>
<t hangText="Multicast Data:"><vspace blankLines="0" />Sent by
relays to deliver an encapsulated IP multicast datagram to a
gateway.</t>
<t hangText="Teardown:"><vspace blankLines="0" />Sent by
gateways to stop the delivery of Multicast Data messages
requested in an earlier Membership Update message.</t>
</list>The following sections describe how these messages are
exchanged to execute the protocol.</t>
<section anchor="overview-relay-discovery-sequence"
title="Relay Discovery Sequence">
<figure title="AMT Relay Discovery Sequence">
<artwork><![CDATA[
Gateway Relay
------- -----
: :
| |
[1] |Relay Discovery |
|------------------->|
| |
| Relay Advertisement| [2]
|<-------------------|
[3] | |
: :
]]></artwork>
</figure>
<t>The following sequence describes how the Relay Discovery and
Relay Advertisement messages are used to find a relay with which
to communicate:<list style="numbers">
<t>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 topologically-nearest network node that advertises that
address.</t>
<t>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 relay.</t>
<t>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.</t>
</list></t>
<t>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 broker).</t>
</section>
<section anchor="overview-membership-update-sequence"
title="Membership Update Sequence">
<t>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.</t>
<t>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 general-query response. A gateway accomplishes this by sending a
Request message to a relay. The relay responds by sending
Membership Query message back to the gateway. The Membership Query
message carries an encapsulated general 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 general query by an IGMP/MLD router.
This query cycle may continue indefinitely once started by sending
the initial Request message.</t>
<t>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
general-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.</t>
<figure title="Membership Update Sequence (IGMPv3/MLDv2 Example)">
<artwork><![CDATA[
IGMP/MLD Pseudo-I/F Relay
-------- ---------- -----
: : :
| | Request |
| 1|-------------------->|
| | Membership Query |2
Query | | Q(0,{}) |
Timer | Start 3|<--------------------|
(QT)<--------------------------| |
| Q(0,{}) | |
|<--------------------| |
4| R({}) | Membership Update |
|-------------------->|5 R({}) |
| |====================>|6a
Join(S,G) : : :
()--------->|7 R({G:ALLOW({S})}) | Membership Update |
|-------------------->|8 R({G:ALLOW({S})}) |
| |====================>|9a Join(S,G)
| | |---------->()
: : :
| ------------|---------------------|------------
| | | | |
| | | Multicast Data | IP(S,G) |
| | | IP(S,G) 10|<--------() |
| | IP(S,G) 11|<====================| |
| | ()<--------| | |
| | | | |
: ------------:---------------------:------------
| Expired | |
(QT)-------------------------->|12 Request |
| 1|-------------------->|
| | Membership Query |2
| | Q(0,{}) |
| Start 3|<--------------------|
(QT)<--------------------------| |
| Q(0,{}) | |
|<--------------------| |
4| R({G:INCLUDE({S})}) | Membership Update |
|-------------------->|5 R({G:INCLUDE({S})})|
| |====================>|6b
Leave(S,G) : : :
()--------->|7 R({G:BLOCK({S})}) | Membership Update |
|-------------------->|8 R({G:BLOCK({S})}) |
| |====================>|9b Prune(S,G)
| | |---------->()
: : :
]]></artwork>
</figure>
<t>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:<list
style="numbers">
<t>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.</t>
<t>When the relay receives a Request message, it generates a
message authentication code (MAC) by computing a hash value
from a private secret and the nonce, source IP address, and
source UDP port carried by the Request message. 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.</t>
<t>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 QQIC field in the IGMPv3 or MLDv2 general
query.</t>
<t>The gateway's IGMP or MLD protocol implementation processes
the general query to produce a current-state report.</t>
<t>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).</t>
<t>When the relay receives a Membership Update message, it
computes a MAC from a private secret and the request nonce,
source IP address, and source UDP port carried by the message.
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 issuing any upstream protocol requests required to
satisfy the state change. The diagram illustrates two
scenarios: <list style="letters">
<t>The gateway has not previously reported any group
subscriptions and the report does not contain any group
subscriptions, so the relay takes no action.</t>
<t>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.</t>
</list></t>
<t>A receiver indicates to the gateway that it wishes to join
(allow) or leave (block) specific multicast traffic. This
request is typically made through some form IGMP/MLD service
interface (as described in Section 2 of <xref
target="RFC3376"></xref> or Section 3 of <xref
target="RFC3810"></xref>). The IGMP/MLD protocol responds by
generating an IGMP or MLD state-change message.</t>
<t>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
or MLD).<vspace blankLines="1" />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
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).</t>
<t>When the relay receives a Membership Update message, it
again computes a MAC from a private secret and the request
nonce, source IP address, and source UDP port carried by the
message. 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
issuing any upstream protocol requests required to satisfy the
state change. The diagram illustrates two scenarios:<list
style="letters">
<t>The gateway wishes to add a group subscription.</t>
<t>The gateway wishes to delete a previously reported
group subscription.</t>
</list></t>
<t>Multicast datagrams transmitted by 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 address.</t>
<t>When the gateway receives a Multicast Data message, it
extracts the multicast packet from the message and passes it
on to the appropriate receivers.</t>
<t>When the query timer expires the gateway sends a new
Request message to the relay to start a new membership update
cycle.</t>
</list></t>
<t>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.</t>
<t>A relay will only allocate new tunnel state if the IGMP/MLD
report carried by the Membership Update message creates one or
more group subscriptions.</t>
<t>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.</t>
<t>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).</t>
</section>
<section anchor="overview-teardown-sequence"
title="Teardown Sequence">
<t>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 <xref
target="address-roaming"></xref>) to stop the transmission of
undeliverable or duplicate multicast data messages. Support for
the Teardown message is optional - gateways are not required to
send them and relays are not required to act upon them.</t>
<figure anchor="figure-teardown-message-sequence"
title="Teardown Message Sequence (IGMPv3/MLDv2 Example)">
<artwork><![CDATA[
Gateway Relay
------- -----
: Request :
[1] | N |
|---------------------->|
| Membership Query | [2]
| N,MAC,gADDR,gPORT |
|<======================|
[3] | Membership Update |
| ({G:INCLUDE({S})}) |
|======================>|
| |
----------------------:-----------------------:----------------------
| | | |
| | *Multicast Data | *IP Packet(S,G) |
| | gADDR,gPORT |<------------------() |
| *IP Packet(S,G) |<======================| |
| ()<------------------| | |
| | | |
----------------------:-----------------------:----------------------
~ |
~ Request |
[4] | N' |
|---------------------->|
| Membership Query | [5]
| N',MAC',gADDR',gPORT' |
|<======================|
[6] | |
| Teardown |
| N,MAC,gADDR,gPORT |
|---------------------->|
| | [7]
| Membership Update |
| ({G:INCLUDE({S})}) |
|======================>|
| |
----------------------:-----------------------:----------------------
| | | |
| | *Multicast Data | *IP Packet(S,G) |
| | gADDR',gPORT' |<------------------() |
| *IP Packet (S,G) |<======================| |
| ()<------------------| | |
| | | |
----------------------:-----------------------:----------------------
| |
: :
]]></artwork>
</figure>
<t>The following sequence describes how the Membership Query and
Teardown message are used to detect an address change and stop the
delivery of Multicast Data messages to an address:<list
style="numbers">
<t>A gateway sends a Request message containing a random nonce
to the relay.</t>
<t>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.</t>
<t>When the gateway receives a Membership Query message that
carries the gateway address fields, it compares the gateway IP
address and 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 occurred.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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 Robustness Variable
(QRV) value contained in the IGMPv3/MLDv2 general query
carried by the original Membership Query. The gateway
continues to process the new Membership Query message as
usual.</t>
<t>When the relay receives a Teardown message, it computes a
MAC from a private secret and the request nonce, gateway IP
address, and gateway port number carried by the Teardown
message. 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 that address.</t>
</list></t>
</section>
<section title="Timeout and Retransmission">
<t>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.</t>
<t>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 <xref target="gateway-operation"></xref>.</t>
</section>
</section>
<section anchor="overview-tunneling" title="Tunneling" toc="exclude">
<t>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. This
address is referred here as the tunnel endpoint address.</t>
<t>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).</t>
<t>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.</t>
<t>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.</t>
<t>A tunnel ceases to exist when all group subscriptions for a
tunnel endpoint are deleted. This may occur as a result of the
following events:<list style="symbols">
<t>The gateway sends an IGMP or MLD report, leave or done
message to the relay that deletes the last group subscription
linked to the tunnel endpoint.</t>
<t>The gateway sends a Teardown message to the relay that causes
it to delete any and all subscriptions bound to the tunnel
endpoint.</t>
<t>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.</t>
</list></t>
<t>The tunneling approach described above conceptually transforms a
unicast-only inter-network 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.</t>
<section anchor="address-roaming" title="Address Roaming"
toc="exclude">
<t>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 that address.</t>
<t>This can cause problems for a gateway if the address carried by
the messages it sends to a relay change 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.</t>
<t>There are several scenarios in which the address carried by
messages sent by a gateway may change without that gateway's
knowledge, as for example, when:<list style="symbols">
<t>The message originates from a different interface on a
gateway that possesses multiple interfaces.</t>
<t>The DHCP assignment for a gateway interface changes.</t>
<t>The gateway roams to a different wireless network.</t>
<t>The address mapping applied by an intervening
network-translation-device (NAT) changes as a result of
mapping expiration or routing changes in a multi-homed
network.</t>
</list></t>
<t>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 <xref target="overview-membership-update-sequence"></xref>).
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.</t>
<t>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 <xref
target="overview-teardown-sequence"></xref>.</t>
</section>
<section anchor="network-address-translation"
title="Network Address Translation" toc="exclude">
<t>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, bi-directional communication can only be
conducted by sending outgoing packets to the source address and
port carried by the last incoming packet.</t>
<figure title="Network Address Translation in AMT">
<artwork><![CDATA[
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
]]></artwork>
</figure>
<t>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.</t>
<t>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 <xref
target="overview-membership-update-sequence"></xref>).</t>
</section>
<section anchor="udp-encapsulation" title="UDP Encapsulation"
toc="exclude">
<figure title="AMT Encapsulation">
<artwork><![CDATA[
Gateway Relay
IP:IGMP IP:IGMP
| 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
]]></artwork>
</figure>
<t>The IGMP and MLD messages used in AMT are exchanged as complete
IP datagrams. These IP datagrams are encapsulated in AMT messages
which are transmitted using UDP. The same holds true for multicast
traffic - each multicast IP datagram that arrives at the relay is
encapsulated in an AMT message and transmitted to one or more
gateways via UDP.</t>
<t>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 IPv4/IGMP packets.</t>
<t>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
datagram.</t>
<t>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 <xref target="RFC2460"></xref>.
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. See <xref
target="I-D.ietf-6man-udpchecksums"></xref> and <xref
target="I-D.ietf-6man-udpzero"></xref> for details.</t>
</section>
</section>
</section>
</section>
<section anchor="protocol-description" title="Protocol Description">
<t>This section provides a normative description of the AMT
protocol.</t>
<section title="Protocol Messages">
<t>The AMT protocol defines seven message types for control and
encapsulation. These messages are assigned the following names and
numeric identifiers:</t>
<texttable style="full">
<ttcol align="center">Message Type</ttcol>
<ttcol>Message Name</ttcol>
<c>1</c>
<c>Relay Discovery</c>
<c>2</c>
<c>Relay Advertisement</c>
<c>3</c>
<c>Request</c>
<c>4</c>
<c>Membership Query</c>
<c>5</c>
<c>Membership Update</c>
<c>6</c>
<c>Multicast Data</c>
<c>7</c>
<c>Teardown</c>
</texttable>
<t>These messages are exchanged as IPv4 or IPv6 UDP datagrams.</t>
<section anchor="relay-discovery-message" title="Relay Discovery"
toc="exclude">
<t>A Relay Discovery message is used to solicit a response from a
relay in the form of a Relay Advertisement message.</t>
<t>The UDP/IP datagram containing this message MUST carry a valid,
non-zero UDP checksum and carry the following IP address and UDP
port values:<list style="hanging">
<t hangText="Source IP Address -">The IP address of the gateway
interface on which the gateway will listen for a relay response.
Note: The value of this field may be changed as a result of
network address translation before arriving at the relay.</t>
<t hangText="Source UDP Port -">The UDP port number on which the
gateway will listen for a relay response. Note: The value of
this field may be changed as a result of network address
translation before arriving at the relay.</t>
<t hangText="Destination IP Address -">An anycast or unicast IP
address, i.e. the Relay Discovery Address advertised by a
relay.</t>
<t hangText="Destination UDP Port -">The IANA-assigned AMT port
number.</t>
</list></t>
<figure title="Relay Discovery Message Format">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<section title="Version (V)" toc="exclude">
<t>The protocol version number for this message is 0.</t>
</section>
<section title="Type" toc="exclude">
<t>The type number for this message is 1.</t>
</section>
<section title="Reserved" toc="exclude">
<t>Reserved bits that MUST be set to zero by the gateway and
ignored by the relay.</t>
</section>
<section anchor="relay-advertisement-discovery-nonce"
title="Discovery Nonce" toc="exclude">
<t>A 32-bit random value generated by the gateway and echoed by
the relay in a Relay Advertisement message. This value is used by
the gateway to correlate Relay Advertisement messages with Relay
Discovery messages. Discovery nonce generation is described in
<xref target="gateway-discovery-nonce-generation"></xref>.</t>
</section>
</section>
<section anchor="relay-advertisement-message"
title="Relay Advertisement" toc="exclude">
<t>The Relay Advertisement message is used to supply a gateway with
a unicast IP address of a relay. A relay sends this message to a
gateway when it receives a Relay Discovery message from that
gateway.</t>
<t>The UDP/IP datagram containing this message MUST carry a valid,
non-zero UDP checksum and carry the following IP address and UDP
port values:<list style="hanging">
<t hangText="Source IP Address -">The destination IP address
carried by the Relay Discovery message (i.e. the Relay Discovery
Address advertised by the relay).</t>
<t hangText="Source UDP Port -">The destination UDP port carried
by the Relay Discovery message (i.e. the IANA-assigned AMT port
number).</t>
<t hangText="Destination IP Address -">The source IP address
carried by the Relay Discovery message. Note: The value of this
field may be changed as a result of network address translation
before arriving at the gateway.</t>
<t hangText="Destination UDP Port -">The source UDP port carried
by the Relay Discovery message. Note: The value of this field
may be changed as a result of network address translation before
arriving at the gateway.</t>
</list></t>
<figure title="Relay Advertisement Message Format">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=2 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Relay Address (IPv4 or IPv6) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<section title="Version (V)" toc="exclude">
<t>The protocol version number for this message is 0.</t>
</section>
<section title="Type" toc="exclude">
<t>The type number for this message is 2.</t>
</section>
<section title="Reserved" toc="exclude">
<t>Reserved bits that MUST be set to zero by the relay and ignored
by the gateway.</t>
</section>
<section title="Discovery Nonce" toc="exclude">
<t>A 32-bit value copied from the Discovery Nonce field (<xref
target="relay-advertisement-discovery-nonce"></xref>) contained in
the Relay Discovery message. The gateway uses this value to match
a Relay Advertisement to a Relay Discovery message.</t>
</section>
<section title="Relay Address" toc="exclude">
<t>The unicast IPv4 or IPv6 address of the relay. A gateway uses
the length of the UDP datagram containing the Relay Advertisement
message to determine the address family; i.e. length - 8 = 4
(IPv4) or 16 (IPv6).</t>
</section>
</section>
<section anchor="request-message" title="Request" toc="exclude">
<t>A gateway sends a Request message to a relay to solicit a
Membership Query response.</t>
<t>The successful delivery of this message marks the start of the
first stage in the three-way handshake used to create or update
state within a relay.</t>
<t>The UDP/IP datagram containing this message MUST carry a valid,
non-zero UDP checksum and carry the following IP address and UDP
port values:<list style="hanging">
<t hangText="Source IP Address -">The IP address of the gateway
interface on which the gateway will listen for a response from
the relay. Note: The value of this field may be changed as a
result of network address translation before arriving at the
relay.</t>
<t hangText="Source UDP Port -">The UDP port number on which the
gateway will listen for a response from the relay. Note: The
value of this field may be changed as a result of network
address translation before arriving at the relay.</t>
<t hangText="Destination IP Address -">The unicast IP address of
the relay.</t>
<t hangText="Destination UDP Port -">The IANA-assigned AMT port
number.</t>
</list></t>
<figure title="Request Message Format">
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=3 | Reserved |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
</figure>
<section title="Version (V)" toc="exclude">
<t>The protocol version number for this message is 0.</t>
</section>
<section title="Type" toc="exclude">
<t>The type number for this message is 3.</t>
</section>
<section title="Reserved" toc="exclude">
<t>Reserved bits that MUST be set to zero by the gateway and
ignored by the relay.</t>
</section>
<section title="P Flag" toc="exclude">
<t>The "P" flag is set to indicate which group membership protocol
the gateway wishes the relay to use in the Membership Query
response:</t>
<texttable style="none" suppress-title="true">
<ttcol align="center">Value</ttcol>
<ttcol>Meaning</ttcol>
<c>0</c>
<c>The relay MUST respond with a Membership Query message that
contains an IPv4 packet carrying an IGMPv3 general query
message.</c>
<c>1</c>
<c>The relay MUST respond with a Membership Query message that
contains an IPv6 packet carrying an MLDv2 general query
message.</c>
</texttable>
</section>
<section anchor="request-request-nonce" title="Request Nonce"
toc="exclude">
<t>A 32-bit random value generated by the gateway and echoed by
the relay in a Membership Query message. This value is used by the
relay to compute the Response MAC value and is used by the gateway
to correlate Membership Query messages with Request messages.
Request nonce generation is described in <xref
target="gateway-request-nonce-generation"></xref>.</t>
</section>
</section>
<section anchor="membership-query-message" title="Membership Query"
toc="exclude">
<t>A relay sends a Membership Query message to a gateway to solicit
a Membership Update response, but only after receiving a Request
message from the gateway.</t>
<t>The successful delivery of this message to a gateway marks the
start of the second-stage in the three-way handshake used to create
or update tunnel state within a relay.</t>
<t>The UDP/IP datagram containing this message MUST carry a valid,
non-zero UDP checksum and carry the following IP address and UDP
port values:<list style="hanging">
<t hangText="Source IP Address -">The destination IP address
carried by the Request message (i.e. the unicast IP address of
the relay).</t>
<t hangText="Source UDP Port -">The destination UDP port carried
by the Request message (i.e. the IANA-assigned AMT port
number).</t>
<t hangText="Destination IP Address -">The source IP address
carried by the Request message. Note: The value of this field
may be changed as a result of network address translation before
arriving at the gateway.</t>
<t hangText="Destination UDP Port -">The source UDP port carried
by the Request message. Note: The value of this field may be
changed as a result of network address translation before
arriving at the gateway.</t>
</list></t>
<figure title="Membership Query Message Format">
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=4 | Reserved |L|G| Response MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Encapsulated General Query Message |
~ IPv4:IGMPv3(Membership Query) ~
| IPv6:MLDv2(Listener Query) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway Port Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| Gateway IP Address (IPv4 or IPv6) |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<section title="Version (V)" toc="exclude">
<t>The protocol version number for this message is 0.</t>
</section>
<section title="Type" toc="exclude">
<t>The type number for this message is 4.</t>
</section>
<section title="Reserved" toc="exclude">
<t>Reserved bits that MUST be set to zero by the relay and ignored
by the gateway.</t>
</section>
<section title="Limit (L) Flag" toc="exclude">
<t>A 1-bit flag set to 1 to indicate that the relay is NOT
accepting Membership Update messages from new gateway tunnel
endpoints and that it will ignore any that are. A value of 0 has
no special significance - the relay may or may not be accepting
Membership Update messages from new gateway tunnel endpoints. A
gateway checks this flag before attempting to create new group
subscription state on the relay to determine whether it should
restart relay discovery. A gateway that has already created group
subscriptions on the relay may ignore this flag. Support for this
flag is RECOMMENDED.</t>
</section>
<section title="Gateway Address (G) Flag" toc="exclude">
<t>A 1-bit flag set to 0 to indicate that the message does NOT
carry the Gateway Port and Gateway IP Address fields, and 1 to
indicate that it does. A relay implementation that supports the
optional teardown procedure (See <xref
target="relay-handling-teardown-message"></xref>) SHOULD set this
flag and and the Gateway Address field values. If a relay sets
this flag, it MUST also include the Gateway Address fields in the
message. A gateway implementation that does not support the
optional teardown procedure (See <xref
target="gateway-teardown-procedure"></xref>) MAY ignore this flag
and the Gateway Address fields if they are present.</t>
</section>
<section anchor="membership-query-response-mac" title="Response MAC"
toc="exclude">
<t>A 48-bit source authentication hash generated by the relay as
described in <xref target="relay-response-mac-generation"></xref>.
The gateway echoes this value in subsequent Membership Update
messages to allow the relay to verify that the sender of a
Membership Update message was the intended receiver of a
Membership Query sent by the relay.</t>
</section>
<section anchor="membership-query-request-nonce"
title="Request Nonce" toc="exclude">
<t>A 32-bit value copied from the Request Nonce field (<xref
target="request-request-nonce"></xref>) carried by a Request
message. The relay will have included this value in the Response
MAC hash computation. The gateway echoes this value in subsequent
Membership Update messages. The gateway also uses this value to
match a Membership Query to a Request message.</t>
</section>
<section title="Encapsulated General Query Message" toc="exclude">
<t>An IP-encapsulated IGMP or MLD message generated by the relay.
This field will contain one of the following IP datagrams:<list
style="empty">
<t>IPv4:IGMPv3 Membership Query</t>
<t>IPv6:MLDv2 Listener Query</t>
</list>The source address carried by the query message SHOULD be
set to zero to indicate that query originated from a
non-querier.</t>
<t>The Querier's Query Interval Code (QQIC) field in the general
query is used by a relay to specify the time offset a gateway
should use to schedule a new three-way handshake to refresh the
group membership state within the relay (current time + Query
Interval).</t>
<t>The Querier's Robustness Variable (QRV) field in the general
query is used by a relay to specify the number of times a gateway
should retransmit unsolicited membership reports, encapsulated
within Membership Update messages, and optionally, the number of
times to send a Teardown message.</t>
</section>
<section anchor="membership-query-gateway-address-fields"
title="Gateway Address Fields" toc="exclude">
<t>The Gateway Port Number and Gateway Address fields are present
in the Membership Query message if, and only if, the "G" flag is
set.</t>
<t>A gateway need not parse the encapsulated IP datagram to
determine the position of these fields within the UDP datagram
containing the Membership Query messsage - if the G-flag is set,
the gateway may simply subtract the total length of the fields (18
bytes) from the total length of the UDP datagram to obtain the
offset.</t>
<section anchor="membership-query-gateway-port-number"
title="Gateway Port Number">
<t>A 16-bit UDP port containing a UDP port value.</t>
<t>The Relay sets this field to the value of the UDP source port
of the Request message that triggered the Query message.</t>
</section>
<section anchor="membership-query-gateway-ip-address"
title="Gateway IP Address">
<t>A 16-byte IP address that, when combined with the value
contained in the Gateway Port Number field, forms the gateway
endpoint address that the relay will use to identify the tunnel
instance, if any, created by a subsequent Membership Update
message. This field may contain an IPv6 address or an IPv4
address stored as an IPv4-compatible IPv6 address, where the
IPv4 address is prefixed with 96 bits set to zero (See <xref
target="RFC4291"></xref>). This address must match that used by
the relay to compute the value stored in the Response MAC
field.</t>
</section>
</section>
</section>
<section anchor="membership-update-message" title="Membership Update"
toc="exclude">
<t>A gateway sends a Membership Update message to a relay to report
a change in group membership state, or to report the current group
membership state in response to receiving a Membership Query
message. The gateway encapsulates the IGMP or MLD message as an IP
datagram within a Membership Update message and sends it to the
relay, where it may (see below) be decapsulated and processed by the
relay to update group membership and forwarding state.</t>
<t>A gateway cannot send a Membership Update message until a
receives a Membership Query from a relay because the gateway must
copy the Request Nonce and Response MAC values carried by a
Membership Query into any subsequent Membership Update messages it
sends back to that relay. These values are used by the relay to
verify that the sender of the Membership Update message was the
recipient of the Membership Query message from which these values
were copied.</t>
<t>The successful delivery of this message to the relay marks the
start of the final stage in the three-way handshake. This stage
concludes when the relay successfully verifies that sender of the
Message Update message was the recipient of a Membership Query
message sent earlier. At this point, the relay may proceed to
process the encapsulated IGMP or MLD message to create or update
group membership and forwarding state on behalf of the gateway.</t>
<t>The UDP/IP datagram containing this message MUST carry a valid,
non-zero UDP checksum and carry the following IP address and UDP
port values:<list style="hanging">
<t hangText="Source IP Address -">The IP address of the gateway
interface on which the gateway will listen for Multicast Data
messages from the relay. The address must be the same address
used to send the initial Request message or the message will be
ignored. Note: The value of this field may be changed as a
result of network address translation before arriving at the
relay.</t>
<t hangText="Source UDP Port -">The UDP port number on which the
gateway will listen for Multicast Data messages from the relay.
This port must be the same port used to send the initial Request
message or the message will be ignored. Note: The value of this
field may be changed as a result of network address translation
before arriving at the relay.</t>
<t hangText="Destination IP Address -">The unicast IP address of
the relay.</t>
<t hangText="Destination UDP Port -">The IANA-assigned AMT UDP
port number.</t>
</list></t>
<figure title="Membership Update Message Format">
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=5 | Reserved | Response MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Encapsulated Group Membership Update Message |
~ IPv4:IGMP(Membership Report|Leave Group) ~
| IPv6:MLD(Listener Report|Listener Done) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<section title="Version (V)" toc="exclude">
<t>The protocol version number for this message is 0.</t>
</section>
<section title="Type" toc="exclude">
<t>The type number for this message is 5.</t>
</section>
<section title="Reserved" toc="exclude">
<t>Reserved bits that MUST be set to zero by the gateway and
ignored by the relay.</t>
</section>
<section title="Response MAC" toc="exclude">
<t>A 48-bit value copied from the Response MAC field (<xref
target="membership-query-response-mac"></xref>) in a Membership
Query message. Used by the relay to perform source
authentication.</t>
</section>
<section title="Request Nonce" toc="exclude">
<t>A 32-bit value copied from the Request Nonce field in a Request
or Membership Query message. Used by the relay to perform source
authentication.</t>
</section>
<section title="Encapsulated Group Membership Update Message"
toc="exclude">
<t>An IP-encapsulated IGMP or MLD message produced by the
host-mode IGMP or MLD protocol running on a gateway
pseudo-interface. This field will contain of one of the following
IP datagrams:<list style="empty">
<t>IPv4:IGMPv2 Membership Report</t>
<t>IPv4:IGMPv2 Leave Group</t>
<t>IPv4:IGMPv3 Membership Report</t>
<t>IPv6:MLDv1 Multicast Listener Report</t>
<t>IPv6:MLDv1 Multicast Listener Done</t>
<t>IPv6:MLDv2 Multicast Listener Report</t>
</list></t>
</section>
</section>
<section anchor="multicast-data-message" title="Multicast Data"
toc="exclude">
<t>A relay sends a Multicast Data message to deliver an IP multicast
packet to a gateway.</t>
<t>The checksum field in the UDP header of this message MAY contain
a value of zero when sent over IPv4 but SHOULD, if possible, contain
a valid, non-zero value when sent over IPv6 (See <xref
target="udp-encapsulation"></xref>).</t>
<t>The UDP/IP datagram containing this message MUST carry the
following IP address and UDP port values:<list style="hanging">
<t hangText="Source IP Address -">The unicast IP address of the
relay.</t>
<t hangText="Source UDP Port -">The IANA-assigned AMT port
number.</t>
<t hangText="Destination IP Address -">A tunnel endpoint IP
address, i.e. the source IP address carried by the Membership
Update message sent by a gateway to indicate an interest in
receiving the multicast packet. Note: The value of this field
may be changed as a result of network address translation before
arriving at the gateway.</t>
<t hangText="Destination UDP Port -">A tunnel endpoint UDP port,
i.e. the source UDP port carried by the Membership Update
message sent by a gateway to indicate an interest in receiving
the multicast packet. Note: The value of this field may be
changed as a result of network address translation before
arriving at the gateway.</t>
</list></t>
<figure title="Multicast Data Message Format">
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=6 | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ IP Multicast Packet ~
| |
+ - - - - - - - - - - - - - - - - - - - - - - - -+
| : : : :
+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - - - - - - - - - -
]]></artwork>
</figure>
<section title="Version (V)" toc="exclude">
<t>The protocol version number for this message is 0.</t>
</section>
<section title="Type" toc="exclude">
<t>The type number for this message is 6.</t>
</section>
<section title="Reserved" toc="exclude">
<t>Bits that MUST be set to zero by the relay and ignored by the
gateway.</t>
</section>
<section title="IP Multicast Data" toc="exclude">
<t>A complete IPv4 or IPv6 Multicast datagram.</t>
</section>
</section>
<section anchor="teardown-message" title="Teardown" toc="exclude">
<t>A gateway sends a Teardown message to a relay to request that it
stop sending Multicast Data messages to a tunnel endpoint created by
an earlier Membership Update message. A gateway sends this message
when it detects that a Request message sent to the relay carries an
address that differs from that carried by a previous Request
message. The gateway uses the Gateway IP Address and Gateway Port
Number Fields in the Membership Query message to detect these
address changes.</t>
<t>To provide backwards compatibility with early implementations of
the AMT protocol, support for this message and associated procedures
is considered OPTIONAL - gateways are not required to send this
message and relays are not required to act upon it.</t>
<t>The UDP/IP datagram containing this message MUST carry a valid,
non-zero UDP checksum and carry the following IP address and UDP
port values:<list style="hanging">
<t hangText="Source IP Address -">The IP address of the gateway
interface used to send the message. This address may differ from
that used to send earlier messages. Note: The value of this
field may be changed as a result of network address translation
before arriving at the relay.</t>
<t hangText="Source UDP Port -">The UDP port number. This port
number may differ from that used to send earlier messages. Note:
The value of this field may be changed as a result of network
address translation before arriving at the relay.</t>
<t hangText="Destination IP Address -">The unicast IP address of
the relay.</t>
<t hangText="Destination UDP Port -">The IANA-assigned AMT port
number.</t>
</list></t>
<figure title="Membership Teardown Message Format">
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=7 | Reserved | Response MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway Port Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| Gateway IP Address (IPv4 or IPv6) |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
</figure>
<section title="Version (V)" toc="exclude">
<t>The protocol version number for this message is 0.</t>
</section>
<section title="Type" toc="exclude">
<t>The type number for this message is 7.</t>
</section>
<section title="Reserved" toc="exclude">
<t>Reserved bits that MUST be set to zero by the gateway and
ignored by the relay.</t>
</section>
<section title="Response MAC" toc="exclude">
<t>A 48-bit value copied from the Response MAC field (<xref
target="membership-query-response-mac"></xref>) in the last
Membership Query message the relay sent to the gateway endpoint
address of the tunnel to be torn down. The gateway endpoint
address is provided by the Gateway IP Address and Gateway Port
Number fields carried by the Membership Query message.</t>
</section>
<section title="Request Nonce" toc="exclude">
<t>A 32-bit value copied from the Request Nonce field (<xref
target="membership-query-request-nonce"></xref>) in the last
Membership Query message the relay sent to the gateway endpoint
address of the tunnel to be torn down. The gateway endpoint
address is provided by the Gateway IP Address and Gateway Port
Number fields carried by the Membership Query message. This value
must match that used by the relay to compute the value stored in
the Response MAC field.</t>
</section>
<section title="Gateway Port Number" toc="exclude">
<t>A 16-bit UDP port number that, when combined with the value
contained in the Gateway IP Address field, forms the tunnel
endpoint address that the relay will use to identify the tunnel
instance to tear down. The relay provides this value to the
gateway using the Gateway Port Number field (<xref
target="membership-query-gateway-port-number"></xref>) in a
Membership Query message. This port number must match that used by
the relay to compute the value stored in the Response MAC
field.</t>
</section>
<section title="Gateway IP Address" toc="exclude">
<t>A 16-byte IP address that, when combined with the value
contained in the Gateway Port Number field, forms the tunnel
endpoint address that the relay will used to identify the tunnel
instance to tear down. The relay provides this value to the
gateway using the Gateway IP Address field (<xref
target="membership-query-gateway-ip-address"></xref>) in a
Membership Query message. This field may contain an IPv6 address
or an IPv4 address stored as an IPv4-compatible IPv6 address,
where the IPv4 address is prefixed with 96 bits set to zero (See
<xref target="RFC4291"></xref>). This address must match that used
by the relay to compute the value stored in the Response MAC
field.</t>
</section>
</section>
</section>
<section anchor="gateway-operation" title="Gateway Operation">
<t>The following sections describe gateway implementation
requirements. A non-normative discussion of gateway operation may be
found in <xref target="general-operation"></xref>.</t>
<section anchor="gateway-igmp-mld-protocol-requirements"
title="IP/IGMP/MLD Protocol Requirements" toc="exclude">
<t>Gateway operation requires a subset of host mode IPv4/IGMP and
IPv6/MLD functionality to provide group membership tracking, general
query processing, and report generation. A gateway MAY use IGMPv2
(ASM), IGMPv3 (ASM and SSM), MLDv1 (ASM) or MLDv2 (ASM and SSM).</t>
<t>An application with embedded gateway functionality must provide
its own implementation of this subset of the IPv4/IGMP and IPv6/MLD
protocols. The service interface used to manipulate group membership
state need not match that described in the IGMP and MLD
specifications, but the actions taken as a result SHOULD be similar
to those described in <xref target="RFC3376">Section 5.1 of</xref>
and <xref target="RFC3810">Section 6.1 of</xref>. The gateway
application will likely need to implement many of the same functions
as a host IP stack, including checksum verification, dispatching,
datagram filtering and forwarding, and IP
encapsulation/decapsulation. Applications that use AMT to join
multicast UDP streams may also need to perform IP reassembly to
reconstruct UDP datagrams that were fragmented prior to replication
and encapsulation in the relay.</t>
<t>The IP-encapsulated IGMP/MLD messages generated by the gateway
IPv4/IGMP or IPv6/MLD implementation MUST conform to the
descriptions found in <xref target="RFC3376">Section 4 of </xref>
and <xref target="RFC3810">Section 5 of </xref>. These datagrams
MUST possess the IP headers, header options and header values called
for in these RFCs, with the following exception; the source IP
address for an IGMP/MLD report datagram MAY be set to the
"unspecified" address (all octets are zero ). This exception is made
because the gateway pseudo-interface might not possess an address,
and even if such an address exists, that address would not be a
valid source address on any relay interface. To allow for this
exception, a relay must accept an IGMP or MLD report carried by a
Membership Update message regardless of the source address it
carries. See <xref
target="relay-igmp-mld-protocol-requirements"></xref>.</t>
<t>The gateway IGMP/MLD implementation SHOULD retransmit unsolicited
membership state-change reports and merge new state change reports
with pending reports as described in <xref target="RFC3376">Section
5.1 of</xref> and <xref target="RFC3810">Section 6.1 of</xref>. The
number of retransmissions is specified by the relay in the Querier's
Robustness Variable (QRV) field in the last general query forwarded
by the pseudo-interface.</t>
<t>The gateway IGMP/MLD implementation SHOULD handle general query
messages as described in <xref target="RFC3376">Section 5.2
of</xref> and <xref target="RFC3810">Section 6.2 of</xref>, but MAY
ignore the Max Resp Code field value and generate a current state
report without any delay.</t>
<t>A gateway IPv4 implementation MUST accept IPv4 datagrams that
carry multicast data or the general query variant of the IGMPv3
Membership Query message, as described in Section 4 of <xref
target="RFC3376"></xref>.</t>
<t>A gateway IPv6 implementations MUST accept IPv6 datagrams that
carry multicast data or the general query variant of the MLDv2
Multicast Listener Query message, as described in Section 5 of <xref
target="RFC3810"></xref>.</t>
</section>
<section title="Pseudo-Interface Configuration" toc="exclude">
<t>A gateway host may possess or create multiple gateway
pseudo-interfaces, each with a unique configuration that describes a
binding to a specific IP protocol, relay address, relay discovery
address or upstream network interface.</t>
<section title="Static Relay Address">
<t>Before a gateway implementation can execute the AMT protocol to
request and receive multicast traffic, it must be supplied with a
unicast relay address. A gateway implementation may rely on static
address assignment or support some form of dynamic address
discovery. This specification does not require the use of any
particular method to obtain a relay address - an implementation
may employ any method that returns a suitable relay address.</t>
</section>
<section title="Static Relay Discovery Address">
<t>If a gateway implementation uses AMT relay discovery to obtain
a relay address, it must first be supplied with a relay discovery
address. The relay discovery address may be an anycast or unicast
address. A gateway implementation may rely on a static address
assignment or some form of dynamic address discovery. This
specification does not require that a gateway implementation use
any particular method to obtain a relay discovery address - an
implementation may employ any method that returns a suitable relay
discovery address.</t>
</section>
<section title="Upstream Interface Selection">
<t>A gateway host that possesses multiple network interfaces or
addresses may allow for an explicit selection of the interface to
use when communicating with a relay. The selection might be made
to satisfy connectivity, tunneling or IP protocol
requirements.</t>
</section>
<section title="Optional Retransmission Parameters">
<t>A gateway implementation that supports retransmission MAY
require the following information:<list style="hanging">
<t hangText="Discovery Timeout"><vspace
blankLines="0" />Initial time to wait for a response to a
Relay Discovery message.</t>
<t
hangText="Maximum Relay Discovery Retransmission Count"><vspace
blankLines="0" />Maximum number of Relay Discovery
retransmissions to allow before terminating relay discovery
and reporting an error.</t>
<t hangText="Request Timeout"><vspace blankLines="0" />Initial
time to wait for a response to a Request message.</t>
<t hangText="Maximum Request Retransmission Count"><vspace
blankLines="0" />Maximum number of Request retransmissions to
allow before abandoning a relay and restarting relay discovery
or reporting an error.</t>
<t
hangText="Maximum Retries Count For "Destination Unreachable""><vspace
blankLines="0" />The maximum number of times a gateway should
attempt to send the same Request or Membership Update message
after receiving an ICMP "Destination Unreachable".</t>
</list></t>
</section>
</section>
<section title="Gateway Service" toc="exclude">
<t>In the following descriptions, a gateway pseudo interface is
treated as a passive entity managed by a gateway service. The
gateway pseudo-interface provides the state and the gateway service
provides the processing. The term "gateway" is used when describing
service behavior with respect to a single pseudo-interface.</t>
<section title="Startup">
<t>When a gateway pseudo-interface is started, the gateway service
begins listening for AMT messages sent to the UDP endpoint(s)
associated with the pseudo-interface and for any locally-generated
IGMP/MLD messages passed to the pseudo-interface. The handling of
these messages is described below.</t>
<t>When the pseudo-interface is enabled, the gateway service
MAY:<list style="symbols">
<t>Optionally execute the relay discovery procedure described
in <xref
target="gateway-relay-discovery-procedure"></xref>.</t>
<t>Optionally execute the membership query procedure described
in <xref target="gateway-membership-query-procedure"></xref>
to start the periodic membership update cycle.</t>
</list></t>
</section>
<section title="Handling AMT Messages">
<t>A gateway MUST ignore any datagram it receives that cannot be
interpreted as a Relay Advertisement, Membership Query, or
Multicast Data message. The handling of Relay Advertisement,
Membership Query, and Multicast Data messages is addressed in the
sections that follow.</t>
<t>While listening for AMT messages, a gateway may be notified
that an ICMP Destination Unreachable message was received as a
result of an AMT message transmission. Handling of ICMP
Destination Unreachable messages is described in <xref
target="gateway-handling-destination-unreachable"></xref>.</t>
</section>
<section title="Handling Multicast Data Messages">
<t>A gateway may receive Multicast Data messages after it sends a
Membership Update message to a relay that adds a group
subscription. The gateway may continue to receive Multicast Data
messages long after the gateway sends a Membership Update message
that deletes existing group subscriptions. The gateway MUST be
prepared to receive these messages at any time, but MAY ignore
them or discard their contents if the gateway no longer has any
interest in receiving the multicast datagrams contained within
them.</t>
<t>A gateway MUST ignore a Multicast Data message if it fails to
satisfy any of the following requirements:<list style="symbols">
<t>The source IP address and UDP port carried by the Multicast
Data message MUST be equal to the destination IP address and
UDP port carried by the matching Membership Update message
(i.e., the current relay address).</t>
<t>The destination address carried by the encapsulated IP
datagram MUST fall within the multicast address allocation
assigned to the relavent IP protocol, i.e., 224.0.0.0/4 for
IPv4 and FF00::/8 for IPv6.</t>
</list></t>
<t>The gateway extracts the encapsulated IP datagram and forwards
it to the local IP protocol implementation for checksum
verification, fragmented datagram reassembly, source and group
filtering, and transport-layer protocol processing.</t>
</section>
<section anchor="gateway-relay-discovery-procedure"
title="Relay Discovery Procedure">
<t>This section describes gateway requirements related to the
relay discovery message sequence described in <xref
target="overview-relay-discovery-sequence"></xref>.</t>
<section title="Starting Relay Discovery">
<t>A gateway may start or restart the relay discovery procedure
in response to the following events:<list style="symbols">
<t>When a gateway pseudo-interface is started (enabled).</t>
<t>When the gateway wishes to report a group subscription
when none currently exist.</t>
<t>Before sending the next Request message in a membership
update cycle, i.e. each time the query timer expires (see
below).</t>
<t>After the gateway fails to receive a response to a
Request message.</t>
<t>After the gateway receives a Membership Query message
with the L-flag set to 1.</t>
</list></t>
</section>
<section title="Sending a Relay Discovery Message">
<t>A gateway sends a Relay Discovery message to a relay to start
the relay discovery process.</t>
<t>The gateway MUST send the Relay Discovery message using the
current Relay Discovery Address and IANA-assigned UDP port
number as the destination. The Discovery Nonce value in the
Relay Discovery message must be computed as described in <xref
target="gateway-discovery-nonce-generation"></xref>.</t>
<t>The gateway MUST save a copy of Relay Discovery message or
save the Discovery Nonce value for possible retransmission and
verification of a Relay Advertisement response.</t>
<t>When a gateway sends a Relay Discovery message, it may be
notified that an ICMP Destination Unreachable message was
received as a result of an earlier AMT message transmission.
Handling of ICMP Destination Unreachable messages is described
in <xref
target="gateway-handling-destination-unreachable"></xref>.</t>
</section>
<section title="Waiting for a Relay Advertisement Message">
<t>A gateway MAY retransmit a Relay Discovery message if it does
not receive a matching Relay Advertisement message within some
timeout period. If the gateway retransmits the message multiple
times, the timeout period SHOULD be adjusted to provide an
random exponential back-off. The RECOMMENDED timeout is a random
value in the range [initial_timeout, MIN(initial_timeout *
2^retry_count, maximum_timeout)], with a RECOMMENDED
initial_timeout of 1 second and a RECOMMENDED maximum_timeout of
120 seconds (which is the recommended minimum NAT mapping
timeout described in <xref target="RFC4787"></xref>).</t>
</section>
<section title="Handling a Relay Advertisement Message">
<t>When a gateway receives a Relay Advertisement message it must
first determine whether it should accept or ignore the message.
A gateway MUST ignore a Relay Advertisement message if it fails
to satisfy any of the following requirements:<list
style="symbols">
<t>The gateway MUST be waiting for a Relay Advertisement
message.</t>
<t>The Discovery Nonce value contained in the Relay
Advertisement message MUST equal to the Discovery Nonce
value contained in the Relay Discovery message.</t>
<t>The source IP address and UDP port of the Relay
Advertisement message MUST equal to the destination IP
address and UDP port of the matching Relay Discovery
message.</t>
</list>Once a gateway receives a Relay Advertisement response
to a Relay Discovery message, it SHOULD ignore any other Relay
Advertisements that arrive on the AMT interface until it sends a
new Relay Discovery message.</t>
<t>If a gateway executes the relay discovery procedure at the
start of each membership update cycle and the relay address
returned in the latest Relay Advertisement message differs from
the address returned in a previous Relay Advertisement message,
then the gateway SHOULD send a Teardown message (if supported)
to the old relay address, using information from the last
Membership Query message received from that relay, as described
in <xref target="gateway-teardown-procedure"></xref>. This
behavior is illustrated in the following diagram.</t>
<figure title="Teardown After Relay Address Change">
<artwork><![CDATA[
Gateway Relay-1
------- -------
: :
Query Expired | |
Timer (QT)-------->| |
| Relay Discovery |
|------------------->|
| |
| Relay Advertisement|
|<-------------------|
| |
| Request |
|------------------->|
| |
| Membership Query |
|<===================|
Start | |
(QT)<--------| Membership Update |
|===================>|
| |
~ ~ Relay-2
Expired | | -------
(QT)-------->| | :
| Relay Discovery | |
|------------------------------------>|
| | |
| Relay Advertisement| |
|<------------------------------------|
| | |
| Teardown | |
|------------------->| |
| | |
| Request | |
|------------------------------------>|
| | |
| Membership Query | |
|<====================================|
Start | | |
(QT)<--------| Membership Update | |
|====================================>|
| | |
: : :
]]></artwork>
</figure>
</section>
<section anchor="gateway-discovery-nonce-generation"
title="Discovery Nonce Generation">
<t>The discovery nonce MUST be a random, non-zero, 32-bit value,
and if possible, SHOULD be computed using a cryptographically
secure pseudo random number generator. A new nonce SHOULD be
generated each time the gateway restarts the relay discovery
process. The same nonce SHOULD be used when retransmitting a
Relay Discovery message.</t>
</section>
</section>
<section anchor="gateway-membership-query-procedure"
title="Membership Query Procedure">
<t>This section describes gateway requirements related to the
membership update message sequence described in <xref
target="overview-membership-update-sequence"></xref>.</t>
<section title="Starting the Membership Update Cycle">
<t>A gateway may send a Request message to start a membership
update cycle (following the optional relay discovery procedure)
in response to the following events:<list style="symbols">
<t>When the gateway pseudo-interface is activated.</t>
<t>When the gateway wishes to report a group subscription
when none currently exist.</t>
</list></t>
<t>Starting the membership update cycle when a gateway
pseudo-interface is started provides several benefits:<list
style="symbols">
<t>Better performance by allowing state-change reports to be
sent as they are generated, thus minimizing the time to
join.</t>
<t>More robustness by relying on unsolicited state-change
reports to update group membership state rather than the
current-state reports generated by the membership update
cycle. Unsolicited state-change reports are typically
retransmitted multiple times while current-state reports are
not.</t>
<t>Simplified implementation by eliminating any need to
queue IGMP/MLD messages for delivery after a Membership
Query is received, since the IGMP/MLD state-change messages
may be sent as they are generated.</t>
</list>However, this approach places an additional load on
relays as a gateway will send periodic requests even when it has
no multicast subscriptions. To reduce load on a relay, a gateway
SHOULD only send a Membership Update message while it has active
group subscriptions. A relay will still need to compute a
Response MAC for each Request, but will not be required to
recompute it a second time to authenticate a Membership Update
message that contains no subscriptions.</t>
</section>
<section title="Sending a Request Message">
<t>A gateway sends a Request message to a relay to solicit a
Membership Query response and start the membership update
cycle.</t>
<t>A gateway constructs a Request message containing a Request
Nonce value computed as described in <xref
target="gateway-request-nonce-generation"></xref>. The gateway
MUST set the "P" flag in the Request message to identify the
protocol the gateway wishes the relay to use for the general
query response.</t>
<t>A gateway MUST send a Request message using the current Relay
Address and IANA-assigned AMT port number as the
destination.</t>
<t>A gateway MUST save a copy of the Request message or save the
Request Nonce and P-flag values for possible retransmission and
verification of a Membership Query response.</t>
<t>When a gateway sends a Request message, it may be notified
that an ICMP Destination Unreachable message was received as a
result of an earlier AMT message transmission. Handling of ICMP
Destination Unreachable messages is described in <xref
target="gateway-handling-destination-unreachable"></xref>.</t>
</section>
<section title="Waiting for a Membership Query Message">
<t>A gateway MAY retransmit a Request message if it does not
receive a matching Membership Query message within some timeout
period. If the gateway retransmits the message multiple times,
the timeout period SHOULD be adjusted to provide an random
exponential back-off. The RECOMMENDED timeout is a random value
in the range [initial_timeout, MIN(initial_timeout *
2^retry_count, maximum_timeout)], with a RECOMMENDED
initial_timeout of 1 second and a RECOMMENDED maximum_timeout of
120 seconds (which is the recommended minimum NAT mapping
timeout described in <xref target="RFC4787"></xref>).</t>
<t>If a gateway that uses relay discovery does not receive a
Membership Query within a specified time period or after a
specified number of retries, the gateway SHOULD stop waiting for
a Membership Query message and restart relay discovery to locate
another relay.</t>
</section>
<section anchor="gateway-handling-membership-query-message"
title="Handling a Membership Query Message">
<t>When a gateway receives a Membership Query message it must
first determine whether it should accept or ignore the message.
A gateway MUST ignore a Membership Query message, or the
encapsulated IP datagram within it, if the message fails to
satisfy any of the following requirements:<list style="symbols">
<t>The gateway MUST be waiting for a Membership Query
message.</t>
<t>The Request Nonce value contained in the Membership Query
MUST equal the Request Nonce value contained in the Request
message.</t>
<t>The source IP address and UDP port of the Membership
Query MUST equal the destination IP address and UDP port of
the matching Request message (i.e. the current relay
address).</t>
<t>The encapsulated IP datagram MUST carry an IGMPv3 or
MLDv2 message. The protocol MUST match the protocol
identified by the "P" flag in the Request message.</t>
<t>The IGMPv3 or MLDv2 message MUST be a general query
message.</t>
<t>The total length of the encapsulated IP datagram as
computed from the lengths contained in the datagram
header(s) MUST NOT exceed the available field length within
the Membership Query message.</t>
</list></t>
<t>Once a gateway receives a Membership Query response to a
Request message, it SHOULD ignore any other Membership Query
messages that arrive on the AMT interface until it sends a new
Request message.</t>
<t>The gateway MUST save the Membership Query message, or the
Request Nonce, Response MAC, Gateway IP Address and Gateway Port
Number fields for use in sending subsequent Membership Update
and Teardown messages.</t>
<t>The gateway extracts the encapsulated IP datagram and
forwards it to the local IP protocol implementation for checksum
verification and dispatching to the IGMP or MLD implementation
running on the pseudo-interface. The gateway MUST NOT forward
any octets that might exist between the encapsulated IP datagram
and the end of the message or Gateway Address fields.</t>
<t>An MLD datagram contained in a Membership Query message may
require special handling. The encapsulated query generated by a
relay will likely carry an unspecified or relay link-local
source address. If a gateway relies on a standard host-mode MLD
protocol implementation to process the query, that
implementation will silently ignore the MLD query because it
carries an unspecified or non-link-local source address - a
gateway may need to construct its own query with a valid
link-local address (e.g., a spoofed address in a virtual subnet
defined by the address and netmask assigned to the gateway
pseudo-interface) to ensure that the report will not be ignored
by the MLD protocol implementation.</t>
<t>The gateway must start a timer that will trigger the next
iteration of the membership update cycle by executing the
membership query procedure. The gateway SHOULD compute the timer
duration from the Querier's Query Interval Code carried by the
general-query. A gateway MAY use a smaller timer duration if
required to refresh a NAT mapping that would otherwise timeout.
A gateway MAY use a larger timer duration if it has no group
subscriptions to report.</t>
<t>If the gateway supports the Teardown message and the G-flag
is set in the Membership Query message, the gateway MUST compare
the Gateway IP Address and Gateway Port Number on the new
Membership Query message with the values carried by the previous
Membership Query message. If either value has changed the
gateway MUST send a Teardown message to the relay as described
in <xref target="gateway-teardown-procedure"></xref>.</t>
<t>If the L-flag is set in the Membership Query message, the
relay is reporting that it is NOT accepting Membership Update
messages that create new tunnel endpoints and will simply ignore
any that do. If the L-flag is set and the gateway is not
currently reporting any group subscriptions to the relay, the
gateway SHOULD stop sending periodic Request messages and
restart the relay discovery procedure (if discovery is enabled)
to find a new relay with which to communicate. The gateway MAY
continue to send updates even if the L-flag is set, if it has
previously reported group subscriptions to the relay, one or
more subscriptions still exist and the gateway endpoint address
has not changed since the last Membership Query was received
(see previous paragraph).</t>
</section>
<section title="Handling Query Timer Expiration">
<t>When the query timer (started in the previous step) expires,
the gateway should execute the membership query procedure again
to continue the membership update cycle.</t>
</section>
<section anchor="gateway-request-nonce-generation"
title="Request Nonce Generation">
<t>The request nonce MUST be a random value, and if possible,
SHOULD be computed using a cryptographically secure pseudo
random number generator. A new nonce MUST be generated each time
the gateway starts the membership query process. The same nonce
SHOULD be used when retransmitting a Request message.</t>
</section>
</section>
<section title="Membership Update Procedure">
<t>This section describes gateway requirements related to the
membership update message sequence described in <xref
target="overview-membership-update-sequence"></xref>.</t>
<t>The membership update process is primarily driven by the
host-mode IGMP or MLD protocol implementation running on the
gateway pseudo-interface. The IGMP and MLD protocols produce
current-state reports in response to general queries generated by
the pseudo-interface via AMT and produce state-change reports in
response to receiver requests made using the IGMP or MLD service
interface.</t>
<section title="Handling an IGMP/MLD IP Datagram">
<t>The gateway pseudo-interface MUST accept the following IP
datagrams from the IPv4/IGMP and IPv6/MLD protocols running on
the pseudo-interface:<list style="symbols">
<t>IPv4 datagrams that carry an IGMPv2, or IGMPv3 Membership
Report or an IGMPv2 Leave Group message as described in
Section 4 of <xref target="RFC3376"></xref>.</t>
<t>IPv6 datagrams that carry an MLDv1 or MLDv2 Multicast
Listener Report or an MLDv1 Multicast Listener Done message
as described in Section 5 of <xref
target="RFC3810"></xref>.</t>
</list></t>
<t>The gateway must be prepared to receive these messages any
time the pseudo-interface is running. The gateway MUST ignore
any datagrams not listed above.</t>
<t>A gateway that waits to start a membership update cycle until
after it receives an IGMP/MLD state-change message MAY:<list
style="symbols">
<t>Discard datagrams containing IGMP/MLD messages until it
receives a Membership Query message, at which time it
processes the Membership Query message as normal to
eventually produce a current-state report on the
pseudo-interface which describes the end state
(RECOMMENDED).</t>
<t>Insert IGMP/MLD messages into a queue for transmission
after it receives a Membership Query message.</t>
</list>If the datagram contains a valid IGMP or MLD message,
the gateway sends it to the relay as described in the next
section.</t>
</section>
<section title="Sending a Membership Update Message">
<t>A gateway cannot send a Membership Update message to a relay
until it has received a Membership Query message from a relay.
If the gateway has not yet located a relay with which to
communicate, it must first execute the relay discovery procedure
described in <xref
target="gateway-relay-discovery-procedure"></xref> to obtain a
relay address. If the gateway has a relay address, but has not
yet received a Membership Query message, it must first execute
the membership query procedure described in <xref
target="gateway-membership-query-procedure"></xref> to obtain a
Request Nonce and Response MAC that can be used to send a
Membership Update message.</t>
<t>Once a gateway possesses a valid Relay Address, Request Nonce
and Response MAC, it may encapsulate the IP datagram containing
the IGMP/MLD message into a Membership Update message. The
gateway MUST copy the Request Nonce and Response MAC values from
the last Membership Query received from the relay into the
corresponding fields in the Membership Update. The gateway MUST
send the Membership Update message using the Relay Address and
IANA-assigned AMT port number as the destination.</t>
<t>When a gateway sends a Membership Update message, it may be
notified that an ICMP Destination Unreachable message was
received as a result of an earlier AMT message transmission.
Handling of ICMP Destination Unreachable messages is described
in <xref
target="gateway-handling-destination-unreachable"></xref>.</t>
</section>
</section>
<section anchor="gateway-teardown-procedure"
title="Teardown Procedure">
<t>This section describes gateway requirements related to the
teardown message sequence described in <xref
target="overview-teardown-sequence"></xref>.</t>
<t>Gateway support for the Teardown message is OPTIONAL but
RECOMMENDED.</t>
<t>A gateway that supports Teardown SHOULD make use of Teardown
functionality if it receives a Membership Query message from a
relay that has the "G" flag set to indicate that it contains valid
gateway address fields.</t>
<section title="Handling a Membership Query Message">
<t>As described in <xref
target="gateway-handling-membership-query-message"></xref>, if a
gateway supports the Teardown message, has reported active group
subscriptions, and receives a Membership Query message with the
"G" flag set, the gateway MUST compare the Gateway IP Address
and Gateway Port Number on the new Membership Query message with
the values carried by the previous Membership Query message. If
either value has changed the gateway MUST send a Teardown
message as described in the next section.</t>
</section>
<section title="Sending a Teardown Message">
<t>A gateway sends a Teardown message to a relay to request that
it stop delivering Multicast Data messages to the gateway and
delete any group memberships created by the gateway.</t>
<t>When a gateway constructs a Teardown message, it MUST copy
the Request Nonce, Response MAC, Gateway IP Address and Gateway
Port Number fields from the Membership Query message that
provided the Response MAC for the last Membership Update message
sent, into the corresponding fields of the Teardown message.</t>
<t>A gateway MUST send the Teardown message using the Relay
Address and IANA-assigned AMT port number as the destination. A
gateway MAY send the the Teardown message multiple times for
robustness. The gateway SHOULD use the Querier's Robustness
Variable (QRV) field contained in the query encapsulated within
the last Membership Query to set the limit on the number of
retransmissions. If the gateway sends the Teardown message
multiple times, it SHOULD insert a delay between each
transmission using the timing algorithm employed in IGMP/MLD for
transmitting unsolicited state-change reports.</t>
<t>When a gateway sends a Teardown message, it may be notified
that an ICMP Destination Unreachable message was received as a
result of an earlier AMT message transmission. Handling of ICMP
Destination Unreachable messages is described in <xref
target="gateway-handling-destination-unreachable"></xref>.</t>
</section>
</section>
<section title="Shutdown" toc="exclude">
<t>When a gateway pseudo-interface is stopped and the gateway has
existing group subscriptions, the gateway SHOULD either:<list
style="symbols">
<t>Send a Teardown message to the relay as described in <xref
target="gateway-teardown-procedure"></xref>, but only if the
gateway supports the Teardown message, and the current relay
is returning gateway address fields in Membership Query
messages, or</t>
<t>Send a Membership Update message to the relay that will
delete existing group subscriptions.</t>
</list></t>
</section>
<section anchor="gateway-handling-destination-unreachable"
title="Handling ICMP Destination Unreachable Responses">
<t>A gateway may receive an ICMP "Destination Unreachable" message
<xref target="RFC0792"></xref> after sending an AMT message.
Whether the gateway is notified that an ICMP message was received
is highly dependent the gateway IP stack behavior and gateway
implementation.</t>
<t>If the reception of an ICMP Destination Unreachable message is
reported to the gateway while waiting to receive an AMT message,
the gateway may respond as follows, depending on platform
capabilities and which outgoing message triggered the ICMP
response:<list style="numbers">
<t>The gateway MAY simply abandon the current relay and
restart relay discovery (if used). This is the least desirable
approach as it does not allow for transient network
changes.</t>
<t>If the last message sent was a Relay Discovery or Request
message, the gateway MAY simply ignore the ICMP response and
continue waiting for incoming AMT messages. If the gateway is
configured to retransmit Relay Discovery or Request messages,
the normal retransmission behavior for those messages is
preserved to prevent the gateway from prematurely abandoning a
relay.</t>
<t>If the last message sent was a Membership Update message,
the gateway MAY start a new membership update and associated
Request retransmission cycle.</t>
</list></t>
<t>If the reception of an ICMP Destination Unreachable message is
reported to the gateway when attempting to transmit a new AMT
message, the gateway may respond as follows, depending on platform
capabilities and which outgoing message triggered the ICMP
response:<list style="numbers">
<t>The gateway MAY simply abandon the current relay and
restart relay discovery (if used). This is the least desirable
approach as it does not allow for transient network
changes.</t>
<t>If the last message sent was a Relay Discovery, Request or
Teardown message, the gateway MAY attempt to transmit the new
message. If the gateway is configured to retransmit Relay
Discovery, Request or Teardown messages, the normal
retransmission behavior for those messages is preserved to
prevent the gateway from prematurely abandoning a relay.</t>
<t>If the last message sent was a Membership Update message,
the gateway SHOULD start a new membership update and
associated Request retransmission cycle.</t>
</list></t>
</section>
</section>
</section>
<section anchor="relay-operation" title="Relay Operation">
<t>The following sections describe relay implementation requirements.
A non-normative discussion of relay operation may be found in <xref
target="general-operation"></xref>.</t>
<section anchor="relay-igmp-mld-protocol-requirements"
title="IP/IGMP/MLD Protocol Requirements" toc="exclude">
<t>A relay requires a subset of router-mode IGMP and MLD
functionality to provide group membership tracking and report
processing.</t>
<t>A relay accessible via IPv4 MUST support IPv4/IGMPv3 and MAY
support IPv6/MLDv2. A relay accessible via IPv6 MUST support
IPv6/MLDv2 and MAY support IPv4/IGMPv3.</t>
<t>A relay MUST apply the forwarding rules described in <xref
target="RFC3376">Section 6.3 of</xref> and <xref
target="RFC3810">Section 7.3 of</xref>.</t>
<t>A relay MUST handle incoming reports as described <xref
target="RFC3376">,Section 6.4 of</xref> and <xref
target="RFC3810">Section 7.4 of</xref> with the exception that
actions that lead to queries MAY be modified to eliminate query
generation.</t>
<t>All other aspects of IGMP/MLD router behavior, such as the
handling of queries, querier election, etc., are not used or
required for relay operation.</t>
</section>
<section title="Startup" toc="exclude">
<t>If a relay is deployed for anycast discovery, the relay MUST
advertise an anycast Relay Discovery Address Prefix into the unicast
routing system of the anycast domain. An address within that prefix,
i.e., a Relay Discovery Address, MUST be assigned to a relay
interface.</t>
<t>A unicast IPv4 and/or IPv6 address MUST be assigned to the relay
interface that will be used to send and receive AMT control and data
messages. This address or addresses are returned in Relay
Advertisement messages.</t>
<t>The remaining details of relay "startup" are highly
implementation-dependent and are not addressed in this document.</t>
</section>
<section title="Running" toc="exclude">
<t>When a relay is started, it begins listening for AMT messages on
the interface to which the unicast Relay Address(es) has been
assigned, i.e., the address returned in Relay Advertisement
messages.</t>
<section title="Handling AMT Messages" toc="exclude">
<t>A relay MUST ignore any message other than a Relay Discovery,
Request, Membership Update or Teardown message. The handling of
Relay Discovery, Request, Membership Update, and Teardown messages
is addressed in the sections that follow.</t>
<t>Support for the Teardown message is OPTIONAL. If a relay does
not support the Teardown message, it MUST also ignore this
message.</t>
<t>A relay that conforms to this specification MUST ignore any
message with a Version field value other than zero.</t>
</section>
<section title="Handling a Relay Discovery Message" toc="exclude">
<t>This section describes relay requirements related to the relay
discovery message sequence described in <xref
target="overview-relay-discovery-sequence"></xref>.</t>
<t>A relay MUST accept and respond to Relay Discovery messages
sent to an anycast relay discovery address or the unicast relay
address. If a relay receives a Relay Discovery message sent to its
unicast address, it must respond just as it would if the message
had been sent to its anycast discovery address.</t>
<t>When a relay receives a Relay Discovery message it responds by
sending a Relay Advertisement message back to the source of the
Relay Discovery message. The relay MUST use the source IP address
and UDP port of the Relay Discovery message as the destination IP
address and UDP port. The relay MUST use the destination IP
address and UDP port of the Relay Discovery as the source IP
address and UDP port to ensure successful NAT traversal.</t>
<t>The relay MUST copy the value contained in the Discovery Nonce
field of the Relay Discovery message into the Discovery Nonce
field in the the Relay Advertisement message.</t>
<t>If the Relay Discovery message was received as an IPv4
datagram, the relay MUST return an IPv4 address in the Relay
Address field of the Relay Advertisement message. If the Relay
Discovery message was received as an IPv6 datagram, the relay may
return an IPv4 or IPv6 address in the Relay Address field.</t>
</section>
<section title="Handling a Request Message" toc="exclude">
<t>This section describes relay requirements related to the
membership query portion of the message sequence described in
<xref target="overview-membership-update-sequence"></xref>.</t>
<t>When a relay receives a Request message it responds by sending
a Membership Query message back to the source of the Request
message.</t>
<t>The relay MUST use the source IP address and UDP port of the
Request message as the destination IP address and UDP port for the
Membership Query message. The source IP address and UDP port
carried by the Membership Query MUST match the destination IP
address and UDP port of the Request to ensure successful NAT
traversal.</t>
<t>The relay MUST return the value contained in the Request Nonce
field of the Request message in the Request Nonce field of the
Membership Query message. The relay MUST compute a MAC value, as
described in <xref target="relay-response-mac-generation"></xref>,
and return that value in the Response MAC field of the Membership
Query message.</t>
<t>If a relay supports the Teardown message, it MUST set the
G-flag in the Membership Query message and return the source IP
address and UDP port carried by the Request message in the
corresponding Gateway IP Address and Gateway Port Number fields.
If the relay does not support the Teardown message it SHOULD NOT
set these fields as this may cause the gateway to generate
unnecessary Teardown messages.</t>
<t>If the P-flag in the Request message is 0, the relay MUST
return an IPv4-encapsulated IGMPv3 general query in the Membership
Query message. If the P-flag is 1, the relay MUST return an
IPv6-encapsulated MLDv2 general query in the Membership Query
message.</t>
<t>If the relay is not accepting Membership Update messages that
create new tunnel endpoints due to resource limitations, it SHOULD
set the L-flag in the Membership Query message to notify the
gateway of this state. Support for the L-flag is OPTIONAL. See
<xref target="relay-resource-management"></xref>.</t>
<t>The IGMPv3/MLDv2 general query datagram that a relay
encapsulates within a Membership Query message MUST conform to the
descriptions found in <xref target="RFC3376">Section 4.1 of
</xref> and <xref target="RFC3810">Section 5.1 of </xref>. These
datagrams MUST possess the IP headers, header options and header
values called for in these RFCs, with the following exception; the
source IP address for an IGMP/MLD general query datagram MAY be
set to the "unspecified" address (all octets are zero). This
exception is made because any address that a relay might use will
not be a valid source address on any gateway interface. To allow
for this exception, gateways must accept an IGMP or MLD query
regardless of the source address it carries. See <xref
target="gateway-igmp-mld-protocol-requirements"></xref>.</t>
<t>A relay MUST set the Querier's Query Interval Code (QQIC) field
in the general query to supply the gateway with a suggested time
duration to use for the membership query timer. The QQIC field is
defined in <xref target="RFC3376">Section 4.1.1 in </xref> and
<xref target="RFC3810">Section 5.1.3 in </xref>. A relay MAY
adjust this value to affect the rate at which the Request messages
are sent from a gateway. However, a gateway is allowed to use a
shorter duration than specified in the QQIC field, so a relay may
be limited in its ability to spread out Requests coming from a
gateway.</t>
<t>A relay MUST set the Querier's Robustness Variable (QRV) field
in the general query to a non-zero value. This value SHOULD be
greater than one. If a gateway retransmits a membership state
change messages, it will retransmit them (robustness variable - 1)
times.</t>
<t>A relay SHOULD set the Max Resp Code field in the general query
to a value of 1 to trigger an immediate response from the gateway
(some host IGMP/MLD implementations may not accept a value of
zero). A relay SHOULD NOT use the IGMPv2/MLDv2 Query Response
Interval variable, if available, to generate the Max Resp Code
field value as the Query Response Interval variable is used in
setting the duration of group state timers and must not be set to
such a small value. See <xref
target="relay-state-timers"></xref>.</t>
</section>
<section title="Handling a Membership Update Message">
<t>This section describes relay requirements related to the
membership update portion of the message sequence described in
<xref target="overview-membership-update-sequence"></xref>.</t>
<t>When a relay receives a Membership Update message it must first
determine whether it should accept or ignore the message. A relay
MUST NOT make any changes to group membership and forwarding state
if the message fails to satisfy any of the following
requirements:<list style="symbols">
<t>The IP datagram encapsulated within the message MUST be one
of the following:<list style="symbols">
<t>IPv4 datagram carrying an IGMPv2 or IGMPv3 Membership
Report message.</t>
<t>IPv4 datagram carrying an IGMPv2 Leave Group
message.</t>
<t>IPv6 datagram carrying an MLDv1 or MLDv2 Multicast
Listener Report message.</t>
<t>IPv6 datagram carrying MLDv1 Multicast Listener Done
message.</t>
</list></t>
<t>The encapsulated IP datagram MUST satisfy the IP header
requirements for the IGMP or MLD message type as described in
Section 4 of <xref target="RFC3376"></xref>, Section 2 of
<xref target="RFC2236"></xref>, Section 5 of <xref
target="RFC3810"></xref>, Section 3 of <xref
target="RFC2710"></xref>.</t>
<t>The total length of the encapsulated IP datagram as
computed from the lengths contained in the datagram header(s)
MUST NOT exceed the available field length within the
Membership Update message.</t>
<t>The computed checksums for the encapsulated IP datagram and
its payload MUST match the values contained therein. Checksum
computation and verification varies by protocol; See <xref
target="RFC0791"></xref> for IPv4, <xref
target="RFC3376"></xref> for IGMPv3, and <xref
target="RFC4443"></xref> for MLD (ICMPv6).</t>
<t>If processing of the encapsulated IGMP or MLD message would
result in an allocation of new state or a modification of
existing state, the relay MUST authenticate the source of the
Membership message by verifying that the value contained in
the Response MAC field equals the MAC value computed from the
fields in the Membership Update message datagram. Because the
private secret used to compute Response MAC values may change
over time, the relay MUST retain the previous version of the
private secret to use in authenticating Membership Updates
sent during the subsequent query interval. If the first
attempt at Response MAC authentication fails, the relay MUST
attempt to authenticate the Response MAC using the previous
private secret value unless 2*query_interval time has elapsed
since the private secret change. See <xref
target="relay-response-mac-generation"></xref>. An alternative
approach to Response MAC generation that avoids repeated
Response MAC computations may be found in <xref
target="response-mac-generation-keying"></xref>.</t>
</list></t>
<t>A relay MAY skip source authentication to reduce the
computational cost of handling Membership Update messages if the
relay can make a trivial determination that the IGMP/MLD message
carried by the Membership Update message will produce no changes
in group membership or forwarding state. The relay does not need
to compute and compare MAC values if it finds there are no group
subscriptions for the source of the Membership Update message and
either of the following is true:<list style="symbols">
<t>The encapsulated IP datagram is an IGMPv3 Membership Report
or MLDv2 Multicast Listener Report message that contains no
group records. This may often be the case for gateways that
continuously repeat the membership update cycle even though
they have no group subscriptions to report.</t>
<t>The encapsulated IP datagram is an IGMPv2 Leave Group or
MLDv1 Multicast Listener Done message.</t>
</list></t>
<t>An MLD datagram contained in a Membership Update message may
require special handling. The encapsulated datagram generated by a
gateway will likely carry an unspecified or link-local source
address. If the relay relies on a standard router-mode MLD
protocol implementation to process these reports, that
implementation may silently ignore the MLD report because it
carries an unspecified or non-link-local source address - a relay
may need to use the contents of the encapsulated datagram to
construct a new datagram with a valid link-local source address
(e.g., a spoofed address in a virtual subnet defined by the
address and netmask assigned to the relay pseudo-interface) to
ensure that the report will not be ignored by the MLD protocol
implementation.</t>
<t>Once a relay has determined that the Membership Update message
is valid, it processes the encapsulated IGMP or MLD membership
message to update group membership state and communicates with the
multicast protocol to update forwarding state and possibly send
multicast protocol messages towards upstream routers. The relay
MUST ignore any octets that might exist between the encapsulated
IP datagram and the end of the Membership Update message.</t>
<t>As described in <xref target="overview-tunneling"></xref>, a
relay uses the source IP address and source UDP port carried by a
Membership Update messages to identify a tunnel endpoint. A relay
uses the tunnel endpoint as the destination address for any
Multicast Data messages it sends as a result of the group
membership and forwarding state created by processing the IGMP/MLD
messages contained in Membership Update messages received from the
endpoint.</t>
<t>If a Membership Update message originates from a new endpoint,
the relay MUST determine whether it can accept updates from a new
endpoint. If a relay has been configured with a limit on the total
number of endpoints, or a limit on the total number of endpoints
for a given source address, then the relay MAY ignore the
Membership Update message and possibly withdraw any Relay
Discovery Address Prefix announcement that it might have made. See
<xref target="relay-resource-management"></xref>.</t>
<t>A relay MUST maintain some form of group membership database
for each endpoint. The per-endpoint databases are used update a
forwarding table containing entries that map an (*,G) or (S,G)
subscription to a list of tunnel endpoints.</t>
<t>A relay MUST maintain some form group membership database
representing a merger of the group membership databases of all
endpoints. The merged group membership database is used to update
upstream multicast forwarding state.</t>
<t>A relay MUST maintain a forwarding table that maps each unique
(*,G) and (S,G) subscription to a list of tunnel endpoints. A
relay uses this forwarding table to provide the destination
address when performing UDP/IP encapsulation of the incoming
multicast IP datagrams to form Multicast Data messages.</t>
<t>If a group filter mode for a group entry on a tunnel endpoint
is EXCLUDE, the relay SHOULD NOT forward datagrams that originate
from sources in the filter source list unless the relay
architecture does not readily support source filtering. A relay
MAY ignore the source list if necessary because gateways are
expected to do their own source filtering.</t>
</section>
<section anchor="relay-handling-teardown-message"
title="Handling a Teardown Message" toc="exclude">
<t>This section describes relay requirements related to the
teardown message sequence described in <xref
target="overview-teardown-sequence"></xref>.</t>
<t>When a relay (that supports the Teardown message) receives a
Teardown message, it MUST first authenticate the source of the
Teardown message by verifying that the Response MAC carried by the
Teardown message is equal to a MAC value computed from the fields
carried by the Teardown message. The method used to compute the
MAC differs from that used to generate and validate the Membership
Query and Membership Update messages in that the source IP address
and source UDP port number used to compute the MAC are taken from
the Gateway IP Address and Gateway Port Number field in the
Teardown message rather than from the IP and UDP headers in the
datagram that carries the Teardown message. The MAC computation is
described <xref target="relay-response-mac-generation"></xref>. A
relay MUST ignore a Teardown message If the computed MAC does not
equal the value of the Response MAC field.</t>
<t>If a relay determines that a Teardown message is authentic, it
MUST immediately stop transmitting Multicast Data messages to the
endpoint identified by the Gateway IP Address and Gateway Port
Number fields in the message. The relay MUST eventually delete any
group membership and forwarding state associated with the
endpoint, but MAY delay doing so to allow a gateway to recreate
group membership state on a new endpoint and thereby avoid making
unnecessary (temporary) changes in upstream routing/forwarding
state.</t>
<t>The state changes made by a relay when processing a Teardown
message MUST be identical to those that would be made as if the
relay had received an IGMP/MLD report that would cause the IGMP or
MLD protocol to delete all existing group records in the group
membership database associated with the endpoint. The processing
of the Teardown message should trigger or mimic the normal
interaction between IGMP or MLD and a multicast protocol to
produce required changes in forwarding state and possibly send
prune/leave messages towards upstream routers.</t>
</section>
<section title="Handling Multicast IP Datagrams" toc="exclude">
<t>When a multicast IP datagram is forwarded to the relay
pseudo-interface, the relay MUST, for each gateway that has
expressed an interest in receiving the datagram, encapsulate the
IP datagram into a Multicast Data message and send that message to
the gateway. This process is highly implementation dependent, but
conceptually requires the follow steps:<list style="symbols">
<t>Use the IP datagram source and destination address to look
up the appropriate (*,G) or (S,G) entry in the endpoint
forwarding table created for the pseudo-interface as a result
of IGMP/MLD processing.</t>
<t>Possibly replicate the datagram for each gateway endpoint
listed for that (*,G) or (S,G) entry.</t>
<t>Encapsulate the IP datagram in a UDP/IP Membership Data
message, using the endpoint UDP/IP address as the destination
address and the unicast relay address and IANA-assigned port
as the source UDP/IP address. To ensure successful NAT
traversal, the source address and port MUST match the
destination address and port carried by the Membership Update
message sent by the gateway to create the forwarding table
entry.</t>
<t>Send the message to the gateway.</t>
</list></t>
<t>The relay pseudo-interface MUST ignore any other IP datagrams
forwarded to the pseudo-interface.</t>
</section>
<section anchor="relay-state-timers" title="State Timers">
<t>A relay MUST maintain a timer or timers whose expiration will
trigger the removal of any group subscriptions and forwarding
state previously created for a gateway endpoint should the gateway
fail to refresh the group membership state within a specified time
interval.</t>
<t>A relay MAY use a variant of the IGMPv3/MLDv2 state management
protocol described in <xref target="RFC3376">Section 6 of</xref>
or <xref target="RFC3810">Section 7 of</xref>, or may maintain a
per-endpoint timer to trigger the deletion of group membership
state.</t>
<t>If a per-endpoint timer is used, the relay MUST restart this
timer each time it receives a new Membership Update message from
the gateway endpoint.</t>
<t>The RECOMMENDED endpoint timer duration MAY be computed from
tunable IGMP/MLD variables as follows:<vspace blankLines="1" />
((Robustness_Variable) * (Query_Interval)) +
Query_Response_Interval</t>
<t>If IGMP/MLD default values are used for these variables, the
gateway will timeout after 125s * 2 + 10s = 260s. The timer
duration MUST be greater than the query interval suggested in the
last Membership Query message sent to the gateway endpoint.</t>
<t>Regardless of the timers used (IGMPv3/MLDv2 or endpoint), the
Query_Response_Interval value SHOULD be greater than or equal to
10s to allow for packet loss and round-trip time in the
Request/Membership Query message exchange.</t>
</section>
<section anchor="relay-resource-management"
title="Relay Resource Management">
<t>A relay may be configured with various service limits to ensure
a minimum level of performance for gateways that connect to
it.</t>
<t>If a relay has determined that it has reached or exceeded
maximum allowable capacity or has otherwise exhausted resources
required to support additional gateways, it SHOULD withdraw any
Relay Discovery Address Prefix it has advertised into the unicast
internetwork and SHOULD set the L-flag in any Membership Query
messages it returns to gateways while in this state.</t>
<t>If the relay receives an update from a gateway that adds group
membership or forwarding state for an endpoint that has already
reached maximum allowable state entries, the relay SHOULD continue
to accept updates from the gateway but ignore any group
membership/forwarding state additions requested by that
gateway.</t>
<t>If the relay receives an update from a gateway that would
create a new tunnel endpoint for a source IP address that has
already reach maximum allowable number of endpoints (maximum UDP
ports), it should simply ignore the Membership Update.</t>
</section>
</section>
<section title="Shutdown" toc="exclude">
<t>The following steps should be treated as an abstract description
of the shutdown procedure for a relay:<list style="symbols">
<t>Withdraw the Relay Discovery Address Prefix advertisement (if
used).</t>
<t>Stop listening for Relay Discovery messages.</t>
<t>Stop listening for control messages from gateways.</t>
<t>Stop sending data messages to gateways.</t>
<t>Delete all AMT group membership and forwarding state created
on the relay, coordinating with the multicast routing protocol
to update the group membership state on upstream interfaces as
required.</t>
</list></t>
</section>
<section anchor="relay-response-mac-generation"
title="Response MAC Generation" toc="exclude">
<t>A Response MAC is produced by a hash digest computation. A
Response MAC value is computed from a Request message for inclusion
in a Membership Query message, is computed from a Membership Update
message to authenticate the Response MAC carried within that
message, and is computed from fields in a Teardown message to
authenticate the Response MAC carried within that message.</t>
<t>Gateways treat the Response MAC field as an opaque value, so a
relay implementation may generate the MAC using any method available
to it. The hash function RECOMMENDED for use in computing the
Response MAC is the MD5 hash digest <xref target="RFC1321"></xref>,
though hash functions or keyed-hash functions of greater
cryptographic strength may be used.</t>
<t>The digest MUST be computed over the following values:<list
style="symbols">
<t>The Source IP address of the message (or Teardown Gateway IP
Address field)</t>
<t>The Source UDP port of the message (or Teardown Gateway Port
Number field)</t>
<t>The Request Nonce contained in the message.</t>
<t>A private secret known only to the relay</t>
</list></t>
<t>An Response MAC generation solution that satisfies these
requirements is described in <xref
target="response-mac-generation-keying"></xref>.</t>
</section>
<section anchor="relay-private-secret-generation"
title="Private Secret Generation" toc="exclude">
<t>The private secret, or hash-key, is a random value that the relay
includes in the Response MAC hash digest computation. A relay SHOULD
periodically compute a new private secret. The RECOMMENDED maximum
interval is 2 hours. A relay MUST retain the prior secret for use in
verifying MAC values that were sent to gateways just prior to the
use of the new secret.</t>
<t>The private secret SHOULD be computed using a
cryptographically-secure pseudo-random number generator. The private
secret width SHOULD equal that of the hash function used to compute
the Response MAC, e.g., 128-bits for an MD5 hash.</t>
</section>
</section>
</section>
<section title="Security Considerations">
<t>AMT is not intended to be a strongly secured protocol. In general,
the protocol provides the same level of security and robustness as is
provided by the UDP, IGMP and MLD protocols on which it relies. The lack
of strong security features can largely be attributed to the desire to
make the protocol light-weight by minimizing the state and computation
required to service a single gateway, thereby allowing a relay to
service a larger number of gateways.</t>
<t>Many of the threats and vectors described in <xref
target="RFC3552"></xref> may be employed against the protocol to launch
various types of denial-of-service attacks that can affect the
functioning of gateways or their ability to locate and communicate with
a relay. These scenarios are described below.</t>
<t>As is the case for UDP, IGMP and MLD, the AMT protocol provides no
mechanisms for ensuring message delivery or integrity. The protocol does
not provide confidentiality - multicast groups, sources and streams
requested by a gateway are sent in the clear.</t>
<t>The protocol does use a three-way handshake to provide trivial source
authentication for state allocation and updates (see below). The
protocol also requires gateways and relays to ignore malformed messages
and those messages that do not carry expected address values or protocol
payload types or content.</t>
<section title="Relays" toc="exclude">
<t>The three-way handshake provided by the membership update message
sequence (<xref
target="overview-membership-update-sequence">See</xref>) provides a
defense against source-spoofing-based resource-exhaustion attacks on a
relay by requiring source authentication before state allocation.
However, attackers may still attempt to flood a relay with Request and
Membership Update messages to force the relay to make the hash
computations in an effort to consume computational resources.
Implementations may choose to limit the frequency with which a relay
responds to Request messages sent from a single IP address or IP
address and UDP port pair, but support for this functionality is not
required. The three-way handshake provides no defense against an
eavesdropping or man-in-the-middle attacker.</t>
<t>Attackers that execute the gateway protocol may consume relay
resources by instantiating a large number of tunnels or joining a
large number of multicast streams. A relay implementation should
provide a mechanism for limiting the number of tunnels (Multicast Data
message destinations) that can be created for a single gateway source
address. Relays should also provide a means for limiting the number of
joins per tunnel instance as a defense against these attacks.</t>
<t>Relays may withdraw their AMT anycast prefix advertisement when
they reach configured maximum capacity or exhaust required resources.
This behavior allows gateways to use the relay discovery process to
find the next topologically-nearest relay that has advertised the
prefix. This behavior also allows a successful resource exhaustion
attack to propagate from one relay to the next until all relays
reachable using the anycast address have effectively been taken
offline. This behavior may also be used to acquire the unicast
addresses for individual relays which can then be used to launch a
DDoS attack on all of the relays without using the relay discovery
process. To prevent wider disruption of AMT-based distribution
network, relay anycast address advertisements can be limited to
specific administrative routing domains. This will isolate such
attacks to a single domain.</t>
</section>
<section title="Gateways" toc="exclude">
<t>A passive eavesdropper may launch a denial-of-service attack on a
gateway by capturing a Membership Query or Membership Update message
and using the request nonce and message authentication code carried by
the captured message to send a spoofed a Membership Update or Teardown
message to the relay. The spoofed messages may be used to modify or
destroy group membership state associated with the gateway, thereby
changing or interrupting the multicast traffic flows.</t>
<t>A passive eavesdropper may also spoof Multicast Data messages in an
attempt to overload the gateway or disrupt or supplant existing
traffic flows. A properly implemented gateway will filter Multicast
Data messages that do not originate from the expected relay address
and should filter non-multicast packets and multicast IP packets whose
group or source addresses are not included in the current reception
state for the gateway pseudo-interface.</t>
<t>The anycast discovery technique for finding relays (see <xref
target="overview-deployment"></xref>) introduces a risk that a rogue
router or a rogue AS could introduce a bogus route to a specific Relay
Discovery Address prefix, and thus divert or absorb Relay Discovery
messages sent by gateways. Network managers must guarantee the
integrity of their routing to a particular Relay Discovery Address
prefix in much the same way that they guarantee the integrity of all
other routes.</t>
</section>
<section title="Encapsulated IP Packets" toc="exclude">
<t>An attacker forging or modifying a Membership Query or Membership
Update message may attempt to embed something other than an IGMP or
MLD message within the encapsulated IP packet carried by these
messages in an effort to introduce these into the recipient's IP
stack. A properly implemented gateway or relay will ignore any such
messages - and may further choose ignore Membership Query messages
that do not contain a IGMP/MLD general queries or Membership Update
messages that do not contain IGMP/MLD membership reports.</t>
<t>Property implemented gateways and relays will also filter
encapsulated IP packets that appear corrupted or truncated by
verifying packet length and checksums.</t>
</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<section title="IPv4 and IPv6 Anycast Prefix Allocation" toc="exclude">
<t>The IANA should allocate an IPv4 prefix and an IPv6 prefix
dedicated to the public AMT Relays to advertise to the native
multicast backbone (as described in <xref
target="overview-deployment"></xref>). The prefix length should be
determined by the IANA; the prefix should be large enough to guarantee
advertisement in the default-free BGP networks.</t>
<section title="IPv4" toc="exclude">
<t>A prefix length of 16 will meet this requirement.</t>
</section>
<section title="IPv6" toc="exclude">
<t>A prefix length of 32 will meet this requirement. IANA has
previously set aside the range 2001::/16 for allocating prefixes for
this purpose.</t>
</section>
</section>
<section title="UDP Port number" toc="exclude">
<t>IANA has reserved UDP port number 2268 for AMT.</t>
</section>
</section>
<section title="Contributors">
<t>The following people provided significant contributions to earlier
versions of this specification:</t>
<figure>
<artwork><![CDATA[
Dirk Ooms
OneSparrow
Belegstraat 13; 2018 Antwerp;
Belgium
EMail: dirk@onesparrow.com
Tom Pusateri
!j
2109 Mountain High Rd.
Wake Forest, NC 27587
USA
Email: pusateri@bangj.com
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
USA
Email: dthaler@microsoft.com
]]></artwork>
</figure>
</section>
<section title="Acknowledgments">
<t>The authors would like to thank the following individuals for their
suggestions, comments, and corrections:</t>
<figure>
<artwork><![CDATA[
Amit Aggarwal
Mark Altom
Toerless Eckert
Marshall Eubanks
Dino Farinacci
Lenny Giuliano
Andy Huang
Tom Imburgia
Patricia McCrink
Han Nguyen
Doug Nortz
Pekka Savola
Robert Sayko
Greg Shepherd
Steve Simlo
Mohit Talwar
Lorenzo Vicisano
Kurt Windisch
John Zwiebel
]]></artwork>
</figure>
<t>The anycast discovery mechanism described in this document is based
on similar work done by the NGTrans WG for obtaining automatic IPv6
connectivity without explicit tunnels ("6to4"). Tony Ballardie provided
helpful discussion that inspired this document.</t>
<t>Juniper Networks was instrumental in funding several versions of this
draft as well as an open source implementation.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.0768'?>
<?rfc include='reference.RFC.0792'?>
<?rfc include='reference.RFC.1321'?>
<?rfc include='reference.RFC.3376'?>
<?rfc include='reference.RFC.3810'?>
<?rfc include='reference.RFC.4291'?>
<?rfc include='reference.RFC.4605'?>
<?rfc include='reference.RFC.4607'?>
<?rfc include='reference.RFC.4787'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-6man-udpchecksums'?>
<?rfc include='reference.I-D.ietf-6man-udpzero'?>
<?rfc include='reference.RFC.0791'?>
<?rfc include='reference.RFC.1112'?>
<?rfc include='reference.RFC.1546'?>
<?rfc include='reference.RFC.2104'?>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.2236'?>
<?rfc include='reference.RFC.2460'?>
<?rfc include='reference.RFC.2663'?>
<?rfc include='reference.RFC.2710'?>
<?rfc include='reference.RFC.3053'?>
<?rfc include='reference.RFC.3056'?>
<?rfc include='reference.RFC.3068'?>
<?rfc include='reference.RFC.3552'?>
<?rfc include='reference.RFC.3973'?>
<?rfc include='reference.RFC.4443'?>
<?rfc include='reference.RFC.4601'?>
<?rfc include='reference.RFC.4760'?>
<?rfc include='reference.RFC.4786'?>
</references>
<section title="Implementation Notes">
<section anchor="response-mac-generation-keying"
title="Response MAC Generation and Keying" toc="exclude">
<t>This specification does not require relays to use any particular
method to compute the Response MAC field value - only that it contain
a hash of the source IP address, source UDP port, request nonce, and a
private secret known only to the relay. This allows the relay
implementor a significant amount of leeway in the computation and
structure of the value stored in the Response MAC field.</t>
<t>Section <xref target="relay-private-secret-generation"></xref>
states that a relay should periodically compute a new private secret
(or hash-key) for MAC generation. To prevent the relay from rejecting
Membership Update messages that contain Response MAC values computed
from an old secret, the relay is required to retain the previous
secret so that it can re-attempt authentication using the old secret,
should authentication fail after recomputing the MAC using the new
secret. However, this approach requires a relay to do at least two
hash computations for every Membership Update message that carries an
old or a invalid MAC. A better approach would be to include
information within the message that the relay could use to choose a
single secret for authentication rather relying on sequential
authentication failures to test all possible secrets.</t>
<t>The solution proposed here is to compute and exchange an
"authentication cookie" rather than a simple hash value in the
Response MAC field. The authentication cookie would combine a
timestamp with a hash value. The timestamp is used to calculate the
age of the cookie, allowing the relay to reject a message if the
cookie's age is greater than some maximum allowable value. If the
cookie has not expired, the relay uses the timestamp to lookup the
secret that was in use at that time and then compute and compare the
hash portion of the cookie to authenticate the message source.</t>
<t>A second purpose served by including the timestamp in the MAC field
is that it allows the relay to contribute an unpredictable value to
the authentication hash. This contribution provides a defense against
attempts to use a hash reversal algorithm to determine the relay's
private secret as the hash result will change over time even if the
nonce carried by the Request message does not.</t>
<figure title="The Opaque Response MAC Field">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |4 or 5| Reserved | | Response MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
]]></artwork>
</figure>
<figure title="Using The Response MAC Field To Carry An Authentication Cookie">
<preamble>A relay may use the opaque Response MAC field to store a
cookie as follows:</preamble>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |4 or 5| Reserved | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5(Secret,Timestamp,IP_ADDR,IP_PORT,Request-Nonce) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
]]></artwork>
</figure>
<t>The timestamp is an unsigned integer measured relative to the start
time of relay. The age of the MAC is computed by subtracting the MAC
timestamp from the current system timestamp. The operands must be
unsigned 16-bit integers and the subtraction must use unsigned
arithmetic to allow for timestamp wrap-around. The timestamp
resolution must provide range sufficient to handle the maximum
allowable age for a MAC, e.g., a resolution of 1 second allows a
maximum age of 18 hours. The timestamp should start at a random value
by adding a random offset, computed at startup, to the current system
time.</t>
<figure title="Private Secret Queue">
<artwork><![CDATA[
+-------------------------+----------------/ /-----------------+
-->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |
| +-------------------------+----------------/ /-----------------+
|_____________________________________________________________________
|
+-------------------------+----------------/ /-----------------+ |
-->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |--
| +-------------------------+----------------/ /-----------------+
|_____________________________________________________________________
|
+-------------------------+----------------/ /-----------------+ |
-->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |--
| +-------------------------+----------------/ /-----------------+
|
|__ Current
Secret
]]></artwork>
</figure>
<t>The timestamp is not only used to compute the age of the MAC, but
is also used to lookup the private secret used to generate the MAC.
Each time a new private secret is computed, the value and the time at
which the value was computed is pushed into a fixed-length queue of
recent values (typically only 2-deep). The relay uses the timestamp
contained in the MAC field to lookup the appropriate secret. The relay
iterates over the list of secrets, starting with the newest entry,
until it finds the first secret with a timestamp that is older than
that contained in the MAC field. The relay then uses that secret to
compute the MAC that will be compared with that carried by the
message.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:40:34 |