tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7450

 
 
 

Automatic Multicast Tunneling

Part 3 of 4, p. 31 to 60
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 31 
5.  Protocol Description

   This section provides a normative description of the AMT protocol.

5.1.  Protocol Messages

   The AMT protocol defines seven message types for control and
   encapsulation.  These messages are assigned the following names and
   numeric identifiers:

                  +--------------+---------------------+
                  | Message Type | Message Name        |
                  +--------------+---------------------+
                  |      1       | Relay Discovery     |
                  |      2       | Relay Advertisement |
                  |      3       | Request             |
                  |      4       | Membership Query    |
                  |      5       | Membership Update   |
                  |      6       | Multicast Data      |
                  |      7       | Teardown            |
                  +--------------+---------------------+

   These messages are exchanged as IPv4 or IPv6 UDP datagrams.

5.1.1.  Relay Discovery

   A Relay Discovery message is used to solicit a response from a relay
   in the form of a Relay Advertisement message.

   The UDP/IP datagram containing this message MUST carry a valid,
   non-zero UDP checksum and carry the following IP address and UDP port
   values:

   Source IP Address - The IP address of the gateway interface on which
      the gateway will listen for a relay response.  Note: The value of
      this field may be changed as a result of network address
      translation before arriving at the relay.

   Source UDP Port - The UDP port number on which the gateway will
      listen for a relay response.  Note: The value of this field may be
      changed as a result of network address translation before arriving
      at the relay.

   Destination IP Address - An anycast or unicast IP address, i.e., the
      Relay Discovery Address advertised by a relay.

   Destination UDP Port - The AMT port number (see Section 7.2).

Top      Up      ToC       Page 32 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  V=0  |Type=1 |     Reserved                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Discovery Nonce                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 11: Relay Discovery Message Format

5.1.1.1.  Version (V)

   The protocol version number for this message is 0.

5.1.1.2.  Type

   The type number for this message is 1.

5.1.1.3.  Reserved

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

5.1.1.4.  Discovery Nonce

   A 32-bit random value generated by the gateway and echoed by the
   relay in a Relay Advertisement message.  This value is used by the
   gateway to correlate Relay Advertisement messages with Relay
   Discovery messages.  Discovery nonce generation is described in
   Section 5.2.3.4.5.

5.1.2.  Relay Advertisement

   The Relay Advertisement message is used to supply a gateway with a
   unicast IP address of a relay.  A relay sends this message to a
   gateway when it receives a Relay Discovery message from that gateway.

   The UDP/IP datagram containing this message MUST carry a valid,
   non-zero UDP checksum and carry the following IP address and UDP port
   values:

   Source IP Address - The destination IP address carried by the Relay
      Discovery message (i.e., the Relay Discovery Address advertised by
      the relay).

   Source UDP Port - The destination UDP port carried by the Relay
      Discovery message (i.e., the AMT port number).

Top      Up      ToC       Page 33 
   Destination IP Address - The source IP address carried by the Relay
      Discovery message.  Note: The value of this field may be changed
      as a result of network address translation before arriving at the
      gateway.

   Destination UDP Port - The source UDP port carried by the Relay
      Discovery message.  Note: The value of this field may be changed
      as a result of network address translation before arriving at the
      gateway.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  V=0  |Type=2 |                   Reserved                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Discovery Nonce                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                  Relay Address (IPv4 or IPv6)                 ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 12: Relay Advertisement Message Format

5.1.2.1.  Version (V)

   The protocol version number for this message is 0.

5.1.2.2.  Type

   The type number for this message is 2.

5.1.2.3.  Reserved

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

5.1.2.4.  Discovery Nonce

   A 32-bit value copied from the Discovery Nonce field
   (Section 5.1.1.4) contained in the Relay Discovery message.  The
   gateway uses this value to match a Relay Advertisement to a Relay
   Discovery message.

Top      Up      ToC       Page 34 
5.1.2.5.  Relay Address

   The unicast IPv4 or IPv6 address of the relay.  A gateway uses the
   length of the UDP datagram containing the Relay Advertisement message
   to determine the address family, i.e., length - 8 = 4 (IPv4) or 16
   (IPv6).  The relay returns an IP address for the protocol used to
   send the Relay Discovery message, i.e., an IPv4 address for an IPv4
   Relay Discovery Address or an IPv6 address for an IPv6 Relay
   Discovery Address.

5.1.3.  Request

   A gateway sends a Request message to a relay to solicit a Membership
   Query response.

   The successful delivery of this message marks the start of the first
   stage in the three-way handshake used to create or update state
   within a relay.

   The UDP/IP datagram containing this message MUST carry a valid,
   non-zero UDP checksum and carry the following IP address and UDP port
   values:

   Source IP Address - The IP address of the gateway interface on which
      the gateway will listen for a response from the relay.  Note: The
      value of this field may be changed as a result of network address
      translation before arriving at the relay.

   Source UDP Port - The UDP port number on which the gateway will
      listen for a response from the relay.  Note: The value of this
      field may be changed as a result of network address translation
      before arriving at the relay.

   Destination IP Address - The unicast IP address of the relay.

   Destination UDP Port - The AMT port number.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  V=0  |Type=3 |   Reserved  |P|            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Request Nonce                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 13: Request Message Format

Top      Up      ToC       Page 35 
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.

Top      Up      ToC       Page 36 
   The UDP/IP datagram containing this message MUST carry a valid,
   non-zero UDP checksum and carry the following IP address and UDP port
   values:

   Source IP Address - The destination IP address carried by the Request
      message (i.e., the unicast IP address of the relay).

   Source UDP Port - The destination UDP port carried by the Request
      message (i.e., the AMT port number).

   Destination IP Address - The source IP address carried by the Request
      message.  Note: The value of this field may be changed as a result
      of network address translation before arriving at the gateway.

   Destination UDP Port - The source UDP port carried by the Request
      message.  Note: The value of this field may be changed as a result
      of network address translation before arriving at the gateway.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  V=0  |Type=4 | Reserved  |L|G|         Response MAC          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Request Nonce                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |               Encapsulated General Query Message              |
   ~                 IPv4:IGMPv3(Membership Query)                 ~
   |                  IPv6:MLDv2(Listener Query)                   |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Gateway Port Number       |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +                                                               +
   |                Gateway IP Address (IPv4 or IPv6)              |
   +                                                               +
   |                                                               |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 14: Membership Query Message Format

Top      Up      ToC       Page 37 
5.1.4.1.  Version (V)

   The protocol version number for this message is 0.

5.1.4.2.  Type

   The type number for this message is 4.

5.1.4.3.  Reserved

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

5.1.4.4.  Limit (L) Flag

   A 1-bit flag set to 1 to indicate that the relay is NOT accepting
   Membership Update messages from new gateway tunnel endpoints and that
   it will ignore any that are.  A value of 0 has no special
   significance -- the relay may or may not be accepting Membership
   Update messages from new gateway tunnel endpoints.  A gateway checks
   this flag before attempting to create new group subscription state on
   the relay to determine whether it should restart relay discovery.  A
   gateway that has already created group subscriptions on the relay may
   ignore this flag.  Support for this flag is RECOMMENDED.

5.1.4.5.  Gateway Address (G) Flag

   A 1-bit flag set to 0 to indicate that the message does NOT carry the
   Gateway Port Number and Gateway IP Address fields, and 1 to indicate
   that it does.  A relay implementation that supports the optional
   teardown procedure (see Section 5.3.3.5) SHOULD set this flag as well
   as the Gateway Port Number and Gateway IP Address field values.  If a
   relay sets this flag, it MUST also include the Gateway Port Number
   and Gateway IP Address fields in the message.  A gateway
   implementation that does not support the optional teardown procedure
   (see Section 5.2.3.7) MAY ignore this flag and the Gateway Address
   fields if they are present.

5.1.4.6.  Response MAC

   A 48-bit source authentication value generated by the relay as
   described in Section 5.3.5.  The gateway echoes this value in
   subsequent Membership Update messages to allow the relay to verify
   that the sender of a Membership Update message was the intended
   receiver of a Membership Query sent by the relay.

Top      Up      ToC       Page 38 
5.1.4.7.  Request Nonce

   A 32-bit value copied from the Request Nonce field (Section 5.1.3.5)
   carried by a Request message.  The relay will have included this
   value in the Response MAC computation.  The gateway echoes this value
   in subsequent Membership Update messages.  The gateway also uses this
   value to match a Membership Query to a Request message.

5.1.4.8.  Encapsulated General Query Message

   An IP-encapsulated IGMP or MLD message generated by the relay.  This
   field will contain one of the following IP datagrams:

      IPv4:IGMPv3 Membership Query

      IPv6:MLDv2 Listener Query

   The source address carried by the query message should be set as
   described in Section 5.3.3.3.

   The Querier's Query Interval Code (QQIC) field in the General Query
   is used by a relay to specify the time offset a gateway should use to
   schedule a new three-way handshake to refresh the group membership
   state within the relay (current time + Query Interval).  The QQIC
   field is defined in Section 4.1.7 of [RFC3376] and Section 5.1.9 of
   [RFC3810].

   The Querier's Robustness Variable (QRV) field in the General Query is
   used by a relay to specify the number of times a gateway should
   retransmit unsolicited membership reports, encapsulated within
   Membership Update messages, and, optionally, the number of times to
   send a Teardown message.  The QRV field is defined in Section 4.1.6
   of [RFC3376] and Section 5.1.8 of [RFC3810].

5.1.4.9.  Gateway Address Fields

   The Gateway Port Number and Gateway Address fields are present in the
   Membership Query message if, and only if, the G flag is set.

   A gateway need not parse the encapsulated IP datagram to determine
   the position of these fields within the UDP datagram containing the
   Membership Query message -- if the G flag is set, the gateway may
   simply subtract the total length of the fields (18 bytes) from the
   total length of the UDP datagram to obtain the offset.

Top      Up      ToC       Page 39 
5.1.4.9.1.  Gateway Port Number

   A 16-bit UDP port number containing a UDP port value.

   The relay sets this field to the value of the UDP source port of the
   Request message that triggered the Query message.

5.1.4.9.2.  Gateway IP Address

   A 16-byte IP address that, when combined with the value contained in
   the Gateway Port Number field, forms the gateway endpoint address
   that the relay will use to identify the tunnel instance, if any,
   created by a subsequent Membership Update message.  This field may
   contain an IPv6 address or an IPv4 address stored as an
   IPv4-compatible IPv6 address, where the IPv4 address is prefixed with
   96 bits set to zero (see [RFC4291]).  This address must match that
   used by the relay to compute the value stored in the Response MAC
   field.

5.1.5.  Membership Update

   A gateway sends a Membership Update message to a relay to report a
   change in group membership state, or to report the current group
   membership state in response to receiving a Membership Query message.
   The gateway encapsulates the IGMP or MLD message as an IP datagram
   within a Membership Update message and sends it to the relay, where
   it may (see below) be decapsulated and processed by the relay to
   update group membership and forwarding state.

   A gateway cannot send a Membership Update message until it receives a
   Membership Query from a relay, because the gateway must copy the
   Request Nonce and Response MAC values carried by a Membership Query
   into any subsequent Membership Update messages it sends back to that
   relay.  These values are used by the relay to verify that the sender
   of the Membership Update message was the recipient of the Membership
   Query message from which these values were copied.

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

Top      Up      ToC       Page 40 
   The UDP/IP datagram containing this message MUST carry a valid,
   non-zero UDP checksum and carry the following IP address and UDP port
   values:

   Source IP Address - The IP address of the gateway interface on which
      the gateway will listen for Multicast Data messages from the
      relay.  The address must be the same address used to send the
      initial Request message, or the message will be ignored.  Note:
      The value of this field may be changed as a result of network
      address translation before arriving at the relay.

   Source UDP Port - The UDP port number on which the gateway will
      listen for Multicast Data messages from the relay.  This port must
      be the same port used to send the initial Request message, or the
      message will be ignored.  Note: The value of this field may be
      changed as a result of network address translation before arriving
      at the relay.

   Destination IP Address - The unicast IP address of the relay.

   Destination UDP Port - The AMT port number.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  V=0  |Type=5 |  Reserved     |        Response MAC           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Request Nonce                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |         Encapsulated Group Membership Update Message          |
   ~           IPv4:IGMP(Membership Report|Leave Group)            ~
   |            IPv6:MLD(Listener Report|Listener Done)            |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 15: Membership Update Message Format

5.1.5.1.  Version (V)

   The protocol version number for this message is 0.

5.1.5.2.  Type

   The type number for this message is 5.

Top      Up      ToC       Page 41 
5.1.5.3.  Reserved

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

5.1.5.4.  Response MAC

   A 48-bit value copied from the Response MAC field (Section 5.1.4.6)
   in a Membership Query message.  Used by the relay to perform source
   authentication.

5.1.5.5.  Request Nonce

   A 32-bit value copied from the Request Nonce field in a Request or
   Membership Query message.  Used by the relay to perform source
   authentication.

5.1.5.6.  Encapsulated Group Membership Update Message

   An IP-encapsulated IGMP or MLD message produced by the host-mode IGMP
   or MLD protocol running on a gateway pseudo-interface.  This field
   will contain one of the following IP datagrams:

      IPv4:IGMPv2 Membership Report

      IPv4:IGMPv2 Leave Group

      IPv4:IGMPv3 Membership Report

      IPv6:MLDv1 Multicast Listener Report

      IPv6:MLDv1 Multicast Listener Done

      IPv6:MLDv2 Multicast Listener Report

   The source address carried by the message should be set as described
   in Section 5.2.1.

5.1.6.  Multicast Data

   A relay sends a Multicast Data message to deliver a multicast IP
   datagram or datagram fragment to a gateway.

   The Checksum field in the UDP header of this message MAY contain a
   value of zero when sent over IPv4 but SHOULD, if possible, contain a
   valid, non-zero value when sent over IPv6 (see Section 4.2.2.3).

Top      Up      ToC       Page 42 
   The UDP/IP datagram containing this message MUST carry the following
   IP address and UDP port values:

   Source IP Address - The unicast IP address of the relay.

   Source UDP Port - The AMT port number.

   Destination IP Address - A tunnel endpoint IP address, i.e., the
      source IP address carried by the Membership Update message sent by
      a gateway to indicate an interest in receiving the multicast
      packet.  Note: The value of this field may be changed as a result
      of network address translation before arriving at the gateway.

   Destination UDP Port - A tunnel endpoint UDP port, i.e., the source
      UDP port carried by the Membership Update message sent by a
      gateway to indicate an interest in receiving the multicast packet.
      Note: The value of this field may be changed as a result of
      network address translation before arriving at the gateway.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  V=0  |Type=6 |    Reserved   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   ~                     IP Multicast Packet                       ~
   |                                                               |
   +                - - - - - - - - - - - - - - - - - - - - - - - -+
   |               :               :               :               :
   +-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - - - - - - - - - -

                 Figure 16: Multicast Data Message Format

5.1.6.1.  Version (V)

   The protocol version number for this message is 0.

5.1.6.2.  Type

   The type number for this message is 6.

5.1.6.3.  Reserved

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

Top      Up      ToC       Page 43 
5.1.6.4.  IP Multicast Data

   A complete IPv4 or IPv6 multicast datagram or datagram fragment.

5.1.7.  Teardown

   A gateway sends a Teardown message to a relay to request that it stop
   sending Multicast Data messages to a tunnel endpoint created by an
   earlier Membership Update message.  A gateway sends this message when
   it detects that a Request message sent to the relay carries an
   address that differs from that carried by a previous Request message.
   The gateway uses the Gateway IP Address and Gateway Port Number
   fields in the Membership Query message to detect these address
   changes.

   To provide backwards compatibility with early implementations of the
   AMT protocol, support for this message and associated procedures is
   considered OPTIONAL -- gateways are not required to send this
   message, and relays are not required to act upon it.

   The UDP/IP datagram containing this message MUST carry a valid,
   non-zero UDP checksum and carry the following IP address and UDP port
   values:

   Source IP Address - The IP address of the gateway interface used to
      send the message.  This address may differ from that used to send
      earlier messages.  Note: The value of this field may be changed as
      a result of network address translation before arriving at the
      relay.

   Source UDP Port - The UDP port number.  This port number may differ
      from that used to send earlier messages.  Note: The value of this
      field may be changed as a result of network address translation
      before arriving at the relay.

   Destination IP Address - The unicast IP address of the relay.

   Destination UDP Port - The AMT port number.

Top      Up      ToC       Page 44 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  V=0  |Type=7 |  Reserved     |         Response MAC          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Request Nonce                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Gateway Port Number       |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +                                                               +
   |              Gateway IP Address (IPv4 or IPv6)                |
   +                                                               +
   |                                                               |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 17: Membership Teardown Message Format

5.1.7.1.  Version (V)

   The protocol version number for this message is 0.

5.1.7.2.  Type

   The type number for this message is 7.

5.1.7.3.  Reserved

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

5.1.7.4.  Response MAC

   A 48-bit value copied from the Response MAC field (Section 5.1.4.6)
   in the last Membership Query message the relay sent to the gateway
   endpoint address of the tunnel to be torn down.  The gateway endpoint
   address is provided by the Gateway IP Address and Gateway Port Number
   fields carried by the Membership Query message.  The relay validates
   the Teardown message by comparing this value with one computed from
   the Gateway IP Address field, Gateway Port Number field, Request
   Nonce field, and a private secret (just as it does in the Membership
   Update message).

Top      Up      ToC       Page 45 
5.1.7.5.  Request Nonce

   A 32-bit value copied from the Request Nonce field (Section 5.1.4.7)
   in the last Membership Query message the relay sent to the gateway
   endpoint address of the tunnel to be torn down.  The gateway endpoint
   address is provided by the Gateway IP Address and Gateway Port Number
   fields carried by the Membership Query message.  This value must
   match that used by the relay to compute the value stored in the
   Response MAC field.

5.1.7.6.  Gateway Port Number

   A 16-bit UDP port number that, when combined with the value contained
   in the Gateway IP Address field, forms the tunnel endpoint address
   that the relay will use to identify the tunnel instance to tear down.
   The relay provides this value to the gateway using the Gateway Port
   Number field (Section 5.1.4.9.1) in a Membership Query message.  This
   port number must match that used by the relay to compute the value
   stored in the Response MAC field.

5.1.7.7.  Gateway IP Address

   A 16-byte IP address that, when combined with the value contained in
   the Gateway Port Number field, forms the tunnel endpoint address that
   the relay will use to identify the tunnel instance to tear down.  The
   relay provides this value to the gateway using the Gateway IP Address
   field (Section 5.1.4.9.2) in a Membership Query message.  This field
   may contain an IPv6 address or an IPv4 address stored as an
   IPv4-compatible IPv6 address, where the IPv4 address is prefixed with
   96 bits set to zero (see [RFC4291]).  This address must match that
   used by the relay to compute the value stored in the Response MAC
   field.

5.2.  Gateway Operation

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

5.2.1.  IP/IGMP/MLD Protocol Requirements

   Gateway operation requires a subset of host-mode IPv4/IGMP and IPv6/
   MLD functionality to provide group membership tracking, query
   processing, and report generation.  A gateway MAY use IGMPv2 (ASM),
   IGMPv3 (ASM and SSM), MLDv1 (ASM), or MLDv2 (ASM and SSM).

Top      Up      ToC       Page 46 
   An application with embedded gateway functionality must provide its
   own implementation of this subset of the IPv4/IGMP and IPv6/MLD
   protocols.  The service interface used to manipulate group membership
   state need not match that described in the IGMP and MLD
   specifications, but the actions taken as a result SHOULD be similar
   to those described in Section 5.1 of [RFC3376] and Section 6.1 of
   [RFC3810].  The gateway application will likely need to implement
   many of the same functions as a host IP stack, including checksum
   verification, dispatching, datagram filtering and forwarding, and IP
   encapsulation/decapsulation.

   The encapsulated IGMP datagrams generated by a gateway MUST conform
   to the descriptions found in Section 4 of [RFC3376].  These datagrams
   MUST possess the IP headers, header options, and header values called
   for in [RFC3376], with the following exception: a gateway MAY use any
   source address value in an IGMP report datagram, including the
   "unspecified" address (all octets are zero).  This exception is made
   because a gateway pseudo-interface might not possess a valid IPv4
   address, and even if an address has been assigned to the interface,
   that address might not be a valid link-local source address on any
   relay interface.  It is for this reason that a relay must accept
   encapsulated IGMP reports regardless of the source address they
   carry.  See Section 5.3.1.

   The encapsulated MLD messages generated by a gateway MUST conform to
   the description found in Section 5 of [RFC3810].  These datagrams
   MUST possess the IP headers, header options, and header values called
   for in [RFC3810], with the following exception: a gateway MAY use any
   source address value in an MLD report datagram, including the
   "unspecified" address (all octets are zero).  This exception is made
   because a gateway pseudo-interface might not possess a valid IPv6
   address, and even if an address has been assigned to the interface,
   that address might not be a valid link-local source address on any
   relay interface.  As with IGMP, it is for this reason that a relay
   must accept encapsulated MLD reports regardless of the source address
   they carry.  See Section 5.3.1.

   The gateway IGMP/MLD implementation SHOULD retransmit unsolicited
   membership state-change reports and merge new state-change reports
   with pending reports as described in Section 5.1 of [RFC3376] and
   Section 6.1 of [RFC3810].  The number of retransmissions is specified
   by the relay in the Querier's Robustness Variable (QRV) field in the
   last General Query forwarded by the pseudo-interface.  See
   Section 4.1.6 of [RFC3376] and Section 5.1.8 of [RFC3810].

Top      Up      ToC       Page 47 
   The gateway IGMP/MLD implementation SHOULD handle General Query
   messages as described in Section 5.2 of [RFC3376] and Section 6.2 of
   [RFC3810] but MAY ignore the Max Resp Code (Maximum Response Code)
   field value and generate a current-state report without any delay.

   An IPv4 gateway implementation MUST accept IPv4 datagrams that carry
   the General Query variant of the IGMPv3 Membership Query message, as
   described in Section 4 of [RFC3376].  The gateway MUST accept the
   IGMP datagram regardless of the IP source address carried by that
   datagram.

   An IPv6 gateway implementation MUST accept IPv6 datagrams that carry
   the General Query variant of the MLDv2 Multicast Listener Query
   message, as described in Section 5 of [RFC3810].  The gateway MUST
   accept the MLD datagram regardless of the IP source address carried
   by that datagram.

5.2.2.  Pseudo-Interface Configuration

   A gateway host may possess or create multiple gateway
   pseudo-interfaces, each with a unique configuration that describes a
   binding to a specific IP protocol, Relay Address, Relay Discovery
   Address, or upstream network interface.

5.2.2.1.  Relay Discovery Address

   If a gateway implementation uses AMT relay discovery to obtain a
   Relay Address, it must first be supplied with a Relay Discovery
   Address.  The Relay Discovery Address may be an anycast or unicast
   address.  A gateway implementation may rely on a static address
   assignment or some form of dynamic address discovery.  This
   specification does not require that a gateway implementation use any
   particular method to obtain a Relay Discovery Address -- an
   implementation may employ any method that returns a suitable Relay
   Discovery Address.

5.2.2.2.  Relay Address

   Before a gateway implementation can execute the AMT protocol to
   request and receive multicast traffic, it must be supplied with a
   unicast Relay Address.  A gateway implementation may rely on static
   address assignment or support some form of dynamic address discovery.
   This specification does not require the use of any particular method
   to obtain a Relay Address -- an implementation may employ any method
   that returns a suitable Relay Address.

Top      Up      ToC       Page 48 
5.2.2.3.  Upstream Interface Selection

   A gateway host that possesses multiple network interfaces or
   addresses may allow for an explicit selection of the interface to use
   when communicating with a relay.  The selection might be made to
   satisfy connectivity, tunneling, or IP protocol requirements.

5.2.2.4.  Optional Retransmission Parameters

   A gateway implementation that supports retransmission MAY require the
   following information:

   Discovery Timeout
      Initial time to wait for a response to a Relay Discovery message.

   Maximum Relay Discovery Retransmission Count
      Maximum number of Relay Discovery retransmissions to allow before
      terminating relay discovery and reporting an error.

   Request Timeout
      Initial time to wait for a response to a Request message.

   Maximum Request Retransmission Count
      Maximum number of Request retransmissions to allow before
      abandoning a relay and restarting relay discovery or reporting an
      error.

   Maximum Retries Count for "Destination Unreachable"
      The maximum number of times a gateway should attempt to send the
      same Request or Membership Update message after receiving an ICMP
      Destination Unreachable message.

5.2.3.  Gateway Service

   In the following descriptions, a gateway pseudo-interface is treated
   as a passive entity managed by a gateway service.  The gateway
   pseudo-interface provides the state, and the gateway service provides
   the processing.  The term "gateway" is used when describing service
   behavior with respect to a single pseudo-interface.

5.2.3.1.  Startup

   When a gateway pseudo-interface is started, the gateway service
   begins listening for AMT messages sent to the UDP endpoint(s)
   associated with the pseudo-interface and for any locally generated
   IGMP/MLD messages passed to the pseudo-interface.  The handling of
   these messages is described below.

Top      Up      ToC       Page 49 
   When the pseudo-interface is enabled, the gateway service MAY:

   o  Optionally execute the relay discovery procedure described in
      Section 5.2.3.4.

   o  Optionally execute the membership query procedure described in
      Section 5.2.3.5 to start the periodic membership update cycle.

5.2.3.2.  Handling AMT Messages

   A gateway MUST ignore any datagram it receives that cannot be
   interpreted as a Relay Advertisement, Membership Query, or Multicast
   Data message.  The handling of Relay Advertisement, Membership Query,
   and Multicast Data messages is addressed in the sections that follow.

   A gateway that conforms to this specification MUST ignore any message
   with a Version field value other than zero.

   While listening for AMT messages, a gateway may be notified that an
   ICMP Destination Unreachable message was received as a result of an
   AMT message transmission.  Handling of ICMP Destination Unreachable
   messages is described in Section 5.2.3.9.

5.2.3.3.  Handling Multicast Data Messages

   A gateway may receive Multicast Data messages after it sends a
   Membership Update message to a relay that adds a group subscription.
   The gateway may continue to receive Multicast Data messages long
   after the gateway sends a Membership Update message that deletes
   existing group subscriptions.  The gateway MUST be prepared to
   receive these messages at any time but MAY ignore them or discard
   their contents if the gateway no longer has any interest in receiving
   the multicast datagrams contained within them.

   A gateway MUST ignore a Multicast Data message if it fails to satisfy
   any of the following requirements:

   o  The source IP address and UDP port carried by the Multicast Data
      message MUST be equal to the destination IP address and UDP port
      carried by the matching Membership Update message (i.e., the
      current Relay Address).

   o  The destination address carried by the encapsulated IP datagram
      MUST fall within the multicast address allocation assigned to the
      relevant IP protocol, i.e., 224.0.0.0/4 for IPv4 and ff00::/8
      for IPv6.

Top      Up      ToC       Page 50 
   The gateway extracts the encapsulated IP datagram and forwards it to
   the local IP protocol implementation for checksum verification,
   fragmented datagram reassembly, source and group filtering, and
   transport-layer protocol processing.

   Because AMT uses UDP encapsulation to deliver multicast datagrams to
   gateways, it qualifies as a tunneling protocol subject to the
   limitations described in [RFC6936].  If supported, a gateway SHOULD
   employ the solution described in [RFC6936] to ensure that the local
   IP stack does not discard IPv6 datagrams with zero checksums.  If
   Multicast Data message datagrams are processed directly within the
   gateway (instead of the host IP stack), the gateway MUST NOT discard
   any of these datagrams because they carry a UDP checksum of zero.

5.2.3.4.  Relay Discovery Procedure

   This section describes gateway requirements related to the relay
   discovery message sequence described in Section 4.2.1.1.

5.2.3.4.1.  Starting Relay Discovery

   A gateway may start or restart the relay discovery procedure in
   response to the following events:

   o  When a gateway pseudo-interface is started (enabled).

   o  When the gateway wishes to report a group subscription when none
      currently exist.

   o  Before sending the next Request message in a membership update
      cycle, i.e., each time the query timer expires (see below).

   o  After the gateway fails to receive a response to a Request
      message.

   o  After the gateway receives a Membership Query message with the
      L flag set to 1.

5.2.3.4.2.  Sending a Relay Discovery Message

   A gateway sends a Relay Discovery message to a relay to start the
   relay discovery process.

   The gateway MUST send the Relay Discovery message using the current
   Relay Discovery Address and AMT port number as the destination.  The
   Discovery Nonce value in the Relay Discovery message MUST be computed
   as described in Section 5.2.3.4.5.

Top      Up      ToC       Page 51 
   The gateway MUST save a copy of the Relay Discovery message or save
   the Discovery Nonce value for possible retransmission and
   verification of a Relay Advertisement response.

   When a gateway sends a Relay Discovery message, it may be notified
   that an ICMP Destination Unreachable message was received as a result
   of an earlier AMT message transmission.  Handling of ICMP Destination
   Unreachable messages is described in Section 5.2.3.9.

5.2.3.4.3.  Waiting for a Relay Advertisement Message

   A gateway MAY retransmit a Relay Discovery message if it does not
   receive a matching Relay Advertisement message within some timeout
   period.  If the gateway retransmits the message multiple times, the
   timeout period SHOULD be adjusted to provide a random exponential
   back-off.  The RECOMMENDED timeout is a random value in the range
   [initial_timeout, MIN(initial_timeout * 2^retry_count,
   maximum_timeout)], with a RECOMMENDED initial_timeout of 1 second and
   a RECOMMENDED maximum_timeout of 120 seconds (which is the
   recommended minimum NAT mapping timeout described in [RFC4787]).

5.2.3.4.4.  Handling a Relay Advertisement Message

   When a gateway receives a Relay Advertisement message, it must first
   determine whether it should accept or ignore the message.  A gateway
   MUST ignore a Relay Advertisement message if it fails to satisfy any
   of the following requirements:

   o  The gateway MUST be waiting for a Relay Advertisement message.

   o  The Discovery Nonce value contained in the Relay Advertisement
      message MUST be equal to the Discovery Nonce value contained in
      the Relay Discovery message.

   o  The source IP address and UDP port of the Relay Advertisement
      message MUST be equal to the destination IP address and UDP port
      of the matching Relay Discovery message.

   Once a gateway receives a Relay Advertisement response to a Relay
   Discovery message, it SHOULD ignore any other Relay Advertisements
   that arrive on the AMT interface until it sends a new Relay Discovery
   message.

   If a gateway executes the relay discovery procedure at the start of
   each membership update cycle and the Relay Address returned in the
   latest Relay Advertisement message differs from the address returned
   in a previous Relay Advertisement message, then the gateway SHOULD
   send a Teardown message (if supported) to the old Relay Address,

Top      Up      ToC       Page 52 
   using information from the last Membership Query message received
   from that relay, as described in Section 5.2.3.7.  This behavior is
   illustrated in the following diagram.

                     Gateway              Relay-1
                     -------              -------
                        :                    :
     Query      Expired |                    |
     Timer (QT)-------->|                    |
                        |  Relay Discovery   |
                        |------------------->|
                        |                    |
                        | Relay Advertisement|
                        |<-------------------|
                        |                    |
                        |      Request       |
                        |------------------->|
                        |                    |
                        |  Membership Query  |
                        |<===================|
                  Start |                    |
           (QT)<--------| Membership Update  |
                        |===================>|
                        |                    |
                        ~                    ~             Relay-2
                Expired |                    |             -------
           (QT)-------->|                    |                :
                        |  Relay Discovery   |                |
                        |------------------------------------>|
                        |                    |                |
                        | Relay Advertisement|                |
                        |<------------------------------------|
                        |                    |                |
                        |     Teardown       |                |
                        |------------------->|                |
                        |                    |                |
                        |      Request       |                |
                        |------------------------------------>|
                        |                    |                |
                        |  Membership Query  |                |
                        |<====================================|
                  Start |                    |                |
           (QT)<--------| Membership Update  |                |
                        |====================================>|
                        |                    |                |
                        :                    :                :

              Figure 18: Teardown after Relay Address Change

Top      Up      ToC       Page 53 
5.2.3.4.5.  Discovery Nonce Generation

   The discovery nonce MUST be a random, non-zero 32-bit value and, if
   possible, SHOULD be computed using a cryptographically secure
   pseudorandom number generator.  A new nonce SHOULD be generated each
   time the gateway restarts the relay discovery process.  The same
   nonce SHOULD be used when retransmitting a Relay Discovery message.

5.2.3.5.  Membership Query Procedure

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

5.2.3.5.1.  Starting the Membership Update Cycle

   A gateway may send a Request message to start a membership update
   cycle (following the optional relay discovery procedure) in response
   to the following events:

   o  When the gateway pseudo-interface is activated.

   o  When the gateway wishes to report a group subscription when none
      currently exist.

   Starting the membership update cycle when a gateway pseudo-interface
   is started provides several benefits:

   o  Better performance by allowing state-change reports to be sent as
      they are generated, thus minimizing the time to join.

   o  More robustness by relying on unsolicited state-change reports to
      update group membership state rather than the current-state
      reports generated by the membership update cycle.  Unsolicited
      state-change reports are typically retransmitted multiple times
      while current-state reports are not.

   o  Simplified implementation by eliminating any need to queue IGMP/
      MLD messages for delivery after a Membership Query is received,
      since the IGMP/MLD state-change messages may be sent as they are
      generated.

   However, this approach places an additional load on relays, as a
   gateway will send periodic requests even when it has no multicast
   subscriptions.  To reduce load on a relay, a gateway SHOULD only send
   a Membership Update message while it has active group subscriptions.
   A relay will still need to compute a Response MAC for each Request

Top      Up      ToC       Page 54 
   but will not be required to recompute it a second time to
   authenticate a Membership Update message that contains no
   subscriptions.

5.2.3.5.2.  Sending a Request Message

   A gateway sends a Request message to a relay to solicit a Membership
   Query response and start the membership update cycle.

   A gateway constructs a Request message containing a Request Nonce
   value computed as described in Section 5.2.3.5.6.  The gateway MUST
   set the P flag in the Request message to identify the protocol the
   gateway wishes the relay to use for the General Query response.

   A gateway MUST send a Request message using the current Relay Address
   and AMT port number as the destination.

   A gateway MUST save a copy of the Request message or save the Request
   Nonce and P flag values for possible retransmission and verification
   of a Membership Query response.

   When a gateway sends a Request message, it may be notified that an
   ICMP Destination Unreachable message was received as a result of an
   earlier AMT message transmission.  Handling of ICMP Destination
   Unreachable messages is described in Section 5.2.3.9.

5.2.3.5.3.  Waiting for a Membership Query Message

   A gateway MAY retransmit a Request message if it does not receive a
   matching Membership Query message within some timeout period.  If the
   gateway retransmits the message multiple times, the timeout period
   SHOULD be adjusted to provide a random exponential back-off.  The
   RECOMMENDED timeout is a random value in the range [initial_timeout,
   MIN(initial_timeout * 2^retry_count, maximum_timeout)], with a
   RECOMMENDED initial_timeout of 1 second and a RECOMMENDED
   maximum_timeout of 120 seconds (which is the recommended minimum NAT
   mapping timeout described in [RFC4787]).

   If a gateway that uses relay discovery does not receive a Membership
   Query within a specified time period or after a specified number of
   retries, the gateway SHOULD stop waiting for a Membership Query
   message and restart relay discovery to locate another relay.

Top      Up      ToC       Page 55 
5.2.3.5.4.  Handling a Membership Query Message

   When a gateway receives a Membership Query message, it must first
   determine whether it should accept or ignore the message.  A gateway
   MUST ignore a Membership Query message, or the encapsulated IP
   datagram within it, if the message fails to satisfy any of the
   following requirements:

   o  The gateway MUST be waiting for a Membership Query message.

   o  The Request Nonce value contained in the Membership Query MUST
      equal the Request Nonce value contained in the Request message.

   o  The source IP address and UDP port of the Membership Query MUST
      equal the destination IP address and UDP port of the matching
      Request message (i.e., the current Relay Address).

   o  The encapsulated IP datagram MUST carry an IGMPv3 or MLDv2
      message.  The protocol MUST match the protocol identified by the
      P flag in the Request message.

   o  The IGMPv3 or MLDv2 message MUST be a General Query message.

   o  The total length of the encapsulated IP datagram as computed from
      the lengths contained in the datagram header(s) MUST NOT exceed
      the available field length within the Membership Query message.

   Once a gateway receives a Membership Query response to a Request
   message, it SHOULD ignore any other Membership Query messages that
   arrive on the AMT interface until it sends a new Request message.

   The gateway MUST save the Membership Query message, or the Request
   Nonce, Response MAC, Gateway IP Address, and Gateway Port Number
   fields for use in sending subsequent Membership Update and Teardown
   messages.

   The gateway extracts the encapsulated IP datagram and forwards it to
   the local IP protocol implementation for checksum verification and
   dispatching to the IGMP or MLD implementation running on the
   pseudo-interface.  The gateway MUST NOT forward any octets that might
   exist between the encapsulated IP datagram and the end of the message
   or Gateway Address fields.

   The MLD protocol specification indicates that senders should use a
   link-local source IP address in message datagrams.  This requirement
   must be relaxed for AMT because gateways and relays do not normally
   share a common subnet.  For this reason, a gateway implementation
   MUST accept MLD (and IGMP) query message datagrams regardless of the

Top      Up      ToC       Page 56 
   source IP address they carry.  This may require additional processing
   on the part of the gateway that might be avoided if the relay and
   gateway use the IPv4 and IPv6 addresses allocated for use in
   AMT-encapsulated control packets as described in Section 5.2.1.

   The gateway MUST start a timer that will trigger the next iteration
   of the membership update cycle by executing the membership query
   procedure.  The gateway SHOULD compute the timer duration from the
   Querier's Query Interval Code carried by the General Query.  A
   gateway MAY use a smaller timer duration if required to refresh a NAT
   mapping that would otherwise time out.  A gateway MAY use a larger
   timer duration if it has no group subscriptions to report.

   If the gateway supports the Teardown message and the G flag is set in
   the Membership Query message, the gateway MUST compare the Gateway IP
   Address and Gateway Port Number on the new Membership Query message
   with the values carried by the previous Membership Query message.  If
   either value has changed, the gateway MUST send a Teardown message to
   the relay as described in Section 5.2.3.7.

   If the L flag is set in the Membership Query message, the relay is
   reporting that it is NOT accepting Membership Update messages that
   create new tunnel endpoints and will simply ignore any that do.  If
   the L flag is set and the gateway is not currently reporting any
   group subscriptions to the relay, the gateway SHOULD stop sending
   periodic Request messages and restart the relay discovery procedure
   (if discovery is enabled) to find a new relay with which to
   communicate.  Even if the L flag is set, the gateway MAY continue to
   send updates if it has previously reported group subscriptions to the
   relay, one or more subscriptions still exist, and the gateway
   endpoint address has not changed since the last Membership Query was
   received (see previous paragraph).

5.2.3.5.5.  Handling Query Timer Expiration

   When the query timer (started in the previous step) expires, the
   gateway should execute the membership query procedure again to
   continue the membership update cycle.

5.2.3.5.6.  Request Nonce Generation

   The Request Nonce MUST be a random value and, if possible, SHOULD be
   computed using a cryptographically secure pseudorandom number
   generator.  A new nonce MUST be generated each time the gateway
   starts the membership query process.  The same nonce SHOULD be used
   when retransmitting a Request message.

Top      Up      ToC       Page 57 
5.2.3.6.  Membership Update Procedure

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

   The membership update process is primarily driven by the host-mode
   IGMP or MLD protocol implementation running on the gateway
   pseudo-interface.  The IGMP and MLD protocols produce current-state
   reports in response to General Query messages generated by the
   pseudo-interface via AMT and produce state-change reports in response
   to receiver requests made using the IGMP or MLD service interface.

5.2.3.6.1.  Handling an IGMP/MLD IP Datagram

   The gateway pseudo-interface MUST accept the following IP datagrams
   from the IPv4/IGMP and IPv6/MLD protocols running on the
   pseudo-interface:

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

   o  IPv6 datagrams that carry an MLDv1 or MLDv2 Multicast Listener
      Report or an MLDv1 Multicast Listener Done message as described in
      Section 5 of [RFC3810].

   The gateway must be prepared to receive these messages any time the
   pseudo-interface is running.  The gateway MUST ignore any datagrams
   not listed above.

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

   o  Discard IGMP or MLD datagrams until it receives a Membership Query
      message, at which time it processes the Membership Query message
      as normal to eventually produce a current-state report on the
      pseudo-interface, which describes the end state (RECOMMENDED).

   o  Insert IGMP or MLD datagrams into a queue for transmission after
      it receives a Membership Query message.

   If and when a gateway receives a Membership Query message (for IGMP
   or MLD), it sends any queued or incoming IGMP or MLD datagrams to the
   relay as described in the next section.

Top      Up      ToC       Page 58 
5.2.3.6.2.  Sending a Membership Update Message

   A gateway cannot send a Membership Update message to a relay until it
   has received a Membership Query message from a relay.  If the gateway
   has not yet located a relay with which to communicate, it MUST first
   execute the relay discovery procedure described in Section 5.2.3.4 to
   obtain a Relay Address.  If the gateway has a Relay Address but has
   not yet received a Membership Query message, it MUST first execute
   the membership query procedure described in Section 5.2.3.5 to obtain
   a Request Nonce and Response MAC that can be used to send a
   Membership Update message.

   Once a gateway possesses a valid Relay Address, Request Nonce, and
   Response MAC, it may encapsulate the IP datagram containing the IGMP/
   MLD message into a Membership Update message.  The gateway MUST copy
   the Request Nonce and Response MAC values from the last Membership
   Query received from the relay into the corresponding fields in the
   Membership Update.  The gateway MUST send the Membership Update
   message using the Relay Address and AMT port number as the
   destination.

   When a gateway sends a Membership Update message, it may be notified
   that an ICMP Destination Unreachable message was received as a result
   of an earlier AMT message transmission.  Handling of ICMP Destination
   Unreachable messages is described in Section 5.2.3.9.

5.2.3.7.  Teardown Procedure

   This section describes gateway requirements related to the teardown
   message sequence described in Section 4.2.1.3.

   Gateway support for the Teardown message is RECOMMENDED.

   A gateway that supports Teardown SHOULD make use of Teardown
   functionality if it receives a Membership Query message from a relay
   that has the G flag set to indicate that it contains valid Gateway
   Address fields.

5.2.3.7.1.  Handling a Membership Query Message

   As described in Section 5.2.3.5.4, if a gateway supports the Teardown
   message, has reported active group subscriptions, and receives a
   Membership Query message with the G flag set, the gateway MUST
   compare the Gateway IP Address and Gateway Port Number on the new
   Membership Query message with the values carried by the previous
   Membership Query message.  If either value has changed, the gateway
   MUST send a Teardown message as described in the next section.

Top      Up      ToC       Page 59 
5.2.3.7.2.  Sending a Teardown Message

   A gateway sends a Teardown message to a relay to request that it stop
   delivering Multicast Data messages to the gateway and delete any
   group memberships created by the gateway.

   When a gateway constructs a Teardown message, it MUST copy the
   Request Nonce, Response MAC, Gateway IP Address, and Gateway Port
   Number fields from the Membership Query message that provided the
   Response MAC for the last Membership Update message sent, into the
   corresponding fields of the Teardown message.

   A gateway MUST send the Teardown message using the Relay Address and
   AMT port number as the destination.  A gateway MAY send the Teardown
   message multiple times for robustness.  The gateway SHOULD use the
   Querier's Robustness Variable (QRV) field contained in the query
   encapsulated within the last Membership Query to set the limit on the
   number of retransmissions (see Section 4.1.6 of [RFC3376] and
   Section 5.1.8 of [RFC3810]).  If the gateway sends the Teardown
   message multiple times, it SHOULD insert a delay between each
   transmission using the timing algorithm employed in IGMP/MLD for
   transmitting unsolicited state-change reports.  The RECOMMENDED
   default delay value is 1 second.

   When a gateway sends a Teardown message, it may be notified that an
   ICMP Destination Unreachable message was received as a result of an
   earlier AMT message transmission.  Handling of ICMP Destination
   Unreachable messages is described in Section 5.2.3.9.

5.2.3.8.  Shutdown

   When a gateway pseudo-interface is stopped and the gateway has
   existing group subscriptions, the gateway SHOULD either:

   o  Send a Teardown message to the relay as described in
      Section 5.2.3.7, but only if the gateway supports the Teardown
      message and the current relay is returning Gateway Address fields
      in Membership Query messages, or

   o  Send a Membership Update message to the relay that will delete
      existing group subscriptions.

5.2.3.9.  Handling ICMP Destination Unreachable Responses

   A gateway may receive an ICMP Destination Unreachable message
   [RFC0792] after sending an AMT message.  Whether the gateway is
   notified that an ICMP message was received is highly dependent on
   firewall and gateway IP stack behavior and gateway implementation.

Top      Up      ToC       Page 60 
   If the reception of an ICMP Destination Unreachable message is
   reported to the gateway while waiting to receive an AMT message, the
   gateway may respond as follows, depending on platform capabilities
   and which outgoing message triggered the ICMP response:

   1.  The gateway MAY simply abandon the current relay and restart
       relay discovery (if used).  This is the least desirable approach,
       as it does not allow for transient network changes.

   2.  If the last message sent was a Relay Discovery or Request
       message, the gateway MAY simply ignore the ICMP response and
       continue waiting for incoming AMT messages.  If the gateway is
       configured to retransmit Relay Discovery or Request messages, the
       normal retransmission behavior for those messages is preserved to
       prevent the gateway from prematurely abandoning a relay.

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

   If the reception of an ICMP Destination Unreachable message is
   reported to the gateway when attempting to transmit a new AMT
   message, the gateway may respond as follows, depending on platform
   capabilities and which outgoing message triggered the ICMP response:

   1.  The gateway MAY simply abandon the current relay and restart
       relay discovery (if used).  This is the least desirable approach,
       as it does not allow for transient network changes.

   2.  If the last message sent was a Relay Discovery, Request, or
       Teardown message, the gateway MAY attempt to transmit the new
       message.  If the gateway is configured to retransmit Relay
       Discovery, Request, or Teardown messages, the normal
       retransmission behavior for those messages is preserved to
       prevent the gateway from prematurely abandoning a relay.

   3.  If the last message sent was a Membership Update message, the
       gateway SHOULD start a new membership update and associated
       Request retransmission cycle.


Next RFC Part