doc: Add RFC documents

1 files changed, 4595 insertions, 0 deletions

diff --git a/doc/rfc/rfc7450.txt b/doc/rfc/rfc7450.txt
new file mode 100644
index 0000000..a881f36
--- /dev/null
+++ b/doc/rfc/rfc7450.txt
@@ -0,0 +1,4595 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     G. Bumgardner
+Request for Comments: 7450                                 February 2015
+Category: Standards Track
+ISSN: 2070-1721
+
+
+                     Automatic Multicast Tunneling
+
+Abstract
+
+   This document describes Automatic Multicast Tunneling (AMT), a
+   protocol for delivering multicast traffic from sources in a
+   multicast-enabled network to receivers that lack multicast
+   connectivity to the source network.  The protocol uses UDP
+   encapsulation and unicast replication to provide this functionality.
+
+   The AMT protocol is specifically designed to support rapid deployment
+   by requiring minimal changes to existing network infrastructure.
+
+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 has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   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) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+Bumgardner                   Standards Track                    [Page 1]
+
+RFC 7450                           AMT                     February 2015
+
+
+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
+
+
+
+
+Bumgardner                   Standards Track                    [Page 2]
+
+RFC 7450                           AMT                     February 2015
+
+
+   8. References .....................................................78
+      8.1. Normative References ......................................78
+      8.2. Informative References ....................................79
+   Acknowledgments ...................................................81
+   Contributors ......................................................82
+   Author's Address ..................................................82
+
+1.  Introduction
+
+   The advantages and benefits provided by multicast technologies are
+   well known.  There are a number of application areas that are ideal
+   candidates for the use of multicast, including media broadcasting,
+   video conferencing, collaboration, real-time data feeds, data
+   replication, and software updates.  Unfortunately, many of these
+   applications lack multicast connectivity to networks that carry
+   traffic generated by multicast sources.  The reasons for the lack of
+   connectivity vary but are primarily the result of service provider
+   policies and network limitations.
+
+   Automatic Multicast Tunneling (AMT) is a protocol that uses UDP-based
+   encapsulation to overcome the aforementioned lack of multicast
+   connectivity.  AMT enables sites, hosts, or applications that do not
+   have native multicast access to a network with multicast connectivity
+   to a source, to request and receive Source-Specific Multicast (SSM)
+   [RFC4607] and Any-Source Multicast (ASM) [RFC1112] traffic from a
+   network that does provide multicast connectivity to that source.
+
+2.  Applicability
+
+   This document 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.  This document does not
+   describe any methods for sourcing multicast traffic from isolated
+   sites, as this topic is out of scope.
+
+   AMT is not intended to be used as a substitute for native multicast,
+   especially in conditions or environments requiring high traffic flow.
+   AMT uses unicast replication to reach multiple receivers, and the
+   bandwidth cost for this replication will be higher than that required
+   if the receivers were reachable via native multicast.
+
+   AMT is designed to be deployed at the border of networks possessing
+   native multicast capabilities where access and provisioning can be
+   managed by the AMT service provider.
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                    [Page 3]
+
+RFC 7450                           AMT                     February 2015
+
+
+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].
+
+3.2.  Definitions
+
+   This document adopts the following definitions for use in describing
+   the protocol:
+
+   Downstream:
+      A downstream interface or connection that faces away from the
+      multicast distribution root or towards multicast receivers.
+
+   Upstream:
+      An upstream interface or connection that faces a multicast
+      distribution root or source.
+
+   Non-Broadcast Multi-Access (NBMA):
+      An NBMA network or interface is one to which multiple network
+      nodes (hosts or routers) are attached, but where packets are
+      transmitted directly from one node to another node over a virtual
+      circuit or physical link.  NBMA networks do not support multicast
+      or broadcast traffic -- a node that sources multicast traffic must
+      replicate the multicast packets for separate transmission to each
+      node that has requested the multicast traffic.
+
+   Multicast Receiver:
+      An entity that requests and receives multicast traffic.  A
+      receiver may be a router, host, application, or application
+      component.  The method by which a receiver transmits group
+      membership requests and receives multicast traffic varies
+      according to receiver type.
+
+   Group Membership Database:
+      A group membership database describes the current multicast
+      subscription state (also referred to as "reception state") for an
+      interface or system.  See Section 3 of [RFC3376] for a detailed
+      definition.
+
+   Reception State:
+      The multicast subscription state of a pseudo-interface, virtual
+      interface, or physical network interface.  Often synonymous with
+      group membership database.
+
+
+
+
+Bumgardner                   Standards Track                    [Page 4]
+
+RFC 7450                           AMT                     February 2015
+
+
+   Subscription:
+      A group or state entry in a group membership database or reception
+      state table.  The presence of a subscription entry indicates
+      membership in an IP multicast group.
+
+   Group Membership Protocol:
+      The term "group membership protocol" is used as a generic
+      reference to the Internet Group Management Protocol (IGMP)
+      [RFC1112] [RFC2236] [RFC3376] or the Multicast Listener Discovery
+      protocol [RFC2710] [RFC3810].
+
+   Multicast Protocol:
+      The term "multicast protocol" is used as a generic reference to
+      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):
+      Network Address Translation is the process of modifying the source
+      IP address and port numbers carried by an IP packet while
+      transiting a network node (see [RFC2663]).  Intervening NAT
+      devices may change the source address and port carried by messages
+      sent from an AMT gateway to an AMT relay, possibly producing
+      changes in protocol state and behavior.
+
+   Anycast:
+      A network addressing and routing method in which packets from a
+      single sender are routed to the topologically nearest node in a
+      group of potential receivers all identified by the same
+      destination address.  See [RFC4786].
+
+3.3.  Abbreviations
+
+      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).
+
+
+
+Bumgardner                   Standards Track                    [Page 5]
+
+RFC 7450                           AMT                     February 2015
+
+
+      NBMA - Non-Broadcast Multi-Access (network, interface, or mode).
+
+      PIM - Protocol Independent Multicast.
+
+      SSM - Source-Specific Multicast.
+
+4.  Protocol Overview
+
+   This section provides an informative description of the protocol.  A
+   normative description of the protocol and implementation requirements
+   may be found in Section 5.
+
+4.1.  General Architecture
+
+   Isolated Site |    Unicast Network   |  Native Multicast
+                 |      (Internet)      |
+                 |                      |
+                 |                      |
+                 |   Group Membership   |
+      +-------+ =========================> +-------+ Multicast +------+
+      |Gateway|  |                      |  | Relay |<----//----|Source|
+      +-------+ <========================= +-------+           +------+
+                 |   Multicast Data     |
+                 |                      |
+                 |                      |
+
+                     Figure 1: Basic AMT Architecture
+
+   The AMT protocol employs a client-server model in which a "gateway"
+   sends requests to receive specific multicast traffic to a "relay"
+   that responds by delivering the requested multicast traffic back to
+   the gateway.
+
+   Gateways are generally deployed within networks that lack multicast
+   support or lack connectivity to a multicast-enabled network
+   containing multicast sources of interest.
+
+   Relays are deployed within multicast-enabled networks that contain,
+   or have connectivity to, multicast sources.
+
+4.1.1.  Relationship to IGMP and MLD Protocols
+
+   AMT relies on the Internet Group Management Protocol (IGMP) [RFC3376]
+   and the Multicast Listener Discovery (MLD) protocol [RFC3810] to
+   provide the functionality required to manage, communicate, and act on
+   changes in multicast group membership.  A gateway or relay
+   implementation does not necessarily require a fully functional,
+   conforming implementation of IGMP or MLD to adhere to this
+
+
+
+Bumgardner                   Standards Track                    [Page 6]
+
+RFC 7450                           AMT                     February 2015
+
+
+   specification, but the protocol description that appears in this
+   document assumes that this is the case.  The minimum functional and
+   behavioral requirements for the IGMP and MLD protocols are described
+   in Sections 5.2.1 and 5.3.1.
+
+               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/MLD
+
+   A gateway runs the host portion of the IGMP and MLD protocols to
+   generate group membership updates that are sent via AMT messages to a
+   relay.  A relay runs the router portion of the IGMP and MLD protocols
+   to process the group membership updates to produce the required
+   changes in multicast forwarding state.  A relay uses AMT messages to
+   send incoming multicast IP datagrams to gateways according to their
+   current group membership state.
+
+   The primary function of AMT is to provide the handshaking,
+   encapsulation, and decapsulation required to transport the IGMP and
+   MLD messages and multicast IP datagrams between the gateways and
+   relays.  The IGMP and MLD messages that are exchanged between
+   gateways and relays are encapsulated as complete IP datagrams within
+   AMT control messages.  Multicast IP datagrams are replicated and
+   encapsulated in AMT data messages.  All AMT messages are sent via
+   unicast UDP/IP.
+
+4.1.2.  Gateways
+
+   The downstream side of a gateway services one or more receivers --
+   the gateway accepts group membership requests from receivers and
+   forwards requested multicast traffic back to those receivers.  The
+   gateway functionality may be directly implemented in the host
+   requesting the multicast service or within an application running on
+   a host.
+
+
+
+
+
+Bumgardner                   Standards Track                    [Page 7]
+
+RFC 7450                           AMT                     February 2015
+
+
+   The upstream side of a gateway connects to relays.  A gateway sends
+   encapsulated IGMP and MLD messages to a relay to indicate an interest
+   in receiving specific multicast traffic.
+
+4.1.2.1.  Architecture
+
+   Each gateway possesses a logical pseudo-interface:
+
+     join/leave ---+                   +----------+
+                   |                   |          |
+                   V      IGMPv3/MLDv2 |          |
+              +---------+ General Query|          |   AMT
+              |IGMP/MLD |<-------------|   AMT    | Messages +------+
+              |Host-Mode|              | Gateway  |<-------->|UDP/IP|
+              |Protocol |------------->|Pseudo-I/F|          +------+
+              +---------+   IGMP/MLD   |          |             ^
+                             Report    |          |             |
+                           Leave/Done  |          |             V
+    IP Multicast <---------------------|          |           +---+
+                                       +----------+           |I/F|
+                                                              +---+
+
+                  Figure 3: AMT Gateway Pseudo-Interface
+
+   The pseudo-interface is conceptually a network interface on which the
+   gateway executes the host portion of the IPv4/IGMP (v2 or v3) and
+   IPv6/MLD (v1 or v2) protocols.  The multicast reception state of the
+   pseudo-interface is manipulated using the IGMP or MLD service
+   interface.  The IGMP and MLD host protocols produce IP datagrams
+   containing group membership messages that the gateway will send to
+   the relay.  The IGMP and MLD protocols also supply the retransmission
+   and timing behavior required for protocol robustness.
+
+   All AMT encapsulation, decapsulation, and relay interaction are
+   assumed to occur within the pseudo-interface.
+
+   A gateway host or application may create separate interfaces for
+   IPv4/IGMP and IPv6/MLD.  A gateway host or application may also
+   require additional pseudo-interfaces for each source or domain-
+   specific relay address.
+
+   Within this document, the term "gateway" may be used as a generic
+   reference to an entity executing the gateway protocol, a gateway
+   pseudo-interface, or a gateway device that has one or more interfaces
+   connected to a unicast internetwork and one or more AMT gateway
+   pseudo-interfaces.
+
+
+
+
+
+Bumgardner                   Standards Track                    [Page 8]
+
+RFC 7450                           AMT                     February 2015
+
+
+   The following diagram illustrates how an existing host IP stack
+   implementation might be used to provide AMT gateway functionality to
+   a multicast application:
+
+           +-----------------------------------------------------+
+           |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 Example
+
+   In this example, the host IP stack uses a virtual network interface
+   to interact with a gateway pseudo-interface implementation.
+
+
+
+
+Bumgardner                   Standards Track                    [Page 9]
+
+RFC 7450                           AMT                     February 2015
+
+
+4.1.2.2.  Use Cases
+
+   Use cases for gateway functionality include the following:
+
+   IGMP/MLD Proxy
+      An IGMP/MLD proxy that runs AMT on an upstream interface and
+      router-mode IGMP/MLD on downstream interfaces to provide host
+      access to multicast traffic via the IGMP and MLD protocols.
+
+   Virtual Network Interface
+      A virtual network interface or pseudo-network device driver that
+      runs AMT on a physical network interface to provide socket-layer
+      access to multicast traffic via the IGMP/MLD service interface
+      provided by the host IP stack.
+
+   Application
+      An application or application component that implements and
+      executes IGMP/MLD and AMT internally to gain access to multicast
+      traffic.
+
+4.1.3.  Relays
+
+   The downstream side of a relay services gateways -- the relay accepts
+   encapsulated IGMP and MLD group membership messages from gateways and
+   encapsulates and forwards the requested multicast traffic back to
+   those gateways.
+
+   The upstream side of a relay communicates with a native multicast
+   infrastructure -- the relay sends join and prune/leave requests
+   towards multicast sources and accepts requested multicast traffic
+   from those sources.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 10]
+
+RFC 7450                           AMT                     February 2015
+
+
+4.1.3.1.  Architecture
+
+   Each relay possesses a logical pseudo-interface:
+
+                                       +------------------------------+
+                     +--------+        | Multicast Control Plane      |
+                     |        |IGMP/MLD|                              |
+                     |        | Query* | +------------+  +----------+ |
+                     |        |<---//----|IGMPv3/MLDv2|  |Multicast | |
+              AMT    |        |        | |Router-Mode |->|Routing   |<->
+   +------+ Messages | AMT    |----//--->|Protocol    |  |Protocol  | |
+   |UDP/IP|<-------->| Relay  |IGMP/MLD| +------------+  +----------+ |
+   +------+          | Pseudo-| Report |      |               |       |
+      ^              | I/F    | Leave/ +------|---------------|-------+
+      |              |        |  Done         |               |
+      |              |        |               v               |
+      V              |        | IP        +-----------+       |
+    +---+            |        | Multicast |Multicast  |<------+
+    |I/F|            |        |<---//-----|Forwarding |
+    +---+            +--------+           |Plane      |<--- IP Multicast
+                                          +-----------+
+
+    * Queries, if generated, are consumed by the pseudo-interface.
+
+            Figure 5: AMT Relay Pseudo-Interface (Router-Based)
+
+   The pseudo-interface is conceptually a network interface on which the
+   relay runs the router portion of the IPv4/IGMPv3 and IPv6/MLDv2
+   protocols.  Relays do not send unsolicited IGMPv3/MLDv2 query
+   messages to gateways so relays must consume or discard any local
+   queries normally generated by IGMPv3 or MLDv2.  Note that the
+   protocol mandates the use of IGMPv3 and MLDv2 for query messages.
+   The AMT protocol is primarily intended for use in SSM applications
+   and relies on several values provided by IGMPv3/MLDv2 to control
+   gateway behavior.
+
+   A relay maintains group membership state for each gateway connected
+   through the pseudo-interface as well as for the entire
+   pseudo-interface (if multiple gateways are managed via a single
+   interface).  Multicast packets received on upstream interfaces on the
+   relay are routed to the pseudo-interface where they are replicated,
+   encapsulated, and sent to interested gateways.  Changes in the
+   pseudo-interface group membership state may trigger the transmission
+   of multicast protocol requests upstream towards a given source or
+   rendezvous point and cause changes in internal routing/forwarding
+   state.
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 11]
+
+RFC 7450                           AMT                     February 2015
+
+
+   The relay pseudo-interface is an architectural abstraction used to
+   describe AMT protocol operation.  For the purposes of this document,
+   the pseudo-interface is most easily viewed as an interface to a
+   single gateway -- encapsulation, decapsulation, and other
+   AMT-specific processing occurs "within" the pseudo-interface while
+   forwarding and replication occur outside of it.
+
+   An alternative view is to treat the pseudo-interface as a
+   non-broadcast multi-access (NBMA) network interface whose link layer
+   is the unicast-only network over which AMT messages are exchanged
+   with gateways.  Individual gateways are conceptually treated as
+   logical NBMA links on the interface.  In this architectural model,
+   group membership tracking, replication, and forwarding functions
+   occur in the pseudo-interface.
+
+   This document does not specify any particular architectural solution
+   -- a relay developer may choose to implement and distribute protocol
+   functionality as required to take advantage of existing relay
+   platform services and architecture.
+
+   Within this document, the term "relay" may be used as a generic
+   reference to an entity executing the relay protocol, a relay
+   pseudo-interface, or a relay device that has one or more network
+   interfaces with multicast connectivity to a native multicast
+   infrastructure, zero or more interfaces connected to a unicast
+   internetwork, and one or more relay pseudo-interfaces.
+
+4.1.3.2.  Use Cases
+
+   Use cases for relay functionality include the following:
+
+   Multicast Router
+      A multicast router that runs AMT on a downstream interface to
+      provide gateway access to multicast traffic.  A "relay router"
+      uses a multicast routing protocol (e.g., PIM-SM [RFC4601]) to
+      construct a forwarding path for multicast traffic by sending join
+      and prune messages to neighboring routers to join or leave
+      multicast distribution trees for a given SSM source or ASM
+      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 to join and leave specific SSM or ASM groups.
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 12]
+
+RFC 7450                           AMT                     February 2015
+
+
+4.1.4.  Deployment
+
+   The AMT protocol calls for a relay deployment model that uses anycast
+   addressing [RFC1546] [RFC4291] to pair gateways with relays.
+
+   Under this approach, one or more relays advertise a route for the
+   same IP address prefix.  To find a relay with which to communicate, a
+   gateway sends a message to an anycast IP address within that prefix.
+   This message is routed to the topologically nearest relay that has
+   advertised the prefix.  The relay that receives the message responds
+   by sending its unicast address back to the gateway.  The gateway uses
+   this address as the destination address for any messages it
+   subsequently sends to the relay.
+
+   The use of anycast addressing provides the following benefits:
+
+   o  Relays may be deployed at multiple locations within a single
+      multicast-enabled network.  Relays might be installed "near"
+      gateways to reduce bandwidth requirements and latency and to limit
+      the number of gateways that might be serviced by a single relay.
+
+   o  Relays may be added or removed at any time, thereby allowing
+      staged deployment, scaling, and hot-swapping -- the relay
+      discovery process will always return the nearest operational
+      relay.
+
+   o  Relays may take themselves offline when they exhaust resources
+      required to service additional gateways.  Existing gateway
+      connections may be preserved, but new gateway requests would be
+      routed to the next-nearest relay.
+
+4.1.4.1.  Public versus Private
+
+   Ideally, the AMT protocol would provide a universal solution for
+   connecting receivers to multicast sources, so that any gateway could
+   be used to access any globally advertised multicast source via
+   publicly accessible, widely deployed relays.  Unfortunately, today's
+   Internet does not yet allow this, because many relays will lack
+   native multicast access to sources even though they may be globally
+   accessible via unicast.
+
+   In these cases, a provider may deploy relays within their own source
+   network to allow for multicast distribution within that network.
+   Gateways that use these relays must use a provider-specific relay
+   discovery mechanism or a private anycast address to obtain access to
+   these relays.
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 13]
+
+RFC 7450                           AMT                     February 2015
+
+
+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 passing
+   through a network.  While congestion remediation might be provided by
+   multicast receiver applications via multicast group selection or
+   upstream reporting mechanisms, there are no means by which to ensure
+   that such mechanisms are employed.  To limit the possible congestion
+   across a network or wider Internet, AMT service providers are
+   expected to deploy AMT relays near the provider's network border and
+   its interface with edge routers.  The provider must limit relay
+   address advertisements to those edges to prevent distant gateways
+   from being able to access a relay and potentially generate flows that
+   consume or exceed the capacity of intervening links.
+
+4.1.5.  Discovery
+
+   To execute the gateway portion of the protocol, a gateway requires a
+   unicast IP address of an operational relay.  This address may be
+   obtained using a number of methods -- it may be statically assigned
+   or dynamically chosen via some form of relay discovery process.
+
+   As described in the previous section, the AMT protocol provides a
+   relay discovery method that relies on anycast addressing.  Gateways
+   are not required to use AMT relay discovery, but all relay
+   implementations must support it.
+
+   The AMT protocol uses the following terminology when describing the
+   discovery process:
+
+   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
+
+   The selection of an anycast Relay Discovery Address may be source
+   dependent, as a relay located via relay discovery must have multicast
+   connectivity to a desired source.
+
+
+
+Bumgardner                   Standards Track                   [Page 14]
+
+RFC 7450                           AMT                     February 2015
+
+
+   Similarly, the selection of a unicast Relay Address may be source
+   dependent, as a relay contacted by a gateway to supply multicast
+   traffic must have native multicast connectivity to the traffic
+   source.
+
+   Methods that might be used to perform source-specific or
+   group-specific relay selection are highly implementation dependent
+   and are not further addressed by this document.  Possible approaches
+   include the use of static lookup tables, DNS-based queries, or a
+   provision of a service interface that accepts join requests on
+   (S,G,relay-discovery-address) or (S,G,relay-address) tuples.
+
+4.1.5.2.  Relay Discovery Address Prefix
+
+   IANA has assigned IPv4 and IPv6 address prefixes for use in
+   advertising and discovering publicly accessible relays.
+
+   A Relay Discovery Address is constructed from an address prefix by
+   setting the low-order octet of the prefix address to 1 (for both IPv4
+   and IPv6).  All remaining addresses within each prefix are reserved
+   for future use.
+
+   Public relays must advertise a route to the address prefix (e.g., via
+   BGP [RFC4271]) and configure an interface to respond to the Relay
+   Discovery Address.
+
+   The discovery address prefixes are described in Section 7.
+
+4.2.  General Operation
+
+4.2.1.  Message Sequences
+
+   The AMT protocol defines the following messages for control and
+   encapsulation.  These messages are exchanged as UDP/IP datagrams, one
+   message per datagram.
+
+   Relay Discovery:
+      Sent by gateways to solicit a Relay Advertisement from any relay.
+      Used to find a relay with which to communicate.
+
+   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.
+
+
+
+
+Bumgardner                   Standards Track                   [Page 15]
+
+RFC 7450                           AMT                     February 2015
+
+
+   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 following sections describe how these messages are exchanged to
+   execute the protocol.
+
+4.2.1.1.  Relay Discovery Sequence
+
+                       Gateway               Relay
+                       -------               -----
+                          :                    :
+                          |                    |
+                      [1] |Relay Discovery     |
+                          |------------------->|
+                          |                    |
+                          | Relay Advertisement| [2]
+                          |<-------------------|
+                      [3] |                    |
+                          :                    :
+
+                  Figure 6: AMT Relay Discovery Sequence
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 16]
+
+RFC 7450                           AMT                     February 2015
+
+
+   The following sequence describes how the Relay Discovery and Relay
+   Advertisement messages are used to find a relay with which to
+   communicate:
+
+   1.  The gateway sends a Relay Discovery message containing a random
+       nonce to the Relay Discovery Address.  If the Relay Discovery
+       Address is an anycast address, the message is routed to the
+       topologically nearest network node that advertises that address.
+
+   2.  The node receiving the Relay Discovery message sends a Relay
+       Advertisement message back to the source of the Relay Discovery
+       message.  The message carries a copy of the nonce contained in
+       the Relay Discovery message and the unicast IP address of a
+       relay.
+
+   3.  When the gateway receives the Relay Advertisement message, it
+       verifies that the nonce matches the one sent in the Relay
+       Discovery message and, if it does, uses the Relay Address carried
+       by the Relay Advertisement as the destination address for
+       subsequent AMT messages.
+
+   Note that the responder need not be a relay -- the responder may
+   obtain a Relay Address by some other means and return the result in
+   the Relay Advertisement (i.e., the responder is a load-balancer or
+   broker).
+
+4.2.1.2.  Membership Update Sequence
+
+   There exists a significant difference between normal IGMP and MLD
+   behavior and that required by AMT.  An IGMP/MLD router acting as a
+   querier normally transmits query messages on a network interface to
+   construct and refresh group membership state for the connected
+   network.  These query messages are multicast to all IGMP/MLD-enabled
+   hosts on the network.  Each host responds by multicasting report
+   messages that describe their current multicast reception state.
+
+   However, AMT does not allow relays to send unsolicited query messages
+   to gateways, as the set of active gateways may be unknown to the
+   relay and potentially quite large.  Instead, AMT requires each
+   gateway to periodically send a message to a relay to solicit a query
+   response.  A gateway accomplishes this by sending a Request message
+   to a relay.  The relay responds by sending a Membership Query message
+   back to the gateway.  The Membership Query message carries an
+   encapsulated query that is processed by the IGMP or MLD protocol
+   implementation on the gateway to produce a membership/listener
+   report.  Each time the gateway receives a Membership Query message,
+   it starts a timer whose expiration will trigger the start of a new
+   Request->Membership Query message exchange.  This timer-driven
+
+
+
+Bumgardner                   Standards Track                   [Page 17]
+
+RFC 7450                           AMT                     February 2015
+
+
+   sequence is used to mimic the transmission of a periodic query by an
+   IGMP/MLD router.  This query cycle may continue indefinitely once
+   started by sending the initial Request message.
+
+   A membership update occurs when an IGMP or MLD report, leave, or done
+   message is passed to the gateway pseudo-interface.  These messages
+   may be produced as a result of the aforementioned query processing or
+   as a result of receiver interaction with the IGMP/MLD service
+   interface.  Each report is encapsulated and sent to the relay after
+   the gateway has successfully established communication with the relay
+   via a Request and Membership Query message exchange.  If a report is
+   passed to the pseudo-interface before the gateway has received a
+   Membership Query message from the relay, the gateway may discard the
+   report or queue the report for delivery after a Membership Query is
+   received.  Subsequent IGMP/MLD report/leave/done messages that are
+   passed to the pseudo-interface are immediately encapsulated and
+   transmitted to the relay.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 18]
+
+RFC 7450                           AMT                     February 2015
+
+
+           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)
+
+
+
+Bumgardner                   Standards Track                   [Page 19]
+
+RFC 7450                           AMT                     February 2015
+
+
+   The following sequence describes how the Request, Membership Query,
+   and Membership Update messages are used to report current group
+   membership state or changes in group membership state:
+
+   1.   A gateway sends a Request message to the relay that contains a
+        random nonce and a flag indicating whether the relay should
+        return an IGMPv3 or MLDv2 General Query.
+
+   2.   When the relay receives a Request message, it generates a
+        message authentication code (MAC), typically, by computing a
+        hash digest from the message source IP address, source UDP port,
+        request nonce, and a private secret.  The relay then sends a
+        Membership Query message to the gateway that contains the
+        request nonce, the MAC, and an IGMPv3 or MLDv2 General Query.
+
+   3.   When the gateway receives a Membership Query message, it
+        verifies that the request nonce matches the one sent in the last
+        Request, and if it does, the gateway saves the request nonce and
+        MAC for use in sending subsequent Membership Update messages.
+        The gateway starts a timer whose expiration will trigger the
+        transmission of a new Request message and extracts the
+        encapsulated General Query message for processing by the IGMP or
+        MLD protocol.  The query timer duration is specified by the
+        relay in the Querier's Query Interval Code (QQIC) field in the
+        IGMPv3 or MLDv2 General Query.  The QQIC field is defined in
+        Section 4.1.7 of [RFC3376] and Section 5.1.9 of [RFC3810]).
+
+   4.   The gateway's IGMP or MLD protocol implementation processes the
+        General Query to produce a current-state report.
+
+   5.   When an IGMP or MLD report is passed to the pseudo-interface,
+        the gateway encapsulates the report in a Membership Update
+        message and sends it to the relay.  The request nonce and MAC
+        fields in the Membership Update are assigned the values from the
+        last Membership Query message received for the corresponding
+        group membership protocol (IGMPv3 or MLDv2).
+
+   6.   When the relay receives a Membership Update message, it computes
+        a MAC from the message source IP address, source UDP port,
+        request nonce, and a private secret.  The relay accepts the
+        Membership Update message if the received MAC matches the
+        computed MAC; otherwise, the message is ignored.  If the message
+        is accepted, the relay may proceed to allocate, refresh, or
+        modify tunnel state.  This includes making any group membership,
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 20]
+
+RFC 7450                           AMT                     February 2015
+
+
+        routing, and forwarding state changes, and also issuing any
+        upstream protocol requests required to satisfy the state change.
+        The diagram illustrates two scenarios:
+
+        A.  The gateway has not previously reported any group
+            subscriptions and the report does not contain any group
+            subscriptions, so the relay takes no action.
+
+        B.  The gateway has previously reported a group subscription, so
+            the current-state report lists all current subscriptions.
+            The relay responds by refreshing tunnel or group state and
+            resetting any related timers.
+
+   7.   A receiver indicates to the gateway that it wishes to join
+        (allow) or leave (block) specific multicast traffic.  This
+        request is typically made using some form of IGMP/MLD service
+        interface (as described in Section 2 of [RFC3376] and Section 3
+        of [RFC3810]).  The IGMP/MLD protocol responds by generating an
+        IGMP or MLD state-change message.
+
+   8.   When an IGMP or MLD report/leave/done message is passed to the
+        pseudo-interface, the gateway encapsulates the message in a
+        Membership Update message and sends it to the relay.  The
+        request nonce and MAC fields in the Membership Update are
+        assigned the values from the last Membership Query message
+        received for the corresponding group membership protocol (IGMP
+        or MLD).
+
+        The IGMP and MLD protocols may generate multiple messages to
+        provide robustness against packet loss -- each of these must be
+        encapsulated in a new Membership Update message and sent to the
+        relay.  The Querier's Robustness Variable (QRV) field in the
+        last IGMP/MLD query delivered to the IGMP/MLD protocol is
+        typically used to specify the number of repetitions (i.e., the
+        host adopts the QRV value as its own Robustness Variable value).
+        The QRV field is defined in Section 4.1.6 of [RFC3376] and
+        Section 5.1.8 of [RFC3810].
+
+   9.   When the relay receives a Membership Update message, it again
+        computes a MAC from the message source IP address, source UDP
+        port, request nonce, and a private secret.  The relay accepts
+        the Membership Update message if the received MAC matches the
+        computed MAC; otherwise, the message is ignored.  If the message
+        is accepted, the relay processes the encapsulated IGMP/MLD and
+        allocates, modifies, or deletes tunnel state accordingly.  This
+        includes making any group membership, routing, and forwarding
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 21]
+
+RFC 7450                           AMT                     February 2015
+
+
+        state changes, and also issuing any upstream protocol requests
+        required to satisfy the state change.  The diagram illustrates
+        two scenarios:
+
+        A.  The gateway wishes to add a group subscription.
+
+        B.  The gateway wishes to delete a previously reported group
+            subscription.
+
+   10.  Multicast datagrams transmitted from a source travel through the
+        native multicast infrastructure to the relay.  When the relay
+        receives a multicast IP datagram that carries a source and
+        destination address for which a gateway has expressed an
+        interest in receiving (via the Membership Update message), it
+        encapsulates the datagram into a Multicast Data message and
+        sends it to the gateway using the source IP address and UDP port
+        carried by the Membership Update message as the destination
+        address.
+
+   11.  When the gateway receives a Multicast Data message, it extracts
+        the multicast packet from the message and passes it on to the
+        appropriate receivers.
+
+   12.  When the query timer expires, the gateway sends a new Request
+        message to the relay to start a new membership update cycle.
+
+   The MAC-based source-authentication mechanism described above
+   provides a simple defense against malicious attempts to exhaust relay
+   resources via source-address spoofing.  Flooding a relay with spoofed
+   Request or Membership Update messages may consume computational
+   resources and network bandwidth but will not result in the allocation
+   of state, because the Request message is stateless and spoofed
+   Membership Update messages will fail source authentication and be
+   rejected by the relay.
+
+   A relay will only allocate new tunnel state if the IGMP/MLD report
+   carried by the Membership Update message creates one or more group
+   subscriptions.
+
+   A relay deallocates tunnel state after one of the following events:
+   the gateway sends a Membership Update message containing a report
+   that results in the deletion of all remaining group subscriptions,
+   the IGMP/MLD state expires (due to lack of refresh by the gateway),
+   or the relay receives a valid Teardown message from the gateway (see
+   Section 4.2.1.3).
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 22]
+
+RFC 7450                           AMT                     February 2015
+
+
+   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 request that it stop
+   delivering Multicast Data messages to a tunnel endpoint created by an
+   earlier Membership Update message.  This message is intended to be
+   used following a gateway address change (see Section 4.2.2.1) to stop
+   the transmission of undeliverable or duplicate Multicast Data
+   messages.  Gateway support for the Teardown message is RECOMMENDED.
+   Gateways are not required to send them and may instead rely on group
+   membership to expire on the relay.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 23]
+
+RFC 7450                           AMT                     February 2015
+
+
+                      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)
+
+
+
+Bumgardner                   Standards Track                   [Page 24]
+
+RFC 7450                           AMT                     February 2015
+
+
+   The following sequence describes how the Membership Query and
+   Teardown messages are used to detect an address change and stop the
+   delivery of Multicast Data messages to an address:
+
+   1.  A gateway sends a Request message containing a random nonce to
+       the relay.
+
+   2.  The relay sends a Membership Query message to the gateway that
+       contains the source IP address (gADDR) and source UDP port
+       (gPORT) values from the Request message.  These values will be
+       used to identify the tunnel should one be created by a subsequent
+       Membership Update message.
+
+   3.  When the gateway receives a Membership Query message that carries
+       the gateway address fields, it compares the gateway IP address
+       and UDP port number values with those received in the previous
+       Membership Query (if any).  If these values do not match, this
+       indicates that the Request message arrived at the relay carrying
+       a different source address than the one sent previously.  At this
+       point in the sequence, no change in source address or port has
+       occurred.
+
+   4.  The gateway sends a new Request message to the relay.  However,
+       this Request message arrives at the relay carrying a different
+       source address than that of the previous Request due to some
+       change in network interface, address assignment, network
+       topology, or NAT mapping.
+
+   5.  The relay again responds by sending a Membership Query message to
+       the gateway that contains the new source IP address (gADDR') and
+       source UDP port (gPORT') values from the Request message.
+
+   6.  When the gateway receives the Membership Query message, it
+       compares the gateway address and port number values against those
+       returned in the previous Membership Query message.
+
+   7.  If the reported address or port has changed, the gateway sends a
+       Teardown message to the relay that contains the request nonce,
+       MAC, gateway IP address, and gateway port number returned in the
+       earlier Membership Query message.  The gateway may send the
+       Teardown message multiple times where the number of repetitions
+       is governed by the Querier's Robustness Variable (QRV) value
+       contained in the IGMPv3/MLDv2 General Query carried by the
+       original Membership Query (see Section 4.1.6 of [RFC3376] and
+       Section 5.1.8 of [RFC3810]).  The gateway continues to process
+       the new Membership Query message as usual.
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 25]
+
+RFC 7450                           AMT                     February 2015
+
+
+   8.  When the relay receives a Teardown message, it computes a MAC
+       from the message source IP address, source UDP port, request
+       nonce, and a private secret.  The relay accepts the Teardown
+       message if the received MAC matches the computed MAC; otherwise,
+       the message is ignored.  If the message is accepted, the relay
+       makes any group membership, routing, and forwarding state changes
+       required to stop the transmission of Multicast Data messages to
+       that address.
+
+4.2.1.4.  Timeout and Retransmission
+
+   The AMT protocol does not establish any requirements regarding what
+   actions a gateway should take if it fails to receive a response from
+   a relay.  A gateway implementation may wait for an indefinite period
+   of time to receive a response, may set a time limit on how long to
+   wait for a response, may retransmit messages should the time limit be
+   reached, may limit the number of retransmissions, or may simply
+   report an error.
+
+   For example, a gateway may retransmit a Request message if it fails
+   to receive a Membership Query or expected Multicast Data messages
+   within some time period.  If the gateway fails to receive any
+   response to a Request after several retransmissions or within some
+   maximum period of time, it may reenter the relay discovery phase in
+   an attempt to find a new relay.  This topic is addressed in more
+   detail in Section 5.2.
+
+4.2.2.  Tunneling
+
+   From the standpoint of a relay, an AMT "tunnel" is identified by the
+   IP address and UDP port pair used as the destination address for
+   sending encapsulated multicast IP datagrams to a gateway.  In this
+   document, we refer to this address as the tunnel endpoint address.
+
+   A gateway sends a Membership Update message to a relay to add or
+   remove group subscriptions to a tunnel endpoint.  The tunnel endpoint
+   is identified by the source IP address and source UDP port carried by
+   the Membership Update message when it arrives at a relay (this
+   address may differ from that carried by the message when it exited
+   the gateway as a result of network address translation).
+
+   The Membership Update messages sent by a single gateway host may
+   originate from several source addresses or ports -- each unique
+   combination represents a unique tunnel endpoint.  A single gateway
+   host may legitimately create and accept traffic on multiple tunnel
+   endpoints, e.g., the gateway may use separate ports for the IPv4/IGMP
+   and IPv6/MLD protocols.
+
+
+
+
+Bumgardner                   Standards Track                   [Page 26]
+
+RFC 7450                           AMT                     February 2015
+
+
+   A tunnel is "created" when a gateway sends a Membership Update
+   message containing an IGMP or MLD membership report that creates one
+   or more group subscriptions when none currently existed for that
+   tunnel endpoint address.
+
+   A tunnel ceases to exist when all group subscriptions for a tunnel
+   endpoint are deleted.  This may occur as a result of the following
+   events:
+
+   o  The gateway sends an IGMP or MLD report, leave, or done message to
+      the relay that deletes the last group subscription linked to the
+      tunnel endpoint.
+
+   o  The gateway sends a Teardown message to the relay that causes it
+      to delete any and all subscriptions bound to the tunnel endpoint.
+
+   o  The relay stops receiving updates from the gateway until such time
+      that per-group or per-tunnel timers expire, causing the relay to
+      delete the subscriptions.
+
+   The tunneling approach described above conceptually transforms a
+   unicast-only internetwork into an NBMA link layer, over which
+   multicast traffic may be delivered.  Each relay, plus the set of all
+   gateways using the relay, together may be thought of as being on a
+   separate logical NBMA link, where the "link layer" address is a UDP/
+   IP address-port pair provided by the Membership Update message.
+
+4.2.2.1.  Address Roaming
+
+   As described above, each time a relay receives a Membership Update
+   message from a new source address-port pair, the group subscriptions
+   described by that message apply to the tunnel endpoint identified by
+   that address.
+
+   This can cause problems for a gateway if the address carried by the
+   messages it sends to a relay changes unexpectedly.  These changes may
+   cause the relay to transmit duplicate, undeliverable, or unrequested
+   traffic back towards the gateway or an intermediate device.  This may
+   create congestion and have negative consequences for the gateway, its
+   network, or multicast receivers and in some cases may also produce a
+   significant amount of ICMP traffic directed back towards the relay by
+   a NAT, router, or gateway host.
+
+
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 27]
+
+RFC 7450                           AMT                     February 2015
+
+
+   There are several scenarios in which the address carried by messages
+   sent by a gateway may change without that gateway's knowledge -- for
+   example, when:
+
+   o  The message originates from a different interface on a gateway
+      that possesses multiple interfaces.
+
+   o  The DHCP assignment for a gateway interface changes.
+
+   o  The gateway roams to a different wireless network.
+
+   o  The address mapping applied by an intervening network-translation
+      device (NAT) changes as a result of mapping expiration or routing
+      changes in a multihomed network.
+
+   In the case where the address change occurs between the transmission
+   of a Request message and subsequent Membership Update messages, the
+   relay will simply ignore any Membership Update messages from the new
+   address because MAC authentication will fail (see Section 4.2.1.2).
+   The relay may continue to transmit previously requested traffic, but
+   no duplication will occur, i.e., the possibility for the delivery of
+   duplicate traffic does not arise until a Request message is received
+   from the new address.
+
+   The protocol provides a method for a gateway to detect an address
+   change and explicitly request that the relay stop sending traffic to
+   a previous address.  This process involves the Membership Query and
+   Teardown messages and is described in Section 4.2.1.3.
+
+4.2.2.2.  Network Address Translation
+
+   The messages sent by a gateway to a relay may be subject to network
+   address translation (NAT) -- the source IP address and UDP port
+   carried by an IP packet sent by the gateway may be modified multiple
+   times before arriving at the relay.  In the most restrictive form of
+   NAT, the NAT device will create a new mapping for each combination of
+   source and destination IP address and UDP port.  In this case,
+   bidirectional communication can only be conducted by sending outgoing
+   packets to the source address and port carried by the last incoming
+   packet.
+
+
+
+
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 28]
+
+RFC 7450                           AMT                     February 2015
+
+
+            Membership Update                 Membership Update
+            src: iADDR:iPORT                  src: eADDR:ePORT
+            dst: rADDR:rPORT                  dst: rADDR:rPORT
+                               +---------+
+                               |   NAT   |
+        +---------+           +-----------+          +---------+
+        |         |---------->|           |--------->|         |
+        | Gateway |           |  Mapping  |          |  Relay  |
+        |         |<----------|           |<---------|         |
+        +---------+           +-----------+          +---------+
+                               |         |
+                               +---------+
+            Multicast Data                    Multicast Data
+            src: rADDR:rPORT                  src: rADDR:rPORT
+            dst: iADDR:iPORT                  dst: eADDR:ePORT
+
+               Figure 9: Network Address Translation in AMT
+
+   AMT provides automatic NAT traversal by using the source IP address
+   and UDP port carried by the Membership Update message as received at
+   the relay as the destination address for any Multicast Data messages
+   the relay sends back as a result.
+
+   The NAT mapping created by a Membership Update message will
+   eventually expire unless it is refreshed by a passing message.  This
+   refresh will occur each time the gateway performs the periodic update
+   required to refresh group state within the relay (see
+   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 Encapsulation
+
+
+
+Bumgardner                   Standards Track                   [Page 29]
+
+RFC 7450                           AMT                     February 2015
+
+
+   The IGMP and MLD messages used in AMT are exchanged as complete IP
+   datagrams.  These IP datagrams are encapsulated in AMT messages that
+   are transmitted using UDP.  The same holds true for multicast traffic
+   -- each multicast IP datagram or datagram fragment that arrives at
+   the relay is encapsulated in an AMT message and transmitted to one or
+   more gateways via UDP.
+
+   The IP protocol of the encapsulated packets need not match the IP
+   protocol used to send the AMT messages.  AMT messages sent via IPv4
+   may carry IPv6/MLD packets, and AMT messages sent via IPv6 may carry
+   IPv4/IGMP packets.
+
+   The Checksum field contained in the UDP header of the messages
+   requires special consideration.  Of primary concern is the cost of
+   computing a checksum on each replicated multicast packet after it is
+   encapsulated for delivery to a gateway.  Many routing/forwarding
+   platforms do not possess the capability to compute checksums on
+   UDP-encapsulated packets, as they may not have access to the entire
+   datagram.
+
+   To avoid placing an undue burden on the relay platform, the protocol
+   specifically allows zero-valued UDP checksums on the Multicast Data
+   messages.  This is not an issue in UDP over IPv4, as the UDP Checksum
+   field may be set to zero.  However, this is a problem for UDP over
+   IPv6, as that protocol requires a valid, non-zero checksum in UDP
+   datagrams [RFC2460].  Messages sent over IPv6 with a UDP checksum of
+   zero may fail to reach the gateway.  This is a well-known issue for
+   UDP-based tunneling protocols and is described in [RFC6936].  A
+   recommended solution is described in [RFC6935].
+
+4.2.2.4.  UDP Fragmentation
+
+   Naive encapsulation of multicast IP datagrams within AMT data
+   messages may produce UDP datagrams that might require fragmentation
+   if their size exceeds the MTU of the network path between the relay
+   and a gateway.  Many multicast applications, especially those related
+   to media streaming, are designed to deliver independent data samples
+   in separate packets, without fragmentation, to ensure that some
+   number of complete samples can be delivered even in the presence of
+   packet loss.  To prevent or reduce undesirable fragmentation, the AMT
+   protocol describes specific procedures for handling multicast
+   datagrams whose encapsulation might exceed the Path MTU.  These
+   procedures are described in Section 5.3.3.6.
+
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 30]
+
+RFC 7450                           AMT                     February 2015
+
+
+5.  Protocol Description
+
+   This section provides a normative description of the AMT protocol.
+
+5.1.  Protocol Messages
+
+   The AMT protocol defines seven message types for control and
+   encapsulation.  These messages are assigned the following 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 are exchanged as IPv4 or IPv6 UDP datagrams.
+
+5.1.1.  Relay Discovery
+
+   A Relay Discovery message is used to solicit a response from a relay
+   in the form of a Relay Advertisement message.
+
+   The UDP/IP datagram containing this message MUST carry a valid,
+   non-zero UDP checksum and carry the following IP address and UDP port
+   values:
+
+   Source IP Address - The IP address of the gateway interface on which
+      the gateway will listen for a relay response.  Note: The value of
+      this field may be changed as a result of network address
+      translation before arriving at the relay.
+
+   Source UDP Port - The UDP port number on which the gateway will
+      listen for a relay response.  Note: The value of this field may be
+      changed as a result of network address translation before arriving
+      at the relay.
+
+   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).
+
+
+
+
+Bumgardner                   Standards Track                   [Page 31]
+
+RFC 7450                           AMT                     February 2015
+
+
+    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.
+
+5.1.1.2.  Type
+
+   The type number for this message is 1.
+
+5.1.1.3.  Reserved
+
+   Reserved bits that MUST be set to zero by the gateway and ignored by
+   the relay.
+
+5.1.1.4.  Discovery Nonce
+
+   A 32-bit random value generated by the gateway and echoed by the
+   relay in a Relay Advertisement message.  This value is used by the
+   gateway to correlate Relay Advertisement messages with Relay
+   Discovery messages.  Discovery nonce generation is described in
+   Section 5.2.3.4.5.
+
+5.1.2.  Relay Advertisement
+
+   The Relay Advertisement message is used to supply a gateway with a
+   unicast IP address of a relay.  A relay sends this message to a
+   gateway when it receives a Relay Discovery message from that gateway.
+
+   The UDP/IP datagram containing this message MUST carry a valid,
+   non-zero UDP checksum and carry the following IP address and UDP port
+   values:
+
+   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).
+
+
+
+
+Bumgardner                   Standards Track                   [Page 32]
+
+RFC 7450                           AMT                     February 2015
+
+
+   Destination IP Address - The source IP address carried by the Relay
+      Discovery message.  Note: The value of this field may be changed
+      as a result of network address translation before arriving at the
+      gateway.
+
+   Destination UDP Port - The source UDP port carried by the Relay
+      Discovery message.  Note: The value of this field may be changed
+      as a result of network address translation before arriving at the
+      gateway.
+
+    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
+
+   Reserved bits that MUST be set to zero by the relay and ignored by
+   the gateway.
+
+5.1.2.4.  Discovery Nonce
+
+   A 32-bit value copied from the Discovery Nonce field
+   (Section 5.1.1.4) contained in the Relay Discovery message.  The
+   gateway uses this value to match a Relay Advertisement to a Relay
+   Discovery message.
+
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 33]
+
+RFC 7450                           AMT                     February 2015
+
+
+5.1.2.5.  Relay Address
+
+   The unicast IPv4 or IPv6 address of the relay.  A gateway uses the
+   length of the UDP datagram containing the Relay Advertisement message
+   to determine the address family, i.e., length - 8 = 4 (IPv4) or 16
+   (IPv6).  The relay returns an IP address for the protocol used to
+   send the Relay Discovery message, i.e., 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 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 containing this message MUST carry a valid,
+   non-zero UDP checksum and carry 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 a response from the relay.  Note: The
+      value of this field may be changed as a result of network address
+      translation before arriving at the relay.
+
+   Source UDP Port - The UDP port number on which the gateway will
+      listen for a response from the relay.  Note: The value of this
+      field may be changed as a result of network address translation
+      before arriving at the relay.
+
+   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
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 34]
+
+RFC 7450                           AMT                     February 2015
+
+
+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
+
+   Reserved bits that MUST be set to zero by the gateway and ignored by
+   the relay.
+
+5.1.3.4.  P Flag
+
+   The P flag is set to indicate which group membership protocol the
+   gateway wishes the relay to use 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
+
+   A 32-bit random value generated by the gateway and echoed by the
+   relay in a Membership Query message.  This value is used by the relay
+   to compute the Response MAC value and is used by the gateway to
+   correlate Membership Query messages with Request messages.  Request
+   Nonce generation is described in 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 receiving a Request
+   message from the 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.
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 35]
+
+RFC 7450                           AMT                     February 2015
+
+
+   The UDP/IP datagram containing this message MUST carry a valid,
+   non-zero UDP checksum and carry the following IP address and UDP port
+   values:
+
+   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: The value of this field may be changed as a result
+      of network address translation before arriving at the gateway.
+
+   Destination UDP Port - The source UDP port carried by the Request
+      message.  Note: The value of this field may be changed as a result
+      of network address translation before arriving at the gateway.
+
+    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
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 36]
+
+RFC 7450                           AMT                     February 2015
+
+
+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
+
+   Reserved bits that MUST be set to zero by the relay and ignored by
+   the gateway.
+
+5.1.4.4.  Limit (L) Flag
+
+   A 1-bit flag set to 1 to indicate that the relay is NOT accepting
+   Membership Update messages from new gateway tunnel endpoints and that
+   it will ignore any that are.  A value of 0 has no special
+   significance -- the relay may or may not be accepting Membership
+   Update messages from new gateway tunnel endpoints.  A gateway checks
+   this flag before attempting to create new group subscription state on
+   the relay to determine whether it should restart relay discovery.  A
+   gateway that has already created group subscriptions on the relay may
+   ignore this flag.  Support for this flag is RECOMMENDED.
+
+5.1.4.5.  Gateway Address (G) Flag
+
+   A 1-bit flag set to 0 to indicate that the message does NOT carry the
+   Gateway Port Number and Gateway IP Address fields, and 1 to indicate
+   that it does.  A relay implementation that supports the optional
+   teardown procedure (see Section 5.3.3.5) SHOULD set this flag as well
+   as 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
+   implementation 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 are present.
+
+5.1.4.6.  Response MAC
+
+   A 48-bit source authentication value generated by the relay as
+   described in Section 5.3.5.  The gateway echoes this value in
+   subsequent Membership Update messages to allow the relay to verify
+   that the sender of a Membership Update message was the intended
+   receiver of a Membership Query sent by the relay.
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 37]
+
+RFC 7450                           AMT                     February 2015
+
+
+5.1.4.7.  Request Nonce
+
+   A 32-bit value copied from the Request Nonce field (Section 5.1.3.5)
+   carried by a Request message.  The relay will have included this
+   value in the Response MAC computation.  The gateway echoes this value
+   in subsequent Membership Update messages.  The gateway also uses this
+   value to match a Membership Query to a Request message.
+
+5.1.4.8.  Encapsulated General Query Message
+
+   An IP-encapsulated IGMP or MLD message generated by the relay.  This
+   field will contain one of the following IP datagrams:
+
+      IPv4:IGMPv3 Membership Query
+
+      IPv6:MLDv2 Listener Query
+
+   The 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 used by a relay to specify the time offset a gateway should use to
+   schedule a new three-way handshake to refresh the group membership
+   state within the relay (current time + Query Interval).  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
+   used by a relay to specify the number of times a gateway should
+   retransmit unsolicited membership reports, encapsulated within
+   Membership Update messages, and, optionally, the number of times to
+   send a Teardown message.  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 need not parse the encapsulated IP datagram to determine
+   the position of these fields within the UDP datagram containing the
+   Membership Query message -- if the G flag is set, the gateway may
+   simply subtract the total length of the fields (18 bytes) from the
+   total length of the UDP datagram to obtain the offset.
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 38]
+
+RFC 7450                           AMT                     February 2015
+
+
+5.1.4.9.1.  Gateway Port Number
+
+   A 16-bit UDP port number containing 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
+
+   A 16-byte IP address that, when combined with the value contained in
+   the Gateway Port Number field, forms the gateway endpoint address
+   that the relay will use to identify the tunnel instance, if any,
+   created by a subsequent Membership Update message.  This field may
+   contain an IPv6 address or an IPv4 address stored as an
+   IPv4-compatible IPv6 address, where the IPv4 address is prefixed with
+   96 bits set to zero (see [RFC4291]).  This address must match that
+   used by the relay to compute the value stored in the Response MAC
+   field.
+
+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 receiving a Membership Query message.
+   The gateway encapsulates the IGMP or MLD message as an IP datagram
+   within a Membership Update message and sends it to the relay, where
+   it may (see below) be decapsulated and processed by the relay to
+   update group membership and forwarding state.
+
+   A gateway cannot send a Membership Update message until it receives a
+   Membership Query from a relay, because the gateway must copy the
+   Request Nonce and Response MAC values carried by a Membership Query
+   into any subsequent Membership Update messages it sends back to that
+   relay.  These values are used by the relay to verify that the sender
+   of the Membership Update message was the recipient of the Membership
+   Query message from which these values were copied.
+
+   The successful delivery of this message to the relay marks the start
+   of the final stage in the three-way handshake.  This stage concludes
+   when the relay successfully verifies that the sender of the
+   Membership Update message was the recipient of a Membership Query
+   message sent earlier.  At this point, the relay may proceed to
+   process the encapsulated IGMP or MLD message to create or update
+   group membership and forwarding state on behalf of the gateway.
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 39]
+
+RFC 7450                           AMT                     February 2015
+
+
+   The UDP/IP datagram containing this message MUST carry a valid,
+   non-zero UDP checksum and carry the following IP address and UDP port
+   values:
+
+   Source IP Address - The IP address of the gateway interface on which
+      the gateway will listen for Multicast Data messages from the
+      relay.  The address must be the same address used to send the
+      initial Request message, or the message will be ignored.  Note:
+      The value of this field may be changed as a result of network
+      address translation before arriving at the relay.
+
+   Source UDP Port - The UDP port number on which the gateway will
+      listen for Multicast Data messages from the relay.  This port must
+      be the same port used to send the initial Request message, or the
+      message will be ignored.  Note: The value of this field may be
+      changed as a result of network address translation before arriving
+      at the relay.
+
+   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 Format
+
+5.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.
+
+
+
+
+Bumgardner                   Standards Track                   [Page 40]
+
+RFC 7450                           AMT                     February 2015
+
+
+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
+
+   A 48-bit value copied from the Response MAC field (Section 5.1.4.6)
+   in a Membership Query message.  Used by the relay to perform source
+   authentication.
+
+5.1.5.5.  Request Nonce
+
+   A 32-bit value copied from the Request Nonce field in a Request or
+   Membership Query message.  Used by the relay to perform source
+   authentication.
+
+5.1.5.6.  Encapsulated Group Membership Update Message
+
+   An IP-encapsulated IGMP or MLD message produced by the host-mode IGMP
+   or MLD protocol running on a gateway pseudo-interface.  This field
+   will contain 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 Report
+
+   The 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).
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 41]
+
+RFC 7450                           AMT                     February 2015
+
+
+   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 sent by
+      a gateway to indicate an interest in receiving the multicast
+      packet.  Note: The value of this field may be changed as a result
+      of network address translation before arriving at the gateway.
+
+   Destination UDP Port - A tunnel endpoint UDP port, i.e., the source
+      UDP port carried by the Membership Update message sent by a
+      gateway to indicate an interest in receiving the multicast packet.
+      Note: The value of this field may be changed as a result of
+      network address translation before arriving at the gateway.
+
+    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 Format
+
+5.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.
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 42]
+
+RFC 7450                           AMT                     February 2015
+
+
+5.1.6.4.  IP Multicast Data
+
+   A complete IPv4 or IPv6 multicast datagram or datagram fragment.
+
+5.1.7.  Teardown
+
+   A gateway sends a Teardown message to a relay to request that it stop
+   sending Multicast Data messages to a tunnel endpoint created by an
+   earlier Membership Update message.  A gateway sends this message when
+   it detects that a Request message sent to the relay carries an
+   address that differs from that carried by a previous Request message.
+   The gateway uses the Gateway IP Address and Gateway Port Number
+   fields in the Membership Query message to detect these address
+   changes.
+
+   To provide backwards compatibility with early implementations of the
+   AMT protocol, support for this message and associated procedures is
+   considered OPTIONAL -- gateways are not required to send this
+   message, and relays are not required to act upon it.
+
+   The UDP/IP datagram containing this message MUST carry a valid,
+   non-zero UDP checksum and carry the following IP address and UDP port
+   values:
+
+   Source IP Address - The IP address of the gateway interface used to
+      send the message.  This address may differ from that used to send
+      earlier messages.  Note: The value of this field may be changed as
+      a result of network address translation before arriving at the
+      relay.
+
+   Source UDP Port - The UDP port number.  This port number may differ
+      from that used to send earlier messages.  Note: The value of this
+      field may be changed as a result of network address translation
+      before arriving at the relay.
+
+   Destination IP Address - The unicast IP address of the relay.
+
+   Destination UDP Port - The AMT port number.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 43]
+
+RFC 7450                           AMT                     February 2015
+
+
+    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
+
+   Reserved bits that MUST be set to zero by the gateway and ignored by
+   the relay.
+
+5.1.7.4.  Response MAC
+
+   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 to be torn down.  The gateway endpoint
+   address is provided by the Gateway IP Address and Gateway Port Number
+   fields carried by the Membership Query message.  The relay validates
+   the Teardown message by comparing this value with one computed from
+   the Gateway IP Address field, Gateway Port Number field, Request
+   Nonce field, and a private secret (just as it does in the Membership
+   Update message).
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 44]
+
+RFC 7450                           AMT                     February 2015
+
+
+5.1.7.5.  Request Nonce
+
+   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 to be torn down.  The gateway endpoint
+   address is provided by the Gateway IP Address and Gateway Port Number
+   fields carried by the Membership Query message.  This value must
+   match that used by the relay to compute the value stored in the
+   Response MAC field.
+
+5.1.7.6.  Gateway Port Number
+
+   A 16-bit UDP port number that, when combined with the value contained
+   in the Gateway IP Address field, forms the tunnel endpoint address
+   that the relay will use to identify the tunnel instance to tear down.
+   The relay provides this value to the gateway using the Gateway Port
+   Number field (Section 5.1.4.9.1) in a Membership Query message.  This
+   port number must match that used by the relay to compute the value
+   stored in the Response MAC field.
+
+5.1.7.7.  Gateway IP Address
+
+   A 16-byte IP address that, when combined with the value contained in
+   the Gateway Port Number field, forms the tunnel endpoint address that
+   the relay will use to identify the tunnel instance to tear down.  The
+   relay provides this value to the gateway using the Gateway IP Address
+   field (Section 5.1.4.9.2) in a Membership Query message.  This field
+   may contain an IPv6 address or an IPv4 address stored as an
+   IPv4-compatible IPv6 address, where the IPv4 address is prefixed with
+   96 bits set to zero (see [RFC4291]).  This address must match that
+   used by the relay to compute the value stored in the Response MAC
+   field.
+
+5.2.  Gateway Operation
+
+   The following sections describe gateway implementation requirements.
+   A non-normative discussion of gateway operation may be found in
+   Section 4.2.
+
+5.2.1.  IP/IGMP/MLD Protocol Requirements
+
+   Gateway operation requires a subset of host-mode IPv4/IGMP and IPv6/
+   MLD functionality to provide group membership tracking, query
+   processing, and report generation.  A gateway MAY use IGMPv2 (ASM),
+   IGMPv3 (ASM and SSM), MLDv1 (ASM), or MLDv2 (ASM and SSM).
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 45]
+
+RFC 7450                           AMT                     February 2015
+
+
+   An application with embedded gateway functionality must provide its
+   own implementation of this subset of the IPv4/IGMP and IPv6/MLD
+   protocols.  The service interface used to manipulate group membership
+   state need not match that described in the IGMP and MLD
+   specifications, but the actions taken as a result SHOULD be similar
+   to those described in Section 5.1 of [RFC3376] and Section 6.1 of
+   [RFC3810].  The gateway application will likely need to implement
+   many of the same functions as a host IP stack, including checksum
+   verification, dispatching, datagram filtering and forwarding, and IP
+   encapsulation/decapsulation.
+
+   The encapsulated IGMP datagrams generated by a gateway MUST conform
+   to the descriptions found in Section 4 of [RFC3376].  These datagrams
+   MUST possess the IP headers, header options, and header values called
+   for in [RFC3376], with the following exception: a gateway MAY use any
+   source address value in an IGMP report datagram, including the
+   "unspecified" address (all octets are zero).  This exception is made
+   because a gateway pseudo-interface might not possess a valid IPv4
+   address, and even if an address has been assigned to the interface,
+   that address might not be a valid link-local source address on any
+   relay interface.  It is for this reason that a relay must accept
+   encapsulated IGMP reports regardless of the source address they
+   carry.  See Section 5.3.1.
+
+   The encapsulated MLD messages generated by a gateway MUST conform to
+   the description found in Section 5 of [RFC3810].  These datagrams
+   MUST possess the IP headers, header options, and header values called
+   for in [RFC3810], with the following exception: a gateway MAY use any
+   source address value in an MLD report datagram, including the
+   "unspecified" address (all octets are zero).  This exception is made
+   because a gateway pseudo-interface might not possess a valid IPv6
+   address, and even if an address has been assigned to the interface,
+   that address might not be a valid link-local source address on any
+   relay interface.  As with IGMP, it is for this reason that 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 number of retransmissions is specified
+   by the relay in the Querier's Robustness Variable (QRV) field in the
+   last General Query forwarded by the pseudo-interface.  See
+   Section 4.1.6 of [RFC3376] and Section 5.1.8 of [RFC3810].
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 46]
+
+RFC 7450                           AMT                     February 2015
+
+
+   The gateway IGMP/MLD implementation SHOULD handle General Query
+   messages as described in Section 5.2 of [RFC3376] and Section 6.2 of
+   [RFC3810] but 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 that carry
+   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 carried by that
+   datagram.
+
+   An IPv6 gateway implementation MUST accept IPv6 datagrams that carry
+   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 carried
+   by that datagram.
+
+5.2.2.  Pseudo-Interface Configuration
+
+   A gateway host may possess or create multiple gateway
+   pseudo-interfaces, each with a unique configuration that describes a
+   binding to a specific IP protocol, Relay Address, Relay Discovery
+   Address, or upstream network interface.
+
+5.2.2.1.  Relay Discovery Address
+
+   If a gateway implementation uses AMT relay discovery to obtain a
+   Relay Address, it must first be supplied with a Relay Discovery
+   Address.  The Relay Discovery Address may be an anycast or unicast
+   address.  A gateway implementation may rely on a static address
+   assignment or some form of dynamic address discovery.  This
+   specification does not require that a gateway implementation use any
+   particular method to obtain a Relay Discovery Address -- an
+   implementation may employ any method that returns a suitable Relay
+   Discovery Address.
+
+5.2.2.2.  Relay Address
+
+   Before a gateway implementation can execute the AMT protocol to
+   request and receive multicast traffic, it must be supplied with a
+   unicast Relay Address.  A gateway implementation may rely on static
+   address assignment or support some form of dynamic address discovery.
+   This specification does not require the use of any particular method
+   to obtain a Relay Address -- an implementation may employ any method
+   that returns a suitable Relay Address.
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 47]
+
+RFC 7450                           AMT                     February 2015
+
+
+5.2.2.3.  Upstream Interface Selection
+
+   A gateway host that possesses multiple network interfaces or
+   addresses may allow for an explicit selection of the interface to use
+   when communicating with a relay.  The selection might be made to
+   satisfy connectivity, tunneling, or IP protocol requirements.
+
+5.2.2.4.  Optional Retransmission Parameters
+
+   A gateway implementation that supports retransmission MAY require the
+   following information:
+
+   Discovery Timeout
+      Initial time to wait for a response to a Relay Discovery message.
+
+   Maximum Relay Discovery Retransmission Count
+      Maximum number of Relay Discovery retransmissions to allow before
+      terminating relay discovery and reporting an error.
+
+   Request Timeout
+      Initial time to wait for a response to a Request message.
+
+   Maximum Request Retransmission Count
+      Maximum number of Request retransmissions to allow before
+      abandoning a relay and restarting relay discovery or reporting an
+      error.
+
+   Maximum Retries Count for "Destination Unreachable"
+      The maximum number of times a gateway should attempt to send the
+      same Request or Membership Update message after receiving an ICMP
+      Destination Unreachable message.
+
+5.2.3.  Gateway Service
+
+   In the following descriptions, a gateway pseudo-interface is treated
+   as a passive entity managed by a gateway service.  The gateway
+   pseudo-interface provides the state, and the gateway service provides
+   the processing.  The term "gateway" is used when describing service
+   behavior with respect to a single pseudo-interface.
+
+5.2.3.1.  Startup
+
+   When a gateway pseudo-interface is started, the gateway service
+   begins listening for AMT messages sent to the UDP endpoint(s)
+   associated with the pseudo-interface and for any locally generated
+   IGMP/MLD messages passed to the pseudo-interface.  The handling of
+   these messages is described below.
+
+
+
+
+Bumgardner                   Standards Track                   [Page 48]
+
+RFC 7450                           AMT                     February 2015
+
+
+   When the pseudo-interface is enabled, the gateway service MAY:
+
+   o  Optionally execute the relay discovery procedure described in
+      Section 5.2.3.4.
+
+   o  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 receives that cannot be
+   interpreted as a Relay Advertisement, Membership Query, or Multicast
+   Data message.  The handling of Relay Advertisement, Membership Query,
+   and Multicast Data messages is addressed in the sections that follow.
+
+   A gateway that conforms to this specification MUST ignore any message
+   with a Version field value other than zero.
+
+   While listening for AMT messages, a gateway may be notified that an
+   ICMP Destination Unreachable message was received as a result of an
+   AMT message transmission.  Handling of ICMP Destination Unreachable
+   messages is described in Section 5.2.3.9.
+
+5.2.3.3.  Handling Multicast Data Messages
+
+   A gateway may receive Multicast Data messages after it sends a
+   Membership Update message to a relay that adds a group subscription.
+   The gateway may continue to receive Multicast Data messages long
+   after the gateway sends a Membership Update message that deletes
+   existing group subscriptions.  The gateway MUST be prepared to
+   receive these messages at any time but MAY ignore them or discard
+   their contents if the gateway no longer has any interest in receiving
+   the multicast datagrams contained within them.
+
+   A gateway MUST ignore a Multicast Data message if it fails to satisfy
+   any of the following requirements:
+
+   o  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).
+
+   o  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.
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 49]
+
+RFC 7450                           AMT                     February 2015
+
+
+   The gateway extracts the encapsulated IP datagram and forwards it to
+   the local IP protocol implementation for checksum verification,
+   fragmented datagram reassembly, source and group filtering, and
+   transport-layer protocol processing.
+
+   Because AMT uses UDP encapsulation to deliver multicast datagrams to
+   gateways, it qualifies as a tunneling protocol subject to the
+   limitations described in [RFC6936].  If supported, a gateway SHOULD
+   employ the solution described in [RFC6936] to ensure that the local
+   IP stack does not discard IPv6 datagrams with zero checksums.  If
+   Multicast Data message datagrams are processed directly within the
+   gateway (instead of the host IP stack), the gateway MUST NOT discard
+   any of these datagrams because they carry a UDP checksum of zero.
+
+5.2.3.4.  Relay Discovery Procedure
+
+   This section describes gateway requirements related to 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 in
+   response to the following events:
+
+   o  When a gateway pseudo-interface is started (enabled).
+
+   o  When the gateway wishes to report a group subscription when none
+      currently exist.
+
+   o  Before sending the next Request message in a membership update
+      cycle, i.e., each time the query timer expires (see below).
+
+   o  After the gateway fails to receive a response to a Request
+      message.
+
+   o  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 start 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.
+
+
+
+
+Bumgardner                   Standards Track                   [Page 50]
+
+RFC 7450                           AMT                     February 2015
+
+
+   The gateway MUST save a copy of the Relay Discovery message or save
+   the Discovery Nonce value for possible retransmission and
+   verification of a Relay Advertisement response.
+
+   When a gateway sends a Relay Discovery message, it may be notified
+   that an ICMP Destination Unreachable message was received as a result
+   of an earlier AMT message transmission.  Handling of ICMP Destination
+   Unreachable messages is described in 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 does not
+   receive a matching Relay Advertisement message within some timeout
+   period.  If the gateway retransmits the message multiple times, the
+   timeout period SHOULD be adjusted to provide 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
+   determine whether it should accept or ignore the message.  A gateway
+   MUST ignore a Relay Advertisement message if it fails to satisfy any
+   of the following requirements:
+
+   o  The gateway MUST be waiting for a Relay Advertisement message.
+
+   o  The Discovery Nonce value contained in the Relay Advertisement
+      message MUST be equal to the Discovery Nonce value contained in
+      the Relay Discovery message.
+
+   o  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 receives a Relay Advertisement response to a Relay
+   Discovery message, it SHOULD ignore any other Relay Advertisements
+   that arrive on the AMT interface until it sends a new Relay Discovery
+   message.
+
+   If a gateway executes the relay discovery procedure at the start of
+   each membership update cycle and the Relay Address returned in the
+   latest Relay Advertisement message differs from the address returned
+   in a previous Relay Advertisement message, then the gateway SHOULD
+   send a Teardown message (if supported) to the old Relay Address,
+
+
+
+Bumgardner                   Standards Track                   [Page 51]
+
+RFC 7450                           AMT                     February 2015
+
+
+   using information from the last Membership Query message received
+   from that relay, as described in Section 5.2.3.7.  This behavior is
+   illustrated in the following diagram.
+
+                     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 Change
+
+
+
+Bumgardner                   Standards Track                   [Page 52]
+
+RFC 7450                           AMT                     February 2015
+
+
+5.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.  The same
+   nonce SHOULD be used when retransmitting a Relay Discovery message.
+
+5.2.3.5.  Membership Query Procedure
+
+   This section describes gateway requirements related to the membership
+   update message sequence described in Section 4.2.1.2.
+
+5.2.3.5.1.  Starting the Membership Update Cycle
+
+   A gateway may send a Request message to start a membership update
+   cycle (following the optional relay discovery procedure) in response
+   to the following events:
+
+   o  When the gateway pseudo-interface is activated.
+
+   o  When the gateway wishes to report a group subscription when none
+      currently exist.
+
+   Starting the membership update cycle when a gateway pseudo-interface
+   is started provides several benefits:
+
+   o  Better performance by allowing state-change reports to be sent as
+      they are generated, thus minimizing the time to join.
+
+   o  More robustness by relying on unsolicited state-change reports to
+      update group membership state rather than the current-state
+      reports generated by the membership update cycle.  Unsolicited
+      state-change reports are typically retransmitted multiple times
+      while current-state reports are not.
+
+   o  Simplified implementation by eliminating any need to queue IGMP/
+      MLD messages for delivery after a Membership Query is received,
+      since the IGMP/MLD state-change messages may be sent as they are
+      generated.
+
+   However, this approach places an additional load on relays, as a
+   gateway will send periodic requests even when it has no multicast
+   subscriptions.  To reduce load on a relay, a gateway SHOULD only send
+   a Membership Update message while it has active group subscriptions.
+   A relay will still need to compute a Response MAC for each Request
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 53]
+
+RFC 7450                           AMT                     February 2015
+
+
+   but will not be required to recompute it a second time 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.
+
+   A gateway constructs a Request message containing 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 the
+   gateway wishes the relay to use for the General Query response.
+
+   A gateway MUST send a Request message using the current Relay Address
+   and AMT port number as the destination.
+
+   A gateway MUST save a copy of the Request message or save the Request
+   Nonce and P flag values for possible retransmission and verification
+   of a Membership Query response.
+
+   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 does not receive a
+   matching Membership Query message within some timeout period.  If the
+   gateway retransmits the message multiple times, the timeout period
+   SHOULD be adjusted to provide 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 does not receive a Membership
+   Query within a specified time period or after a specified number of
+   retries, the gateway SHOULD stop waiting for a Membership Query
+   message and restart relay discovery to locate another relay.
+
+
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 54]
+
+RFC 7450                           AMT                     February 2015
+
+
+5.2.3.5.4.  Handling a Membership Query Message
+
+   When a gateway receives a Membership Query message, it must first
+   determine whether it should accept or ignore the message.  A gateway
+   MUST ignore a Membership Query message, or the encapsulated IP
+   datagram within it, if the message fails to satisfy any of the
+   following requirements:
+
+   o  The gateway MUST be waiting for a Membership Query message.
+
+   o  The Request Nonce value contained in the Membership Query MUST
+      equal the Request Nonce value contained in the Request message.
+
+   o  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).
+
+   o  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.
+
+   o  The IGMPv3 or MLDv2 message MUST be a General Query message.
+
+   o  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 indicates that senders should use a
+   link-local source IP address in message datagrams.  This requirement
+   must be relaxed for AMT because gateways and relays do not normally
+   share a common subnet.  For this reason, a gateway implementation
+   MUST accept MLD (and IGMP) query message datagrams regardless of the
+
+
+
+Bumgardner                   Standards Track                   [Page 55]
+
+RFC 7450                           AMT                     February 2015
+
+
+   source IP address they carry.  This may require additional processing
+   on the part of the gateway that 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 will simply ignore any that do.  If
+   the L flag is set and the gateway is not currently reporting any
+   group subscriptions to the relay, the gateway SHOULD stop sending
+   periodic Request messages and restart the relay discovery procedure
+   (if discovery is enabled) to find a new relay with which to
+   communicate.  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.
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 56]
+
+RFC 7450                           AMT                     February 2015
+
+
+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 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:
+
+   o  IPv4 datagrams that carry an IGMPv2 or IGMPv3 Membership Report or
+      an IGMPv2 Leave Group message as described in Section 4 of
+      [RFC3376].
+
+   o  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:
+
+   o  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).
+
+   o  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.
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 57]
+
+RFC 7450                           AMT                     February 2015
+
+
+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 with which to communicate, 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
+
+   This section describes gateway requirements related to the teardown
+   message sequence described in Section 4.2.1.3.
+
+   Gateway support for the Teardown message is RECOMMENDED.
+
+   A gateway that supports Teardown SHOULD make use of Teardown
+   functionality if it receives a Membership Query message from a relay
+   that has the G flag set to indicate that it contains valid Gateway
+   Address fields.
+
+5.2.3.7.1.  Handling a Membership Query Message
+
+   As described in Section 5.2.3.5.4, if a gateway supports the Teardown
+   message, has reported active group subscriptions, and receives a
+   Membership Query message with the G flag set, the gateway MUST
+   compare the Gateway IP Address and Gateway Port Number on the new
+   Membership Query message with the values carried by the previous
+   Membership Query message.  If either value has changed, the gateway
+   MUST send a Teardown message as described in the next section.
+
+
+
+
+Bumgardner                   Standards Track                   [Page 58]
+
+RFC 7450                           AMT                     February 2015
+
+
+5.2.3.7.2.  Sending a Teardown Message
+
+   A gateway sends a Teardown message to a relay to request that it stop
+   delivering Multicast Data messages to the gateway and delete any
+   group memberships created by the gateway.
+
+   When a gateway constructs a Teardown message, it MUST copy the
+   Request Nonce, Response MAC, Gateway IP Address, and Gateway Port
+   Number fields from the Membership Query message that provided the
+   Response MAC for the last Membership Update message sent, into the
+   corresponding fields of the Teardown message.
+
+   A gateway MUST send the Teardown message using the Relay Address and
+   AMT port number as the destination.  A gateway MAY send the Teardown
+   message multiple times for robustness.  The gateway SHOULD use the
+   Querier's Robustness Variable (QRV) field contained in the query
+   encapsulated within the last Membership Query to set the limit on the
+   number of retransmissions (see Section 4.1.6 of [RFC3376] and
+   Section 5.1.8 of [RFC3810]).  If the gateway sends the Teardown
+   message multiple times, it SHOULD insert a delay between each
+   transmission using the timing algorithm employed in IGMP/MLD for
+   transmitting unsolicited state-change reports.  The RECOMMENDED
+   default delay value is 1 second.
+
+   When a gateway sends a Teardown message, it may be notified that an
+   ICMP Destination Unreachable message was received as a result of an
+   earlier AMT message transmission.  Handling of ICMP Destination
+   Unreachable messages is described in Section 5.2.3.9.
+
+5.2.3.8.  Shutdown
+
+   When a gateway pseudo-interface is stopped and the gateway has
+   existing group subscriptions, the gateway SHOULD either:
+
+   o  Send a Teardown message to the relay as described in
+      Section 5.2.3.7, but only if the gateway supports the Teardown
+      message and the current relay is returning Gateway Address fields
+      in Membership Query messages, or
+
+   o  Send a Membership Update message to the relay that will delete
+      existing group subscriptions.
+
+5.2.3.9.  Handling ICMP Destination Unreachable Responses
+
+   A gateway may receive an ICMP Destination Unreachable message
+   [RFC0792] after sending an AMT message.  Whether the gateway is
+   notified that an ICMP message was received is highly dependent on
+   firewall and gateway IP stack behavior and gateway implementation.
+
+
+
+Bumgardner                   Standards Track                   [Page 59]
+
+RFC 7450                           AMT                     February 2015
+
+
+   If the reception of an ICMP Destination Unreachable message is
+   reported to the gateway while waiting to receive an AMT message, the
+   gateway may respond as follows, depending on platform capabilities
+   and which outgoing message triggered the ICMP response:
+
+   1.  The gateway MAY simply abandon the current relay and restart
+       relay discovery (if used).  This is the least desirable approach,
+       as it does not allow for transient network changes.
+
+   2.  If the last message sent was a Relay Discovery or Request
+       message, the gateway MAY simply ignore the ICMP response and
+       continue waiting for incoming AMT messages.  If the gateway is
+       configured to retransmit Relay Discovery or Request messages, the
+       normal retransmission behavior for those messages is preserved to
+       prevent the gateway from prematurely abandoning a relay.
+
+   3.  If the last message sent was a Membership Update message, the
+       gateway MAY start a new membership update and associated Request
+       retransmission cycle.
+
+   If the reception of an ICMP Destination Unreachable message is
+   reported to the gateway when attempting to transmit a new AMT
+   message, the gateway may respond as follows, depending on platform
+   capabilities and which outgoing message triggered the ICMP response:
+
+   1.  The gateway MAY simply abandon the current relay and restart
+       relay discovery (if used).  This is the least desirable approach,
+       as it does not allow for transient network changes.
+
+   2.  If the last message sent was a Relay Discovery, Request, or
+       Teardown message, the gateway MAY attempt to transmit the new
+       message.  If the gateway is configured to retransmit Relay
+       Discovery, Request, or Teardown messages, the normal
+       retransmission behavior for those messages is preserved to
+       prevent the gateway from prematurely abandoning a relay.
+
+   3.  If the last message sent was a Membership Update message, the
+       gateway SHOULD start a new membership update and associated
+       Request retransmission cycle.
+
+
+
+
+
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 60]
+
+RFC 7450                           AMT                     February 2015
+
+
+5.3.  Relay Operation
+
+   The following sections describe relay implementation requirements.  A
+   non-normative discussion of relay operation may be found in
+   Section 4.2.
+
+5.3.1.  IP/IGMP/MLD Protocol Requirements
+
+   A relay requires a subset of router-mode IGMP and MLD functionality
+   to provide 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 described in 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], with the exception that
+   actions that lead to queries MAY be modified to eliminate query
+   generation.  A relay MUST accept IGMP and MLD report datagrams
+   regardless of the IP source address carried by those datagrams.
+
+   All other aspects of IGMP/MLD router behavior, such as the handling
+   of queries, querier election, etc., are not used or required for
+   relay operation.
+
+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 within that prefix,
+   i.e., 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 be used to send and receive AMT control and data
+   messages.  This address or addresses are returned in Relay
+   Advertisement messages.
+
+   The remaining details of relay "startup" are highly implementation
+   dependent and are not addressed in this document.
+
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 61]
+
+RFC 7450                           AMT                     February 2015
+
+
+5.3.3.  Running
+
+   When a relay is started, it begins listening for AMT messages on the
+   interface to which the unicast Relay Address(es) has been assigned,
+   i.e., the address returned in Relay Advertisement messages.
+
+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
+   Relay Discovery, Request, Membership Update, and Teardown messages is
+   addressed in the sections that follow.
+
+   Support for the Teardown message is OPTIONAL.  If a relay does not
+   support the Teardown message, it MUST also ignore this 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 describes relay requirements related to the relay
+   discovery message sequence described in 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 receives a Relay Discovery message sent to its unicast
+   address, it MUST respond just as it would if the message had been
+   sent to its anycast 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 to ensure successful NAT traversal.
+
+   The relay MUST copy the value contained in the Discovery Nonce field
+   of the Relay Discovery message into the Discovery Nonce field in the
+   Relay Advertisement message.
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 62]
+
+RFC 7450                           AMT                     February 2015
+
+
+   If the Relay Discovery message was received as an IPv4 datagram, the
+   relay MUST return an IPv4 address in the Relay Address field of the
+   Relay Advertisement message.  If the Relay Discovery message was
+   received as an IPv6 datagram, the relay MUST return an IPv6 address
+   in the Relay Address field.
+
+5.3.3.3.  Handling a Request Message
+
+   This section describes relay requirements related to the membership
+   query portion of the message sequence described in Section 4.2.1.2.
+
+   When a relay receives a Request message, it responds by sending a
+   Membership Query message back to the source of the Request message.
+
+   The relay MUST use the source IP address and UDP port of the Request
+   message as the destination IP address and UDP port for the Membership
+   Query message.  The source IP address and UDP port carried by the
+   Membership Query MUST match the destination IP address and UDP port
+   of the Request to ensure successful NAT traversal.
+
+   The relay MUST return the value contained in the Request Nonce field
+   of the Request message in the Request Nonce field of the Membership
+   Query message.  The relay MUST compute a MAC value, as described in
+   Section 5.3.5, and return that value in the Response MAC field of the
+   Membership Query message.
+
+   If a relay supports the Teardown message, it MUST set the G flag in
+   the Membership Query message and return the source IP address and UDP
+   port carried by the Request message in the corresponding Gateway IP
+   Address and Gateway Port Number fields.  If the relay does not
+   support the Teardown message, it SHOULD NOT set these fields, as this
+   may cause the gateway to generate unnecessary Teardown messages.
+
+   If the P flag in the Request message is 0, the relay MUST return an
+   IPv4-encapsulated IGMPv3 General Query in the Membership Query
+   message.  If the P flag is 1, the relay MUST return an
+   IPv6-encapsulated MLDv2 General Query in the Membership Query
+   message.
+
+   If the relay is not accepting Membership Update messages that create
+   new tunnel endpoints due to resource limitations, it SHOULD set the
+   L flag in the Membership Query message to notify the gateway of this
+   state.  Support for the L flag is OPTIONAL.  See Section 5.3.3.8.
+
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 63]
+
+RFC 7450                           AMT                     February 2015
+
+
+   The encapsulated IGMPv3 General Query datagrams generated by a relay
+   MUST conform to the descriptions found in Section 4.1 of [RFC3376].
+   These datagrams MUST possess the IP headers, header options, and
+   header values called for in [RFC3376], with the following exception:
+   a relay MAY use any source IP address for an IGMP General Query
+   datagram, including the "unspecified" address (all octets are zero).
+   This exception is made because any source address that a relay might
+   normally send may not be a valid link-local address on any gateway
+   interface.  It is for this reason that a gateway must accept
+   encapsulated IGMP queries regardless of the source address they
+   carry.  See Section 5.2.1.
+
+   The encapsulated MLDv2 General Query datagrams generated by a relay
+   MUST conform to the descriptions found in Section 5.1 of [RFC3810].
+   These datagrams MUST possess the IP headers, header options, and
+   header values called for in [RFC3810], with the following exception:
+   a relay MAY use any source IP address for an MLD General Query
+   datagram, including the "unspecified" address (all octets are zero).
+   This exception is made because any source address that a relay might
+   normally send may not be a valid link-local address on any gateway
+   interface.  As with IGMP, it is for this reason that 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 to supply the gateway with a suggested time
+   duration to use for the 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 affect the rate at which the Request
+   messages are sent from a gateway.  However, a gateway is allowed to
+   use a shorter duration than the duration specified in the QQIC field,
+   so a relay may be limited in its ability to spread out Requests
+   coming from a gateway.
+
+   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
+   will 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 a value of 1 to trigger an immediate response from the
+   gateway (some host IGMP/MLD implementations may not accept a value of
+   zero).  A relay SHOULD NOT use the IGMPv3/MLDv2 Query Response
+   Interval variable, if available, to generate the Maximum Response
+   Code field value, as the Query Response Interval variable is used in
+   setting the duration of group state timers and must not be set to
+
+
+
+Bumgardner                   Standards Track                   [Page 64]
+
+RFC 7450                           AMT                     February 2015
+
+
+   such a small 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 describes relay requirements related to the membership
+   update portion of the message sequence described in Section 4.2.1.2.
+
+   When a relay receives a Membership Update message, it must first
+   determine whether it should accept or ignore the message.  A relay
+   MUST NOT make any changes to group membership and forwarding state if
+   the message fails to satisfy any of the following requirements:
+
+   o  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.
+
+   o  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], with the following
+      exception: a relay MUST accept an IGMP or MLD message regardless
+      of the IP source address carried by the datagram.
+
+   o  The total length of the encapsulated IP datagram as computed from
+      the lengths contained in the datagram header(s) MUST NOT exceed
+      the available field length within the Membership Update message.
+
+   o  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).
+
+   o  If processing of the encapsulated IGMP or MLD message would result
+      in an allocation of new state or a modification of existing state,
+      the relay MUST authenticate the source of the message by verifying
+      that the value contained in the Response MAC field equals the MAC
+      value computed from the fields in the Membership Update message
+
+
+
+Bumgardner                   Standards Track                   [Page 65]
+
+RFC 7450                           AMT                     February 2015
+
+
+      datagram.  If a time-varying private secret is used in the
+      computation of a Response MAC, the relay MUST retain the previous
+      version of the private secret for use in authenticating Membership
+      Updates sent during the subsequent query interval.  If the first
+      attempt at Response MAC authentication fails, the relay MUST
+      attempt to authenticate the Response MAC using the previous
+      private secret value unless 2 * query_interval time has elapsed
+      since the private secret change.  See Section 5.3.5.
+
+   A relay MAY skip source authentication to reduce the computational
+   cost of handling Membership Update messages if the relay can make a
+   trivial determination that the IGMP/MLD message carried by the
+   Membership Update message will produce no changes in group membership
+   or forwarding state.  The relay does not need to compute and compare
+   MAC values if it finds there are no group subscriptions for the
+   source of the Membership Update message and either of the following
+   is true:
+
+   o  The encapsulated IP datagram is an IGMPv3 Membership Report or
+      MLDv2 Multicast Listener Report message that contains no group
+      records.  This may often be the case for gateways that
+      continuously repeat the membership update cycle even though they
+      have no group subscriptions to report.
+
+   o  The encapsulated IP datagram is an IGMPv2 Leave Group or MLDv1
+      Multicast Listener Done message.
+
+   The IGMP and MLD protocol specifications indicate that senders SHOULD
+   use a link-local source IP address in message datagrams.  This
+   requirement must be relaxed for AMT because gateways and relays do
+   not 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 determined that the Membership Update message is
+   valid, it processes the encapsulated IGMP or MLD message to update
+   group membership state and communicates with the multicast protocol
+   to update forwarding state and possibly send multicast protocol
+   messages towards upstream routers.  The relay MUST ignore any octets
+   that might exist between the encapsulated IP datagram and the end of
+   the Membership Update message.
+
+   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.  A relay uses the tunnel endpoint as the destination
+   address for any Multicast Data messages it sends as a result of the
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 66]
+
+RFC 7450                           AMT                     February 2015
+
+
+   group membership and forwarding state created by processing the IGMP/
+   MLD messages contained in Membership Update messages received from
+   the endpoint.
+
+   If a Membership Update message originates from a new endpoint, the
+   relay MUST determine whether it can accept updates from a new
+   endpoint.  If a relay has been configured with a limit on the total
+   number of endpoints, or a limit on the total number of endpoints for
+   a given source address, then the relay MAY ignore the Membership
+   Update message and possibly withdraw any Relay Discovery Address
+   Prefix announcement that it might have made.  See 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 containing 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
+   representing a merger of the group membership databases of all
+   endpoints.  The merged group membership 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.  A relay uses
+   this forwarding table to provide the destination address when
+   performing UDP/IP encapsulation of the incoming multicast IP
+   datagrams to form Multicast Data messages.
+
+   If a group filter mode for a group entry on a tunnel endpoint is
+   EXCLUDE, the relay SHOULD NOT forward datagrams that originate from
+   sources in the filter source list unless the relay architecture does
+   not readily support source filtering.  A relay MAY ignore the source
+   list if necessary because gateways are expected to do their own
+   source filtering.
+
+5.3.3.5.  Handling a Teardown Message
+
+   This section describes relay requirements related to the teardown
+   message sequence described in Section 4.2.1.3.
+
+   When a relay (that supports the Teardown message) receives a Teardown
+   message, it MUST first authenticate the source of the Teardown
+   message by verifying that the Response MAC carried by the Teardown
+   message is equal to a MAC value computed from the fields carried by
+   the Teardown message.  The method used to compute the MAC differs
+   from that used to generate and validate the Membership Query and
+   Membership Update messages in that the source IP address and source
+   UDP port number used to compute the MAC are taken from the Gateway IP
+
+
+
+Bumgardner                   Standards Track                   [Page 67]
+
+RFC 7450                           AMT                     February 2015
+
+
+   Address and Gateway Port Number fields in the Teardown message rather
+   than from the IP and UDP headers in the datagram that carries the
+   Teardown message.  The MAC computation is described in Section 5.3.5.
+   A relay MUST ignore a Teardown message if the computed MAC does not
+   equal the value of the Response MAC field.
+
+   If a relay determines that a Teardown message is authentic, it MUST
+   immediately stop transmitting Multicast Data messages to the endpoint
+   identified by the Gateway IP Address and Gateway Port Number fields
+   in the message.  The relay MUST eventually delete any group
+   membership and forwarding state associated with the endpoint but MAY
+   delay doing so to allow a gateway to recreate group membership state
+   on a new endpoint and thereby avoid making unnecessary (temporary)
+   changes in upstream routing/forwarding state.
+
+   The state changes made by a relay when processing a Teardown message
+   MUST be identical to those that would be made if the relay had
+   received an IGMP/MLD report that would cause the IGMP or MLD protocol
+   to delete all existing group records in the group membership database
+   associated with the endpoint.  The processing of the Teardown message
+   should trigger or mimic the normal interaction between IGMP or MLD
+   and a multicast protocol to produce required changes in forwarding
+   state and possibly send prune/leave messages towards upstream
+   routers.
+
+5.3.3.6.  Handling Multicast IP Datagrams
+
+   When a multicast IP datagram is forwarded to the relay
+   pseudo-interface, the relay MUST, for each gateway that has expressed
+   an interest in receiving the datagram, encapsulate the IP datagram
+   into a Multicast Data message or messages and send that message or
+   messages to the gateway.  This process is highly implementation
+   dependent but conceptually requires the following steps:
+
+   o  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.
+
+   o  Possibly replicate the datagram for each gateway endpoint listed
+      for that (*,G) or (S,G) entry.
+
+
+
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 68]
+
+RFC 7450                           AMT                     February 2015
+
+
+   o  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.
+
+   o  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.  A relay will use the TMTU value to
+   determine whether an incoming multicast IP datagram can be delivered
+   downstream in a Membership Data message without fragmentation.  A
+   relay MUST compute the TMTU by subtracting 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.  A relay MUST support
+   one or both of the following methods for determining the PMTU value:
+
+   o  The relay MAY provide a configuration option that establishes a
+      fixed PMTU that will be applied to all AMT tunnels originating at
+      the relay.
+
+   o  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, the relay MUST provide a
+   configuration option that disables this feature and also 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).  When dynamic PMTU
+   adjustments are disabled, the PMTU for all tunnels MUST default to
+   the Link MTU (first hop) on the downstream interface.
+
+
+
+
+
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 69]
+
+RFC 7450                           AMT                     February 2015
+
+
+5.3.3.6.2.  MTU Filtering Procedure
+
+   This section defines procedures that a relay must execute when it
+   receives a multicast datagram whose size is greater than the Tunnel
+   MTU of the tunnel or tunnels through which it must be delivered.
+
+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 and, if the datagram
+   originated from an SSM source, send an ICMPv4 [RFC0792] Destination
+   Unreachable message to the source, with code 4 (fragmentation needed
+   and DF set).  The ICMP Destination Unreachable message MUST contain a
+   Next-Hop MTU (as specified by [RFC1191]), and the relay MUST set the
+   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 will receive complete,
+   non-fragmented Multicast Data messages, containing fragmented
+   multicast datagram payloads.  The relay SHOULD avoid generating a
+   separate ICMP message for each tunnel but instead 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 the 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 but 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, using the tunnel endpoint UDP/IP address as the
+   destination address and the unicast Relay Address and port number as
+   the source UDP/IP address.  To ensure successful NAT traversal, the
+   source address and port MUST match the destination address and port
+   carried by the Membership Update message sent by the gateway to
+   create the forwarding table entry.
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 70]
+
+RFC 7450                           AMT                     February 2015
+
+
+   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), by default, the relay
+   MUST 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 to
+   allow downstream fragmentation of the Multicast Data message.  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; see 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 what number of
+   sequential Destination Unreachable messages can be received and
+   ignored before the relay will automatically shut down a tunnel.
+
+
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 71]
+
+RFC 7450                           AMT                     February 2015
+
+
+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 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_Interval
+
+   If 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 the timers used (IGMPv3/MLDv2 or endpoint), the
+   Query_Response_Interval value SHOULD be greater than or equal to 10s
+   to allow for packet loss and round-trip time in the Request/
+   Membership Query message exchange.
+
+5.3.3.8.  Relay Resource Management
+
+   A relay may be configured with various service limits to ensure a
+   minimum level of performance for gateways that connect to it.
+
+   If a relay has determined that it has reached or exceeded maximum
+   allowable capacity or has otherwise exhausted resources required to
+   support additional gateways, it SHOULD withdraw any Relay Discovery
+   Address Prefix it has advertised into the unicast internetwork and
+   SHOULD set the L flag in any Membership Query messages it returns to
+   gateways while in this state.
+
+   If the relay receives an update from a gateway that adds group
+   membership or forwarding state for an endpoint that has already
+   reached maximum allowable state entries, the relay SHOULD continue to
+   accept updates from the gateway but ignore any group membership/
+   forwarding state additions requested by that gateway.
+
+
+
+Bumgardner                   Standards Track                   [Page 72]
+
+RFC 7450                           AMT                     February 2015
+
+
+   If the relay receives an update from a gateway that would create a
+   new tunnel endpoint for a source IP address that has already reached
+   the maximum allowable number of endpoints (maximum UDP ports), it
+   should simply ignore the Membership Update.
+
+5.3.4.  Shutdown
+
+   The following steps should be treated as an abstract description of
+   the shutdown procedure for a relay:
+
+   o  Withdraw the Relay Discovery Address Prefix advertisement
+      (if used).
+
+   o  Stop listening for Relay Discovery messages.
+
+   o  Stop listening for control messages from gateways.
+
+   o  Stop sending data messages to gateways.
+
+   o  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:
+
+   o  To generate a Response MAC value from a Request message for
+      inclusion in a Membership Query message.
+
+   o  To generate a Response MAC value from a Membership Update message
+      for use in authenticating the Response MAC carried within that
+      message.
+
+   o  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:
+
+   o  The source IP address of the message (or Teardown Gateway IP
+      Address field).
+
+
+
+
+Bumgardner                   Standards Track                   [Page 73]
+
+RFC 7450                           AMT                     February 2015
+
+
+   o  The source UDP port of the message (or Teardown Gateway Port
+      Number field).
+
+   o  The Request Nonce contained in the message.
+
+   o  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.
+
+6.  Security Considerations
+
+   AMT is not intended to be a strongly secure protocol.  In general,
+   the protocol provides the same level of security and robustness as is
+   provided by the UDP, IGMP, and MLD protocols on which it relies.  The
+   lack of strong security features can be largely attributed to the
+   desire to make the protocol lightweight by minimizing the state and
+   computation required to service a single gateway, thereby allowing a
+   relay to service a larger number of gateways.
+
+   Many of the threats and vectors described in [RFC3552] may be
+   employed against the protocol to launch various types of denial-of-
+   service attacks that can affect the functioning of gateways or their
+   ability to locate and communicate with a relay.  These scenarios are
+   described below.
+
+   As is the case for UDP, IGMP, and MLD, the AMT protocol provides no
+   mechanisms for ensuring message delivery or integrity.  The protocol
+   does not provide confidentiality -- multicast groups, sources, and
+   streams requested by a gateway are sent in the clear.
+
+   The protocol does use a three-way handshake to provide trivial source
+   authentication for state allocation and updates (see below).  The
+   protocol also requires gateways and relays to ignore malformed
+   messages and those messages that do not carry expected address
+   values, 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) provides a defense against source-
+   spoofing-based resource-exhaustion attacks on a relay by requiring
+   source authentication before state allocation.  However, in an effort
+
+
+
+Bumgardner                   Standards Track                   [Page 74]
+
+RFC 7450                           AMT                     February 2015
+
+
+   to consume computational resources, attackers may still attempt to
+   flood a relay with Request and Membership Update messages to force
+   the relay to make the MAC authentication computations.
+   Implementations may choose to limit the frequency with which a relay
+   responds to Request messages sent from a single IP address or IP
+   address and UDP port pair, but support for this functionality is not
+   required.  The three-way handshake provides no defense against an
+   eavesdropping or man-in-the-middle attacker.
+
+   Attackers that execute the gateway protocol may consume relay
+   resources by instantiating a large number of tunnels or joining a
+   large number of multicast streams.  A relay implementation should
+   provide a mechanism for limiting the number of tunnels (Multicast
+   Data message destinations) that can be created for a single gateway
+   source address.  Relays should also provide a means for limiting the
+   number of joins per tunnel instance as a defense against these
+   attacks.
+
+   Relays may withdraw their AMT anycast prefix advertisement when they
+   reach configured maximum capacity or exhaust required resources.
+   This behavior allows gateways to use the relay discovery process to
+   find the next topologically nearest relay that has advertised the
+   prefix.  This behavior also allows a successful resource-exhaustion
+   attack to propagate from one relay to the next until all relays
+   reachable using the anycast address have effectively been taken
+   offline.  This behavior may also be used to acquire the unicast
+   addresses for individual relays that 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.  This will isolate such
+   attacks 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 is adversely affected.  In order
+   to mitigate such attacks, relay implementations MUST include a
+   configuration option to disable Path MTU adjustments on AMT tunnels.
+
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 75]
+
+RFC 7450                           AMT                     February 2015
+
+
+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
+   and using the Request Nonce and message authentication code carried
+   by the captured message to send a spoofed Membership Update or
+   Teardown message to the relay.  The spoofed messages may be used to
+   modify or destroy group membership state associated with the gateway,
+   thereby changing or interrupting the multicast traffic flows.
+
+   A passive eavesdropper may also spoof Multicast Data messages in an
+   attempt to overload the gateway or to disrupt or supplant existing
+   traffic flows.  A properly implemented gateway will filter Multicast
+   Data messages that do not originate from the expected Relay Address
+   and should filter non-multicast packets and multicast IP packets
+   whose group or source addresses are not included in the current
+   reception state for the gateway pseudo-interface.
+
+   An active eavesdropper may launch a man-in-the-middle attack in which
+   messages normally exchanged between a gateway and relay are
+   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) introduces 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 thus divert or absorb Relay
+   Discovery messages sent by gateways.  Network managers must guarantee
+   the integrity of their routing to a particular Relay Discovery
+   Address Prefix in much the same way that they guarantee the integrity
+   of all other routes.
+
+6.3.  Encapsulated IP Packets
+
+   An attacker forging or modifying a Membership Query or Membership
+   Update message may attempt to embed something other than an IGMP or
+   MLD message within the encapsulated IP packet carried by these
+   messages in an effort to introduce these into the recipient's IP
+   stack.  A properly implemented gateway or relay will ignore any such
+   messages and may further choose 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.
+
+
+
+
+Bumgardner                   Standards Track                   [Page 76]
+
+RFC 7450                           AMT                     February 2015
+
+
+   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          |
+                 +----------------------+----------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 77]
+
+RFC 7450                           AMT                     February 2015
+
+
+7.1.2.  IPv6
+
+   IANA has registered the following 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 use in the
+   implementation and deployment of AMT.  The protocol described by this
+   document continues to use this port number according to the intent of
+   the original request.  IANA has updated the assignee, contact, and
+   reference fields for this port number in accordance with this
+   document.
+
+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>.
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 78]
+
+RFC 7450                           AMT                     February 2015
+
+
+   [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>.
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 79]
+
+RFC 7450                           AMT                     February 2015
+
+
+   [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>.
+
+
+
+
+
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 80]
+
+RFC 7450                           AMT                     February 2015
+
+
+Acknowledgments
+
+   The author would like to thank the following individuals 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 81]
+
+RFC 7450                           AMT                     February 2015
+
+
+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.com
+
+      Thomas Morin
+      Orange
+      2, avenue Pierre Marzin
+      Lannion  22300
+      France
+      EMail: thomas.morin@orange.com
+
+      Dirk Ooms
+      OneSparrow
+      Robert Molsstraat 11; 2018 Antwerp
+      Belgium
+      EMail: dirk@onesparrow.com
+
+      Tom Pusateri
+      !j
+      Wake Forest, NC
+      United States
+      EMail: pusateri@bangj.com
+
+      Dave Thaler
+      Microsoft Corporation
+      One Microsoft Way
+      Redmond, WA  98052-6399
+      United States
+      EMail: dthaler@microsoft.com
+
+Author's Address
+
+   Gregory Bumgardner
+
+   Phone: +1 541 343 6790
+   EMail: gbumgard@gmail.com
+
+
+
+
+
+
+
+Bumgardner                   Standards Track                   [Page 82]
+