Network Working Group                                          D. Thaler                                      G. Bumgardner
Internet-Draft                                                 M. Talwar                                                     Cisco
Intended status: Standards Track                             A. Aggarwal
Expires: January 12, 2012                          Microsoft Corporation
                                                             L. Vicisano
                                                           Qualcomm Inc.
                                                             T. Pusateri
                                                                      !j                                T. Morin
Expires: August 19, 2012                         France Telecom - Orange
                                                           July 11, 2011
                                                       February 16, 2012

                     Automatic IP Multicast Tunneling
                  draft-ietf-mboned-auto-multicast-11
                  draft-ietf-mboned-auto-multicast-12

Abstract

   This document describes Automatic IP Multicast Tunneling (AMT) allows (AMT), a
   protocol for delivering multicast reception by
   isolated multicast-enabled sites or hosts, attached to traffic from sources in a
   multicast-enabled network
   which has no native multicast support.  It enables them to receive receivers that lack multicast traffic from
   connectivity to the native multicast infrastructure without
   requiring any manual configuration.  AMT source network.  The protocol uses an UDP
   encapsulation
   interface so that no changes to a host stack or applications are
   required, all protocols (not just UDP) are handled, and there unicast replication to provide this functionality.

   The AMT protocol is no
   additional overhead in core routers. specifically designed to support rapid deployment
   by requiring minimal changes to existing network infrastructure.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 12, August 19, 2012.

Copyright Notice

   Copyright (c) 2011 2012 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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5  4
   2.  Applicability  . . . . . . . . . . . . . . . . . . . . . . . .  6  5
   3.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  7
   4.  Definitions  . . .  Terminology  . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  AMT Pseudo-Interface . . . .  6
     3.1.  Requirements Notation  . . . . . . . . . . . . . . .  8
     4.2.  AMT Gateway . . .  6
     3.2.  Definitions  . . . . . . . . . . . . . . . . . . . .  8
     4.3.  AMT Site . . .  6
     3.3.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  8
     4.4.  AMT Relay  7
   4.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  9
     4.1.  General Architecture . .  8
     4.5.  AMT Relay Anycast Prefix . . . . . . . . . . . . . . . . .  9
     4.6.  AMT Relay Anycast Address  . .
     4.2.  General Operation  . . . . . . . . . . . . . .  9
   5.  Overview . . . . . . 18
   5.  Protocol Description . . . . . . . . . . . . . . . . . . . . . 10 33
     5.1.  Scalability Considerations . . . . . . .  Protocol Messages  . . . . . . . . . 11
     5.2.  Spoofing Considerations . . . . . . . . . . . 33
     5.2.  Gateway Operation  . . . . . . 11
     5.3.  Protocol Sequence . . . . . . . . . . . . . . 47
     5.3.  Relay Operation  . . . . . . 12
   6.  Message Formats . . . . . . . . . . . . . . . 61
   6.  Security Considerations  . . . . . . . . 15
     6.1.  Use of UDP . . . . . . . . . . . 72
   7.  IANA Considerations  . . . . . . . . . . . . . 15
     6.2.  AMT Relay Discovery . . . . . . . . 75
   8.  Contributors . . . . . . . . . . . 15
       6.2.1.  Type . . . . . . . . . . . . . . 76
   9.  Acknowledgments  . . . . . . . . . . . 15
       6.2.2.  Reserved . . . . . . . . . . . . 77
   10. References . . . . . . . . . . . 15
       6.2.3.  Discovery Nonce . . . . . . . . . . . . . . . 78
     10.1. Normative References . . . . 15
     6.3.  AMT Relay Advertisement . . . . . . . . . . . . . . . 78
     10.2. Informative References . . 16
       6.3.1.  Type . . . . . . . . . . . . . . . . 78
   Appendix A.  Implementation Notes  . . . . . . . . . 16
       6.3.2.  Reserved . . . . . . . 81
   Authors' Addresses . . . . . . . . . . . . . . . . 16
       6.3.3.  Discovery Nonce  . . . . . . . . . . . . . . . . . . . 84

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 must currently rely on unicast replication at or near
   sources because most clients lack multicast connectivity to the
   network containing the sources.  The reasons for the lack of
   connectivity vary, but are primarily the result of service provider
   policies and network limitations.

   Automatic Multicast Tunneling (AMT) is a protocol that uses UDP-based
   encapsulation to overcome the aforementioned lack of multicast
   connectivity.  AMT enables sites, hosts or applications that do not
   have native multicast access to a multicast source network to request
   and receive SSM [RFC4607] and ASM [RFC1112] multicast traffic from
   sources in that network.

2.  Applicability

   This document describes a protocol that may be used to deliver
   multicast traffic from sources in a multicast enabled network to
   sites that lack multicast connectivity to the source network.  This
   document does not describe any methods for sourcing multicast traffic
   from isolated sites as this topic is out of scope.

   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.

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 (NMBA):
      A non-broadcast multiple-access (NBMA) network or interface is one
      to which multiple network nodes (hosts or routers) are attached,
      but where packets are transmitted directly from one node to
      another node over a virtual circuit or physical link.  NBMA
      networks do not support multicast or broadcast traffic - a node
      that sources multicast traffic must replicate the multicast
      packets for separate transmission to each node that has requested
      the multicast traffic.

   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/reception sate for an interface or system.

   Reception State:
      The multicast subscription state of a pseudo, virtual or physical
      network interface.  See group membership database.

   Subscription:
      A group or state entry in a group membership database or reception
      state table.

   Group Membership Protocol:
      The term "group membership protocol" is used as a generic
      reference to the Internet Group Management (IGMP) ([RFC1112],
      [RFC2236], [RFC3376]) or Multicast Listener Discovery ([RFC2710],
      [RFC3810]) protocols.

   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 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).

      NBMA - Non-Broadcast Multi-Access (network, interface or mode)

      SSM - Source-Specific Multicast.

      PIM - Protocol Independent 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 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"
   which 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 (IGMP) [RFC3376] and
   Multicast Listener Discovery (MLD) [RFC3810] protocols to provide the
   functionality required to manage, communicate, and act on changes in
   multicast group membership.  A gateway or relay implementation does
   not necessarily require a fully-functional, conforming implementation
   of IGMP or MLD to adhere to this specification, but the protocol
   description that appears in this document assumes that this is the
   case.  The minimum functional and behavioral requirements for the
   IGMP and MLD protocols are described in Section 5.2.1 and
   Section 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
                           |_____|       |_____|

               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 multicast receivers - the
   gateway accepts group membership requests from receivers and forwards
   requested multicast traffic back to those receivers.

   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  |<-------->|UPD/IP|
               |Protocol |------------->|Pseudo I/F|          +------+
               +---------+   IGMP/MLD   |          |             ^
                              Report    |          |             |
                            Leave/Done  |          |             V
     IP Multicast <---------------------|          |           +---+
                                        +----------+           |I/F|
                                                               +---+

                  Figure 2: 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 is 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 inter-network and one or more AMT gateway
   pseudo-interfaces.

   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

                 Virtual Interface Implementation Example

   In this example, the host IP stack uses a virtual network interface
   to interact with a gateway pseudo-interface implementation.

4.1.2.2.  Use-Cases

   Use-cases for gateway functionality include:

   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.

4.1.3.1.  Architecture

   Each relay possesses a logical pseudo-interface:

                                      +------------------------------+
                    +--------+        | Multicast Control Plane      |
                    |        |IGMP/MLD|                              |
                    |        | Query* | +------------+  +----------+ |
                    |        |<---//----|IGMPv3/MLDv2|  |          | |
             AMT    |        |        | |Router Mode |->|  PIM-SM  |<-->
  +------+ Messages | AMT    |----//--->|Protocol    |  |          | |
  |UDP/IP|<-------->| Relay  |IGMP/MLD| +------------+  +----------+ |
  +------+          | Pseudo | Report |      |               |       |
     ^              | I/F    | Leave/ +------|---------------|-------+
     |              |        |  Done         |               |
     |              |        |               v               |
     V              |        | IP        +-----------+       |
   +---+            |        | Multicast |Multicast  |<------+
   |I/F|            |        |<---//-----|Forwarding |
   +---+            +--------+           |Plane      |<--- IP Multicast
                                         +-----------+

   * Queries, if generated, are consumed by the pseudo-interface.

                 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.

   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.

   The relay pseudo-interface is a architectural abstraction used to
   describe AMT protocol operation.  For the purposes of this document,
   the pseudo-interface is most easily viewed as an interface to a
   single gateway - encapsulation, decapsulation, and other AMT-specific
   processing occurs "within" the pseudo-interface while forwarding and
   replication occur outside of it.

   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 inter-network, and one
   or more relay pseudo-interfaces.

4.1.3.2.  Use-Cases

   Use-cases for relay functionality include:

   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 [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 a upstream interface.  This "relay
      proxy" sends group membership reports to a local, multicast-
      enabled router to join and leave specific SSM or ASM groups.

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, latency and 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 gateways to multicast sources - that any gateway would be
   able to access any globally advertised multicast source via publicly-
   accessible, widely-deployed relays.  Unfortunately, today's internet
   does not yet allow this, as many relays will lack native multicast
   access to sources even though they may be globally accessible via
   unicast.

   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.

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.

   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.  IANA-Assigned Relay Discovery Address Prefix

   This document calls for IANA to allocate an anycast address prefix
   for use in advertising and discovering publicly accessible relays.

   A relay discovery address is constructed from the anycast address
   prefix by setting the low-order octet of the prefix address to 1 (for
   both IPv4 and IPv6).

   Public relays must advertise a route to the anycast address prefix
   and configure an interface to respond to the relay discovery address.

   The IANA address assignments are discussed 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
      in order 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.

   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 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] |                    |
                          :                    :

                       AMT Relay Discovery Sequence

   The following sequence describes how the Relay Discovery and Relay
   Advertisement messages are used to find a relay with which to
   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
       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
   general-query response.  A gateway accomplishes this by sending a
   Request message to a relay.  The relay responds by sending Membership
   Query message back to the gateway.  The Membership Query message
   carries an encapsulated general query that is processed by the IGMP
   or MLD protocol implementation on the gateway to produce a
   membership/listener report.  Each time the gateway receives a
   Membership Query message it starts a timer whose expiration will
   trigger the start of a new Request->Membership Query message
   exchange.  This timer-driven sequence is used to mimic the
   transmission of a periodic general query by an IGMP/MLD router.  This
   query cycle may continue indefinitely once started by sending the
   initial Request message.

   A membership update occurs when an IGMP or MLD report, leave or done
   message is passed to the gateway pseudo-interface.  These messages
   may be produced as a result of the aforementioned general-query
   processing or as a result of receiver interaction with the IGMP/MLD
   service interface.  Each report is encapsulated and sent to the relay
   after the gateway has successfully established communication with the
   relay via a Request and Membership Query message exchange.  If a
   report is passed to the pseudo-interface before the gateway has
   received a Membership Query message from the relay, the gateway may
   discard the report or queue the report for delivery after a
   Membership Query is received.  Subsequent IGMP/MLD report/leave/done
   messages that are passed to the pseudo-interface are immediately
   encapsulated and transmitted to the relay.

          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)
              |                     |                     |---------->()
              :                     :                     :

             Membership Update Sequence (IGMPv3/MLDv2 Example)

   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) by computing a hash value from
        a private secret and the nonce, source IP address, and source
        UDP port carried by the Request message.  The relay then sends a
        Membership Query message to the gateway that contains the
        request nonce, the MAC, and an IGMPv3 or MLDv2 general query.

   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 QQIC field in the IGMPv3 or MLDv2 general query.

   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 a private secret and the request nonce, source IP
        address, and source UDP port carried by the message.  The relay
        accepts the Membership Update message if the received MAC
        matches the computed MAC, otherwise the message is ignored.  If
        the message is accepted, the relay may proceed to allocate,
        refresh, or modify tunnel state.  This includes making any group
        membership, routing and forwarding state changes and issuing any
        upstream protocol requests required to satisfy the state change.
        The diagram illustrates two scenarios:

        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 through some form IGMP/MLD service
        interface (as described in Section 2 of [RFC3376] or 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 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).

   9.   When the relay receives a Membership Update message, it again
        computes a MAC from a private secret and the request nonce,
        source IP address, and source UDP port carried by the message.
        The relay accepts the Membership Update message if the received
        MAC matches the computed MAC, otherwise the message is ignored.
        If the message is accepted, the relay processes the encapsulated
        IGMP/MLD and allocates, modifies or deletes tunnel state
        accordingly.  This includes making any group membership, routing
        and forwarding state changes and issuing any upstream protocol
        requests required to satisfy the state change.  The diagram
        illustrates two scenarios:

        A.  The gateway wishes to add a group subscription.

        B.  The gateway wishes to delete a previously reported group
            subscription.

   10.  Multicast datagrams transmitted by a source travel through the
        native multicast infrastructure to the relay.  When the relay
        receives a multicast IP datagram that carries a source and
        destination address for which a gateway has expressed an
        interest in receiving (via the Membership Update message), it
        encapsulates the datagram into a Multicast Data message and
        sends it to the gateway using the source IP address and UDP port
        carried by the Membership Update message as the destination
        address.

   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.

   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.  Support for the Teardown message is optional - gateways
   are not required to send them and relays are not required to act upon
   them.

                      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 3: Teardown Message Sequence (IGMPv3/MLDv2 Example)

   The following sequence describes how the Membership Query and
   Teardown message are used to detect an address change and stop the
   delivery of Multicast Data messages to an address:

   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 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 Robustness Variable (QRV) value
       contained in the IGMPv3/MLDv2 general query carried by the
       original Membership Query.  The gateway continues to process the
       new Membership Query message as usual.

   8.  When the relay receives a Teardown message, it computes a MAC
       from a private secret and the request nonce, gateway IP address,
       and gateway port number carried by the Teardown message.  The
       relay accepts the Teardown message if the received MAC matches
       the computed MAC, otherwise the message is ignored.  If the
       message is accepted, the relay makes any group membership,
       routing and forwarding state changes required to stop the
       transmission of Multicast Data messages to that address.

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.  This
   address is referred here as the tunnel endpoint address.

   A gateway sends a Membership Update message to a relay to add or
   remove group subscriptions to a tunnel endpoint.  The tunnel endpoint
   is identified by the source IP address and source UDP port carried by
   the Membership Update message when it arrives at a relay (this
   address may differ from that carried by the message when it exited
   the gateway as a result of network address translation).

   The Membership Update messages sent by a single gateway host may
   originate from several source addresses or ports - each unique
   combination represents a unique tunnel endpoint.  A single gateway
   host may legitimately create and accept traffic on multiple tunnel
   endpoints, e.g., the gateway may use separate ports for the IPv4/IGMP
   and IPv6/MLD protocols.

   A tunnel is "created" when a gateway sends a Membership Update
   message containing an IGMP or MLD membership report that creates one
   or more group subscriptions when none currently existed for that
   tunnel endpoint address.

   A tunnel ceases to exist when all group subscriptions for a tunnel
   endpoint are deleted.  This may occur as a result of the following
   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 inter-network into an NBMA link layer, over which
   multicast traffic may be delivered.  Each relay, plus the set of all
   gateways using the relay, together may be thought of as being on a
   separate logical NBMA link, where the "link layer" address is a
   UDP/IP address-port pair provided by the Membership Update message.

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 change unexpectedly.  These changes may
   cause the relay to transmit duplicate, undeliverable or unrequested
   traffic back towards the gateway or an intermediate device.  This may
   create congestion and have negative consequences for the gateway, its
   network, or multicast receivers, and in some cases, may also produce
   a significant amount of ICMP traffic directed back towards the relay
   by a NAT, router or gateway host.

   There are several scenarios in which the address carried by messages
   sent by a gateway may change without that gateway's knowledge, as for
   example, when:

   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 multi-homed 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, bi-
   directional communication can only be conducted by sending outgoing
   packets to the source address and port carried by the last incoming
   packet.

       Membership Update                 Membership Update
       src: iADDR:iPORT                  src: eADDR:ePORT
       dst: rADDR:rPORT                  dst: rADDR:rPORT
                          +---------+
                          |   NAT   |
   +---------+           +-----------+          +---------+
   |         |---------->|           |--------->|         |
   | Gateway |           |  Mapping  |          |  Relay  |
   |         |<----------|           |<---------|         |
   +---------+           +-----------+          +---------+
                          |         |
                          +---------+
       Multicast Data                    Multicast Data
       src: rADDR:rPORT                  src: rADDR:rPORT
       dst: iADDR:iPORT                  dst: eADDR:ePORT

                    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

                             AMT Encapsulation

   The IGMP and MLD messages used in AMT are exchanged as complete IP
   datagrams.  These IP datagrams are encapsulated in AMT messages which
   are transmitted using UDP.  The same holds true for multicast traffic
   - each multicast IP datagram that arrives at the relay is
   encapsulated in an AMT message and transmitted to one or more
   gateways via UDP.

   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.  See [I-D.ietf-6man-udpchecksums] and
   [I-D.ietf-6man-udpzero] for details.

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 IANA-assigned 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=1 |     Reserved                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Discovery Nonce                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      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 IANA-assigned AMT port number).

   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)                 ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    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.

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
       6.3.4.
   (IPv6).

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 IANA-assigned 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                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          Request Message Format

5.1.3.1.  Version (V)

   The protocol version number for this message is 0.

5.1.3.2.  Type

   The type number for this message is 3.

5.1.3.3.  Reserved

   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.

   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 IANA-assigned 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)              |
   +                                                               +
   |                                                               |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Membership Query Message Format

5.1.4.1.  Version (V)

   The protocol version number for this message is 0.

5.1.4.2.  Type

   The type number for this message is 4.

5.1.4.3.  Reserved

   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 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 and and the
   Gateway Address field values.  If a relay sets this flag, it MUST
   also include the Gateway Address fields in the message.  A gateway
   implementation that does not support the optional teardown procedure
   (See 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 hash 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.

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 hash computation.  The gateway echoes this
   value in subsequent Membership Update messages.  The gateway also
   uses this value to match a Membership Query to a Request message.

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 to zero
   to indicate that query originated from a non-querier.

   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 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.

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 messsage - if the G-flag is set, the gateway may
   simply subtract the total length of the fields (18 bytes) from the
   total length of the UDP datagram to obtain the offset.

5.1.4.9.1.  Gateway Port Number

   A 16-bit UDP port 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 a receives a
   Membership Query from a relay because the gateway must copy the
   Request Nonce and Response MAC values carried by a Membership Query
   into any subsequent Membership Update messages it sends back to that
   relay.  These values are used by the relay to verify that the sender
   of the Membership Update message was the recipient of the Membership
   Query message from which these values were copied.

   The successful delivery of this message to the relay marks the start
   of the final stage in the three-way handshake.  This stage concludes
   when the relay successfully verifies that sender of the Message
   Update message was the recipient of a Membership Query message sent
   earlier.  At this point, the relay may proceed to process the
   encapsulated IGMP or MLD message to create or update group membership
   and forwarding state on behalf of the gateway.

   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 IANA-assigned AMT UDP 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)            |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     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.

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 of 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

5.1.6.  Multicast Data

   A relay sends a Multicast Data message to deliver an IP multicast
   packet 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).

   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 IANA-assigned 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                       ~
   |                                                               |
   +                - - - - - - - - - - - - - - - - - - - - - - - -+
   |               :               :               :               :
   +-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - - - - - - - - - -

                       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

   Bits that MUST be set to zero by the relay and ignored by the
   gateway.

5.1.6.4.  IP Multicast Data

   A complete IPv4 or IPv6 Multicast datagram.

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  . . . . . . . . . . . . . . . . . . . . 16
     6.4. -  The unicast IP address of the relay.

   Destination UDP Port -  The IANA-assigned AMT port number.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  V=0  |Type=7 |  Reserved     |         Response MAC          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Request  . . . . . . . . . . . . . . . . . . . . . . . 16
       6.4.1. Nonce                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Gateway Port Number       |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +                                                               +
   |              Gateway IP Address (IPv4 or IPv6)                |
   +                                                               +
   |                                                               |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Membership Teardown Message Format

5.1.7.1.  Version (V)

   The protocol version number for this message is 0.

5.1.7.2.  Type . . . . . . . . . . . . . . . . . . . . . . . . . 17
       6.4.2.

   The type number for this message is 7.

5.1.7.3.  Reserved . . . . . . . . . . . . . . . . . . . . . . . 17
       6.4.3.

   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.

5.1.7.5.  Request Nonce  . . . . . . . . . . . . . . . . . . . . 17
     6.5.

   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 used 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, general query
   processing, and report generation.  A gateway MAY use IGMPv2 (ASM),
   IGMPv3 (ASM and SSM), MLDv1 (ASM) or MLDv2 (ASM and SSM).

   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.  Applications that use AMT to join
   multicast UDP streams may also need to perform IP reassembly to
   reconstruct UDP datagrams that were fragmented prior to replication
   and encapsulation in the relay.

   The IP-encapsulated IGMP/MLD messages generated by the gateway IPv4/
   IGMP or IPv6/MLD implementation MUST conform to the descriptions
   found in Section 4 of [RFC3376] and Section 5 of [RFC3810].  These
   datagrams MUST possess the IP headers, header options and header
   values called for in these RFCs, with the following exception; the
   source IP address for an IGMP/MLD report datagram MAY be set to the
   "unspecified" address (all octets are zero ).  This exception is made
   because the gateway pseudo-interface might not possess an address,
   and even if such an address exists, that address would not be a valid
   source address on any relay interface.  To allow for this exception,
   a relay must accept an IGMP or MLD report carried by a Membership Query . . . . . . . . . . . . . . . . . . . 17
       6.5.1.  Type . . . . . . . . . . . . . . . . . . . . . . . . . 18
       6.5.2.  Flags  . . . . . . . . . . . . . . . . . . . . . . . . 18
       6.5.3.  Response MAC . . . . . . . . . . . . . . . . . . . . . 19
       6.5.4.  Request Nonce  . . . . . . . . . . . . . . . . . . . . 19
       6.5.5.
   Update message regardless of the source address it carries.  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.

   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 field value and generate
   a current state report without any delay.

   A gateway IPv4 implementation MUST accept IPv4 datagrams that carry
   multicast data or the general query variant of the IGMPv3 Membership
   Query message, as described in Section 4 of [RFC3376].

   A gateway IPv6 implementations MUST accept IPv6 datagrams that carry
   multicast data or the general query variant of the MLDv2 Multicast
   Listener Query (including message, as described in Section 5 of [RFC3810].

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 Header) . . . . . . . . . 19
       6.5.6.  Gateway information fields . . . . . . . . . . . . . . 19
     6.6. protocol, relay address, relay discovery address or
   upstream network interface.

5.2.2.1.  Static 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.

5.2.2.2.  Static 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.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  . . . . . . . . . . . . . . . . . . 19
       6.6.1.  Type . . . . . . . . . . . . . . . . . . . . . . . . . 20
       6.6.2.  Reserved . . . . . . . . . . . . . . . . . . . . . . . 20
       6.6.3.  Response MAC . . . . . . . . . . . . . . . . . . . . . 20
       6.6.4.  Request Nonce  . . . . . . . . . . . . . . . . . . . . 21
       6.6.5. message after receiving an ICMP
      "Destination Unreachable".

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 Message (including IP Header) . . . . . . . . 21
     6.7. messages passed to the pseudo-interface.  The handling of
   these messages is described below.

   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.

   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  . . . . . . . . . . . . . . . . . . 21
       6.7.1.  Type . . . . . . . . . . . . . . . . . . . . . . . . . 22
       6.7.2.  Reserved . . . . . . . . . . . . . . . . . . . . . . . 22
       6.7.3.
      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 Multicast Data  . . . . . . . . . . . . . . . . . . 22

     6.8.  AMT Teardown . . . . . . . . . . . . . . . . . . . . . . . 22
       6.8.1.  Type . . . . . . . . . . . . . . . . . . . . . . . . . 23
       6.8.2.  Reserved . . . . . . . . . . . . . . . . . . . . . . . 23
       6.8.3.  Original Response MAC  . . . . . . . . . . . . . . . . 23
       6.8.4.  Original datagram
      MUST fall within the multicast address allocation assigned to the
      relavent IP protocol, i.e., 224.0.0.0/4 for IPv4 and FF00::/8 for
      IPv6.

   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.

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 Nonce . . . . . . . . . . . . . . . . 23
       6.8.5.  Original Source Port . . . . . . . . . . . . . . . . . 23
       6.8.6.  Original Source 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  . . . . . . . . . . . . . . . 23
   7. and IANA-assigned UDP port number as the
   destination.  The Discovery Nonce value in the Relay Discovery
   message must be computed as described in Section 5.2.3.4.5.

   The gateway MUST save a copy of 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 an random exponential
   back-off.  The RECOMMENDED timeout is a random value in the range
   [initial_timeout, MIN(initial_timeout * 2^retry_count,
   maximum_timeout)], with a RECOMMENDED initial_timeout of 1 second and
   a RECOMMENDED maximum_timeout of 120 seconds (which is the
   recommended minimum NAT mapping timeout described in [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 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 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 Gateway Details  . . . . . . . . . . . . . . . . . . . . . 25
     7.1.  At Startup Time  . . . . . . . . . . . . . . . . . . . . . 25
     7.2.  Gateway identification . . . . . . . . . . . . . . . . . . 25
     7.3.  Joining Multicast Groups . . . . . . . . . . . . . . . . . 26
     7.4.  Responding 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,
   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 Changes  . . . . . . . . . . . . . . . 26
   8.  AMT Discovery   |                |
                        |------------------------------------>|
                        |                    |                |
                        | Relay Details  . . . . . . . . . . . . . . . . . . . . . . 27
     8.1.  At Startup Advertisement|                |
                        |<------------------------------------|
                        |                    |                |
                        |     Teardown       |                |
                        |------------------->|                |
                        |                    |                |
                        |      Request       |                |
                        |------------------------------------>|
                        |                    |                |
                        |  Membership Query  |                |
                        |<====================================|
                  Start |                    |                |
           (QT)<--------| Membership Update  |                |
                        |====================================>|
                        |                    |                |
                        :                    :                :

                    Teardown After Relay Address Change

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 pseudo
   random number generator.  A new nonce SHOULD be generated each time  . . . . . . . . . . . . . . . . . . . . . 27
     8.2.  Receiving
   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 the Anycast
           Address  . . . . . . . . . . . . . . . . . . . . . . . . . 27
     8.3.  Receiving compute a Response MAC for each Request,
   but will not be required to recompute it a second time to
   authenticate a Membership Updates from AMT Gateways . . . . . . 27
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
     9.1.  IPv4 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 IPv6 Anycast Prefix Allocation  . . . . . . . . . 29
       9.1.1.  IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 29
       9.1.2.  IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 29
     9.2.  UDP Port 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 IANA-assigned AMT port number  . . . . . . . . . . . . . . . . . . . . . 29
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 30
   11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31
   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 32
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 33
     13.2. Informative References . . . . . . . . . . . . . . . . . . 33
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35

1.  Introduction 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 an random exponential back-off.  The primary goal
   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 this document 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 foster locate another relay.

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 deployment message.  A gateway
   MUST ignore a Membership Query message, or the encapsulated IP
   datagram within it, if the message fails to satisfy any of
   native 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 multicast 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 enabling a potentially large number of nodes
   to connect to the already present multicast infrastructure.
   Therefore,
      "P" flag in the techniques discussed here should Request message.

   o  The IGMPv3 or MLDv2 message MUST be viewed a general query message.

   o  The total length of the encapsulated IP datagram as an
   interim solution to help computed from
      the lengths contained in the various stages of datagram header(s) MUST NOT exceed
      the available field length within the transition Membership Query message.

   Once a gateway receives a Membership Query response to a
   native multicast network.

   To allow fast deployment, Request
   message, it SHOULD ignore any other Membership Query messages that
   arrive on the solution presented here only requires
   small 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 concentrated changes 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 network infrastructure, local IP protocol implementation for checksum verification and no
   changes at all
   dispatching to user applications the IGMP or to MLD implementation running on the socket API pseudo-
   interface.  The gateway MUST NOT forward any octets that might exist
   between the encapsulated IP datagram and the end of end-
   nodes' operating systems. the message or
   Gateway Address fields.

   An MLD datagram contained in a Membership Query message may require
   special handling.  The encapsulated query generated by a relay will
   likely carry an unspecified or relay link-local source address.  If a
   gateway relies on a standard host-mode MLD protocol introduced in this
   specification can be deployed implementation to
   process the query, that implementation will silently ignore the MLD
   query because it carries an unspecified or non-link-local source
   address - a gateway may need to construct its own query with a valid
   link-local address (e.g., a spoofed address in a few strategically-placed network
   nodes virtual subnet
   defined by the address and in user-installable software modules (pseudo device drivers
   and/or user-mode daemons) that reside underneath netmask assigned to the socket API of
   end-nodes' operating systems.  This mechanism is very similar gateway pseudo-
   interface) to ensure that
   used by "6to4" [RFC3056], [RFC3068] to get automatic IPv6
   connectivity.

   Effectively, AMT treats the unicast-only inter-network as a large
   non-broadcast multi-access (NBMA) link layer, over which we require report will not be ignored by the ability to multicast.  To do this, multicast packets being sent
   to site MLD
   protocol implementation.

   The gateway must be encapsulated in unicast packets.  If start a timer that will trigger the group has
   members in multiple sites, AMT encapsulation next iteration
   of the same multicast
   packet will take place multiple times membership update cycle by necessity.

   A previous of this solution was previously "Automatic IP Multicast
   without explicit Tunnels", to highlight executing the fact that membership query
   procedure.  The gateway SHOULD compute the tunneling
   used is lightweight and does not require statically configured
   tunnels used as point to point interfaces.

2.  Applicability

   AMT is not a substitute for native multicast or timer duration from the
   Querier's Query Interval Code carried by the general-query.  A
   gateway MAY use a statically
   configured multicast tunnel for high traffic flow.  Unicast
   replication is smaller timer duration if required to reach multiple receivers refresh a NAT
   mapping that are not part
   of the native multicast infrastructure.  However, this is no worse
   than regular unicast distribution of streams and in most cases much
   better.

   This document specifies procedures allowing isolated sites to receive
   both general Any Source Multicast (ASM, [RFC1112]), and Specific
   Source Multicast (SSM, [RFC4607]).

   Earlier versions of this document were describing how to would otherwise timeout.  A gateway MAY use AMT to
   allow isolated non-NAT sites/hosts a larger
   timer duration if it has no group subscriptions to transmit SSM multicast ; the
   specifications for these functionalities have been left off report.

   If the
   current document for gateway supports the following reasons: Teardown message and the drawback that these
   specifications required a source site Gateway to replicate traffic to
   many Relays G-flag is set in
   the multicast-enabled part of Membership Query message, the gateway MUST compare the network, lack of
   contributors to document alternative proposals based Gateway IP
   Address and Gateway Port Number on AMT,
   existence of ways to offer similar functionality using Tunnel Broker
   approaches [RFC3053], or at the application layer.

   Implementers should be aware that site administrators may have
   configured administratively scoped multicast boundaries and a remote new Membership Query message
   with the values carried by the previous Membership Query message.  If
   either value has changed the gateway may provide MUST send a means Teardown message to circumvent administrative boundaries.
   Therefore, implementations should allow for
   the configuration of such
   boundaries on relays and gateways and perform filtering as needed.

3.  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 relay as described in [RFC2119].

4.  Definitions

    +---------------+        Internet            +---------------+
    | AMT Site      |                            | Native MCast  |
    |               |                            |               |
    |        +------+----+         AMT      +----+----+          |
    |        |AMT Gateway|         Anycast  |AMT Relay|          |
    |        |     +-----+-+       Prefix +-+-----+   |          |
    |        |     |AMT IF | <------------|AMT IF |   |          |
    |        |     +-----+-+              +-+-----+   |          |
    |        +------+----+                  +----+----+          |
    |               |                            |               |
    +---------------+                            +---------------+

4.1.  AMT Pseudo-Interface

   AMT encapsulation of multicast packets inside unicast packets occurs
   at a point that Section 5.2.3.7.

   If the L-flag is logically equivalent to an interface, with set in the
   link layer being Membership Query message, the unicast-only network.  This point relay is referred to
   as a pseudo-interface.  Some implementations may treat
   reporting that it exactly
   like is NOT accepting Membership Update messages that
   create new tunnel endpoints and will simply ignore any other interface that do.  If
   the L-flag is set and others may treat it like a tunnel end-
   point.

4.2.  AMT Gateway

   A host, or a site the gateway router, supporting an AMT Pseudo-Interface.
   It does is not have native multicast connectivity currently reporting any
   group subscriptions to the native
   multicast backbone infrastructure.  It relay, the gateway SHOULD stop sending
   periodic Request messages and restart the relay discovery procedure
   (if discovery is simply referred enabled) to in this
   document as find a "gateway".

4.3.  AMT Site

   A multicast-enabled network not connected new relay with which to the multicast backbone
   served by an AMT Gateway.  It could also be a stand-alone AMT
   Gateway.

4.4.  AMT Relay

   A multicast router configured
   communicate.  The gateway MAY continue to support transit routing between AMT
   Sites and send updates even if the native multicast backbone infrastructure.  The relay
   router
   L-flag is set, if it has one or more interfaces connected previously reported group subscriptions to
   the native multicast
   infrastructure, zero relay, one or more interfaces connected to the non-
   multicast capable inter-network, subscriptions still exist and an AMT pseudo-interface.  It is
   simply referred to in this document as a "relay".

   As with [RFC3056], we assume that normal multicast routers do the gateway
   endpoint address has not
   want to be tunnel endpoints (especially if this results 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 high fan
   out).  Instead, we assume that special-purpose routers will be
   deployed that are suitable for serving as relays.

4.5.  AMT Relay Anycast Prefix

   A well-known address prefix used to advertise (into the unicast
   routing infrastructure) a route previous step) expires, the
   gateway should execute the membership query procedure again to an available AMT Relay Router.
   This could also
   continue the membership update cycle.

5.2.3.5.6.  Request Nonce Generation

   The request nonce MUST be private (i.e., not well-known) for a private
   relay.

   Prefixes for both IPv4 random value, and IPv6 will if possible, SHOULD be assigned in
   computed using a future version
   of this draft.

4.6.  AMT Relay Anycast Address

   An anycast address which is used to reach cryptographically secure pseudo random number
   generator.  A new nonce MUST be generated each time the nearest AMT Relay
   Router. gateway
   starts the membership query process.  The same nonce SHOULD be used
   when retransmitting a Request message.

5.2.3.6.  Membership Update Procedure

   This address corresponds section describes gateway requirements related to the setting membership
   update message sequence described in Section 4.2.1.2.

   The membership update process is primarily driven by the low-order octet of host-mode
   IGMP or MLD protocol implementation running on the
   AMT Relay Anycast Prefix to 1 (for both IPv4 gateway pseudo-
   interface.  The IGMP and IPv6).

5.  Overview

                               Internet
    +---------------+                            +---------------+
    | AMT Site      |     2. 3-way Membership    | Native MCast  |
    |               |          Handshake         |               |
    |   1. Join +---+---+ =================> +---+---+           |
    |     +---->|Gateway|                    | Relay |           |
    |     |     +---+---+ <================= +---+---+           |
    |   R-+         |       3. Receive Data      |               |
    +---------------+                            +---------------+

                    Receiving Multicast MLD protocols produce current-state reports
   in an AMT Site

   AMT relays and gateways cooperate response to transmit multicast traffic
   sourced within general queries generated by the native multicast infrastructure to pseudo-interface via
   AMT sites:
   relays receive the traffic natively and unicast-encapsulate it produce state-change reports in response to
   gateways; gateways decapsulate receiver requests
   made using the traffic 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 possibly forward it
   into IPv6/MLD protocols running on the AMT site.

   Each gateway has pseudo-
   interface:

   o  IPv4 datagrams that carry an AMT pseudo-interface IGMPv2, or IGMPv3 Membership Report
      or an IGMPv2 Leave Group message as described in Section 4 of
      [RFC3376].

   o  IPv6 datagrams that serves carry an MLDv1 or MLDv2 Multicast Listener
      Report or an MLDv1 Multicast Listener Done message as a default
   multicast route.  Requests to join a multicast session are sent to
   this interface and encapsulated described in
      Section 5 of [RFC3810].

   The gateway must be prepared to a particular relay reachable
   across receive these messages any time the unicast-only infrastructure.

   Each relay has an AMT
   pseudo-interface too.  Multicast traffic sent
   on this interface is encapsulated to zero or more gateways running.  The gateway MUST ignore any datagrams
   not listed above.

   A gateway that have
   joined waits to start a membership update cycle until after
   it receives an IGMP/MLD state-change message MAY:

   o  Discard datagrams containing IGMP/MLD messages until it receives a
      Membership Query message, at which time it processes the
      Membership Query message as normal to eventually produce a
      current-state report on the relay.  The AMT recipient-list is determined for each
   multicast session.  This requires pseudo-interface which describes the relay to keep
      end state (RECOMMENDED).

   o  Insert IGMP/MLD messages into a queue for each
   gateway which has joined transmission after it
      receives a particular group Membership Query message.

   If the datagram contains a valid IGMP or (source, group) pair.
   Multicast packets from MLD message, the native infrastructure behind gateway
   sends it to the relay
   will be sent to each gateway which has requested them.

   All multicast packets (data and control) are encapsulated as described in unicast
   packets.  UDP encapsulation is used for all AMT control and data
   packets using the IANA reserved UDP port number for AMT.

   Each relay, plus next section.

5.2.3.6.2.  Sending a Membership Update Message

   A gateway cannot send a Membership Update message to a relay until it
   has received a Membership Query message from a relay.  If the set of all gateways using gateway
   has not yet located a relay with which to communicate, it must first
   execute the relay, together
   are thought of as being on relay discovery procedure described in Section 5.2.3.4 to
   obtain a separate logical NBMA link.  This
   implies that relay address.  If the AMT recipient-list is gateway has a list of "link layer"
   addresses which are (IP relay address, UDP port) pairs.

   Since but has
   not yet received a Membership Query message, it must first execute
   the number of gateways using membership query procedure described in Section 5.2.3.5 to obtain
   a relay can be quite large, Request Nonce and we
   expect Response MAC that most sites will not want to receive most groups, an
   explicit-joining protocol is required for gateways to communicate
   group membership information can be used to send a relay.
   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 two most likely
   candidates are gateway MUST copy
   the IGMP/MLD protocol [RFC3376], [RFC3810], Request Nonce and Response MAC values from the
   PIM-Sparse Mode protocol [RFC4601].  Since an last Membership
   Query received from the relay into the corresponding fields in the
   Membership Update.  The gateway MUST send the Membership Update
   message using the Relay Address and IANA-assigned AMT port number as
   the destination.

   When a gateway sends a Membership Update message, it may be a
   host, and hosts typically do not implement routing protocols,
   gateways will use IGMP/MLD 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 7 below. 5.2.3.9.

5.2.3.7.  Teardown Procedure

   This
   allows a host kernel (or a pseudo device driver) to easily implement
   AMT section describes gateway behavior, and obviates requirements related to the relay from teardown
   message sequence described in Section 4.2.1.3.

   Gateway support for the need to know
   whether a given gateway Teardown message is OPTIONAL but RECOMMENDED.

   A gateway that supports Teardown SHOULD make use of Teardown
   functionality if it receives a host or Membership Query message from a router.  From relay
   that has the relay's
   perspective, all gateways are indistinguishable from hosts on an NBMA
   leaf network.

5.1.  Scalability Considerations

   It is possible "G" flag set to indicate that millions of hosts will enable AMT it contains valid gateway
   functionality
   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 so an important design goal is not to create receives a
   Membership Query message with the "G" flag set, the gateway state in each relay until 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 joins
   MUST send a multicast
   group.  But even Teardown message as described in the requirement that next section.

5.2.3.7.2.  Sending a relay keep group state per Teardown Message

   A gateway that has joined sends a group introduces potential scalability
   concerns.

   Scalability of AMT can be achieved by adding more relays, and using
   an appropriate relay discovery mechanism for gateways to discover
   relays.  The solution we adopt is to assign addresses in anycast
   fashion Teardown message to relays [RFC1546], [RFC4291].  However, simply sending
   periodic membership reports a relay to an anycast address can cause
   duplicates.  Specifically, if routing changes such request that it stop
   delivering Multicast Data messages to the gateway and delete any
   group memberships created by the gateway.

   When a different
   relay receives gateway constructs a periodic membership report, both Teardown message, it MUST copy the new
   Request Nonce, Response MAC, Gateway IP Address and old
   relays will encapsulate data to Gateway Port
   Number fields from the AMT site until Membership Query message that provided the old relay's
   state times out.  This is obviously undesirable.  Instead, we use
   Response MAC for the
   anycast address merely to find last Membership Update message sent, into the unicast address
   corresponding fields of a relay to
   which membership reports are sent.

   This approach allows the gateways to be spread out among more relays
   so as to keep Teardown message.

   A gateway MUST send the Teardown message using the Relay Address and
   IANA-assigned AMT port number of gateways per relay at a reasonable level.

5.2.  Spoofing Considerations

   An attacker could affect as the group state in destination.  A gateway MAY send
   the relay by spoofing the
   source address Teardown message multiple times for robustness.  The gateway
   SHOULD use the Querier's Robustness Variable (QRV) field contained in AMT Update messages containing join or leave
   reports.  This can be used
   the query encapsulated within the last Membership Query to launch reflection or denial of service
   attacks set the
   limit on the target Relay.  Such attacks can be mitigated by using number of retransmissions.  If the gateway sends the
   Teardown message multiple times, it SHOULD insert a three way handshake delay between
   each transmission using the gateway and the relay timing algorithm employed in IGMP/MLD for each
   multicast membership report or leave.
   transmitting unsolicited state-change reports.

   When a gateway wants to send sends a membership report, Teardown message, it first sends may be notified that an
   AMT Request with
   ICMP Destination Unreachable message was received as a request nonce result of an
   earlier AMT message transmission.  Handling of ICMP Destination
   Unreachable messages is described in it.  The Relay can calculate 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 authentication code (MAC) based on (for example)the source IP
   address of to the Request, relay as described in
      Section 5.2.3.7, but only if the source UDP port, gateway supports the request nonce, Teardown
      message, and the current relay is returning gateway address fields
      in Membership Query messages, or

   o  Send a
   secret key known only Membership Update message to the Relay.  The algorithm does not have to
   be standardized since 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 Relay generates and verifies gateway is
   notified that an ICMP message was received is highly dependent the MAC
   gateway IP stack behavior and gateway implementation.

   If the Gateway simply echoes it back, but reception of an ICMP Destination Unreachable message is
   reported to the gateway while waiting to receive an algorithm such as
   HMAC-MD5-48 [RFC2104] SHOULD be used at a minimum.

   An AMT Membership Query 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 back to was a Relay Discovery or Request
       message, the gateway having originated
   the Request, including MAY simply ignore the request nonce ICMP response and
       continue waiting for incoming AMT messages.  If the MAC.  The gateway
   then sends the IGMP/MLD Membership/Listener Report is
       configured to retransmit Relay Discovery or Leave/Done
   (including the IP Header) along with the request nonce and Request messages, the
   received MAC back
       normal retransmission behavior for those messages is preserved to
       prevent the relay, finalizing the 3-way handshake.

   Upon reception, the relay can recalculate the MAC based on the source
   IP address, gateway from prematurely abandoning a relay.

   3.  If the source UDP port, last message sent was a Membership Update message, the request nonce,
       gateway MAY start a new membership update and associated Request
       retransmission cycle.

   If the local
   secret.  The IGMP/MLD reception of an ICMP Destination Unreachable message is only accepted if the received MAC
   matches
   reported to the calculated MAC.

   A relay MUST NOT create state for a gateway before successful
   validation of when attempting to transmit a MAC of an new AMT Update from this gateway; a relay
   SHOULD delete all states for a
   message, the gateway after a small timer after 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
   stops having any AMT forwarding state does not allow for transient network changes.

   2.  If the last message sent was a Gateway (i.e. Relay Discovery, Request or
       Teardown message, the Gateway
   left all multicast groups it had joined).

   The local secret never has gateway MAY attempt to be shared with transmit the other side.  It new
       message.  If the gateway is
   only used configured to verify return routability of the originator.

   Since the same retransmit Relay
       Discovery, Request Nonce and source IP address can be re-used,
   the relay SHOULD change its secret key at least once per hour.
   However, AMT Membership updates received with or Teardown messages, the previous secret
   MUST be accepted normal
       retransmission behavior for up those messages is preserved to the IGMP/MLD Query Interval.

   The condition might occur where
       prevent the gateway that initially from prematurely abandoning a relay.

   3.  If the last message sent was a Membership Update message, the
   AMT Request dynamically changes its IP address.  This might occur due
   to
       gateway SHOULD start a change new membership update and associated
       Request retransmission cycle.

5.3.  Relay Operation

   The following sections describe relay implementation requirements.  A
   non-normative discussion of relay operation may be found in wireless networks,
   Section 4.2.

5.3.1.  IP/IGMP/MLD Protocol Requirements

   A relay requires a DHCP assignment, or another
   network failure.  When this occurs, it is no longer possible to
   verify the MAC using the source address subset of router-mode IGMP and source port.  Though, in
   order to reduce state, it is desirable MLD functionality
   to tear down the state that
   was created with 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 old source address. forwarding rules described in Section 6.3 of
   [RFC3376] and Section 7.3 of [RFC3810].

   A Teardown message relay MUST handle incoming reports as described ,Section 6.4 of

   [RFC3376] and Section 7.4 of [RFC3810] with
   special considerations for calculating the MAC is described below exception that
   actions that lead to
   perform this function.

5.3.  Protocol Sequence

   This description assumes the Gateway can queries MAY be a host joining modified to eliminate query
   generation.

   All other aspects of IGMP/MLD router behavior, such as a
   receiver the handling
   of queries, querier election, etc., are not used or a network device acting as a Gateway when a directly
   connected host joins as a receiver.

   Protocol sequence required for a multicast SSM channel (S1,G1):

   o  Receiver at AMT site sends IGMPv3/MLDv2 report joining (S1,G1).

   o  Gateway receives report.
   relay operation.

5.3.2.  Startup

   If it has no tunnel state with a Relay,
      it originates relay is deployed for anycast discovery, the relay MUST
   advertise an AMT anycast Relay Discovery message addressed to Address Prefix into the
      Anycast Relay IP address.  The AMT unicast
   routing system of the anycast domain.  An address within that prefix,
   i.e., a Relay Discovery message can Address, MUST be
      sent on demand if no assigned to a relay is known at this time or at startup and
   interface.

   A unicast IPv4 and/or IPv6 address MUST be periodically refreshed.

   o  The closest Relay topologically receives assigned to the relay
   interface that will be used to send and receive AMT Relay Discovery
      message control and returns the nonce from the Discovery data
   messages.  This address or addresses are returned in an AMT Relay
   Advertisement message so the Gateway can learn messages.

   The remaining details of the Relay's
      unique IP address.

   o relay "startup" are highly implementation-
   dependent and are not addressed in this document.

5.3.3.  Running

   When the Gateway receives the AMT Relay Advertisement message, a relay is started, it
      now has an address to use begins listening for all subsequent (S,G) entries it will
      join AMT messages on behalf of attached receivers (or itself).

   o  If the gateway
   interface to which the unicast Relay Address(es) has a valid Response MAC from a previous AMT Query
      message, it can send an AMT Membership Update message as described
      below.  Otherwise, been assigned,
   i.e., the Gateway sends an address returned in Relay Advertisement messages.

5.3.3.1.  Handling AMT Request Messages

   A relay MUST ignore any message to 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
      Relay's unique IP address to begin sections that follow.

   Support for the process of joining Teardown message is OPTIONAL.  If a relay does not
   support the
      (S,G).  The gateway Teardown message, it MUST also SHOULD initialize a timer used to send
      periodic Requests ignore this message.

   A relay that conforms to this specification MUST ignore any message
   with a random Version field value from the interval [0, [Query
      Interval]] before sending other than zero.

5.3.3.2.  Handling a Relay Discovery Message

   This section describes relay requirements related to the first periodic report, relay
   discovery message sequence described in order Section 4.2.1.1.

   A relay MUST accept and respond to
      prevent startup synchronization.

   o  The Relay responds Discovery messages sent to
   an anycast relay discovery address or the AMT Request message by returning the
      nonce from the Request in unicast relay address.  If
   a AMT Query message.  The Query relay receives a Relay Discovery message
      contains an IGMP/MLD QUERY indicating how often the Gateway should
      repeat AMT Request messages so the (S,G) state can stay refreshed
      in sent to its unicast
   address, it must respond just as it would if the Relay.  The Query message also includes an opaque security
      code which is generated locally (with no external coordination).

   o had been
   sent to its anycast discovery address.

   When the Gateway a relay receives the AMT Query a Relay Discovery message it responds by
      copying the security code from the AMT Query message into
   sending a AMT
      Membership Update message.  The Update Relay Advertisement message contains (S1,G1) in
      an IGMPv3/MLDv2 formatted packet with an IP header.  The nonce
      from the AMT Request is also included in back to the AMT Membership Update
      message.

   o  When source of the Relay receives the AMT Membership Update, it will add
   Discovery message.  The relay MUST use the
      tunnel to source IP address and UDP
   port of the Gateway in it's outgoing interface list for it's
      (S1,G1) entry stored in Relay Discovery message as the multicast routing table.  If destination IP address and
   UDP port.  The relay MUST use the
      (S1,G1) entry was created do to this interaction, destination IP address and UDP port
   of the multicast
      routing protocol running on Relay Discovery as the Relay will trigger a Join message
      towards source S1 IP address and UDP port to build a native multicast tree
   ensure successful NAT traversal.

   The relay MUST copy the value contained in the native
      multicast infrastructure.

   o  As packets are sent from Discovery Nonce field
   of the host S1, they will travel natively
      down Relay Discovery message into the multicast tree associated with (S1,G1) Discovery Nonce field in the native
      multicast infrastructure to
   the Relay.  The Relay will replicate
      to all interfaces in it's outgoing interface list as well Advertisement message.

   If the Relay Discovery message was received as an IPv4 datagram, the
      tunnel outgoing interface, which is encapsulated
   relay MUST return an IPv4 address in a unicast AMT
      Multicast Data message.

   o  When the Gateway receives Relay Address field of the AMT Multicast Data message, it will
      accept
   Relay Advertisement message.  If the packet since it Relay Discovery message was
   received over as an IPv6 datagram, the pseudo-interface
      associated with relay may return an IPv4 or IPv6
   address in the tunnel Relay Address field.

5.3.3.3.  Handling a Request Message

   This section describes relay requirements related to the Relay it had attached to, and
      forward membership
   query portion of the packet 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 outgoing interfaces joined by any
      attached receiver hosts (or deliver source of the packet to Request message.

   The relay MUST use the application
      when source IP address and UDP port of the Gateway is Request
   message as the receiver).

   o  If later (S2,G2) is joined destination IP address and UDP port for the Membership
   Query message.  The source IP address and UDP port carried by a receiver, a 3-way handshake the
   Membership Query MUST match the destination IP address and UDP port
   of
      Request/ Query/Update occurs for this entry. the Request to ensure successful NAT traversal.

   The Discovery/
      Advertisement exchange is not required.

   o  To keep relay MUST return the state for (S1,G1) and (S2,G2) alive value contained in the Relay, Request Nonce field
   of the
      Gateway will send periodic AMT Membership Updates.  The Membership
      Update can be sent directly if Request message in the sender has a valid nonce from a
      previous Request.  If not, an AMT Request messages should be sent
      to solicit a Nonce field of the Membership
   Query Message.  When sending message.  The relay MUST compute a periodic state
      refresh, all joined state MAC value, as described in the Gateway is packed
   Section 5.3.5, and return that value in the fewest
      number Response MAC field of AMT the
   Membership Update messages.

   o  When Query message.

   If a relay supports the Gateway leaves all (S,G) entries, Teardown message, it MUST set the Relay can free
      resources associated with G-flag in
   the tunnel.  It is assumed that when Membership Query message and return the source IP address and UDP
   port carried by the Request message in the corresponding Gateway would want to join an (S,G) again, IP
   Address and Gateway Port Number fields.  If the relay does not
   support the Teardown message it would start SHOULD NOT set these fields as this
   may cause the
      Discovery/Advertisement tunnel establishment process over again.

   This same procedure would be used for receivers who operate in Any-
   Source Multicast (ASM) mode.

6.  Message Formats

6.1.  Use of UDP

   All AMT messages are UDP packets.

   Messages sent gateway to generate unnecessary Teardown messages.

   If the Relay are sent to P-flag in the IANA reserved AMT port
   number (Section 9), from a source port uniquely selected by Request message is 0, the host
   operating system of relay MUST return an
   IPv4-encapsulated IGMPv3 general query in the Gateway.  Messages sent by Membership Query
   message.  If the Relay are sent
   from P-flag is 1, the IANA reserved AMT port number.

   The UDP checksum relay MUST be valid return an IPv6-
   encapsulated MLDv2 general query in all AMT control messages (Relay
   Discovery, Relay Advertisement, Membership Request, Membership Query, the Membership Update).  Section 6.7 specifies Query message.

   If the behavior with
   reference relay is not accepting Membership Update messages that create
   new tunnel endpoints due to resource limitations, it SHOULD set the UDP checksums of AMT IP Multicast Data messages.

6.2.  AMT Relay Discovery

   The AMT Relay Discovery
   L-flag in the Membership Query message is sent from to notify the AMT gateway unicast
   address to of this
   state.  Support for the AMT Relay Anycast address L-flag is OPTIONAL.  See Section 5.3.3.8.

   The IGMPv3/MLDv2 general query datagram that a relay encapsulates
   within a Membership Query message MUST conform to discover the unicast
   address of an AMT relay.

   The payload descriptions
   found in Section 4.1 of the UDP packet contains the following fields.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type=0x1  |     Reserved                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Discovery Nonce                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            AMT Relay Discovery

6.2.1.  Type

   The type [RFC3376] and Section 5.1 of [RFC3810].
   These datagrams MUST possess the message.

6.2.2.  Reserved

   A 24-bit reserved field.  Sent as 0, ignored on receipt.

6.2.3.  Discovery Nonce

   A 32-bit random value generated by the gateway IP headers, header options and replayed by
   header values called for in these RFCs, with the
   relay.

6.3.  AMT Relay Advertisement

   The AMT Relay Advertisement message sent from following exception;
   the AMT relay anycast source IP address for an IGMP/MLD general query datagram MAY be
   set to the "unspecified" address (all octets are zero).  This
   exception is made because any address that a relay might use will not
   be a valid source address on any gateway interface.  To allow for
   this exception, gateways must accept an IGMP or MLD query regardless
   of the discovery message.

   The UDP source port is the IANA reserved AMT port number and the UDP
   destination port is address it carries.  See Section 5.2.1.

   A relay MUST set the source port received Querier's Query Interval Code (QQIC) field in
   the Discovery
   message.

   The payload of general query to supply the UDP packet contains gateway with a suggested time
   duration to use for the following fields.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type=0x2  |     Reserved                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Discovery Nonce                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Relay Address                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          AMT Relay Advertisement

6.3.1.  Type membership query timer.  The type of the message.

6.3.2.  Reserved

   A 24-bit reserved field.  Sent as 0, ignored on receipt.

6.3.3.  Discovery Nonce QQIC field is
   defined in Section 4.1.1 in [RFC3376] and Section 5.1.3 in [RFC3810].
   A 32-bit random relay MAY adjust this value generated by to affect the gateway and replayed by rate at which the
   relay.

6.3.4.  Relay Address

   The unicast IPv4 or IPv6 address of Request
   messages are sent from a gateway.  However, a gateway is allowed to
   use a shorter duration than specified in the AMT relay.  The family can QQIC field, so a relay
   may be
   determined by limited in its ability to spread out Requests coming from a
   gateway.

   A relay MUST set the length of Querier's Robustness Variable (QRV) field in the Advertisement.

6.4.  AMT Request

   A Request packet is sent by
   general query to a Gateway non-zero value.  This value SHOULD be greater than
   one.  If a gateway retransmits a membership state change messages, it
   will retransmit them (robustness variable - 1) times.

   A relay SHOULD set the Max Resp Code field in the general query to a Relay
   value of 1 to begin a 3-way
   handshake for sending trigger an IGMP/MLD Membership/Listener Report or
   Leave/Done.

   It is sent immediate response from the Gateway address to the Relay's unique unicast
   address.

   The UDP source port is uniquely selected by the local gateway (some
   host operating
   system.  It can be different from the source port used in Discovery
   messages but does IGMP/MLD implementations may not have to be.  The UDP source port must be
   consistent across Request and Update messages (see also Section 7.2).

   The UDP destination port is the IANA reserved 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type=0x3  |     Reserved                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Request Nonce                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                AMT Request

6.4.1.  Type

   The type accept a value of the message.

6.4.2.  Reserved

   A 24-bit reserved field.  Sent as 0, ignored on receipt.

6.4.3.  Request Nonce zero).  A 32-bit identifier used to distinguish this request.

6.5.  AMT Membership
   relay SHOULD NOT use the IGMPv2/MLDv2 Query

   An AMT Membership Response Interval
   variable, if available, to generate the Max Resp Code field value as
   the Query packet Response Interval variable is sent from the Relay back to used in setting the
   Gateway duration
   of group state timers and must not be set to solicit an AMT such a small value.  See
   Section 5.3.3.7.

5.3.3.4.  Handling a Membership Update while confirming Message

   This section describes relay requirements related to the
   source membership
   update portion of the original request.  It contains message sequence described in Section 4.2.1.2.

   When a relay Message
   Authentication Code (MAC) that is a cryptographic hash of receives a private
   secret, the originators address, and the request nonce.

   It is sent from the destination address received in Membership Update message it must first
   determine whether it should accept or ignore the Request message.  A relay
   MUST NOT make any changes to group membership and forwarding state if
   the source address message fails to satisfy any of the Request, i.e. following requirements:

   o  The IP datagram encapsulated within the Relay Address advertised
   in message MUST be one of the Relay Advertisement
      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 UDP source port is the IANA reserved AMT port number and encapsulated IP datagram MUST satisfy the UDP
   destination port is IP header
      requirements for the source port received IGMP or MLD message type as described in the Request message.

    0                   1                   2                   3
    0 1 2 3
      Section 4 5 6 7 8 9 0 1 of [RFC3376], Section 2 3 4 of [RFC2236], Section 5 6 7 8 9 0 1 2 of
      [RFC3810], Section 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type=0x4  |    Flags      |         Response MAC          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Response MAC (continued)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Request Nonce                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            IGMP Membership Query or MLD Listener Query        |
   |            (including of [RFC2710].

   o  The total length of the encapsulated IP Header)                              |
   |            ...                                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Gateway Port Number       |       Gateway Address ...     | ?
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?
   |                    ... Gateway Address (ctd) ...              | ?
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?
   |                    ... Gateway Address (ctd) ...              | ?
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?
   |                    ... Gateway Address (ctd) ...              | ?
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?
   |   ... Gateway Address (ctd)   |                                 ?
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           AMT datagram as computed from
      the lengths contained in the datagram header(s) MUST NOT exceed
      the available field length within the Membership Query

6.5.1.  Type Update message.

   o  The type computed checksums for the encapsulated IP datagram and its
      payload MUST match the values contained therein.  Checksum
      computation and verification varies 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 message.

6.5.2.  Flags

   An 8-bit flags field having relay MUST authenticate the following format:
                    0 1 2 3 4 5 6 7
                   +-+-+-+-+-+-+-+-+
                   |   Reserved  |G|
                   +-+-+-+-+-+-+-+-+

   The "G" flag is set to 1 if Gateway information fields are present in source of the Query Membership message (see below Section 6.5.6), and to zero if they are
   not.

   Other flags are currently unused and reserved: they are sent as zero
   and their
      by verifying that the value is ignored on receipt.

6.5.3. contained in the Response MAC

   A 48-bit hash generated by field
      equals the Relay and sent to MAC value computed from the Gateway for
   inclusion fields in the AMT Membership
      Update (see Section 5.2).

6.5.4.  Request Nonce

   A 32-bit identifier echoed back to message datagram.  Because the originator to private secret used to identify
      compute Response MAC values may change over time, the corresponding request (see Section 5.2).

6.5.5.  IGMP/MLD Query (including IP Header)

   The message contains either an IGMP Query or an MLD Multicast
   Listener Query.  The IGMP or MLD relay MUST
      retain the previous version sent should default to
   IGMPv3 or MLDv2 unless explicitly configured of the private secret to use IGMPv2 or MLDv1.
   The IGMP/MLD Query includes a full IP Header.  The IP source address
   of in
      authenticating Membership Updates sent during the subsequent query would match the anycast address on
      interval.  If the pseudo interface.
   The TTL of first attempt at Response MAC authentication
      fails, the outer IP header should be sufficient relay MUST attempt to reach the
   tunnel endpoint and not mimic authenticate the inner IP header TTL which is
   typically 1 for IGMP/MLD messages.

6.5.6.  Gateway information fields

   The "Gateway Port Number" and "Gateway Address" fields are present in Response MAC
      using the Query message if, and only if, previous private secret value unless 2*query_interval
      time has elapsed since the "G" flag is set private secret change.  See
      Section 5.3.5.  An alternative approach to Response MAC generation
      that avoids repeated Response MAC computations may be found in the Flags
   field.

6.5.6.1.  Gateway Port Number
      Appendix A.1.

   A 16-bit field containing a UDP port value.

   The Relay sets this field relay MAY skip source authentication to reduce the value computational
   cost of handling Membership Update messages if the UDP source port of relay can make a
   trivial determination that the
   Request IGMP/MLD message that triggered carried by the Query message.

6.5.6.2.  Gateway Address

   A 16-byte field containing
   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 IP
   source address of the Request Membership Update message that triggered this Query message.  The field contains an
   IPv4-compatible IPv6 address ([RFC4291], section 2.5.5.1) if and either of the
   address following
   is true:

   o  The encapsulated IP datagram is an IPv4 address (i.e. the IPv4 address prefixed with 96
   bits set to zero), or an IPv6 address.

6.6.  AMT Membership Update

   An AMT IGMPv3 Membership Update is sent to report a membership after a valid
   Response MAC has been received.  It contains the original IGMP/MLD
   Membership/Listener Report or Leave/Done received over
      MLDv2 Multicast Listener Report message that contains no group
      records.  This may often be the AMT
   pseudo-interface including case for gateways that
      continuously repeat the original membership update cycle even though they
      have no group subscriptions to report.

   o  The encapsulated IP header.  It echoes the
   Response MAC received datagram is an IGMPv2 Leave Group or MLDv1
      Multicast Listener Done message.

   An MLD datagram contained in the AMT a Membership Query so Update message may require
   special handling.  The encapsulated datagram generated by a gateway
   will likely carry an unspecified or link-local source address.  If
   the respondent
   can verify return routability relay relies on a standard router-mode MLD protocol
   implementation to process these reports, that implementation may
   silently ignore the originator.

   It is sent from MLD report because it carries an unspecified or
   non-link-local source address - a relay may need to use the destination address received in contents
   of the Query encapsulated datagram to the construct a new datagram with a valid
   link-local source address received (e.g., a spoofed address in a virtual
   subnet defined by the Query which should both be address and netmask assigned to the same as relay
   pseudo-interface) to ensure that the original Request.

   The UDP source and destination port numbers should report will not be ignored by
   the same ones
   sent in MLD protocol implementation.

   Once a relay has determined that the original Request.

   The UDP destination port Membership Update message is
   valid, it processes the IANA reserved AMT port number encapsulated IGMP or MLD membership message
   to update group membership state and communicates with the
   UDP source port is the source port used for the Request message.

   The Relay is not required multicast
   protocol to use 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 source address datagram and
   the end of the IGMP Membership Report for any particular purpose.

   The same Request Nonce Update message.

   As described in Section 4.2.2, a relay uses the source IP address and Response MAC can be used across multiple
   AMT
   source UDP port carried by a Membership Update messages without having to send individual AMT
   Membership Query messages.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type=0x5  |    Reserved   |         Response MAC          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Response MAC (continued)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Request Nonce                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            IGMP or MLD Message (including IP header)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            ...                                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           AMT Membership Update

6.6.1.  Type

   The type of identify a
   tunnel endpoint.  A relay uses the tunnel endpoint as the message.

6.6.2.  Reserved

   A 8-bit reserved field.  Sent destination
   address for any Multicast Data messages it sends as 0, ignored on receipt.

6.6.3.  Response MAC

   The 48-bit MAC received in a result of the Membership Query
   group membership and echoed back forwarding state created by processing the IGMP/
   MLD messages contained in Membership Update messages received from
   the endpoint.

   If a Membership Update (see Section 5.2).

6.6.4.  Request Nonce

   A 32-bit identifier matching message originates from a new endpoint, the nonce in
   relay MUST determine whether it can accept updates from a new
   endpoint.  If a relay has been configured with a limit on the AMT Request (see
   Section 5.2).

6.6.5.  IGMP/MLD Message (including IP Header)

   The message contains either an IGMP Membership Report, an IGMP
   Membership Leave, an MLD Multicast Listener Report, or an MLD
   Listener Done.  The IGMP or MLD version sent should be in function total
   number of endpoints, or a limit on the version total number of endpoints for
   a given source address, then the query received in relay MAY ignore the AMT Membership Query.
   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
   IGMP/MLD Message includes per-endpoint databases are used update a full IP Header.

6.7.  AMT IP Multicast Data forwarding
   table containing entries that map an (*,G) or (S,G) subscription to a
   list of tunnel endpoints.

   A relay MUST maintain some form group membership database
   representing a merger of the group membership databases of all
   endpoints.  The AMT Data message merged group membership database is used to update
   upstream multicast forwarding state.

   A relay MUST maintain a UDP packet encapsulating 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 requested by the originator based Data messages.

   If a group filter mode for a group entry on a previous AMT Membership
   Update message.

   It tunnel endpoint is sent from the Relay's unique unicast address (destination
   address of
   EXCLUDE, the Membership update) to relay SHOULD NOT forward datagrams that originate from
   sources in the Gateway's unicast address
   (source address of filter source list unless the Membership Update).

   The UDP relay architecture does
   not readily support source port is filtering.  A relay MAY ignore the IANA reserved AMT port number and 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
   destination port should be teardown
   message sequence described in Section 4.2.1.3.

   When a relay (that supports the same as Teardown message) receives a Teardown
   message, it MUST first authenticate the source port of the
   Membership Update Teardown
   message by verifying that resulted in the creation of forwarding state
   for the encapsulated IP packet.

   The UDP checksum SHOULD be zero for AMT IP Multicast Data messages
   carried over IPv4, and MAY be zero for AMT IP Multicast Data messages Response MAC carried over IPv6 [I-D.ietf-6man-udpchecksums].

   The payload of by the UDP packet contains Teardown
   message is equal to a MAC value computed from the following fields.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type=0x6  |    Reserved   |     IP Multicast Data ...     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            ...                                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           AMT IP Multicast Data

6.7.1.  Type

   The type of fields carried by
   the Teardown message.

6.7.2.  Reserved

   An 8-bit reserved field.  Sent as 0, ignored on receipt.

6.7.3.  IP Multicast Data  The original IP Multicast data packet method used to compute the MAC differs
   from that used to generate and validate the Membership Query and
   Membership Update messages in that is being replicated by the
   Relay source IP address and source
   UDP port number used to compute the Gateway, including MAC are taken from the original Gateway IP header.

6.8.  AMT
   Address and Gateway Port Number field in the Teardown

   An AMT message rather
   than from the IP and UDP headers in the datagram that carries the
   Teardown message.  The MAC computation is sent by a Gateway after described Section 5.3.5.  A
   relay MUST ignore a valid Response Teardown message If the computed MAC has
   been received and after does not
   equal the source address that was used to generate value of the Response MAC field.

   If a relay determines that a Teardown message is no longer available for sending packets.

   It is sent authentic, it MUST
   immediately stop transmitting Multicast Data messages to the source address received in endpoint
   identified by the original Query which
   should be Gateway IP Address and Gateway Port Number fields
   in the same as message.  The relay MUST eventually delete any group
   membership and forwarding state associated with the original Request. 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 UDP destination port number should state changes made by a relay when processing a Teardown message
   MUST be identical to those that would be made as if the same one sent relay had
   received an IGMP/MLD report that would cause the IGMP or MLD protocol
   to delete all existing group records in the
   original Request.

   An AMT group membership database
   associated with the endpoint.  The processing of the Teardown from message
   should trigger or mimic the original source address normal interaction between IGMP or MLD
   and source port is
   NOT valid a multicast protocol to produce required changes in forwarding
   state and should be discarded if received.  Use an AMT Membership
   Update instead.

   In order 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 Relay to verify datagram, encapsulate the Teardown message, this IP datagram into
   a Multicast Data message
   must contain the original source address and source port in addition send that message to the Original Request Nonce and Original Response MAC.  In
   situations where NAT gateway.  This
   process is used, this information can be known by highly implementation dependent, but conceptually requires
   the
   Gateway thanks follow steps:

   o  Use the IP datagram source and destination address to look up the optional Gateway information fields
      appropriate (*,G) or (S,G) entry in the
   Query message (Section 6.5.6).  Hence, endpoint forwarding table
      created for the pseudo-interface as a Relay supporting result of IGMP/MLD
      processing.

   o  Possibly replicate the
   Teardown mechanism SHOULD include datagram for each gateway endpoint listed
      for that (*,G) or (S,G) entry.

   o  Encapsulate the Gateway information fields IP datagram in
   the Query messages it sends.

   On reception of a valid Teardown UDP/IP Membership Data message, a Relay should remove all
   state corresponding to
      using the gateway identified by endpoint UDP/IP address as the destination address and
      the unicast relay address and IANA-assigned port as the (original source
   address, original
      UDP/IP address.  To ensure successful NAT traversal, the source port) tuple,
      address and stop forwarding all traffic
   to this destination.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type=0x7  |    Reserved   |    Original Response MAC      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Original Response MAC (continued)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Original Request Nonce                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Original Source Port      |  Original Source Address ...  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Original Source Address (ctd) ...            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             ...  Original Source Address (ctd) ...            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             ...  Original Source Address (ctd) ...            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ... Original Src Addr. (ctd)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          AMT port MUST match the destination address and port
      carried by the Membership Teardown

6.8.1.  Type Update message sent by the gateway to
      create the forwarding table entry.

   o  Send the message to the gateway.

   The type relay pseudo-interface MUST ignore any other IP datagrams
   forwarded to the pseudo-interface.

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 message.

6.8.2.  Reserved gateway fail to
   refresh the group membership state within a specified time interval.

   A 8-bit reserved field.  Sent 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 RECOMMENDED endpoint timer duration MAY be computed from tunable
   IGMP/MLD variables as 0, ignored on receipt.

6.8.3.  Original Response MAC follows:

   ((Robustness_Variable) * (Query_Interval)) + Query_Response_Interval

   If IGMP/MLD default values are used for these variables, the gateway
   will timeout after 125s * 2 + 10s = 260s.  The 48-bit MAC received timer duration MUST be
   greater than the query interval suggested in the last Membership Query.

6.8.4.  Original Request Nonce

   A 32-bit identifier corresponding
   Query message sent to the original Request.

6.8.5.  Original Source Port

   The 16-bit port number 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 original AMT Request 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
   was used connect to generate the Original Response MAC.

6.8.6.  Original Source 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

   A 16-byte field containing Prefix it has advertised into the IP source address used unicast internetwork and
   SHOULD set the L-flag in any Membership Query messages it returns to
   gateways while in this state.

   If the original
   AMT Request message relay receives an update from a gateway that was used to generate adds group
   membership or forwarding state for an endpoint that has already
   reached maximum allowable state entries, the Original Response
   MAC of relay SHOULD continue to
   accept updates from the Request message gateway but ignore any group membership/
   forwarding state additions requested by that triggered this Query message.  The
   field contains an IPv4-compatible IPv6 address ([RFC4291], section
   2.5.5.1) if gateway.

   If the address is relay receives an IPv4 address (i.e. the IPv4 update from a gateway that would create a
   new tunnel endpoint for a source IP address
   prefixed with 96 bits set to zero), or an IPv6 address.

7.  AMT Gateway Details

   This section details the behavior that has already reach
   maximum allowable number of an AMT Gateway, which may endpoints (maximum UDP ports), it should
   simply ignore the Membership Update.

5.3.4.  Shutdown

   The following steps should be a
   router serving treated as an AMT site, or the site may consist abstract description of
   the shutdown procedure for a single host,
   serving as its own gateway.

7.1.  At Startup Time

   At startup time, relay:

   o  Withdraw the AMT gateway will bring up an AMT pseudo-
   interface to be used Relay Discovery Address Prefix advertisement (if
      used).

   o  Stop listening for encapsulation.  The gateway needs to
   discover an AMT Relay Discovery messages.

   o  Stop listening for control messages from gateways.

   o  Stop sending data messages to send Membership Requests.  It can send an gateways.

   o  Delete all AMT Relay Discovery at startup time or wait until it has 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 is produced by a hash digest computation.  A Response
   MAC value is computed from a group
   membership to report.  The AMT Relay Discovery Request message for inclusion in a
   Membership Query message, is sent computed from a Membership Update
   message to authenticate the
   AMT Relay Anycast Address.  A unicast address (which Response MAC carried within that message,
   and is treated computed from fields in a Teardown message to authenticate the
   Response MAC carried within that message.

   Gateways treat the Response MAC field as an opaque value, so a
   link-layer address relay
   implementation may generate the MAC using any method available to it.
   The hash function RECOMMENDED for use in computing the encapsulation interface) Response MAC
   is received in the
   AMT Relay Advertisement message. MD5 hash digest [RFC1321], though hash functions or keyed-hash
   functions of greater cryptographic strength may be used.

   The discovery process SHOULD digest MUST be
   done periodically (e.g., once a day) to re-resolve computed over the unicast following values:

   o  The Source IP address of a close relay.  To prevent startup synchronization, the
   timer SHOULD use at least 10 percent jitter.

   If message (or Teardown Gateway IP
      Address field)

   o  The Source UDP port of the gateway message (or Teardown Gateway Port
      Number field)

   o  The Request Nonce contained in the message.

   o  A private secret known only to the relay

   An Response MAC generation solution that satisfies these requirements
   is serving as a local router, it SHOULD also function
   as an IGMP/MLD Proxy, as described in [RFC4605], with its IGMP/MLD
   host-mode interface being Appendix A.1.

5.3.6.  Private Secret Generation

   The private secret, or hash-key, is a random value that the AMT pseudo-interface.  This enables it relay
   includes in the Response MAC hash digest computation.  A relay SHOULD
   periodically compute a new private secret.  The RECOMMENDED maximum
   interval is 2 hours.  A relay MUST retain the prior secret for use in
   verifying MAC values that were sent to translate group memberships on its downstream interfaces into
   IGMP/MLD Reports.  Hosts receiving multicast packets through an AMT
   gateway acting as gateways just prior to the use
   of the new secret.

   The private secret SHOULD be computed using a proxy should ensure cryptographically-
   secure pseudo-random number generator.  The private secret width
   SHOULD equal that their M-RIB accepts
   multicast packets from of the AMT gateway for hash function used to compute the sources it Response
   MAC, e.g., 128-bits for an MD5 hash.

6.  Security Considerations

   AMT is joining.

7.2.  Gateway identification

   From not intended to be a strongly secured protocol.  In general,
   the point of view protocol provides the same level of a Relay, a Gateway security and robustness as is identified
   provided by the (IP
   source address, UDP source port) tuple in Membership Update messages.
   If an implementation UDP, IGMP and MLD protocols on which it relies.  The
   lack of Gateway procedure was to use a different UDP
   source port and/or IP source address strong security features can largely be attributed to join or leave different
   multicast groups, it would appear the
   desire to make the Relay as distinct Gateways.

   For instance, a Relay having forwarding state resulting in protocol light-weight by minimizing the
   forwarding of (S,G) state and
   computation required to service a said gateway identified by single gateway, thereby allowing a (IP source
   address, UDP source port) tuple, will not remove this state if it
   receives an AMT Membership Update message from
   relay to service a different (IP source
   address, UDP source port) tuple.

   It results 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 a Gateway has can affect the functioning of gateways or their
   ability to use locate and communicate with a relay.  These scenarios are
   described below.

   As is the same UDP source port case for AMT
   Request UDP, IGMP and MLD, the AMT Update messages related to protocol provides no
   mechanisms for ensuring message delivery or integrity.  The protocol
   does not provide confidentiality - multicast groups, sources and
   streams requested by a same (S,G).  A said
   Gateway instance is typically expected to use gateway are sent in the same UDP source
   port and IP clear.

   The protocol does use a three-way handshake to provide trivial source address
   authentication for all Request state allocation and Updates messages for
   all multicast groups.

7.3.  Joining Multicast Groups updates (see below).  The IGMP/MLD
   protocol usually operates also requires gateways and relays to ignore malformed
   messages and those messages that do not carry expected address values
   or protocol payload types or content.

6.1.  Relays

   The three-way handshake provided by having the Querier
   multicast an IGMP/MLD Query membership update message
   sequence (See (Section 4.2.1.2)) provides a defense against source-
   spoofing-based resource-exhaustion attacks on the link.  This behavior does
   not work on NBMA links which do not support multicast.  Since the set
   of gateways is typically unknown a relay by requiring
   source authentication before state allocation.  However, attackers
   may still attempt to flood a relay with Request and Membership Update
   messages to force the relay (and potentially quite
   large), unicasting to make the queries is also impractical.  The following
   behavior is used instead.

   Applications residing hash computations in a gateway should join groups on an
   effort to consume computational resources.  Implementations may
   choose to limit the AMT
   pseudo-interface, causing IGMP/MLD Membership/Listener Reports frequency with which a relay responds to be Request
   messages sent over that interface.  When UDP encapsulating the membership
   reports (and in fact any other messages, unless specified otherwise
   in this document), the destination from a single IP address in the outer or IP header is
   the relay's unicast address.  Robustness address and UDP port
   pair, but support for this functionality is provided by the
   underlying IGMP/MLD protocol messages sent on the AMT pseudo-
   interface.  In other words, the gateway does not need to retransmit
   IGMP/MLD Membership/Listener Reports and Leave/Done messages received
   on the pseudo-interface since IGMP/MLD will already do this. required.  The three-
   way handshake provides no defense against an eavesdropping or man-in-
   the-middle attacker.

   Attackers that execute the gateway simply needs to encapsulate each IGMP/MLD Membership/Listener
   Report and Leave/Done message it receives.

   However, since periodic IGMP/MLD Membership/Listener Reports are sent
   in response to IGMP/MLD Queries, 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 to trigger periodic
   Membership/Listener Reports and Leave/Done messages is necessary.
   The for limiting the number of tunnels (Multicast
   Data message destinations) that can be created for a single gateway
   source address.  Relays should use also provide a timer to trigger periodic AMT Membership
   Updates.

   If means for limiting the gateway is behind
   number of joins per tunnel instance as a firewall device, the firewall defense against these
   attacks.

   Relays may require withdraw their AMT anycast prefix advertisement when they
   reach configured maximum capacity or exhaust required resources.
   This behavior allows gateways to use the gateway relay discovery process to periodically refresh
   find the UDP state in next topologically-nearest relay that has advertised the firewall at
   prefix.  This behavior also allows a shorter interval than the standard IGMP/MLD Query interval.  AMT
   Requests can be sent periodically successful resource exhaustion
   attack to propagate from one relay to solicit IGMP/MLD Queries.  The
   interval at which the AMT Requests are sent should next until all relays
   reachable using the anycast address have effectively been taken
   offline.  This behavior may also be configurable used to
   ensure acquire the firewall does not revert unicast
   addresses for individual relays which can then be used to blocking launch a
   DDoS attack on all of the UDP encapsulated
   IP Multicast data packets.  When relays without using the AMT Query is received, it relay discovery
   process.  To prevent wider disruption of AMT-based distribution
   network, relay anycast address advertisements can be
   ignored unless it is time for limited to
   specific administrative routing domains.  This will isolate such
   attacks to a single domain.

6.2.  Gateways

   A passive eavesdropper may launch a denial-of-service attack on a
   gateway by capturing a periodic AMT Membership Update.

   The relay can use Query or Membership Update message
   and using the Querier's Robustness Variable (QRV) defined in
   [RFC3376] request nonce and [RFC3810] message authentication code carried
   by the captured message to send a spoofed a Membership Update or
   Teardown message to adjust the number of Membership/Listener
   Reports that are sent by relay.  The spoofed messages may be used to
   modify or destroy group membership state associated with the host joining gateway,
   thereby changing or interrupting the group.

7.4.  Responding multicast traffic flows.

   A passive eavesdropper may also spoof Multicast Data messages in an
   attempt to Relay Changes

   When a overload the gateway determines or disrupt or supplant existing
   traffic flows.  A properly implemented gateway will filter Multicast
   Data messages that its current relay is unreachable
   (e.g., upon receipt of an ICMP Unreachable message [RFC0792] for do not originate from the
   relay's unicast address), it may need to repeat expected relay address
   discovery.  However, care
   and should be taken filter non-multicast packets and multicast IP packets
   whose group or source addresses are not to abandon included in the current
   relay too quickly due to transient network conditions.

8.  AMT Relay Details

8.1.  At Startup time

   At startup time,
   reception state for the relay router will bring up an NBMA-style AMT gateway pseudo-interface.  It shall also add the AMT Relay Anycast Address on
   some interface.

   The relay anycast discovery technique for finding relays (see
   Section 4.1.4) introduces a risk that a rogue router shall then advertise the AMT Relay Anycast Prefix
   into the unicast-only Internet, as if it were or a connection to an
   external network.  When the advertisement is done using BGP, the rogue AS
   path leading
   could introduce a bogus route to the AMT a specific Relay Anycast Prefix shall include Discovery Address
   prefix, and thus divert or absorb Relay Discovery messages sent by
   gateways.  Network managers must guarantee the
   identifier integrity of their
   routing to a particular Relay Discovery Address prefix in much the local AS.

   The relay router shall also enable IGMPv3/MLDv2 on the AMT pseudo-
   interface, except
   same way that it shall not multicast Queries (this might be
   done, for example, by having they guarantee the AMT pseudo-device drop them, integrity of all other routes.

6.3.  Encapsulated IP Packets

   An attacker forging or by
   having the IGMP/MLD module not send them in modifying a Membership Query or Membership
   Update message may attempt to embed something other than an IGMP or
   MLD message within the first place).

8.2.  Receiving Relay Discovery encapsulated IP packet carried by these
   messages sent to the Anycast Address

   When a relay receives in an AMT Relay Discovery message directed effort to introduce these into the
   AMT Relay recipient's IP
   stack.  A properly implemented gateway or relay will ignore any such
   messages - and may further choose ignore Membership Query messages
   that do not contain a IGMP/MLD general queries or Membership Update
   messages that do not contain IGMP/MLD membership reports.

   Property 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 Address, it Prefix Allocation

   The IANA should respond with allocate an AMT Relay
   Advertisement containing its unicast address.  The source IPv4 prefix and
   destination addresses of an IPv6 prefix dedicated
   to the advertisement public AMT Relays to advertise to the native multicast
   backbone (as described in Section 4.1.4).  The prefix length should
   be determined by the same as the
   destination and source addresses of the discovery message
   respectively.  Further, IANA; the nonce prefix should be large enough to
   guarantee advertisement in the discovery message MUST be
   copied into default-free BGP networks.

7.1.1.  IPv4

   A prefix length of 16 will meet this requirement.

7.1.2.  IPv6

   A prefix length of 32 will meet this requirement.  IANA has
   previously set aside the advertisement message.

8.3.  Receiving Membership Updates from AMT Gateways range 2001::/16 for allocating prefixes for
   this purpose.

7.2.  UDP Port number

   IANA has reserved UDP port number 2268 for AMT.

8.  Contributors

   The following people provided significant contributions to earlier
   versions of this specification:

     Dirk Ooms
     OneSparrow
     Belegstraat 13; 2018 Antwerp;
     Belgium
     EMail: dirk@onesparrow.com

     Tom Pusateri
     !j
     2109 Mountain High Rd.
     Wake Forest, NC  27587
     USA
     Email: pusateri@bangj.com

     Dave Thaler
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA  98052-6399
     USA
     Email: dthaler@microsoft.com

9.  Acknowledgments

   The relay operates passively, sending no periodic IGMP/MLD Queries
   but simply tracking membership information according authors would like to AMT Request/
   Query/Membership Update tuples received.  As noted in Section 7.2, thank the Relay tracks Gateways following individuals for their
   suggestions, comments, and corrections:

       Amit Aggarwal
       Mark Altom
       Toerless Eckert
       Marshall Eubanks
       Dino Farinacci
       Lenny Giuliano
       Andy Huang
       Tom Imburgia
       Patricia McCrink
       Han Nguyen
       Doug Nortz
       Pekka Savola
       Robert Sayko
       Greg Shepherd
       Steve Simlo
       Mohit Talwar
       Lorenzo Vicisano
       Kurt Windisch
       John Zwiebel

   The anycast discovery mechanism described in this document is based
   on similar work done by the (IP source address, UDP source
   port) tuple.  In addition, the relay must also do NGTrans WG for obtaining automatic IPv6
   connectivity without explicit membership
   tracking, tunnels ("6to4").  Tony Ballardie
   provided helpful discussion that inspired this document.

   Juniper Networks was instrumental in funding several versions of this
   draft as well as to which gateways on the AMT pseudo-interface have
   joined which groups.  Once an AMT Membership Update has been
   successfully received, it updates the forwarding state open source implementation.

10.  References

10.1.  Normative References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              April 1992.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4605]  Fenner, B., He, H., Haberman, B., and H. Sandick,
              "Internet Group Management Protocol (IGMP) / Multicast
              Listener Discovery (MLD)-Based Multicast Forwarding
              ("IGMP/MLD Proxying")", RFC 4605, August 2006.

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for the
   appropriate group
              IP", RFC 4607, August 2006.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

10.2.  Informative References

   [I-D.ietf-6man-udpchecksums]
              Eubanks, M. and source (if provided).  When data arrives P. Chimento, "UDP Checksums for
   that group, the traffic must be encapsulated, once to each (address,
   port) of each gateway which has joined that group or (S,G).

   The explicit membership tracking Tunneled
              Packets", draft-ietf-6man-udpchecksums-01 (work in
              progress), October 2011.

   [I-D.ietf-6man-udpzero]
              Fairhurst, G. and unicast replication may be done M. Westerlund, "IPv6 UDP Checksum
              Considerations", draft-ietf-6man-udpzero-05 (work in any implementation-specific manner.  Some examples are:

   1.  The AMT pseudo-device driver might track the group information
              progress), December 2011.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, August 1989.

   [RFC1546]  Partridge, C., Mendez, T., and perform the replication at the "link-layer", with no changes
       to a pre-existing IGMP/MLD module.

   2.  The IGMP/MLD module might have native support W. Milliken, "Host
              Anycasting Service", RFC 1546, November 1993.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for explicit
       membership tracking, especially if it supports other NBMA-style
       interfaces.

   If a relay wants to affect the rate at which the AMT Requests are
   originated from a gateway, it can tune the membership timeout by
   adjusting the Querier's Query Interval Code (QQIC) field in the IGMP/
   MLD Query contained within the AMT Membership Query message.  The
   QQIC field is defined Message Authentication", RFC 2104,
              February 1997.

   [RFC2119]  Bradner, S., "Key words for use in [RFC3376] RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2236]  Fenner, W., "Internet Group Management Protocol, Version
              2", RFC 2236, November 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

   [RFC2710]  Deering, S., Fenner, W., and [RFC3810].  However, since the
   gateway may need to send AMT Requests frequently enough to prevent
   firewall state from timing out, the relay may be limited in its
   ability to spread out Requests coming from a gateway by adjusting the
   QQIC field.

9.  IANA Considerations

9.1.  IPv4 B. Haberman, "Multicast
              Listener Discovery (MLD) for IPv6", RFC 2710,
              October 1999.

   [RFC3053]  Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
              Tunnel Broker", RFC 3053, January 2001.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3068]  Huitema, C., "An Anycast Prefix Allocation

   The IANA should allocate an IPv4 prefix for 6to4 Relay Routers",
              RFC 3068, June 2001.

   [RFC3552]  Rescorla, E. and an IPv6 prefix dedicated
   to the public AMT Relays to advertise to the native multicast
   backbone.  The prefix length should be determined by the IANA; the
   prefix should be large enough to guarantee advertisement in the
   default-free BGP networks.

9.1.1.  IPv4

   A prefix length of 16 will meet this requirement.

9.1.2.  IPv6

   A prefix length of 32 will meet this requirement.  IANA has
   previously set aside the range 2001::/16 B. Korver, "Guidelines for allocating prefixes Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.

   [RFC3973]  Adams, A., Nicholas, J., and W. Siadak, "Protocol
              Independent Multicast - Dense Mode (PIM-DM): Protocol
              Specification (Revised)", RFC 3973, January 2005.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for
   this purpose.

9.2.  UDP Port number

   IANA has previously allocated UDP reserved port number 2268 the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for AMT
   encapsulation.

10.  Security Considerations

   The anycast technique introduces a risk that a rogue router or a
   rogue AS could introduce a bogus route to the AMT Relay BGP-4", RFC 4760,
              January 2007.

   [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast
   prefix,
              Services", BCP 126, RFC 4786, December 2006.

Appendix A.  Implementation Notes

A.1.  Response MAC Generation and thus divert the traffic.  Network managers have Keying

   This specification does not require relays to
   guarantee the integrity of their routing use any particular
   method to compute the AMT Relay Anycast
   prefix in much the same way Response MAC field value - only that they guarantee the integrity it contain
   a hash of all
   other routes.

   Gateways will accept and decapsulate multicast traffic from any the source from which regular unicast traffic is accepted.  If this is,
   for any reason, felt to be a security risk, then additional IP address, source
   address based packet filtering MUST be applied: UDP port, request nonce, and
   a gateway MUST
   discard encapsulated multicast packets if the source address in private secret known only to the
   outer header is not relay.  This allows the address relay
   implementor a significant amount of leeway in the Relay to which the
   encapsulated join message was sent.  AMT Gateways MUST also drop non-
   multicast traffic incoming on an AMT pseudo-interface.

   AMT Relays MUST NOT process AMT Data messages.

   AMT Relays computation and Gateways MUST drop IP messages encapsulated
   structure of the value stored in AMT
   Query and the Response MAC field.

   Section Section 5.3.6 states that a relay should periodically compute
   a new private secret (or hash-key) for MAC generation.  To prevent
   the relay from rejecting Membership Update messages that are not IGMP/MLD messages.

   Even though a Relay does not need to maintain any state before
   completion of contain
   Response MAC values computed from an old secret, the three-way handshake (Section 5.2), if no mitigation
   is in place, it relay is still possible for one host
   required to instantiate retain the previous secret so that it can re-attempt
   authentication using the old secret, should authentication fail after
   recomputing the MAC using the new secret.  However, this approach
   requires a large
   amount of Gateways instances relay to do at least two hash computations for every
   Membership Update message that would each join one carries an old or more
   multicast groups to a Relay, thus resulting in a large amount of
   resources being used on the Relay.  Thus, AMT Relays MUST invalid MAC.  A
   better approach would be
   implemented so as to allow include information within the mitigation of risks of denial of
   service attacks on their resources.  A Relay SHOULD NOT allow message
   that the
   instantiation of an unbounded number of AMT pseudo-interfaces for a
   said gateway IP address.  For instance, an implementation may provide
   a way relay could use to set choose a configurable limit single secret for authentication
   rather relying on the maximum number of pseudo-
   interfaces sequential authentication failures to test all
   possible secrets.

   The solution proposed here is to compute and exchange an
   "authentication cookie" rather than a same gateway IP address, simple hash value in the
   Response MAC field.  The authentication cookie would combine a
   timestamp with a default value for
   this limit being low enough to provide protection, and high enough hash value.  The timestamp is used to
   cope with calculate the possibility
   age of an address being shared by multiple
   devices.

   In the case where a Relay is reaching cookie, allowing the situation where it would
   stop accepting relay to instantiate new pseudo-interfaces, it MAY stop
   advertising reject a message if the AMT Relay Anycast address; thanks to
   cookie's age is greater than some maximum allowable value.  If the AMT
   discovery procedures, this will allow legitimate AMT Gateways to fall
   back on another Relay.

11.  Contributors

   The following people provided significant contributions to earlier
   versions of these specifications:

     Dirk Ooms
     OneSparrow
     Belegstraat 13; 2018 Antwerp; Belgium
     EMail: dirk@onesparrow.com

12.  Acknowledgments

   Most of
   cookie has not expired, the relay uses the mechanisms described in this document are based on
   similar work done by timestamp to lookup the NGTrans WG for obtaining automatic IPv6
   connectivity without explicit tunnels ("6to4").  Tony Ballardie
   provided helpful discussion
   secret that inspired this document.

   In addition, extensive comments were received from Pekka Savola, Greg
   Shepherd, Dino Farinacci, Toerless Eckert, Marshall Eubanks, John
   Zwiebel, Lenny Giuliano and Greg Bumgardner.

   Juniper Networks was instrumental in funding several versions use at that time and then compute and compare the
   hash portion of this
   draft the cookie to authenticate the message source.

   A second purpose served by including the timestamp in the MAC field
   is that it allows the relay to contribute an unpredictable value to
   the authentication hash.  This contribution provides a defense
   against attempts to use a hash reversal algorithm to determine the
   relay's private secret as well the hash result will change over time even
   if the nonce carried by the Request message does not.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  V=0  |4 or 5|   Reserved   | |         Response MAC          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Request Nonce                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :

                       The Opaque Response MAC Field

   A relay may use the opaque Response MAC field to store a cookie as an open source implementation.

   Greg Shepherd suggested
   follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  V=0  |4 or 5|   Reserved   | |          Timestamp            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      MD5(Secret,Timestamp,IP_ADDR,IP_PORT,Request-Nonce)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Request Nonce                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :

      Using The Response MAC Field To Carry An Authentication Cookie

   The timestamp is an unsigned integer measured relative to the inclusion start
   time of relay.  The age of the AMT Membership Teardown
   message based on field experience.

   Contributors MAC is computed by subtracting the MAC
   timestamp from AT&T provided useful inputs and ideas that were
   integrated into these specifications: Mark Altom, Andy Huang, Tom
   Imburgia, Patricia McCrink, Han Nguyen, Doug Nortz and Robert Sayko.

13.  References

13.1.  Normative References

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [RFC4605]  Fenner, B., He, H., Haberman, B., and H. Sandick,
              "Internet Group Management Protocol (IGMP) / Multicast
              Listener Discovery (MLD)-Based Multicast Forwarding
              ("IGMP/MLD Proxying")", RFC 4605, August 2006.

   [RFC4607]  Holbrook, H. the current system timestamp.  The operands must be
   unsigned 16-bit integers and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, August 2006.

   [I-D.ietf-6man-udpchecksums]
              Eubanks, M., "UDP Checksums the subtraction must use unsigned
   arithmetic to allow for Tunneled Packets",
              draft-ietf-6man-udpchecksums-00 (work in progress),
              March 2011.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

13.2.  Informative References

   [RFC1112]  Deering, S., "Host extensions timestamp wrap-around.  The timestamp
   resolution must provide range sufficient to handle the maximum
   allowable age for IP multicasting", STD 5,
              RFC 1112, August 1989.

   [RFC1546]  Partridge, C., Mendez, T., and W. Milliken, "Host
              Anycasting Service", RFC 1546, November 1993.

   [RFC2104]  Krawczyk, H., Bellare, M., a MAC, e.g., a resolution of 1 second allows a
   maximum age of 18 hours.  The timestamp should start at a random
   value by adding a random offset, computed at startup, to the current
   system time.

     +-------------------------+----------------/ /-----------------+
  -->| Timestamp(N1) [16-bits] |      Random Secret [128-bits]      |
 |   +-------------------------+----------------/ /-----------------+
 |_____________________________________________________________________
                                                                       |
     +-------------------------+----------------/ /-----------------+  |
  -->| Timestamp(N1) [16-bits] |      Random Secret [128-bits]      |--
 |   +-------------------------+----------------/ /-----------------+
 |_____________________________________________________________________
                                                                       |
     +-------------------------+----------------/ /-----------------+  |
  -->| Timestamp(N1) [16-bits] |      Random Secret [128-bits]      |--
 |   +-------------------------+----------------/ /-----------------+
 |
 |__ Current
     Secret

                           Private Secret Queue

   The timestamp is not only used to compute the age of the MAC, but is
   also used to lookup the private secret used to generate the MAC.
   Each time a new private secret is computed, the value and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

   [RFC2119]  Bradner, S., "Key words for use the time at
   which the value was computed is pushed into a fixed-length queue of
   recent values (typically only 2-deep).  The relay uses the timestamp
   contained in RFCs the MAC field to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3053]  Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
              Tunnel Broker", RFC 3053, January 2001.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection lookup the appropriate secret.  The
   relay iterates over the list of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3068]  Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
              RFC 3068, June 2001.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              January 2007. secrets, starting with the newest
   entry, until it finds the first secret with a timestamp that is older
   than that contained in the MAC field.  The relay then uses that
   secret to compute the MAC that will be compared with that carried by
   the message.

Authors' Addresses

   Dave Thaler
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052-6399
   USA

   Phone: +1 425 703 8835
   Email: dthaler@microsoft.com

   Mohit Talwar
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052-6399
   USA

   Phone: +1 425 705 3131
   Email: mohitt@microsoft.com

   Amit Aggarwal
   Microsoft Corporation
   One Microsoft

   Gregory Bumgardner
   Cisco
   3700 Cisco Way
   Redmond, WA  98052-6399
   San Jose, CA  95134
   USA

   Phone: +1 425 706 0593
   Email: amitag@microsoft.com

   Lorenzo Vicisano
   Qualcomm Inc.
   3165 Kifer Road
   Santa Clara, CA  95051
   USA

   Email: vicisano@qualcomm.com
   Tom Pusateri
   !j
   2109 Mountain High Rd.
   Wake Forest, NC  27587
   USA 408 853 4993
   Email: pusateri@bangj.com gbumgard@cisco.com

   Thomas Morin
   France Telecom - Orange
   2, avenue Pierre Marzin
   Lannion  22300
   France

   Phone: +33 2 96 05 3734
   Email: thomas.morin@orange-ftgroup.com thomas.morin@orange.com