Automatic Multicast Tunneling
updated by
Extracted elements (29)
AMT relays do not send unsolicited query messages to gateways because the set of active gateways may be unknown to the relay and potentially very large. Instead, each gateway periodically sends a Request message to solicit a query, mimicking the periodic query behavior of an IGMP/MLD router.
Anycast addressing for relay deployment enables staged deployment, scaling, and hot-swapping without gateway reconfiguration. Relays can be added or removed at any time; the discovery process always routes discovery messages to the topologically nearest operational relay.
Zero-valued UDP checksums are permitted on Multicast Data messages because many routing/forwarding platforms cannot compute checksums on UDP-encapsulated packets, and requiring valid checksums on every replicated multicast packet would impose an undue computational burden on the relay.
AMT provides automatic NAT traversal by using the source IP address and UDP port of the received Membership Update message as the destination for subsequent Multicast Data messages. The NAT mapping is refreshed with each periodic three-way handshake.
AMT specifically permits zero-valued UDP checksums on Multicast Data messages to reduce relay burden. However, UDP over IPv6 requires a non-zero checksum per RFC 2460, so zero-checksum Multicast Data messages over IPv6 may fail to reach the gateway; the recommended solution is described in RFC 6935.
The IP protocol of encapsulated packets need not match the IP protocol used for AMT transport: AMT messages sent via IPv4 may carry IPv6/MLD packets, and AMT messages sent via IPv6 may carry IPv4/IGMP packets.
A relay SHOULD set the G flag and populate the Gateway Port Number and Gateway IP Address fields if it supports the optional teardown procedure, enabling gateways to detect address changes and send Teardown messages.
All relay implementations MUST support the anycast-based relay discovery mechanism, even though gateways are not required to use it and may instead use statically assigned or DNS-based relay addresses.
Gateway support for the Teardown message is RECOMMENDED. Gateways are not required to send Teardown messages and may instead rely on group membership to expire on the relay.
If a relay sets the G flag in the Membership Query message, it MUST also include the Gateway Port Number and Gateway IP Address fields. This allows gateways to detect address changes caused by NAT remapping or interface roaming.
Support for the Limit (L) flag in Membership Query is RECOMMENDED. When L=1, the relay signals it is NOT accepting Membership Update messages from new gateway tunnel endpoints; a gateway should restart relay discovery rather than attempt to create new subscriptions.
The P flag in the Request message determines the protocol the relay MUST use in the query response: P=0 means the relay MUST respond with an IPv4/IGMPv3 General Query; P=1 means the relay MUST respond with an IPv6/MLDv2 General Query.
The UDP/IP datagrams containing Relay Discovery, Relay Advertisement, Request, and Membership Query messages MUST carry a valid, non-zero UDP checksum.
AMT defines seven message types exchanged as UDP datagrams: Relay Discovery (1), Relay Advertisement (2), Request (3), Membership Query (4), Membership Update (5), Multicast Data (6), and Teardown (7). All messages are exchanged as IPv4 or IPv6 UDP datagrams, one message per datagram.
AMT employs a client-server model in which a 'gateway' sends requests to receive specific multicast traffic to a 'relay' that responds by delivering the requested multicast traffic. Gateways are deployed in networks lacking multicast support; relays are deployed in multicast-enabled networks with native multicast connectivity.
AMT uses anycast addressing for relay discovery: relays advertise a route to a shared anycast prefix, and gateways send Relay Discovery messages to the anycast Relay Discovery Address. The responding relay returns its unicast address in a Relay Advertisement, and gateways use that unicast address for all subsequent messages.
The Relay Discovery Address is constructed from an assigned prefix by setting the low-order octet to 1 for both IPv4 and IPv6. All remaining addresses within each prefix are reserved for future use.
The Response MAC is a 48-bit source authentication value generated by the relay, computed as a hash digest of the source IP address, source UDP port, request nonce, and a private secret. Gateways must echo this value in subsequent Membership Update and Teardown messages to authenticate with the relay.
IANA has assigned a well-known UDP port number for AMT protocol messages. All AMT control and data messages use this port as the destination UDP port when addressed to a relay.
IANA has assigned IPv4 and IPv6 anycast address prefixes for advertising and discovering publicly accessible AMT relays. The Relay Discovery Address for each prefix is the prefix address with its low-order octet set to 1; all remaining addresses in each prefix are reserved.
Encapsulated IP packets in AMT Multicast Data messages may carry spoofed source addresses or other malicious content. Gateways and the networks they connect to must treat such encapsulated packets with the same caution applied to packets received from untrusted external networks.
Relays are accessible via a well-known anycast address and are vulnerable to DoS attacks. AMT service providers must deploy relays near network borders and limit relay address advertisements to those edges, preventing distant gateways from generating flows that exhaust intervening link capacity.
The MAC-based source authentication mechanism defends against resource exhaustion via source-address spoofing. Spoofed Request messages are stateless and create no relay state; spoofed Membership Update messages will fail MAC verification and be rejected, preventing the allocation of forwarding state.
A gateway tunnel is created when a Membership Update message carrying an IGMP/MLD report creates one or more group subscriptions where none existed for that tunnel endpoint. The tunnel ceases to exist when all subscriptions are deleted via report/leave/done message, Teardown message, or expiry of per-group or per-tunnel timers on the relay.
The membership refresh cycle: (1) gateway sends Request with random nonce → (2) relay responds with Membership Query containing MAC and nonce → (3) gateway sends Membership Update echoing MAC and nonce. A query timer, whose duration is set by the QQIC field in the encapsulated General Query, drives the next Request when it expires.
Membership Query message (Type=4): version, type, 6 reserved bits, 1-bit L flag, 1-bit G flag, 48-bit Response MAC, 32-bit Request Nonce, variable-length encapsulated IGMPv3/MLDv2 General Query, and optionally a 16-bit Gateway Port Number and 16-byte Gateway IP Address when G=1.
Relay Advertisement message (Type=2): 4-bit version, 4-bit type, 24 reserved bits, 32-bit Discovery Nonce, then a variable-length Relay Address (4 bytes IPv4 or 16 bytes IPv6). Address family is determined by UDP datagram length minus 8.
Relay Discovery message (Type=1): 4-bit version (V=0), 4-bit type, 24 reserved bits in the first 32-bit word, followed by a 32-bit Discovery Nonce. Total fixed length of 8 bytes.
Request message (Type=3): 4-bit version, 4-bit type, 7 reserved bits, 1-bit P flag, 16 reserved bits, then a 32-bit Request Nonce. P=0 requests IGMPv3 General Query; P=1 requests MLDv2 General Query.