RFC 7450
Automatic Multicast Tunneling
RFC 7450 ✨ Part 1 of 16
Title: Automatic Multicast Tunneling 🦋
- Series: IETF, RFC 7450
- Authors: G. Bumgardner
- Date: February 2015
- Category: Standards Track (it's a full Internet Standard, so it's giving official 💅)
- ISSN: 2070-1721
- Obsoletes / Updates: The title block doesn't list any RFCs that this one obsoletes or updates. 🌸
Abstract ✨
okay so this doc describes Automatic Multicast Tunneling (AMT) 🎀. It's a protocol for getting multicast traffic from sources on a multicast-enabled network to receivers that don't have multicast connectivity to that source network. How it works: it uses UDP encapsulation and unicast replication 🧚. The AMT protocol is built for rapid deployment, which means it needs minimal changes to the network infrastructure that already exists. Iconic behavior 😭🔥
Status of This Memo
This is an Internet Standards Track document. 💖
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 🍓.
For info on the current status of this document, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7450 🫶.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. ✨
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please actually read these, bestie, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes. 🔥
Table of Contents 📚
1. Introduction ....................................................3
2. Applicability ...................................................3
3. Terminology .....................................................4
3.1. Requirements Notation ......................................4
3.2. Definitions ................................................4
3.3. Abbreviations ..............................................5
4. Protocol Overview ...............................................6
4.1. General Architecture .......................................6
4.1.1. Relationship to IGMP and MLD Protocols ..............6
4.1.2. Gateways ............................................7
4.1.3. Relays .............................................10
4.1.4. Deployment .........................................13
4.1.5. Discovery ..........................................14
4.2. General Operation .........................................15
4.2.1. Message Sequences ..................................15
4.2.2. Tunneling ..........................................26
5. Protocol Description ...........................................31
5.1. Protocol Messages .........................................31
5.1.1. Relay Discovery ....................................31
5.1.2. Relay Advertisement ................................32
5.1.3. Request ............................................34
5.1.4. Membership Query ...................................35
5.1.5. Membership Update ..................................39
5.1.6. Multicast Data .....................................41
5.1.7. Teardown ...........................................43
5.2. Gateway Operation .........................................45
5.2.1. IP/IGMP/MLD Protocol Requirements ..................45
5.2.2. Pseudo-Interface Configuration .....................47
5.2.3. Gateway Service ....................................48
5.3. Relay Operation ...........................................61
5.3.1. IP/IGMP/MLD Protocol Requirements ..................61
5.3.2. Startup ............................................61
5.3.3. Running ............................................62
5.3.4. Shutdown ...........................................73
5.3.5. Response MAC Generation ............................73
5.3.6. Private Secret Generation ..........................74
6. Security Considerations ........................................74
6.1. Relays ....................................................74
6.2. Gateways ..................................................76
6.3. Encapsulated IP Packets ...................................76
7. IANA Considerations ............................................77
7.1. IPv4 and IPv6 Anycast Prefix Allocation ...................77
7.1.1. IPv4 ...............................................77
7.1.2. IPv6 ...............................................78
7.2. UDP Port Number ...........................................78
8. References .....................................................78
8.1. Normative References ......................................78
8.2. Informative References ....................................79
Acknowledgments ...................................................81
Contributors ......................................................82
Author's Address ..................................................821. Introduction 🎀
The perks of multicast are well known, and there are a bunch of app areas that are perfect for it 😍. We're talking media broadcasting, video conferencing, collaboration, real-time data feeds, data replication, and software updates. The problem is that a lot of these apps don't have multicast connectivity to the networks carrying the traffic from multicast sources 😭. The reasons vary, but they mostly come down to service provider policies and network limitations.
AMT is a protocol that uses UDP-based encapsulation to fix that missing multicast connectivity 🦋. It lets sites, hosts, or apps without native multicast access to a network that has multicast connectivity to a source request and receive Source-Specific Multicast (SSM) [RFC4607] and Any-Source Multicast (ASM) [RFC1112] traffic from that network. Literally a glow-up 💅✨.
2. Applicability 🌈
This doc describes a protocol that may be used to deliver multicast traffic from a multicast-enabled network to sites that lack multicast connectivity to the source network 🧚. It does not describe any methods for sourcing multicast traffic from isolated sites, since that topic is out of scope, so don't come looking for it here 🙈.
ngl, AMT isn't meant to replace native multicast, especially in conditions or environments with high traffic flow 💀. AMT uses unicast replication to reach multiple receivers, and the bandwidth cost of that replication will be higher than it would be if those receivers were reachable over native multicast. Not the vibe for heavy traffic 🌸.
AMT is designed to be deployed at the border of networks that have native multicast capabilities, where the AMT service provider can manage access and provisioning 👑.
3. Terminology 📚
3.1. Requirements Notation 💜
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 [RFC2119]. Those are the official rule words, so read them carefully 🫶.
3.2. Definitions 🍓
This document adopts the following definitions for describing the protocol:
- Downstream: A downstream interface or connection that faces away from the multicast distribution root or towards multicast receivers. Think of it as "away from the source, toward the people watching" 🌊.
- Upstream: An upstream interface or connection that faces a multicast distribution root or source. The opposite of downstream, so it points back toward where the traffic comes from ⬆️.
- Non-Broadcast Multi-Access (NBMA): An NBMA network or interface is one that multiple network nodes (hosts or routers) are attached to, but where packets go directly from one node to another over a virtual circuit or physical link. NBMA networks do not support multicast or broadcast traffic -- so a node that sources multicast traffic has to replicate the multicast packets and send a separate copy to each node that asked for that traffic 🙃.
- Multicast Receiver: An entity that requests and receives multicast traffic. A receiver can be a router, host, application, or application component. How a receiver sends group membership requests and gets multicast traffic depends on the receiver type 💖.
- Group Membership Database: A group membership database describes the current multicast subscription state (also called "reception state") for an interface or system. Section 3 of [RFC3376] has the detailed definition 📖.
- Reception State: The multicast subscription state of a pseudo-interface, virtual interface, or physical network interface. Often used interchangeably with group membership database ✨.
- Subscription: A group or state entry in a group membership database or reception state table. If a subscription entry is there, that means membership in an IP multicast group 🔔.
- Group Membership Protocol: "Group membership protocol" is the generic term for the Internet Group Management Protocol (IGMP) [RFC1112] [RFC2236] [RFC3376] or the Multicast Listener Discovery protocol [RFC2710] [RFC3810] 🧠.
- Multicast Protocol: "Multicast protocol" is the generic term for multicast routing protocols used to join or leave multicast distribution trees, such as Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601] 🌳.
- Network Address Translation (NAT): NAT is the process of changing the source IP address and port numbers carried by an IP packet while it's transiting a network node (see [RFC2663]). Intervening NAT devices may change the source address and port carried by messages sent from an AMT gateway to an AMT relay, which can cause changes in protocol state and behavior. Plot twist 😳🔥.
- Anycast: A network addressing and routing method where packets from a single sender are routed to the topologically nearest node in a group of potential receivers that all share the same destination address. See [RFC4786] 📍.
3.3. Abbreviations 🧚
Here's the abbreviation cheat sheet, bestie 💅:
- AMT - Automatic Multicast Tunneling protocol.
- ASM - Any-Source Multicast.
- DoS - Denial-of-Service (attack) and DDoS for distributed DoS.
- IGMP - Internet Group Management Protocol (v1, v2, and v3).
- IP - Internet Protocol (v4 and v6).
- MAC - Message Authentication Code (or Cookie).
- MLD - Multicast Listener Discovery protocol (v1 and v2).
- NAT - Network Address Translation (or translation node).
- NBMA - Non-Broadcast Multi-Access (network, interface, or mode).
- PIM - Protocol Independent Multicast.
- SSM - Source-Specific Multicast.
4. Protocol Overview 🧚♀️✨
This section gives an informative description of the protocol, so it's the friendly tour 🗺️. The normative description, plus the implementation requirements, lives in Section 5. Go there when you need the official rules 🎀.
Part 1 of 16 done, bestie. More coming!! 🌈💖
4.1. General Architecture ✨
okay so the big picture is that AMT is basically a client-server setup, bestie 💖 a "gateway" asks a "relay" for specific multicast traffic, and the relay sends that traffic back to the gateway. it's giving request and response 🎀
Isolated Site | Unicast Network | Native Multicast
| (Internet) |
| |
| |
| Group Membership |
+-------+ =========================> +-------+ Multicast +------+
|Gateway| | | | Relay |<----//----|Source|
+-------+ <========================= +-------+ +------+
| Multicast Data |
| |
| |
Figure 1: Basic AMT Architecturegateways usually live in networks that don't do multicast, or that can't reach a multicast-enabled network holding the sources you care about 🥺 that's the whole reason they exist 💅
relays sit inside multicast-enabled networks, and they either contain the multicast sources or have a connection to them 🦋
4.1.1. Relationship to IGMP and MLD Protocols
AMT leans on the Internet Group Management Protocol (IGMP) [RFC3376] and the Multicast Listener Discovery (MLD) protocol [RFC3810] to do the group membership stuff: managing it, communicating it, and reacting when it changes 🧚 a gateway or relay doesn't have to be a fully functional, conforming IGMP or MLD implementation to follow this spec, but the protocol description in this doc assumes that it is 🌸 the minimum functional and behavioral requirements for IGMP and MLD live in Sections 5.2.1 and 5.3.1, so go look there if you're curious 👀
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
|_____| |_____|
Figure 2: Multicast Reception State Managed by IGMP/MLDso a gateway runs the host side of IGMP and MLD to make the group membership updates, then ships them off to a relay as AMT messages 🫶 the relay runs the router side to process those updates and change its multicast forwarding state to match 🔥 then the relay uses AMT messages to send incoming multicast IP datagrams down to gateways, based on what each gateway is currently subscribed to 💜
the main job of AMT is handshaking, encapsulation, and decapsulation, so the IGMP and MLD messages and the multicast IP datagrams can travel between gateways and relays 🎀 the IGMP and MLD messages get wrapped up as complete IP datagrams inside AMT control messages, and the multicast IP datagrams get replicated and wrapped inside AMT data messages ✨ everything AMT sends goes over unicast UDP/IP, no multicast needed for the transport itself, which is lowkey iconic 🌈
4.1.2. Gateways
the downstream side of a gateway serves one or more receivers. the gateway takes group membership requests from receivers and forwards the multicast traffic they asked for back to them 🍓 the gateway logic can live right inside the host that wants the multicast service, or inside an application running on that host 💅
the upstream side connects to relays. the gateway sends encapsulated IGMP and MLD messages to a relay to say "hey, I'm interested in this specific multicast traffic" 🦋
4.1.2.1. Architecture
every gateway has a logical pseudo-interface 🧚
join/leave ---+ +----------+
| | |
V IGMPv3/MLDv2 | |
+---------+ General Query| | AMT
|IGMP/MLD |<-------------| AMT | Messages +------+
|Host-Mode| | Gateway |<-------->|UDP/IP|
|Protocol |------------->|Pseudo-I/F| +------+
+---------+ IGMP/MLD | | ^
Report | | |
Leave/Done | | V
IP Multicast <---------------------| | +---+
+----------+ |I/F|
+---+
Figure 3: AMT Gateway Pseudo-Interfaceconceptually, the pseudo-interface is a network interface where the gateway runs the host side of IPv4/IGMP (v2 or v3) and IPv6/MLD (v1 or v2) 🫶 its multicast reception state gets changed through the IGMP or MLD service interface. the host IGMP and MLD protocols make the IP datagrams full of group membership messages that the gateway sends to the relay, and they also handle the retransmission and timing stuff needed for robustness 💖
all the AMT encapsulation, decapsulation, and relay interaction is assumed to happen inside the pseudo-interface 🌸
a gateway host or application can make separate interfaces for IPv4/IGMP and IPv6/MLD 🎀 it might also need extra pseudo-interfaces for each source or domain-specific relay address 🧚
in this document, "gateway" can mean a few things: an entity running the gateway protocol, a gateway pseudo-interface, or a gateway device with one or more interfaces on a unicast internetwork and one or more AMT gateway pseudo-interfaces 💅 context will tell you which one, iykyk 😌
here's a diagram of how an existing host IP stack could be used to give a multicast application AMT gateway functionality 👑
+-----------------------------------------------------+
|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
Figure 4: Virtual Interface Implementation Examplein this example, the host IP stack uses a virtual network interface to talk to a gateway pseudo-interface implementation 🦋
4.1.2.2. Use Cases
gateway functionality shows up in a few different use cases, bestie 🍓
- IGMP/MLD Proxy: an IGMP/MLD proxy that runs AMT on its upstream interface and router-mode IGMP/MLD on its downstream interfaces, so hosts can reach multicast traffic through the IGMP and MLD protocols 🧚
- Virtual Network Interface: a virtual network interface or pseudo-network device driver that runs AMT on a physical network interface, giving socket-layer access to multicast traffic through the IGMP/MLD service interface the host IP stack provides 💖
- Application: an application (or part of one) that runs IGMP/MLD and AMT internally to get access to multicast traffic 👑
4.1.3. Relays
the downstream side of a relay serves gateways. the relay takes encapsulated IGMP and MLD group membership messages from gateways, then encapsulates and forwards the requested multicast traffic back to those gateways 🌈
the upstream side of a relay talks to the native multicast infrastructure. the relay sends join and prune/leave requests toward multicast sources, and it accepts the requested multicast traffic coming from those sources 🫶 the relay is literally the middle person between the two worlds, and it's giving main character energy 💅✨
4.1.3.1. Architecture
okay bestie, so every relay has a logical pseudo-interface 🦋✨
+------------------------------+
+--------+ | Multicast Control Plane |
| |IGMP/MLD| |
| | Query* | +------------+ +----------+ |
| |<---//----|IGMPv3/MLDv2| |Multicast | |
AMT | | | |Router-Mode |->|Routing |<->
+------+ Messages | AMT |----//--->|Protocol | |Protocol | |
|UDP/IP|<-------->| Relay |IGMP/MLD| +------------+ +----------+ |
+------+ | Pseudo-| Report | | | |
^ | I/F | Leave/ +------|---------------|-------+
| | | Done | |
| | | v |
V | | IP +-----------+ |
+---+ | | Multicast |Multicast |<------+
|I/F| | |<---//-----|Forwarding |
+---+ +--------+ |Plane |<--- IP Multicast
+-----------+
* Queries, if generated, are consumed by the pseudo-interface.
Figure 5: AMT Relay Pseudo-Interface (Router-Based)so the pseudo-interface is basically a network interface where the relay acts like the router side of IPv4/IGMPv3 and IPv6/MLDv2 💅 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 🙈 the protocol says IGMPv3 and MLDv2 are the ones used for query messages, and the AMT protocol is mainly built for SSM apps. it leans on a few values from IGMPv3/MLDv2 to control how gateways behave 🫶
a relay keeps group membership state for each gateway hooked up through the pseudo-interface, and also for the whole pseudo-interface when one interface is managing several gateways 🧚 multicast packets that come in on the upstream interfaces get routed to the pseudo-interface, where they get replicated, encapsulated, and sent off to the gateways that care about them. when the pseudo-interface membership state changes, that can kick off multicast protocol requests upstream toward a source or rendezvous point, and it can also change internal routing and forwarding state 🌸
the relay pseudo-interface is an architectural abstraction used to describe how AMT works. for this doc, the easiest way to picture it is as an interface to one single gateway. the encapsulation, decapsulation, and other AMT-specific stuff happens "within" the pseudo-interface, while forwarding and replication happen outside of it 💜
there's also another way to think about it: you can treat the pseudo-interface like a non-broadcast multi-access (NBMA) network interface, where the link layer is the unicast-only network that AMT messages get exchanged over with gateways. each gateway is basically a logical NBMA link on that interface. in this model, group membership tracking, replication, and forwarding all happen inside the pseudo-interface 🦋
this document doesn't pick one specific architecture, so a relay developer can choose how to implement and spread out the protocol functionality, whatever takes advantage of their existing relay platform services and architecture ✨
also, in this document, "relay" can be used as a general term for an entity running the relay protocol, a relay pseudo-interface, or a relay device with one or more network interfaces that have multicast connectivity to a native multicast infrastructure, zero or more interfaces connected to a unicast internetwork, and one or more relay pseudo-interfaces 🎀
4.1.3.2. Use Cases
okay so the use cases for relay functionality include the following 🍓
- Multicast Router: A multicast router that runs AMT on a downstream interface to give gateways access to multicast traffic. A "relay router" uses a multicast routing protocol (e.g., PIM-SM [RFC4601]) to build a forwarding path for multicast traffic by sending join and prune messages to neighboring routers, so it can join or leave multicast distribution trees for a given SSM source or ASM rendezvous point 🌈
- IGMP/MLD Proxy Router: An IGMP/MLD proxy that runs AMT on a downstream interface and host-mode IGMPv3/MLDv2 on an upstream interface. this "relay proxy" sends group membership reports to a local, multicast-enabled router so it can join and leave specific SSM or ASM groups 👑
4.1.4. Deployment
the AMT protocol uses a relay deployment model that relies on anycast addressing [RFC1546] [RFC4291] to pair gateways with relays 🧚♀️✨
here's how it works: one or more relays advertise a route for the same IP address prefix. to find a relay to talk to, a gateway sends a message to an anycast IP address inside that prefix. that message gets routed to the topologically nearest relay that has advertised the prefix. the relay that gets the message responds by sending its unicast address back to the gateway. the gateway then uses that address as the destination for any messages it sends to the relay afterward 💖
using anycast gets you these perks 💅
- Relays can be deployed at multiple locations within a single multicast-enabled network. Relays might be installed "near" gateways to reduce bandwidth requirements and latency, and to limit how many gateways a single relay has to service 🌸
- Relays can be added or removed at any time, which allows staged deployment, scaling, and hot-swapping. the relay discovery process will always return the nearest operational relay 🦋
- Relays can take themselves offline when they run out of resources needed to service more gateways. Existing gateway connections may be preserved, but new gateway requests would be routed to the next-nearest relay 🫶
4.1.4.1. Public versus Private
ideally, the AMT protocol would be a universal solution for connecting receivers to multicast sources. that would mean any gateway could reach any globally advertised multicast source through publicly accessible, widely deployed relays 🌍 unfortunately, today's Internet doesn't allow that yet, because lots of relays won't have native multicast access to sources, even if those sources are globally reachable over unicast 😭
so a provider may deploy relays within their own source network to allow multicast distribution inside that network. gateways that use these relays must use a provider-specific relay discovery mechanism or a private anycast address to reach them 🔐
4.1.4.2. Congestion Considerations
AMT relies on UDP to provide best-effort delivery of multicast data to gateways. Neither AMT nor UDP provides the congestion control mechanisms required to regulate the flow of data messages across a network. congestion remediation might come from multicast receiver applications through group selection or upstream reporting mechanisms, but there's no way to make sure those mechanisms are actually used 👀 to keep congestion under control across a network or the wider Internet, AMT service providers are expected to deploy AMT relays near the provider's network border and its interface with edge routers. the provider must limit relay address advertisements to those edges, so distant gateways can't reach a relay and generate flows that consume or exceed the capacity of the links in between 🚧
4.1.5. Discovery
to run the gateway side of the protocol, a gateway needs a unicast IP address of an operational relay 🎀 that address can be obtained in a few ways. it can be statically assigned, or dynamically chosen through some form of relay discovery process.
like we covered in the previous section, the AMT protocol has 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 💜
when describing the discovery process, the AMT protocol uses these terms 🧚
- Relay Discovery Address Prefix: The anycast address prefix used to route discovery messages to a relay.
- Relay Discovery Address: The anycast destination address used when sending discovery messages.
- Relay Address: The unicast IP address obtained as a result of the discovery process.
4.1.5.1. Relay Discovery Address Selection
choosing an anycast Relay Discovery Address may depend on the source, since a relay found through relay discovery must have multicast connectivity to the desired source 🦋
same deal with a unicast Relay Address: it may depend on the source, because a relay that a gateway contacts to supply multicast traffic must have native multicast connectivity to the traffic source ✨
ways to do source-specific or group-specific relay selection are very implementation dependent, and this document doesn't go further into them. possible approaches include static lookup tables, DNS-based queries, or a service interface that accepts join requests on (S,G,relay-discovery-address) or (S,G,relay-address) tuples 🌸
4.1.5.2. Relay Discovery Address Prefix
IANA has assigned IPv4 and IPv6 address prefixes for advertising and discovering publicly accessible relays 🌈
a Relay Discovery Address is built from an address prefix by setting the low-order octet of the prefix address to 1 (for both IPv4 and IPv6). all remaining addresses within each prefix are reserved for future use 🔒
public relays must advertise a route to the address prefix (e.g., via BGP [RFC4271]) and configure an interface to respond to the Relay Discovery Address 💅
the discovery address prefixes are described in Section 7 🫶
4.2. General Operation
4.2.1. Message Sequences
the AMT protocol defines these messages for control and encapsulation. they get exchanged as UDP/IP datagrams, one message per datagram 📩
- Relay Discovery: Sent by gateways to solicit a Relay Advertisement from any relay. Used to find a relay to communicate with.
- Relay Advertisement: Sent by relays as a response to a Relay Discovery message. Used to deliver a Relay Address to a gateway.
- Request: Sent by gateways to solicit a Membership Query message from a relay.
- Membership Query: Sent by relays as a response to a Request message. Used to deliver an encapsulated IGMPv3 or MLDv2 query message to the gateway.
- Membership Update: Sent by gateways to deliver an encapsulated IGMP or MLD report/leave/done message to a relay.
- Multicast Data: Sent by relays to deliver an encapsulated IP multicast datagram or datagram fragment to a gateway.
- Teardown: Sent by gateways to stop the delivery of Multicast Data messages requested in an earlier Membership Update message.
the next sections explain how these messages get exchanged to run the protocol ✨💖
4.2.1.1. Relay Discovery Sequence
okay so this is the handshake where a gateway goes hunting for a relay 🦋✨
Gateway Relay
------- -----
: :
| |
[1] |Relay Discovery |
|------------------->|
| |
| Relay Advertisement| [2]
|<-------------------|
[3] | |
: :Figure 6: AMT Relay Discovery Sequence 💅
so the gateway sends a Relay Discovery message, the relay sends back a Relay Advertisement, and then the gateway checks everything matches before it starts talking. it's giving very polite group chat etiquette 🫶
Here's how the Relay Discovery and Relay Advertisement messages work together to find a relay to chat with:
- The gateway sends a Relay Discovery message with a random nonce to the Relay Discovery Address. If the Relay Discovery Address is an anycast address, the message gets routed to the topologically nearest network node that advertises that address. 📍
- The node that receives the Relay Discovery message sends a Relay Advertisement message back to whoever sent the Relay Discovery message. The Relay Advertisement carries a copy of the nonce from the Relay Discovery message and the unicast IP address of a relay. 🌸
- When the gateway gets the Relay Advertisement, it checks that the nonce matches the one it sent in the Relay Discovery message. If it matches, the gateway uses the Relay Address from the Relay Advertisement as the destination address for later AMT messages. 🎀
Note that the responder doesn't have to be a relay 👀 The responder can get a Relay Address some other way and send it back in the Relay Advertisement. (So basically, the responder is a load-balancer or a broker. iykyk 🧚)
4.2.1.2. Membership Update Sequence
ngl this section is where AMT is very different from normal IGMP and MLD 🙈 Normally, an IGMP/MLD router that's acting as a querier sends query messages on a network interface to build and refresh group membership state for the network it's connected to. Those queries get multicast to all the IGMP/MLD-enabled hosts on the network, and every host answers by multicasting report messages that describe what it's currently receiving. Main character energy 👑
AMT doesn't work like that, though 😭 A relay isn't allowed to send unsolicited query messages to gateways. The set of active gateways might be unknown to the relay, and it could be really big. So instead, AMT requires each gateway to periodically send a message to a relay asking for a query response. The gateway does this by sending a Request message to a relay. The relay answers with a Membership Query message. That Membership Query carries an encapsulated query, which the IGMP or MLD implementation on the gateway processes to produce a membership/listener report. ✨
Every time the gateway gets a Membership Query message, it starts a timer. When that timer expires, it kicks off a brand new Request->Membership Query message exchange. This timer-driven loop is there to copy how an IGMP/MLD router sends a periodic query. The query cycle can keep going forever once the initial Request message gets sent 🔁
A membership update happens whenever an IGMP or MLD report, leave, or done message gets passed to the gateway pseudo-interface. Those messages might come from the query processing we just talked about, or from a receiver interacting with the IGMP/MLD service interface. Each report gets encapsulated and sent to the relay, but only after the gateway has successfully set up communication with the relay through a Request and Membership Query exchange. 🫶 If a report shows up at the pseudo-interface before the gateway has received a Membership Query from the relay, the gateway may discard the report or queue it up to send after a Membership Query arrives. After that, any later IGMP/MLD report, leave, or done messages that reach the pseudo-interface get encapsulated and sent to the relay right away. 💜
Here's the full diagram for the IGMPv3/MLDv2 example 👇
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)
| | |---------->()
: : :Figure 7: Membership Update Sequence (IGMPv3/MLDv2 Example) 🎀
This is the part where the steps go in order. Here's how the Request, Membership Query, and Membership Update messages work together to share the current group membership state, or any changes to it 💖
- A gateway sends a Request message to the relay. It has a random nonce and a flag that says whether the relay should send back an IGMPv3 or MLDv2 General Query. 🌷
- When the relay gets a Request message, it makes a message authentication code (MAC). Usually that means hashing the message's source IP address, source UDP port, request nonce, and a private secret. Then the relay sends a Membership Query message to the gateway. That message has the request nonce, the MAC, and an IGMPv3 or MLDv2 General Query. 🔐
- When the gateway gets a Membership Query message, it checks that the request nonce matches the one from the last Request. If it does, the gateway saves the request nonce and MAC so it can use them for later Membership Update messages. Then it starts a timer. When that timer expires, it sends a new Request message. The gateway also pulls out the encapsulated General Query so the IGMP or MLD protocol can process it. The timer duration comes from the relay, specified in the Querier's Query Interval Code (QQIC) field in the IGMPv3 or MLDv2 General Query. The QQIC field is defined in Section 4.1.7 of [RFC3376] and Section 5.1.9 of [RFC3810]). ⏰
- The gateway's IGMP or MLD implementation processes the General Query to produce a current-state report. 🧠
- When an IGMP or MLD report gets passed to the pseudo-interface, the gateway encapsulates it in a Membership Update message and sends it to the relay. The request nonce and MAC fields in the Membership Update get the values from the last Membership Query message received for the matching group membership protocol (IGMPv3 or MLDv2). 📦
- When the relay gets a Membership Update message, it computes a MAC from the message's source IP address, source UDP port, request nonce, and a private secret. The relay accepts the Membership Update if the received MAC matches the computed MAC. Otherwise, the message gets ignored. If the message is accepted, the relay may go ahead and allocate, refresh, or modify tunnel state. That includes any group membership, routing, and forwarding state changes, plus any upstream protocol requests needed to make the state change happen. The diagram shows two scenarios:
- A. The gateway hasn't reported any group subscriptions before, and this report doesn't contain any group subscriptions, so the relay doesn't do anything. 😴
- B. The gateway has reported a group subscription before, so this current-state report lists all current subscriptions. The relay responds by refreshing tunnel or group state and resetting any related timers. 🔄
- A receiver tells the gateway that it wants to join (allow) or leave (block) certain multicast traffic. This is usually done through some form of IGMP/MLD service interface (as described in Section 2 of [RFC3376] and Section 3 of [RFC3810]). The IGMP/MLD protocol then generates an IGMP or MLD state-change message. 🙋♀️
- When an IGMP or MLD report/leave/done message gets passed to the pseudo-interface, the gateway encapsulates it in a Membership Update message and sends it to the relay. The request nonce and MAC fields in the Membership Update get the values from the last Membership Query message received for the matching group membership protocol (IGMP or MLD). 💌
The IGMP and MLD protocols can generate multiple messages for robustness against packet loss. Each one of these has to be encapsulated in its own new Membership Update message and sent to the relay 🛡️ The Querier's Robustness Variable (QRV) field in the last IGMP/MLD query delivered to the IGMP/MLD protocol is usually what sets how many repetitions happen. In other words, the host takes the QRV value as its own Robustness Variable value. The QRV field is defined in Section 4.1.6 of [RFC3376] and Section 5.1.8 of [RFC3810]. ✨
- Okay so when the relay gets a Membership Update, it runs the MAC math again 🔐. It uses the message's source IP address, source UDP port, request nonce, and its own private secret. If the MAC it computes matches the one that came in, the message is accepted. If not, it gets ignored, no drama 🙅♀️. Once accepted, the relay processes the encapsulated IGMP/MLD and allocates, modifies, or deletes tunnel state as needed 🦋. That includes group membership, routing, and forwarding state changes, plus any upstream protocol requests needed to make the state change happen ✨. The diagram shows two scenarios:
- A. The gateway wishes to add a group subscription. 🌸
- B. The gateway wishes to delete a previously reported group subscription. 💅
- Multicast datagrams come from a source and travel through the native multicast infrastructure to the relay 🌈. When the relay gets a multicast IP datagram with a source and destination address that a gateway has shown interest in (through a Membership Update message), it wraps the datagram up in a Multicast Data message 🎀. Then it sends that to the gateway, using the source IP address and UDP port carried by the Membership Update message as the destination address 📬.
- When the gateway gets a Multicast Data message, it pulls the multicast packet out and passes it along to the right receivers 🫶.
- When the query timer runs out, the gateway sends a fresh Request message to the relay to kick off a new membership update cycle 🔁.
The MAC-based source-authentication mechanism above is a simple defense against bad actors trying to drain relay resources through source-address spoofing 🛡️. Flooding a relay with spoofed Request or Membership Update messages can eat up computational resources and network bandwidth, but it won't cause any state to be allocated 🙌. Why? The Request message is stateless, and spoofed Membership Update messages fail source authentication and get rejected by the relay 💀.
A relay will only allocate new tunnel state if the IGMP/MLD report carried by the Membership Update message creates one or more group subscriptions 🧚.
A relay deallocates tunnel state after one of these events happens: the gateway sends a Membership Update message with a report that deletes all remaining group subscriptions, the IGMP/MLD state expires (because the gateway stopped refreshing it), or the relay receives a valid Teardown message from the gateway (see Section 4.2.1.3) 🧹.
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 👑.
4.2.1.3. Teardown Sequence
A gateway sends a Teardown message to a relay to ask it to stop delivering Multicast Data messages to a tunnel endpoint that was created by an earlier Membership Update message 🛑. This message is meant to be used after a gateway address change (see Section 4.2.2.1), so that undeliverable or duplicate Multicast Data messages stop being sent 🍓. Gateway support for the Teardown message is RECOMMENDED 💖. Gateways aren't required to send them, and they can instead rely on group membership expiring on the relay ⏳.
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) |<======================| |
| ()<-----------------| | |
| | | |
---------------------:-----------------------:---------------------
| |
: :Figure 8: Teardown Message Sequence (IGMPv3/MLDv2 Example) 📊
The following sequence shows how the Membership Query and Teardown messages work together to detect an address change and stop Multicast Data messages going to an address 🕵️♀️:
- A gateway sends a Request message containing a random nonce to the relay 🎲.
- The relay sends a Membership Query message to the gateway. It contains the source IP address (gADDR) and source UDP port (gPORT) values from the Request message 📇. These values get used to identify the tunnel, should a subsequent Membership Update message create one.
- When the gateway gets a Membership Query message carrying the gateway address fields, it compares the gateway IP address and UDP port number values with the ones from the previous Membership Query (if there is one) 👀. If they don't match, that means the Request message reached the relay with a different source address than the one it sent before. At this point in the sequence, though, no change in source address or port has happened yet 🤔.
- The gateway sends a new Request message to the relay. But this one arrives at the relay with a different source address than the previous Request, because of some change in network interface, address assignment, network topology, or NAT mapping 🌪️.
- The relay responds again with a Membership Query message to the gateway. It contains the new source IP address (gADDR') and source UDP port (gPORT') values from the Request message 📮.
- When the gateway gets that Membership Query message, it compares the gateway address and port number values against the ones in the previous Membership Query message 🔍.
- If the reported address or port has changed, the gateway sends a Teardown message to the relay. That message contains the request nonce, MAC, gateway IP address, and gateway port number from the earlier Membership Query message 🧾. The gateway may send the Teardown message several times. The number of repetitions is governed by the Querier's Robustness Variable (QRV) value in the IGMPv3/MLDv2 General Query carried by the original Membership Query (see Section 4.1.6 of [RFC3376] and Section 5.1.8 of [RFC3810]) 🔁. The gateway keeps processing the new Membership Query message as usual 💜.
- When the relay gets a Teardown message, it computes a MAC from the message source IP address, source UDP port, request nonce, and a private secret 🔐. The relay accepts the Teardown message if the received MAC matches the computed MAC. Otherwise, the message is ignored 🙈. If it's accepted, the relay makes any group membership, routing, and forwarding state changes needed to stop Multicast Data messages going to that address 🧹✨.
4.2.1.4. Timeout and Retransmission
The AMT protocol doesn't set any requirements on what a gateway should do if it doesn't get a response from a relay 🤷♀️. A gateway implementation can wait forever for a response, set a time limit on how long to wait, retransmit messages once that time limit is reached, cap the number of retransmissions, or simply report an error ⏰.
For example, a gateway may retransmit a Request message if it doesn't receive a Membership Query or the expected Multicast Data messages within some time period 🔄. If the gateway gets no response to a Request after several retransmissions or within some maximum period of time, it may go back into the relay discovery phase to look for a new relay 🗺️. This topic gets covered in more detail in Section 5.2 🫶.
4.2.2. Tunneling ✨
okay so from a relay's point of view, an AMT "tunnel" is identified by the IP address and UDP port pair it uses as the destination for sending encapsulated multicast IP datagrams to a gateway. in this doc we call that address the tunnel endpoint address 🦋
a gateway sends a Membership Update message to a relay to add or remove group subscriptions on a tunnel endpoint. the tunnel endpoint is identified by the source IP address and source UDP port the Membership Update carries when it arrives at a relay. (this address may be different from the one it had when it left the gateway, because of network address translation 👀)
one gateway host can send Membership Update messages from a few different source addresses or ports, and each unique combo is its own tunnel endpoint. a single gateway can totally create and accept traffic on multiple tunnel endpoints, e.g., it might use separate ports for IPv4/IGMP and IPv6/MLD 💅
a tunnel is "created" when a gateway sends a Membership Update with an IGMP or MLD membership report that makes one or more group subscriptions, when there were none for that tunnel endpoint address before. iconic 🎀
a tunnel stops existing once all of its group subscriptions for a tunnel endpoint get deleted. that can happen in these ways:
- 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.
- the gateway sends a Teardown message to the relay that makes it delete any and all subscriptions bound to the tunnel endpoint.
- the relay stops hearing updates from the gateway until the per-group or per-tunnel timers expire, which makes the relay delete the subscriptions.
ngl this is the part that makes AMT so cool 🌈 the tunneling approach basically takes a unicast-only internetwork and turns it into an NBMA link layer, so multicast traffic can be delivered over it. each relay, plus all the gateways using that relay, can be thought of as sitting on a separate logical NBMA link, where the "link layer" address is the UDP/IP address-port pair given by the Membership Update message. main character energy for sure 👑
4.2.2.1. Address Roaming
okay this one's a little drama 🙈 as we said above, every time a relay gets a Membership Update from a new source address-port pair, the group subscriptions in that message apply to the tunnel endpoint at that address.
this can cause problems for a gateway if the address its messages carry changes unexpectedly. the relay might then send duplicate, undeliverable, or unrequested traffic back toward the gateway or some device in between. that can cause congestion and cause issues for the gateway, its network, or the multicast receivers, and in some cases a NAT, router, or gateway host might get a huge pile of ICMP traffic sent back toward the relay 😭
there are a few situations where the address in a gateway's messages can change without the gateway knowing, for example when:
- the message comes from a different interface on a gateway that has multiple interfaces.
- the DHCP assignment for a gateway interface changes.
- the gateway roams to a different wireless network.
- the address mapping applied by a network-translation device (NAT) in between changes because the mapping expired or because of routing changes in a multihomed network.
if the address changes between a Request message and the Membership Update messages that follow, the relay will just ignore any Membership Update from the new address, because MAC authentication will fail (see Section 4.2.1.2). the relay might keep sending the traffic it was already asked for, but no duplication happens. the chance of duplicate traffic doesn't show up until a Request message comes in from the new address 🫶
the protocol gives a gateway a way to notice an address change and explicitly ask the relay to stop sending traffic to the old address. this uses the Membership Query and Teardown messages and is described in Section 4.2.1.3 ✨
4.2.2.2. Network Address Translation
so the messages a gateway sends to a relay might go through network address translation (NAT). the source IP address and UDP port in an IP packet from the gateway can get changed several times before the packet reaches the relay. in the most restrictive form of NAT, the NAT device makes a brand new mapping for every combo of source and destination IP address and UDP port. in that case, two-way communication only works if outgoing packets go to the source address and port from the last incoming packet 🌸
Membership Update Membership Update
src: iADDR:iPORT src: eADDR:ePORT
dst: rADDR:rPORT dst: rADDR:rPORT
+---------+
| NAT |
+---------+ +-----------+ +---------+
| |---------->| |--------->| |
| Gateway | | Mapping | | Relay |
| |<----------| |<---------| |
+---------+ +-----------+ +---------+
| |
+---------+
Multicast Data Multicast Data
src: rADDR:rPORT src: rADDR:rPORT
dst: iADDR:iPORT dst: eADDR:ePORT
Figure 9: Network Address Translation in AMTAMT handles automatic NAT traversal by using the source IP address and UDP port from the Membership Update, as the relay received it, as the destination for any Multicast Data messages the relay sends back because of it. clever, right? 🧚
the NAT mapping created by a Membership Update will eventually expire unless a passing message refreshes it. that refresh happens each time the gateway does the periodic update needed to refresh group state within the relay (see Section 4.2.1.2) 💜
4.2.2.3. UDP Encapsulation
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
Figure 10: AMT Encapsulationthe IGMP and MLD messages used in AMT get sent as complete IP datagrams. those datagrams are wrapped up in AMT messages, which get sent over UDP. same deal for multicast traffic: every multicast IP datagram (or datagram fragment) that shows up at the relay gets wrapped in an AMT message and sent over UDP to one or more gateways 🎀
the IP protocol of the wrapped packets doesn't have to match the IP protocol used to send the AMT messages. AMT messages sent over IPv4 can carry IPv6/MLD packets, and AMT messages sent over IPv6 can carry IPv4/IGMP packets 🌈
now the UDP Checksum field needs special handling 🙈 the big worry is how expensive it is to compute a checksum on every replicated multicast packet after it's been wrapped up for a gateway. lots of routing and forwarding platforms can't compute checksums on UDP-encapsulated packets, because they might not have access to the whole datagram.
so to keep the relay from taking on an unfair burden, the protocol specifically allows zero-valued UDP checksums on the Multicast Data messages. this is no problem for UDP over IPv4, since the UDP Checksum field can be set to zero. it IS a problem for UDP over IPv6, though, because that protocol requires a valid, non-zero checksum in UDP datagrams [RFC2460]. messages sent over IPv6 with a UDP checksum of zero might never reach the gateway. this is a well-known issue for UDP-based tunneling protocols and it's described in [RFC6936]. a recommended solution is described in [RFC6935] 💅
4.2.2.4. UDP Fragmentation
okay so naively wrapping multicast IP datagrams inside AMT data messages can produce UDP datagrams that need fragmentation if they get bigger than the MTU of the network path between the relay and a gateway. a lot of multicast apps, especially media streaming, are built to send each independent data sample in its own packet, with no fragmentation, so that some number of complete samples still arrive even when packets get lost. to prevent or reduce unwanted fragmentation, AMT describes specific procedures for handling multicast datagrams whose encapsulation might go over the Path MTU. those procedures are in Section 5.3.3.6 🦋
5. Protocol Description 💜
this section gives a normative description of the AMT protocol. it's the official rulebook, bestie 📜
5.1. Protocol Messages
the AMT protocol defines seven message types for control and encapsulation. they get these names and numeric identifiers:
+--------------+---------------------+
| Message Type | Message Name |
+--------------+---------------------+
| 1 | Relay Discovery |
| 2 | Relay Advertisement |
| 3 | Request |
| 4 | Membership Query |
| 5 | Membership Update |
| 6 | Multicast Data |
| 7 | Teardown |
+--------------+---------------------+these messages get exchanged as IPv4 or IPv6 UDP datagrams 🌸
5.1.1. Relay Discovery ✨
okay bestie, a Relay Discovery message is the gateway basically going "hiii relay, are you out there? 🥺" and it's used to solicit (fancy word for ask for) a response from a relay in the form of a Relay Advertisement message 💌
The UDP/IP datagram carrying this message MUST carry a valid, non-zero UDP checksum 🔒, and it has these IP address and UDP port values:
- Source IP Address - the IP address of the gateway interface where the gateway will listen for a relay response 👀. Note: this field may get changed by network address translation before it arrives at the relay.
- Source UDP Port - the UDP port number where the gateway will listen for a relay response 🎀. Note: this field may get changed by network address translation before it arrives at the relay.
- Destination IP Address - an anycast or unicast IP address, i.e., the Relay Discovery Address advertised by a relay 📡.
- Destination UDP Port - the AMT port number (see Section 7.2) 🦋.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 11: Relay Discovery Message Format 🌸
5.1.1.1. Version (V)
The protocol version number for this message is 0. Easy peasy 🧚
5.1.1.2. Type
The type number for this message is 1 💜
5.1.1.3. Reserved
These reserved bits MUST be set to zero by the gateway and ignored by the relay. Gateway sets them to zero, relay just ignores them, no drama 🫶
5.1.1.4. Discovery Nonce
This is a 32-bit random value that the gateway generates and the relay echoes back in a Relay Advertisement message. The gateway uses it to match up Relay Advertisement messages with their Relay Discovery messages, which is lowkey iconic 🔥. How the nonce gets generated is described in Section 5.2.3.4.5 ✨.
5.1.2. Relay Advertisement
okay now the Relay Advertisement is the relay's reply 💖. It's used to hand a gateway a unicast IP address of a relay, and a relay sends it to a gateway whenever it gets a Relay Discovery message from that gateway 📬.
The UDP/IP datagram carrying this message MUST carry a valid, non-zero UDP checksum 🔒, with these values:
- Source IP Address - the destination IP address carried by the Relay Discovery message (i.e., the Relay Discovery Address advertised by the relay) 🌈.
- Source UDP Port - the destination UDP port carried by the Relay Discovery message (i.e., the AMT port number) 🍓.
- Destination IP Address - the source IP address carried by the Relay Discovery message. Note: this field may get changed by network address translation before it arrives at the gateway 🙈.
- Destination UDP Port - the source UDP port carried by the Relay Discovery message. Note: this field may get changed by network address translation before it arrives at the gateway 🙈.
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) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 12: Relay Advertisement Message Format 🎀
5.1.2.1. Version (V)
The protocol version number for this message is 0 ✨
5.1.2.2. Type
The type number for this message is 2 💅
5.1.2.3. Reserved
These reserved bits MUST be set to zero by the relay and ignored by the gateway. Relay zeroes them, gateway ignores them, periodt 💀
5.1.2.4. Discovery Nonce
This is a 32-bit value copied from the Discovery Nonce field (Section 5.1.1.4) in the Relay Discovery message. The gateway uses it to match a Relay Advertisement to the Relay Discovery message it belongs to 🧚.
5.1.2.5. Relay Address
This is the unicast IPv4 or IPv6 address of the relay 🌸. The gateway figures out the address family from the length of the UDP datagram carrying the Relay Advertisement message, so it's basically length - 8 = 4 (IPv4) or 16 (IPv6) 🧮. The relay sends back an IP address for the same protocol used in the Relay Discovery message, meaning an IPv4 address for an IPv4 Relay Discovery Address or an IPv6 address for an IPv6 Relay Discovery Address 🌈.
5.1.3. Request
A gateway sends a Request message to a relay when it wants to solicit a Membership Query response 💌.
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. 🤝
The UDP/IP datagram carrying this message MUST carry a valid, non-zero UDP checksum 🔒, with these values:
- Source IP Address - the IP address of the gateway interface where the gateway will listen for a response from the relay 👀. Note: this field may get changed by network address translation before it arrives at the relay.
- Source UDP Port - the UDP port number where the gateway will listen for a response from the relay 🎀. Note: this field may get changed by network address translation before it arrives at the relay.
- Destination IP Address - the unicast IP address of the relay 📡.
- Destination UDP Port - the AMT port number 🦋.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 13: Request Message Format 🌈
5.1.3.1. Version (V)
The protocol version number for this message is 0 💖
5.1.3.2. Type
The type number for this message is 3 ✨
5.1.3.3. Reserved
These reserved bits MUST be set to zero by the gateway and ignored by the relay 🫶
5.1.3.4. P Flag
The P flag is how the gateway tells the relay which group membership protocol it wants used in the Membership Query response 🔥:
Value Meaning
0 The relay MUST respond with a Membership Query message that
contains an IPv4 packet carrying an IGMPv3 General Query
message.
1 The relay MUST respond with a Membership Query message that
contains an IPv6 packet carrying an MLDv2 General Query
message.5.1.3.5. Request Nonce
This is a 32-bit random value that the gateway generates and the relay echoes back in a Membership Query message 🎀. The relay uses it to compute the Response MAC value, and the gateway uses it to match Membership Query messages with Request messages 🧠. How the nonce gets generated is described in Section 5.2.3.5.6 💅.
5.1.4. Membership Query
A relay sends a Membership Query message to a gateway to solicit a Membership Update response, but only after it gets a Request message from that gateway 🌸.
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. 🤝
The UDP/IP datagram carrying this message MUST carry a valid, non-zero UDP checksum 🔒, with these values:
- Source IP Address - the destination IP address carried by the Request message (i.e., the unicast IP address of the relay) 🌈.
- Source UDP Port - the destination UDP port carried by the Request message (i.e., the AMT port number) 🍓.
- Destination IP Address - the source IP address carried by the Request message. Note: this field may get changed by network address translation before it arrives at the gateway 🙈.
- Destination UDP Port - the source UDP port carried by the Request message. Note: this field may get changed by network address translation before it arrives at the gateway 🙈.
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) |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 14: Membership Query Message Format 🦋
5.1.4.1. Version (V)
The protocol version number for this message is 0 🧚
5.1.4.2. Type
The type number for this message is 4 💜
5.1.4.3. Reserved
These reserved bits MUST be set to zero by the relay and ignored by the gateway 🫶
5.1.4.4. Limit (L) Flag
This is a 1-bit flag. When it's set to 1, it tells the gateway that the relay is not accepting Membership Update messages from new gateway tunnel endpoints, and the relay will ignore any that show up anyway 🚫. A value of 0 has no special meaning at all. In that case the relay may or may not be accepting Membership Update messages from new gateway tunnel endpoints 🤷♀️. Before a gateway tries to create new group subscription state on the relay, it checks this flag to decide 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. 👑
5.1.4.5. Gateway Address (G) Flag ✨
okay so this is a 1-bit flag 🦋 It's set to 0 when the message does NOT carry the Gateway Port Number and Gateway IP Address fields, and set to 1 when it does.
A relay that supports the optional teardown procedure (see Section 5.3.3.5) SHOULD set this flag and also fill in the Gateway Port Number and Gateway IP Address field values. If a relay sets this flag, it MUST also include the Gateway Port Number and Gateway IP Address fields in the message. A gateway that does not support the optional teardown procedure (see Section 5.2.3.7) MAY ignore this flag and the Gateway Address fields if they're present. 💅
5.1.4.6. Response MAC 🔐
This is a 48-bit source authentication value that the relay generates as described in Section 5.3.5. The gateway echoes it back in later Membership Update messages so the relay can check that the sender of a Membership Update was the intended receiver of a Membership Query the relay sent. Main character security energy 😤
5.1.4.7. Request Nonce 🎀
This is a 32-bit value copied from the Request Nonce field (Section 5.1.3.5) in a Request message. The relay includes this value in the Response MAC computation. The gateway echoes it in later Membership Update messages, and it also uses it to match a Membership Query to a Request message. It's like a little matching bracelet 💖
5.1.4.8. Encapsulated General Query Message 🧚
This is an IP-encapsulated IGMP or MLD message generated by the relay. The field contains one of the following IP datagrams:
IPv4:IGMPv3 Membership Query
IPv6:MLDv2 Listener QueryThe source address carried by the query message should be set as described in Section 5.3.3.3.
The Querier's Query Interval Code (QQIC) field in the General Query is how a relay tells a gateway what time offset to use when scheduling a new three-way handshake to refresh the group membership state within the relay (current time + Query Interval). The QQIC field is defined in Section 4.1.7 of [RFC3376] and Section 5.1.9 of [RFC3810]. 🕰️
The Querier's Robustness Variable (QRV) field in the General Query is how a relay specifies 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. The QRV field is defined in Section 4.1.6 of [RFC3376] and Section 5.1.8 of [RFC3810]. 🔁
5.1.4.9. Gateway Address Fields 🌸
The Gateway Port Number and Gateway Address fields are present in the Membership Query message if, and only if, the G flag is set.
A gateway doesn't need to parse the encapsulated IP datagram to find where these fields sit within the UDP datagram carrying the Membership Query. If the G flag is set, the gateway can simply subtract the total length of the fields (18 bytes) from the total length of the UDP datagram to get the offset. Big brain math, no cap 🧠
5.1.4.9.1. Gateway Port Number 🚪
This is a 16-bit UDP port number holding a UDP port value.
The relay sets this field to the value of the UDP source port of the Request message that triggered the Query message.
5.1.4.9.2. Gateway IP Address 🌐
This is a 16-byte IP address that, combined with the value in the Gateway Port Number field, forms the gateway endpoint address the relay uses to identify the tunnel instance (if any) created by a subsequent Membership Update message. The 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 [RFC4291]). This address must match the one the relay used to compute the value stored in the Response MAC field. It has to be consistent, bestie 🫶
5.1.5. Membership Update 💌
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 a Membership Query message. The gateway encapsulates the IGMP or MLD message as an IP datagram inside a Membership Update message and sends it to the relay, which may (see below) decapsulate and process it to update group membership and forwarding state.
A gateway cannot send a Membership Update until it has received a Membership Query from a relay, because it has to copy the Request Nonce and Response MAC values from that Membership Query into any Membership Update messages it sends back to that relay. The relay uses these values to verify that the sender of the Membership Update was the recipient of the Membership Query those values came from. 🕵️♀️
Successful delivery of this message to the relay marks the start of the final stage of the three-way handshake. That stage concludes when the relay successfully verifies that the sender of the Membership Update was the recipient of an earlier Membership Query. At that point, the relay may go ahead and process the encapsulated IGMP or MLD message to create or update group membership and forwarding state on behalf of the gateway. Finally, the handshake is done 🎉
The UDP/IP datagram containing this message MUST carry a valid, non-zero UDP checksum, plus the following IP address and UDP port values:
- Source IP Address - The IP address of the gateway interface on which the gateway will listen for Multicast Data messages from the relay. It must be the same address used to send the initial Request message, or the message will be ignored. Note: This field's value may be changed by network address translation before it arrives at the relay.
- Source UDP Port - The UDP port number on which the gateway will listen for Multicast Data messages from the relay. It must be the same port used to send the initial Request message, or the message will be ignored. Note: This field's value may be changed by network address translation before it arrives at the relay.
- Destination IP Address - The unicast IP address of the relay.
- Destination UDP Port - The AMT port number.
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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Membership Update Message Format5.1.5.1. Version (V) 🔢
The protocol version number for this message is 0.
5.1.5.2. Type 🏷️
The type number for this message is 5.
5.1.5.3. Reserved 🫧
Reserved bits that MUST be set to zero by the gateway and ignored by the relay.
5.1.5.4. Response MAC 🔐
This is a 48-bit value copied from the Response MAC field (Section 5.1.4.6) in a Membership Query message. The relay uses it to perform source authentication.
5.1.5.5. Request Nonce 🎀
This is a 32-bit value copied from the Request Nonce field in a Request or Membership Query message. The relay uses it to perform source authentication.
5.1.5.6. Encapsulated Group Membership Update Message 💫
This is an IP-encapsulated IGMP or MLD message produced by the host-mode IGMP or MLD protocol running on a gateway pseudo-interface. The field contains one of the following IP datagrams:
IPv4:IGMPv2 Membership Report
IPv4:IGMPv2 Leave Group
IPv4:IGMPv3 Membership Report
IPv6:MLDv1 Multicast Listener Report
IPv6:MLDv1 Multicast Listener Done
IPv6:MLDv2 Multicast Listener ReportThe source address carried by the message should be set as described in Section 5.2.1.
5.1.6. Multicast Data 🎶
A relay sends a Multicast Data message to deliver a multicast IP datagram or datagram fragment to a gateway.
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 Section 4.2.2.3). Zero is allowed on IPv4, but IPv6 really wants a checksum. 💅
The UDP/IP datagram containing this message MUST carry the following IP address and UDP port values:
- Source IP Address - The unicast IP address of the relay.
- Source UDP Port - The AMT port number.
- Destination IP Address - A tunnel endpoint IP address, i.e., the source IP address carried by the Membership Update message that a gateway sent to show it wants the multicast packet. Note: This field's value may be changed by network address translation before it arrives at the gateway.
- Destination UDP Port - A tunnel endpoint UDP port, i.e., the source UDP port carried by the Membership Update message that a gateway sent to show it wants the multicast packet. Note: This field's value may be changed by network address translation before it arrives at the gateway.
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 ~
| |
+ - - - - - - - - - - - - - - - - - - - - - - - -+
| : : : :
+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - - - - - - - - - -
Figure 16: Multicast Data Message Format5.1.6.1. Version (V) 🔢
The protocol version number for this message is 0.
5.1.6.2. Type 🏷️
The type number for this message is 6.
5.1.6.3. Reserved 🫧
Reserved bits that MUST be set to zero by the relay and ignored by the gateway.
5.1.6.4. IP Multicast Data 📦
This is a complete IPv4 or IPv6 multicast datagram or datagram fragment.
5.1.7. Teardown 🧹✨
okay so a gateway sends a Teardown message to a relay to say "bestie, please stop sending me Multicast Data for that tunnel endpoint" 💅 The tunnel was set up earlier by a Membership Update message. The gateway sends this when it notices that a Request message it sent to the relay has a different address than the last Request message did 👀 It checks the Gateway IP Address and Gateway Port Number fields in the Membership Query message to spot these address changes 🔍
To stay backwards compatible with the early AMT implementations 🕰️, supporting this message and its procedures is totally OPTIONAL 🫶 Gateways don't have to send it, and relays don't have to act on it. no pressure bestie 💖
The UDP/IP datagram carrying this message MUST have a valid, non-zero UDP checksum 🔥 and it needs these IP address and UDP port values:
- Source IP Address: the IP address of the gateway interface that sent the message 🌸 This can be different from the one used for earlier messages. Also, network address translation can change this value before it reaches the relay, so keep that in mind 🦋
- Source UDP Port: the UDP port number 🎀 This can also be different from earlier messages, and NAT can rewrite it on the way to the relay too 💜
- Destination IP Address: the unicast IP address of the relay 🧚
- Destination UDP Port: the AMT port number 🍓
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) |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 17: Membership Teardown Message Format 🖼️
5.1.7.1. Version (V) 🔢
the protocol version number for this message is 0 ✨
5.1.7.2. Type 🏷️
the type number for this message is 7 💅
5.1.7.3. Reserved 🫧
these are reserved bits that the gateway MUST set to zero, and the relay just ignores them 🙈
5.1.7.4. Response MAC 🔐
this is a 48-bit value copied from the Response MAC field (Section 5.1.4.6) in the last Membership Query message the relay sent to the gateway endpoint address of the tunnel being torn down 💖 That endpoint address comes from the Gateway IP Address and Gateway Port Number fields in that Membership Query message 🧩 The relay checks the Teardown message by comparing this value with one it computes from the Gateway IP Address field, Gateway Port Number field, Request Nonce field, and a private secret (just like it does for the Membership Update message) 🕵️♀️
5.1.7.5. Request Nonce 🎲
this is a 32-bit value copied from the Request Nonce field (Section 5.1.4.7) in the last Membership Query message the relay sent to the gateway endpoint address of the tunnel being torn down 🌈 Same deal as before: that endpoint address comes from the Gateway IP Address and Gateway Port Number fields in the Membership Query message 💫 This value must match what the relay used to compute the value stored in the Response MAC field 🫶
5.1.7.6. Gateway Port Number 🚪
this is a 16-bit UDP port number that, when combined with the value in the Gateway IP Address field, makes the tunnel endpoint address the relay uses to find the tunnel instance it should tear down 🦋 The relay hands this value to the gateway through the Gateway Port Number field (Section 5.1.4.9.1) in a Membership Query message 🎀 This port number must match the one the relay used to compute the value stored in the Response MAC field 💅
5.1.7.7. Gateway IP Address 🌐
this is a 16-byte IP address that, when combined with the value in the Gateway Port Number field, makes the tunnel endpoint address the relay uses to identify the tunnel instance to tear down 💜 The relay gives this value to the gateway through the Gateway IP Address field (Section 5.1.4.9.2) in a Membership Query message 🧚 This field can hold 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 [RFC4291]) 🌸 This address must match the one the relay used to compute the value stored in the Response MAC field 🔥
5.2. Gateway Operation 🌷
okay this section is all about what gateways have to do 💖 The following sections describe the gateway implementation requirements 📋 If you want a non-normative tour of gateway operation, check out Section 4.2 🫶
5.2.1. IP/IGMP/MLD Protocol Requirements 🧠
gateway operation needs a subset of the host-mode IPv4/IGMP and IPv6/MLD functionality so it can track group membership, process queries, and generate reports 🎀 A gateway MAY use IGMPv2 (ASM), IGMPv3 (ASM and SSM), MLDv1 (ASM), or MLDv2 (ASM and SSM) ✨
an application with embedded gateway functionality has to bring its own implementation of this subset of the IPv4/IGMP and IPv6/MLD protocols 💅 The service interface used to manage group membership state doesn't need to match the one in the IGMP and MLD specifications 🦋 But the actions taken as a result SHOULD be similar to those described in Section 5.1 of [RFC3376] and Section 6.1 of [RFC3810] 🌈 The gateway application will probably need to do a lot of the same stuff as a host IP stack, like checksum verification, dispatching, datagram filtering and forwarding, and IP encapsulation/decapsulation 🧚
the encapsulated IGMP datagrams a gateway generates MUST conform to the descriptions in Section 4 of [RFC3376] 💜 These datagrams MUST have the IP headers, header options, and header values called for in [RFC3376], with one exception 🙈 A gateway MAY use any source address value in an IGMP report datagram, including the "unspecified" address (all octets are zero) 🫧 This exception exists because a gateway pseudo-interface might not have a valid IPv4 address, and even if one was assigned to the interface, it might not be a valid link-local source address on any relay interface 🥺 That's why a relay must accept encapsulated IGMP reports regardless of the source address they carry 💖 See Section 5.3.1 🔍
the encapsulated MLD messages a gateway generates MUST conform to the description in Section 5 of [RFC3810] 🌸 These datagrams MUST have the IP headers, header options, and header values called for in [RFC3810], with one exception 🎀 A gateway MAY use any source address value in an MLD report datagram, including the "unspecified" address (all octets are zero) 💫 This is because a gateway pseudo-interface might not have a valid IPv6 address, and even if one was assigned, it might not be a valid link-local source address on any relay interface 🌷 Just like with IGMP, a relay must accept encapsulated MLD reports regardless of the source address they carry 🫶 See Section 5.3.1 🔍
the gateway IGMP/MLD implementation SHOULD retransmit unsolicited membership state-change reports and merge new state-change reports with pending reports, as described in Section 5.1 of [RFC3376] and Section 6.1 of [RFC3810] 🔁 The relay sets the number of retransmissions in the Querier's Robustness Variable (QRV) field of the last General Query forwarded by the pseudo-interface 🧮 See Section 4.1.6 of [RFC3376] and Section 5.1.8 of [RFC3810] ✨
the gateway IGMP/MLD implementation SHOULD handle General Query messages as described in Section 5.2 of [RFC3376] and Section 6.2 of [RFC3810] 🌈 It MAY ignore the Max Resp Code (Maximum Response Code) field value and generate a current-state report without any delay 🏃♀️💨
an IPv4 gateway implementation MUST accept IPv4 datagrams carrying the General Query variant of the IGMPv3 Membership Query message, as described in Section 4 of [RFC3376] 🌟 The gateway MUST accept the IGMP datagram regardless of the IP source address it carries 🫶
an IPv6 gateway implementation MUST accept IPv6 datagrams carrying the General Query variant of the MLDv2 Multicast Listener Query message, as described in Section 5 of [RFC3810] 👑 The gateway MUST accept the MLD datagram regardless of the IP source address it carries 💖
5.2.2. Pseudo-Interface Configuration 🧩
a gateway host may have or create multiple gateway pseudo-interfaces 🦋 Each one has its own unique configuration, describing a binding to a specific IP protocol, Relay Address, Relay Discovery Address, or upstream network interface 🌸
5.2.2.1. Relay Discovery Address 🔎
if a gateway implementation uses AMT relay discovery to get a Relay Address, it must first be given a Relay Discovery Address 🧚 The Relay Discovery Address can be an anycast or unicast address 💜 A gateway implementation can rely on a static address assignment or some form of dynamic address discovery 🌈 This specification doesn't require a gateway implementation to use any particular method to get a Relay Discovery Address, so an implementation can use any method that returns a suitable one 🎀✨
5.2.2.2. Relay Address 📍
before a gateway implementation can run the AMT protocol to request and receive multicast traffic, it must be given a unicast Relay Address 💅 A gateway implementation can rely on static address assignment or support some form of dynamic address discovery 🦋 This specification doesn't require any particular method to get a Relay Address, so an implementation can use any method that returns a suitable one 🫶
5.2.2.3. Upstream Interface Selection 🛣️
a gateway host that has multiple network interfaces or addresses may allow an explicit choice of the interface to use when talking to a relay 🌷 That choice might be made to satisfy connectivity, tunneling, or IP protocol requirements 💫
5.2.2.4. Optional Retransmission Parameters 🔁
okay so a gateway implementation that supports retransmission MAY need the following info 💖
- Discovery Timeout: the initial time to wait for a response to a Relay Discovery message ⏳
- Maximum Relay Discovery Retransmission Count: the max number of Relay Discovery retransmissions allowed before relay discovery gets terminated and an error gets reported 🚫
- Request Timeout: the initial time to wait for a response to a Request message ⏳
- Maximum Request Retransmission Count: the max number of Request retransmissions allowed before the gateway abandons a relay and restarts relay discovery, or reports an error 💅
- Maximum Retries Count for "Destination Unreachable": the max number of times a gateway should try sending the same Request or Membership Update message after getting an ICMP Destination Unreachable message 🙈
5.2.3. Gateway Service 🧚
okay, in the descriptions coming up, a gateway pseudo-interface is treated as a passive entity that a gateway service manages 🫶 The pseudo-interface holds the state, and the gateway service does the processing ✨ The term "gateway" is used when we're describing service behavior for one single pseudo-interface 💜
5.2.3.1. Startup 🚀
when a gateway pseudo-interface starts up, the gateway service starts listening for AMT messages sent to the UDP endpoint(s) tied to the pseudo-interface, and also for any locally generated IGMP/MLD messages passed to the pseudo-interface 👂 how those messages get handled is described below 🎀
when the pseudo-interface is enabled, the gateway service MAY:
- Optionally execute the relay discovery procedure described in Section 5.2.3.4.
- Optionally execute the membership query procedure described in Section 5.2.3.5 to start the periodic membership update cycle. 🔄
5.2.3.2. Handling AMT Messages 📬
a gateway MUST ignore any datagram it gets that can't be interpreted as a Relay Advertisement, Membership Query, or Multicast Data message 🙅♀️ how those three get handled is covered in the sections that follow 💖
a gateway that conforms to this spec MUST ignore any message with a Version field value other than zero 🚫
while it's listening for AMT messages, a gateway may be told that an ICMP Destination Unreachable message came back as a result of an AMT message transmission. handling those is described in Section 5.2.3.9 🌸
5.2.3.3. Handling Multicast Data Messages 🌊
a gateway may get Multicast Data messages after it sends a Membership Update message to a relay that adds a group subscription 💌 it may keep getting them long after it sends a Membership Update message that deletes existing group subscriptions 👀 so the gateway MUST be ready to receive these at any time, but it MAY ignore them or throw away their contents if it no longer cares about the multicast datagrams inside 🗑️
a gateway MUST ignore a Multicast Data message if it fails to satisfy any of these requirements:
- 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). 💫
- The destination address carried by the encapsulated IP datagram MUST fall within the multicast address allocation assigned to the relevant IP protocol, i.e., 224.0.0.0/4 for IPv4 and ff00::/8 for IPv6. 🌈
the gateway pulls out the encapsulated IP datagram and hands it to the local IP protocol implementation for checksum verification, fragmented datagram reassembly, source and group filtering, and transport-layer protocol processing 🧩
okay, this one's a big deal 😭 because AMT uses UDP encapsulation to deliver multicast datagrams to gateways, it counts as a tunneling protocol, which means the limits in [RFC6936] apply to it 🚨 if it's supported, a gateway SHOULD use the solution in [RFC6936] so the local IP stack doesn't discard IPv6 datagrams with zero checksums 🛡️ and if Multicast Data message datagrams get processed directly inside the gateway (instead of the host IP stack), the gateway MUST NOT discard any of these datagrams just because they carry a UDP checksum of zero 🙅♀️✨
5.2.3.4. Relay Discovery Procedure 🔍
this section covers gateway requirements for the relay discovery message sequence described in Section 4.2.1.1 💫
5.2.3.4.1. Starting Relay Discovery 🏁
a gateway may start or restart the relay discovery procedure when any of these happen:
- When a gateway pseudo-interface is started (enabled).
- When the gateway wants to report a group subscription and none currently exist.
- Before sending the next Request message in a membership update cycle, i.e., each time the query timer expires (see below). ⏰
- After the gateway fails to receive a response to a Request message.
- After the gateway receives a Membership Query message with the L flag set to 1. 🚩
5.2.3.4.2. Sending a Relay Discovery Message 📤
a gateway sends a Relay Discovery message to a relay to kick off the relay discovery process 🚀
the gateway MUST send the Relay Discovery message using the current Relay Discovery Address and AMT port number as the destination 🎯 the Discovery Nonce value in the Relay Discovery message MUST be computed as described in Section 5.2.3.4.5 🔢
the gateway MUST save a copy of the Relay Discovery message, or save the Discovery Nonce value, for possible retransmission and for checking a Relay Advertisement response 💾
when a gateway sends a Relay Discovery message, it may be told that an ICMP Destination Unreachable message came back because of an earlier AMT message transmission. handling those is described in Section 5.2.3.9 🌸
5.2.3.4.3. Waiting for a Relay Advertisement Message ⌛
a gateway MAY retransmit a Relay Discovery message if it doesn't get a matching Relay Advertisement message within some timeout period 🔁 if it retransmits the message multiple times, the timeout period SHOULD be adjusted to provide a 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 [RFC4787]) 🌙
5.2.3.4.4. Handling a Relay Advertisement Message 📩
when a gateway receives a Relay Advertisement message, it must first figure out whether it should accept or ignore the message 🤔 a gateway MUST ignore a Relay Advertisement message if it fails to satisfy any of these requirements:
- The gateway MUST be waiting for a Relay Advertisement message. ⏳
- The Discovery Nonce value contained in the Relay Advertisement message MUST be equal to the Discovery Nonce value contained in the Relay Discovery message. 🔢
- The source IP address and UDP port of the Relay Advertisement message MUST be equal to the destination IP address and UDP port of the matching Relay Discovery message. 🎯
once a gateway gets 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 🙈
if a gateway runs 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 🧹 it uses information from the last Membership Query message received from that relay, as described in Section 5.2.3.7 📋 here's how that looks in the diagram below 👇
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 | |
|====================================>|
| | |
: : :
Figure 18: Teardown after Relay Address Change5.2.3.4.5. Discovery Nonce Generation 🎲
the discovery nonce MUST be a random, non-zero 32-bit value 🔐 and, if possible, SHOULD be computed using a cryptographically secure pseudorandom number generator 💅 a new nonce SHOULD be generated each time the gateway restarts the relay discovery process 🔄 and the same nonce SHOULD be used when retransmitting a Relay Discovery message 🫶
5.2.3.5. Membership Query Procedure 🧾
this section covers gateway requirements for the membership update message sequence described in Section 4.2.1.2 💖
5.2.3.5.1. Starting the Membership Update Cycle 🚀
okay so a gateway may send a Request message to kick off a membership update cycle (following the optional relay discovery procedure) when either of these happens:
- when the gateway pseudo-interface gets activated 💖
- when the gateway wants to report a group subscription and none exist yet ✨
Starting the cycle when the pseudo-interface starts has some major perks, bestie:
- Better performance 🏃♀️: state-change reports can go out as they're generated, so joining takes less time.
- More robustness 🛡️: group membership state gets updated by unsolicited state-change reports instead of the current-state reports the cycle generates. Unsolicited state-change reports are typically retransmitted multiple times, while current-state reports are not.
- Simpler implementation 🧠: there's no need to queue IGMP/MLD messages for delivery after a Membership Query arrives, since the state-change messages can be sent as soon as they're generated.
However, this approach puts extra load on relays, because a gateway keeps sending periodic requests even when it has zero multicast subscriptions 😬. To ease the pressure on a relay, a gateway SHOULD only send a Membership Update message while it has active group subscriptions. A relay still has to compute a Response MAC for each Request, but it won't be required to recompute it a second time just to authenticate a Membership Update message that contains no subscriptions 🙌
5.2.3.5.2. Sending a Request Message 📨
A gateway sends a Request message to a relay to solicit a Membership Query response and start the membership update cycle. 🎯
The gateway builds the Request message with a Request Nonce value computed as described in Section 5.2.3.5.6. The gateway MUST set the P flag in the Request message to identify the protocol it wants the relay to use for the General Query response.
The gateway MUST send a Request message using the current Relay Address and AMT port number as the destination 📍
The gateway MUST save a copy of the Request message, or save the Request Nonce and P flag values, so it can retransmit the message and verify a Membership Query response later 💾
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 Section 5.2.3.9 👀
5.2.3.5.3. Waiting for a Membership Query Message ⏳
A gateway MAY retransmit a Request message if it doesn't 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 a 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 [RFC4787]) 🌸
If a gateway that uses relay discovery doesn't receive a Membership Query within a specified time period or after a specified number of retries, it SHOULD stop waiting for a Membership Query message and restart relay discovery to locate another relay 🔄
5.2.3.5.4. Handling a Membership Query Message 🔍
When a gateway receives a Membership Query message, it must first decide whether to 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:
- The gateway MUST be waiting for a Membership Query message.
- The Request Nonce value contained in the Membership Query MUST equal the Request Nonce value contained in the Request message.
- 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).
- 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.
- The IGMPv3 or MLDv2 message MUST be a General Query message.
- 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.
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 🙅♀️
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 💾
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.
The MLD protocol specification says senders should use a link-local source IP address in message datagrams. That rule has to be relaxed for AMT, because gateways and relays don't normally share a common subnet 🌐. For this reason, a gateway implementation MUST accept MLD (and IGMP) query message datagrams regardless of the source IP address they carry. This may require additional processing on the part of the gateway, which might be avoided if the relay and gateway use the IPv4 and IPv6 addresses allocated for use in AMT-encapsulated control packets as described in Section 5.2.1.
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 time out. A gateway MAY use a larger timer duration if it has no group subscriptions to report ⏱️
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 Section 5.2.3.7 👋
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 it 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 to communicate with. Even if the L flag is set, the gateway MAY continue to send updates 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) 💅
5.2.3.5.5. Handling Query Timer Expiration ⏰
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 🔁
5.2.3.5.6. Request Nonce Generation 🎰
The Request Nonce MUST be a random value and, if possible, SHOULD be computed using a cryptographically secure pseudorandom 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 ✨
5.2.3.6. Membership Update Procedure 🔄
This section describes gateway requirements related to the membership update message sequence described in Section 4.2.1.2 📜
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 Query messages generated by the pseudo-interface via AMT, and they produce state-change reports in response to receiver requests made using the IGMP or MLD service interface 🎀
5.2.3.6.1. Handling an IGMP/MLD IP Datagram 📦
The gateway pseudo-interface MUST accept the following IP datagrams from the IPv4/IGMP and IPv6/MLD protocols running on the pseudo-interface:
- IPv4 datagrams that carry an IGMPv2 or IGMPv3 Membership Report, or an IGMPv2 Leave Group message, as described in Section 4 of [RFC3376].
- IPv6 datagrams that carry an MLDv1 or MLDv2 Multicast Listener Report, or an MLDv1 Multicast Listener Done message, as described in Section 5 of [RFC3810].
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 🙈
A gateway that waits to start a membership update cycle until after it receives a datagram containing an IGMP/MLD state-change message MAY:
- Discard IGMP or MLD datagrams 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).
- Insert IGMP or MLD datagrams into a queue for transmission after it receives a Membership Query message.
If and when a gateway receives a Membership Query message (for IGMP or MLD), it sends any queued or incoming IGMP or MLD datagrams to the relay as described in the next section 🚀
5.2.3.6.2. Sending a Membership Update Message 📤
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 to communicate with, it MUST first execute the relay discovery procedure described in Section 5.2.3.4 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 Section 5.2.3.5 to obtain a Request Nonce and Response MAC that can be used to send a Membership Update message 🔑
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 AMT port number as the destination 💖
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 Section 5.2.3.9 🌈
5.2.3.7. Teardown Procedure ✨
okay so this section is all about the gateway's Teardown message sequence, the one from Section 4.2.1.3 🦋 Gateway support for the Teardown message is RECOMMENDED 💖 and a gateway that supports Teardown SHOULD use it when it gets a Membership Query from a relay with the G flag set, meaning the query has valid Gateway Address fields 🧚
5.2.3.7.1. Handling a Membership Query Message 💌
remember how Section 5.2.3.5.4 talked about Membership Query handling? this is the add-on 💅 if a gateway supports Teardown, has reported active group subscriptions, and gets a Membership Query with the G flag set, it MUST compare the Gateway IP Address and Gateway Port Number on the new query against the values from the previous Membership Query message 👀 if either value has changed, the gateway MUST send a Teardown message, which the next section explains 🫶
5.2.3.7.2. Sending a Teardown Message 📨
so a gateway sends a Teardown message to a relay to say "hey, please stop delivering Multicast Data messages to me and delete any group memberships I made" 🙈
when a gateway builds 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 gave the Response MAC for the last Membership Update message sent, into the matching fields of the Teardown message 🍓
the gateway MUST send the Teardown message to the Relay Address and AMT port number as the destination 🌸 it MAY send the Teardown message multiple times for robustness, which is giving reliability energy 💜 and it SHOULD use the Querier's Robustness Variable (QRV) field from the query inside the last Membership Query to set the retransmission limit (see Section 4.1.6 of [RFC3376] and Section 5.1.8 of [RFC3810]) 🔥 if it does send multiple copies, it SHOULD add a delay between each one, using the timing algorithm IGMP/MLD uses for unsolicited state-change reports ⏳ the RECOMMENDED default delay is 1 second ⭐
when a gateway sends a Teardown message, it might get told that an ICMP Destination Unreachable message came back because of an earlier AMT message transmission 🌈 handling those is covered in Section 5.2.3.9 💅
5.2.3.8. Shutdown 🌙
when a gateway pseudo-interface stops and the gateway still has group subscriptions, the gateway SHOULD do one of these:
- send a Teardown message to the relay, as described in Section 5.2.3.7, but only if the gateway supports Teardown and the current relay is returning Gateway Address fields in Membership Query messages, or
- send a Membership Update message to the relay that deletes the existing group subscriptions 🦋
5.2.3.9. Handling ICMP Destination Unreachable Responses 🚨
a gateway MAY get an ICMP Destination Unreachable message [RFC0792] after it sends an AMT message 👀 whether the gateway actually hears about that ICMP message depends a LOT on firewalls, the gateway's IP stack, and how the gateway was implemented 💀
if an ICMP Destination Unreachable message gets reported to the gateway while it's waiting for an AMT message, it can respond in the ways below, depending on what the platform can do and which outgoing message set it off:
- the gateway MAY simply abandon the current relay and restart relay discovery (if used) 😬 this is the least desirable option, because it doesn't allow for transient network changes 💔
- if the last message sent was a Relay Discovery or Request message, the gateway MAY simply ignore the ICMP response and keep waiting for incoming AMT messages 🌷 if the gateway is set up to retransmit Relay Discovery or Request messages, that normal retransmission behavior is kept so the gateway doesn't give up on a relay too early 🫶
- if the last message sent was a Membership Update message, the gateway MAY start a new membership update and its associated Request retransmission cycle 🔁
if an ICMP Destination Unreachable message gets reported to the gateway while it's trying to send a new AMT message, it can respond in these ways, again depending on platform capabilities and which outgoing message triggered it:
- the gateway MAY simply abandon the current relay and restart relay discovery (if used) 😬 least desirable again, since it doesn't allow for transient network changes 💔
- if the last message sent was a Relay Discovery, Request, or Teardown message, the gateway MAY try to send the new message 🏃♀️ if the gateway is set up to retransmit Relay Discovery, Request, or Teardown messages, that normal retransmission behavior is kept so the gateway doesn't abandon a relay too early 🌸
- if the last message sent was a Membership Update message, the gateway SHOULD start a new membership update and its associated Request retransmission cycle 💖
5.3. Relay Operation 🎀
the next sections cover what relays MUST do to implement this 💅 a non-normative discussion of relay operation is in Section 4.2, so go check that out too 🧚
5.3.1. IP/IGMP/MLD Protocol Requirements 🌈
a relay only needs a subset of router-mode IGMP and MLD functionality, enough for group membership tracking and report processing 🍓
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 ✨
a relay MUST apply the forwarding rules from Section 6.3 of [RFC3376] and Section 7.3 of [RFC3810] 🔥 a relay MUST handle incoming reports as described in Section 6.4 of [RFC3376] and Section 7.4 of [RFC3810], except that actions leading to queries MAY be changed to skip query generation 🙃 and a relay MUST accept IGMP and MLD report datagrams no matter what IP source address they carry 👑
all the other IGMP/MLD router stuff, like query handling, querier election, and so on, isn't used or required for relay operation 🤷♀️
5.3.2. Startup 🚀
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 inside that prefix, a Relay Discovery Address, MUST be assigned to a relay interface 📍
a unicast IPv4 and/or IPv6 address MUST be assigned to the relay interface that will send and receive AMT control and data messages 💌 those addresses get returned in Relay Advertisement messages 💖
the rest of relay "startup" is highly implementation dependent, so this document doesn't cover it 🙈
5.3.3. Running 🏃♀️
when a relay starts, it begins listening for AMT messages on the interface the unicast Relay Address(es) is assigned to, which is the address returned in Relay Advertisement messages 👂
5.3.3.1. Handling AMT Messages 📬
a relay MUST ignore any message other than a Relay Discovery, Request, Membership Update, or Teardown message 🙅♀️ the handling of those four is covered in the sections that follow 🫶
support for the Teardown message is OPTIONAL 🌷 if a relay doesn't support Teardown, it MUST also ignore that message 🥲
a relay that conforms to this specification MUST ignore any message with a Version field value other than zero 🔒
5.3.3.2. Handling a Relay Discovery Message 🔍
this section covers the relay requirements for the relay discovery message sequence from Section 4.2.1.1 🦋
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 gets 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 Relay Discovery Address 🌸
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 number of the Relay Discovery message as the destination IP address and UDP port number for the Relay Advertisement message 🎯 the source IP address and UDP port number carried by the Relay Advertisement message MUST match the destination IP address and UDP port number of the Relay Discovery message, so NAT traversal goes smoothly 🧦✨
the relay MUST copy the value in the Discovery Nonce field of the Relay Discovery message into the Discovery Nonce field of the Relay Advertisement message 🔁
if the Relay Discovery message came in as an IPv4 datagram, the relay MUST return an IPv4 address in the Relay Address field of the Relay Advertisement message 🌐 if it came in as an IPv6 datagram, the relay MUST return an IPv6 address in the Relay Address field 💜
5.3.3.3. Handling a Request Message 📬✨
okay bestie, this bit is all about the membership query part of the message sequence from Section 4.2.1.2 🦋
when a relay gets a Request message, it replies by sending a Membership Query message right back to whoever sent the Request 💌
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 🎯. The source IP address and UDP port carried by the Membership Query MUST match the destination IP address and UDP port of the Request, so NAT traversal actually works 🫶
the relay MUST copy the value from the Request Nonce field of the Request into the Request Nonce field of the Membership Query 🔁. It also MUST compute a MAC value, as described in Section 5.3.5, and put that value in the Response MAC field of the Membership Query 🔐.
if a relay supports the Teardown message, it MUST set the G flag in the Membership Query and copy the source IP address and UDP port from the Request into the matching Gateway IP Address and Gateway Port Number fields 🚪. if the relay does not support the Teardown message, it SHOULD NOT set those fields 🙅♀️
⚠️ the reason is pretty sus if you skip this: setting them when there's no Teardown support may cause the gateway to generate unnecessary Teardown messages. nobody wants that chaos 💀
the P flag in the Request decides which query type goes out 👑. if the P flag is 0, the relay MUST return an IPv4-encapsulated IGMPv3 General Query in the Membership Query. if the P flag is 1, the relay MUST return an IPv6-encapsulated MLDv2 General Query instead 🌈
if the relay isn't accepting Membership Update messages that create new tunnel endpoints because it's out of resources, it SHOULD set the L flag in the Membership Query so the gateway knows what's up 🫠. Support for the L flag is OPTIONAL. see Section 5.3.3.8 for the deets 💅
the encapsulated IGMPv3 General Query datagrams MUST conform to the descriptions in Section 4.1 of [RFC3376]. They MUST possess the IP headers, header options, and header values that [RFC3376] calls for, with one exception 🧁: a relay MAY use any source IP address for an IGMP General Query datagram, including the "unspecified" address (all octets zero). the reason is that whatever source address a relay would normally send might not be a valid link-local address on any gateway interface. so a gateway must accept encapsulated IGMP queries regardless of the source address they carry. see Section 5.2.1 ✨
same energy for MLD 🎀. The encapsulated MLDv2 General Query datagrams MUST conform to Section 5.1 of [RFC3810] and MUST possess the IP headers, header options, and header values that [RFC3810] calls for, with the same exception: a relay MAY use any source IP address for an MLD General Query datagram, including the "unspecified" address (all octets are zero). As with IGMP, a gateway must accept encapsulated MLD queries regardless of the source address they carry. see Section 5.2.1 🦋
a relay MUST set the Querier's Query Interval Code (QQIC) field in the General Query so the gateway gets a suggested duration for its membership query timer ⏱️. The QQIC field is defined in Section 4.1.7 of [RFC3376] and Section 5.1.9 of [RFC3810]. a relay MAY adjust this value to change how fast Request messages come in from a gateway 🐢. however, a gateway is allowed to use a shorter duration than the one in the QQIC field, so a relay might not be able to spread out Requests as much as it'd like 😤
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 membership state-change messages, it'll retransmit them (Robustness Variable - 1) times. The QRV field is defined in Section 4.1.6 of [RFC3376] and Section 5.1.8 of [RFC3810] 🔁
a relay SHOULD set the Maximum Response Code field in the General Query to 1 so the gateway responds right away 🔥 (some host IGMP/MLD implementations may not accept zero, so that's the iconic move). a relay SHOULD NOT use the IGMPv3/MLDv2 Query Response Interval variable, if it has one, to make the Maximum Response Code value. that variable sets how long group state timers last, so it must not be set to such a tiny value 🙈. The Maximum Response Code field is defined in Section 4.1.1 of [RFC3376] and Section 5.1.3 of [RFC3810]. see Section 5.3.3.7 🌸
5.3.3.4. Handling a Membership Update Message 🫧
this section covers the membership update part of the message sequence from Section 4.2.1.2 📦
when a relay receives a Membership Update message, it must first decide whether to accept or ignore it 🧐. A relay MUST NOT make any changes to group membership and forwarding state if the message fails to satisfy any of the following requirements:
- The IP datagram encapsulated within the message MUST be one of the following:
- IPv4 datagram carrying an IGMPv2 or IGMPv3 Membership Report message.
- IPv4 datagram carrying an IGMPv2 Leave Group message.
- IPv6 datagram carrying an MLDv1 or MLDv2 Multicast Listener Report message.
- IPv6 datagram carrying MLDv1 Multicast Listener Done message.
- The encapsulated IP datagram MUST satisfy the IP header requirements for the IGMP or MLD message type, as described in Section 4 of [RFC3376], Section 2 of [RFC2236], Section 5 of [RFC3810], and Section 3 of [RFC2710]. the one exception is that a relay MUST accept an IGMP or MLD message regardless of the IP source address the datagram carries 🪄
- The total length of the encapsulated IP datagram, as computed from the lengths in the datagram header(s), MUST NOT exceed the available field length within the Membership Update message 📏
- The computed checksums for the encapsulated IP datagram and its payload MUST match the values contained therein 🧮. Checksum computation and verification vary by protocol. see [RFC0791] for IPv4, [RFC3376] for IGMPv3, and [RFC4443] for MLD (ICMPv6) 🤓
- If processing the encapsulated IGMP or MLD message would result in allocating new state or modifying existing state, the relay MUST authenticate the source of the message 🔐. It does this by verifying that the value in the Response MAC field equals the MAC value computed from the fields in the Membership Update message datagram. If a time-varying private secret is used in computing a Response MAC, the relay MUST retain the previous version of the private secret for 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_intervaltime has elapsed since the private secret change. See Section 5.3.5 🦋
a relay MAY skip source authentication to save on computational cost when handling Membership Update messages 💅. It can do this if it can make a trivial determination that the IGMP/MLD message in the Membership Update will produce no changes in group membership or forwarding state ✨. The relay doesn't need to compute and compare MAC values if it finds there are no group subscriptions for the source of the Membership Update, and either of the following is true:
- 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 keep repeating the membership update cycle even though they have no group subscriptions to report 🫠.
- The encapsulated IP datagram is an IGMPv2 Leave Group or MLDv1 Multicast Listener Done message.
the IGMP and MLD specs say senders SHOULD use a link-local source IP address in their message datagrams 🌐. This requirement must be relaxed for AMT, because gateways and relays don't share a common subnet 🫶. For this reason, a relay implementation MUST accept IGMP and MLD datagrams regardless of the source IP address they carry 💖
once a relay has decided the Membership Update message is valid, it processes the encapsulated IGMP or MLD message 🛠️. That updates group membership state, and the relay talks to the multicast protocol to update forwarding state and possibly send multicast protocol messages toward upstream routers. The relay MUST ignore any octets that might sit between the encapsulated IP datagram and the end of the Membership Update message 🙈
as described in Section 4.2.2, a relay uses the source IP address and source UDP port carried by a Membership Update message to identify a tunnel endpoint 📍. The relay uses that tunnel endpoint as the destination address for any Multicast Data messages it sends because of the group membership and forwarding state created from the IGMP/MLD messages in Membership Updates received from that endpoint 🎀
if a Membership Update message comes 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 it might have made. see Section 5.3.3.8 🫧
a relay MUST maintain some form of group membership database for each endpoint 🗂️. The per-endpoint databases are used to update a forwarding table with entries that map a (*,G) or (S,G) subscription to a list of tunnel endpoints.
a relay MUST maintain some form of group membership database that represents a merger of the group membership databases of all endpoints 🌈. The merged database is used to update upstream multicast forwarding state.
a relay MUST maintain a forwarding table that maps each unique (*,G) and (S,G) subscription to a list of tunnel endpoints 🗺️. The relay uses this forwarding table to provide the destination address when it does the UDP/IP encapsulation of incoming multicast IP datagrams to form Multicast Data messages.
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 🚫. The exception is when the relay architecture doesn't readily support source filtering. A relay MAY ignore the source list if necessary, because gateways are expected to do their own source filtering 👑
and that's the vibe for this part, bestie 💜🦋
5.3.3.5. Handling a Teardown Message ✨
okay bestie, this part is about the relay's side of the teardown message sequence from Section 4.2.1.3 🦋. When a relay that supports the Teardown message gets one, it MUST first authenticate who sent it by checking that the Response MAC in the message equals a MAC value computed from the message's fields 🔐. This is where it gets a little twisty: the MAC is computed differently than for Membership Query and Membership Update messages, because the source IP address and source UDP port come from the Gateway IP Address and Gateway Port Number fields inside the Teardown itself, not from the IP and UDP headers of the datagram that carried it 💅. The MAC computation is in Section 5.3.5. A relay MUST ignore a Teardown message if the computed MAC does not equal the Response MAC field 🙅
If a relay decides a Teardown is authentic, it MUST immediately stop sending Multicast Data messages to the endpoint named by the Gateway IP Address and Gateway Port Number fields 🛑. The relay MUST eventually delete any group membership and forwarding state tied to that endpoint, but it MAY wait before doing so. The reason is pretty sweet: the delay lets a gateway rebuild its group membership state on a new endpoint, which avoids unnecessary (temporary) changes in upstream routing/forwarding state 🧚
The state changes a relay makes when processing a Teardown MUST be identical to the ones it would make if it had received an IGMP/MLD report that would cause IGMP or MLD to delete all existing group records in the group membership database associated with the endpoint 🤯. Processing the Teardown should trigger or mimic the normal interaction between IGMP or MLD and a multicast protocol, so the required forwarding changes happen and possibly prune/leave messages get sent toward upstream routers 🌊
5.3.3.6. Handling Multicast IP Datagrams 🎀
When a multicast IP datagram gets 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 (or several) and send those to the gateway 📦. This is super implementation dependent, but conceptually it takes these steps:
- 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.
- Possibly replicate the datagram for each gateway endpoint listed for that (*,G) or (S,G) entry.
- If the multicast IP datagram size exceeds the Tunnel MTU as determined according to the procedure described in Section 5.3.3.6.1, the relay must execute the procedure described in Section 5.3.3.6.2.
- Encapsulate and transmit the IP datagram according to the procedure described in Section 5.3.3.6.3.
The relay pseudo-interface MUST ignore any other IP datagrams forwarded to the pseudo-interface 🙈
5.3.3.6.1. Path and Tunnel MTU 📏
A relay MUST compute a Tunnel MTU (TMTU) value for each AMT tunnel that originates on the relay 🌸. The relay will use that TMTU value to figure out whether an incoming multicast IP datagram can go downstream in a Membership Data message without fragmentation. To get it, a relay MUST subtract the size of the Membership Data message headers (IP, UDP, and AMT) from the current Path MTU (PMTU) associated with each AMT tunnel. The relay MUST maintain a PMTU value on a per-tunnel or per-relay basis, and it MUST support one or both of the following methods for determining that PMTU value:
- The relay MAY provide a configuration option that establishes a fixed PMTU that will be applied to all AMT tunnels originating at the relay.
- The relay MAY dynamically adjust PMTU value(s) in response to receipt of ICMP/ICMPv6 Datagram Too Big messages as described in [RFC1191] and [RFC1981].
If a relay supports dynamic adjustment of per-tunnel or per-relay PMTU values in response to ICMP messages, it MUST provide a configuration option that disables this feature, and it also MUST provide a configuration option that establishes a minimum PMTU for all tunnels. These configuration options may be used to mitigate certain types of denial-of-service attacks (see Section 6), so they're kinda important 🛡️. When dynamic PMTU adjustments are disabled, the PMTU for all tunnels MUST default to the Link MTU (first hop) on the downstream interface.
5.3.3.6.2. MTU Filtering Procedure 🧹
This section defines the procedures a relay must execute when it receives a multicast datagram whose size is greater than the Tunnel MTU of the tunnel (or tunnels) it has to be delivered through 💌.
5.3.3.6.2.1. IPv4 Multicast IP Datagrams 🌐
If the DF bit in the multicast datagram header is set to 1 (Don't Fragment), the relay MUST discard the packet. If the datagram originated from an SSM source, the relay also sends an ICMPv4 [RFC0792] Destination Unreachable message back to the source, with code 4 (fragmentation needed and DF set) 😭. That ICMP Destination Unreachable message MUST contain a Next-Hop MTU (as specified by [RFC1191]), and the relay MUST set that Next-Hop MTU to the TMTU associated with the tunnel or tunnels.
If the DF bit in the multicast datagram header is set to 0 (May Fragment), the relay MUST fragment the datagram and encapsulate each fragment within Multicast Data messages for transmission through the tunnel or tunnels. This ensures that gateways receive complete, non-fragmented Multicast Data messages, which contain the fragmented multicast datagram payloads 🧩. The relay SHOULD avoid generating a separate ICMP message for each tunnel. Instead, it should send a single ICMP message with a Next-Hop MTU equal to the smallest TMTU of all tunnels to which the datagram was to be forwarded.
5.3.3.6.2.2. IPv6 Multicast IP Datagrams 💫
The relay MUST discard the packet and, if the datagram originated from an SSM source, send an ICMPv6 [RFC4443] Packet Too Big message to the payload source. The MTU specified in that Packet Too Big message MUST be equal to the TMTU associated with the tunnel or tunnels. The relay SHOULD avoid generating a separate ICMPv6 message for each tunnel, and instead send a single ICMPv6 message with a Next-Hop MTU equal to the smallest TMTU of all tunnels to which the datagram was to be forwarded 🦋
5.3.3.6.3. Encapsulation Procedure 🎁
A relay encapsulates a multicast IP datagram in a UDP/IP Membership Data message. It uses the tunnel endpoint UDP/IP address as the destination address, and the unicast Relay Address and port number as the source UDP/IP address. For successful NAT traversal, the source address and port MUST match the destination address and port carried by the Membership Update message the gateway sent to create the forwarding table entry 🧭
If possible, the relay SHOULD compute a valid, non-zero checksum for the UDP datagram carrying the Multicast Data message. See Section 4.2.2.3 ✅
The following sections describe additional requirements related to the IP protocol of the tunnel and that of the multicast IP datagram 🤓
5.3.3.6.3.1. Tunneling over IPv4 🚇
When a relay delivers an IPv4 payload over an IPv4 tunnel and the DF bit in the payload header is set to 1 (Don't Fragment), the relay MUST set the DF bit in the Multicast Data IP header to 1. When a relay delivers an IPv4 payload over an IPv4 tunnel and the DF bit in the payload header is set to 0 (May Fragment), the relay MUST by default set the DF bit in the Multicast Data IP header to 1. However, a relay MAY provide a configuration option that allows the DF bit to be copied from the payload header to the Multicast Data IP header, so downstream fragmentation of the Multicast Data message is allowed 🎀. When a relay delivers an IPv6 payload over an IPv4 tunnel, the relay MUST set the DF bit in the Multicast Data IP header to 1. The relay MUST NOT transmit a Multicast Data message with an IP header in which the MF (More Fragments) bit is set to 1 🚫
5.3.3.6.3.2. Tunneling over IPv6 🌊
When tunneling over IPv6, a relay MUST NOT emit a Multicast Data message datagram containing an IPv6 fragment header 🙅♀️
5.3.3.6.4. Handling Destination Unreachable Messages 🚨
If a relay receives a sequence of ICMP or ICMPv6 Destination Unreachable messages (excluding ICMP code 4, more on that below) in response to transmission of a sequence of AMT Multicast Data messages to a gateway, the relay SHOULD discontinue sending messages to that gateway and shut down the tunnel for that gateway 🛑
Handling of ICMP Destination Unreachable messages with code 4, "fragmentation needed and DF set" (i.e., "Datagram Too Big"), is covered in Section 5.3.3.6.1. If a relay provides this capability, it MUST provide a configuration option that indicates how many sequential Destination Unreachable messages can be received and ignored before the relay automatically shuts down a tunnel 🔢
5.3.3.7. State Timers ⏰
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 🕰️
A relay MAY use a variant of the IGMPv3/MLDv2 state management protocol described in Section 6 of [RFC3376] or Section 7 of [RFC3810]. Or it may maintain a per-endpoint timer to trigger the deletion of group membership state 💜
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 🔁
The endpoint timer duration MAY be computed from tunable IGMP/MLD variables as follows:
((Robustness_Variable) * (Query_Interval)) + Query_Response_IntervalIf IGMP/MLD default values are used for these variables, the gateway will time out 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 🧮
Regardless of which timers are 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 🌈
5.3.3.8. Relay Resource Management ✨
Okay bestie, so a relay can be set up with service limits so every gateway that connects to it still gets a decent level of performance 💖🫶
If a relay figures out it has hit or passed its max capacity, or it's run out of the resources it needs for more 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 sends back to gateways while it's in that state 🚩
If the relay gets an update from a gateway that adds group membership or forwarding state for an endpoint that's already maxed out on state entries, the relay SHOULD continue to accept updates from that gateway, but it ignores any group membership/forwarding state additions the gateway asks for 💅
And if the relay gets an update from a gateway that would make a new tunnel endpoint for a source IP address that's already reached the max number of endpoints (maximum UDP ports), it should simply ignore the Membership Update. Not me ignoring it, but the protocol being iconic about limits 😭
5.3.4. Shutdown 🌙
The following steps should be treated as an abstract description of the shutdown procedure for a relay:
- Withdraw the Relay Discovery Address Prefix advertisement (if used).
- Stop listening for Relay Discovery messages.
- Stop listening for control messages from gateways.
- Stop sending data messages to gateways.
- 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.
5.3.5. Response MAC Generation 🔐
A Response MAC value is computed by the relay. A Response MAC computation is required in the following situations:
- To generate a Response MAC value from a Request message for inclusion in a Membership Query message.
- To generate a Response MAC value from a Membership Update message for use in authenticating the Response MAC carried within that message.
- To generate a Response MAC value from a Teardown message to authenticate the Response MAC carried within that message.
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 RECOMMENDED method for computing the Response MAC is to compute a cryptographically secure hash or keyed-hash digest from the following values:
- The source IP address of the message (or Teardown Gateway IP Address field).
- The source UDP port of the message (or Teardown Gateway Port Number field).
- The Request Nonce contained in the message.
- A private secret or key known only to the relay.
5.3.6. Private Secret Generation 🤫
If the relay implementation uses a private secret (or key) to compute the Response MAC value, the 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. That way the older MACs still check out for gateways that got them right before the switch 🧚
6. Security Considerations 🔒
AMT is not intended to be a strongly secure protocol. Honestly, the protocol gives you the same level of security and robustness as UDP, IGMP, and MLD, which it all relies on. The lack of strong security features is mostly because the protocol is meant to be lightweight, keeping the state and computation needed to serve one gateway really small so a relay can serve more gateways 🦋
Lots of the threats and vectors described in [RFC3552] can be used against the protocol to launch different kinds of denial-of-service attacks. These can mess with gateways or their ability to find and talk to a relay. The scenarios are described below 💀
Just like UDP, IGMP, and MLD, the AMT protocol provides no mechanisms for ensuring message delivery or integrity. It also doesn't offer confidentiality -- multicast groups, sources, and streams requested by a gateway are sent in the clear 👀
The protocol does use a three-way handshake to provide trivial source authentication for state allocation and updates (see below). It also requires gateways and relays to ignore malformed messages, and those messages that don't carry expected address values, protocol payload types, or content 🛡️
6.1. Relays 🏰
The three-way handshake provided by the membership update message sequence (see Section 4.2.1.2) defends a relay against source-spoofing-based resource-exhaustion attacks, because it requires source authentication before any state gets allocated. Still, attackers may try to burn computational resources by flooding a relay with Request and Membership Update messages, forcing the relay to do the MAC authentication computations over and over 😤 Implementations may choose to limit how often 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 🙅♀️
Attackers who run the gateway protocol can eat up relay resources by setting up a huge number of tunnels or joining a huge 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 🚧
Relays may withdraw their AMT anycast prefix advertisement when they reach configured maximum capacity or exhaust required resources. This lets gateways use the relay discovery process to find the next topologically nearest relay that has advertised the prefix. The catch is that it also lets a successful resource-exhaustion attack spread from one relay to the next until every relay reachable using the anycast address has 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 networks, relay anycast address advertisements can be limited to specific administrative routing domains. That way, an attack gets isolated to a single domain 🧱
The Path and Tunnel MTU adjustment (discovery) procedure described in Section 5.3.3.6.1 is vulnerable to two denial-of-service attacks (see Section 8 of [RFC1191] for details). Both attacks are based on a malicious party sending forged ICMPv4 Destination Unreachable or ICMPv6 Packet Too Big messages to a host. In the first attack, the forged message indicates an inordinately small Path MTU. In the second attack, the forged message indicates an inordinately large Path MTU. In both cases, throughput gets hurt 📉 To mitigate such attacks, relay implementations MUST include a configuration option to disable Path MTU adjustments on AMT tunnels 🎀
6.2. Gateways 🌷
A passive eavesdropper may launch a denial-of-service attack on a gateway by capturing a Membership Query or Membership Update message. They then use the Request Nonce and message authentication code in that captured message to send a spoofed Membership Update or Teardown message to the relay. Those spoofed messages can modify or destroy the group membership state tied to the gateway, which changes or interrupts the multicast traffic flows 😬
A passive eavesdropper may also spoof Multicast Data messages to overload the gateway, or to disrupt or supplant existing traffic flows. A properly implemented gateway will filter Multicast Data messages that don't originate from the expected Relay Address. It should also filter non-multicast packets and multicast IP packets whose group or source addresses aren't included in the current reception state for the gateway pseudo-interface 🫧
An active eavesdropper may launch a man-in-the-middle attack, where messages normally exchanged between a gateway and relay get intercepted, modified, spoofed, or discarded by the attacker. The attacker may deny access to, modify, or replace requested multicast traffic. The AMT protocol provides no means for detecting or defending against a man-in-the-middle attack -- any such functionality must be provided by multicast receiver applications through independent detection and validation of incoming multicast datagrams 🕵️♀️
The anycast discovery technique for finding relays (see Section 4.1.4) carries a risk that a rogue router or a rogue Autonomous System (AS) could introduce a bogus route to a specific Relay Discovery Address Prefix, and then 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 they guarantee the integrity of all their other routes 🗺️
6.3. Encapsulated IP Packets 📦
An attacker who forges or modifies a Membership Query or Membership Update message may try to embed something other than an IGMP or MLD message within the encapsulated IP packet carried by these messages. The goal is to slip it into the recipient's IP stack 👾 A properly implemented gateway or relay will ignore any such messages, and may further choose to ignore Membership Query messages that do not contain IGMP/MLD General Query, or Membership Update messages that do not contain IGMP/MLD membership reports.
Properly implemented gateways and relays will also filter encapsulated IP packets that appear corrupted or truncated, by verifying packet length and checksums ✅
7. IANA Considerations 🌈
7.1. IPv4 and IPv6 Anycast Prefix Allocation 🛰️
The following unicast prefixes have been assigned to provide anycast routing of Relay Discovery messages to public AMT relays, as described in Section 4.1.4. Address assignments within these prefixes are described in Section 4.1.5.2.
7.1.1. IPv4 🎀
IANA has assigned 192.52.193.0/24 from the "IANA IPv4 Special-Purpose Address Registry". The block has been registered as follows:
+----------------------+----------------+
| Attribute | Value |
+----------------------+----------------+
| Address Block |192.52.193.0/24 |
| Name | AMT |
| RFC | [RFC7450] |
| Allocation Date | 2014-12 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+----------------+7.1.2. IPv6
Okay bestie, IANA has registered this special-purpose address block for IPv6 anycast AMT relay discovery 🦋✨
+----------------------+----------------+
| Attribute | Value |
+----------------------+----------------+
| Address Block | 2001:3::/32 |
| Name | AMT |
| RFC | [RFC7450] |
| Allocation Date | 2014-12 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+----------------+7.2. UDP Port Number 💌
The UDP port number 2268 has been reserved with IANA for AMT, so it's officially claimed for this protocol 🎀. This document keeps using that port according to what the original request intended 💅. IANA has also updated the assignee, contact, and reference fields for this port to match this document, so the paperwork is fully iconic now 👑.
8. References 📚
8.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997,
http://www.rfc-editor.org/info/rfc2119. - [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002,
http://www.rfc-editor.org/info/rfc3376. - [RFC3810] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004,
http://www.rfc-editor.org/info/rfc3810. - [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006,
http://www.rfc-editor.org/info/rfc4291. - [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006,
http://www.rfc-editor.org/info/rfc4607. - [RFC4787] Audet, F., Ed., and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007,
http://www.rfc-editor.org/info/rfc4787.
8.2. Informative References
- [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981,
http://www.rfc-editor.org/info/rfc0791. - [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981,
http://www.rfc-editor.org/info/rfc0792. - [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989,
http://www.rfc-editor.org/info/rfc1112. - [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990,
http://www.rfc-editor.org/info/rfc1191. - [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993,
http://www.rfc-editor.org/info/rfc1546. - [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996,
http://www.rfc-editor.org/info/rfc1981. - [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997,
http://www.rfc-editor.org/info/rfc2236. - [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998,
http://www.rfc-editor.org/info/rfc2460. - [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999,
http://www.rfc-editor.org/info/rfc2663. - [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999,
http://www.rfc-editor.org/info/rfc2710. - [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003,
http://www.rfc-editor.org/info/rfc3552. - [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006,
http://www.rfc-editor.org/info/rfc4271. - [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006,
http://www.rfc-editor.org/info/rfc4443. - [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006,
http://www.rfc-editor.org/info/rfc4601. - [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December 2006,
http://www.rfc-editor.org/info/rfc4786. - [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, April 2013,
http://www.rfc-editor.org/info/rfc6935. - [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, April 2013,
http://www.rfc-editor.org/info/rfc6936.
Acknowledgments 🫶
The author would like to thank these amazing people for their suggestions, comments, and corrections 💖:
- Mark Altom
- Toerless Eckert
- Marshall Eubanks
- Gorry Fairhurst
- 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
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 🌈.
Juniper Networks was instrumental in funding several versions of this document as well as an open source implementation 🍓.
Contributors 🧚
The following people provided significant contributions to the design of the protocol and earlier versions of this specification 💜:
Amit Aggarwal
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
United States
EMail: amitag@microsoft.comThomas Morin
Orange
2, avenue Pierre Marzin
Lannion 22300
France
EMail: thomas.morin@orange.comDirk Ooms
OneSparrow
Robert Molsstraat 11; 2018 Antwerp
Belgium
EMail: dirk@onesparrow.comTom Pusateri
!j
Wake Forest, NC
United States
EMail: pusateri@bangj.comDave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
United States
EMail: dthaler@microsoft.comAuthor's Address 🌸
Gregory Bumgardner
Phone: +1 541 343 6790
EMail: gbumgard@gmail.com📦 where this page comes from
- ietf: rfc7450 2015-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms