tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7450

 
 
 

Automatic Multicast Tunneling

Part 4 of 4, p. 61 to 82
Prev RFC Part

 


prevText      Top      Up      ToC       Page 61 
5.3.  Relay Operation

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

5.3.1.  IP/IGMP/MLD Protocol Requirements

   A relay requires a subset of router-mode IGMP and MLD functionality
   to provide group membership tracking and report processing.

   A relay accessible via IPv4 MUST support IPv4/IGMPv3 and MAY support
   IPv6/MLDv2.  A relay accessible via IPv6 MUST support IPv6/MLDv2 and
   MAY support IPv4/IGMPv3.

   A relay MUST apply the forwarding rules described in Section 6.3 of
   [RFC3376] and Section 7.3 of [RFC3810].

   A relay MUST handle incoming reports as described in Section 6.4 of
   [RFC3376] and Section 7.4 of [RFC3810], with the exception that
   actions that lead to queries MAY be modified to eliminate query
   generation.  A relay MUST accept IGMP and MLD report datagrams
   regardless of the IP source address carried by those datagrams.

   All other aspects of IGMP/MLD router behavior, such as the handling
   of queries, querier election, etc., are not used or required for
   relay operation.

5.3.2.  Startup

   If a relay is deployed for anycast discovery, the relay MUST
   advertise an anycast Relay Discovery Address Prefix into the unicast
   routing system of the anycast domain.  An address within that prefix,
   i.e., a Relay Discovery Address, MUST be assigned to a relay
   interface.

   A unicast IPv4 and/or IPv6 address MUST be assigned to the relay
   interface that will be used to send and receive AMT control and data
   messages.  This address or addresses are returned in Relay
   Advertisement messages.

   The remaining details of relay "startup" are highly implementation
   dependent and are not addressed in this document.

Top      Up      ToC       Page 62 
5.3.3.  Running

   When a relay is started, it begins listening for AMT messages on the
   interface to which the unicast Relay Address(es) has been assigned,
   i.e., the address returned in Relay Advertisement messages.

5.3.3.1.  Handling AMT Messages

   A relay MUST ignore any message other than a Relay Discovery,
   Request, Membership Update, or Teardown message.  The handling of
   Relay Discovery, Request, Membership Update, and Teardown messages is
   addressed in the sections that follow.

   Support for the Teardown message is OPTIONAL.  If a relay does not
   support the Teardown message, it MUST also ignore this message.

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

5.3.3.2.  Handling a Relay Discovery Message

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

   A relay MUST accept and respond to Relay Discovery messages sent to
   an anycast Relay Discovery Address or the unicast Relay Address.  If
   a relay receives a Relay Discovery message sent to its unicast
   address, it MUST respond just as it would if the message had been
   sent to its anycast Relay Discovery Address.

   When a relay receives a Relay Discovery message, it responds by
   sending a Relay Advertisement message back to the source of the Relay
   Discovery message.

   The relay MUST use the source IP address and UDP port number of the
   Relay Discovery message as the destination IP address and UDP port
   number for the Relay Advertisement message.  The source IP address
   and UDP port number carried by the Relay Advertisement message MUST
   match the destination IP address and UDP port number of the Relay
   Discovery message to ensure successful NAT traversal.

   The relay MUST copy the value contained in the Discovery Nonce field
   of the Relay Discovery message into the Discovery Nonce field in the
   Relay Advertisement message.

Top      Up      ToC       Page 63 
   If the Relay Discovery message was received as an IPv4 datagram, the
   relay MUST return an IPv4 address in the Relay Address field of the
   Relay Advertisement message.  If the Relay Discovery message was
   received as an IPv6 datagram, the relay MUST return an IPv6 address
   in the Relay Address field.

5.3.3.3.  Handling a Request Message

   This section describes relay requirements related to the membership
   query portion of the message sequence described in Section 4.2.1.2.

   When a relay receives a Request message, it responds by sending a
   Membership Query message back to the source of the Request message.

   The relay MUST use the source IP address and UDP port of the Request
   message as the destination IP address and UDP port for the Membership
   Query message.  The source IP address and UDP port carried by the
   Membership Query MUST match the destination IP address and UDP port
   of the Request to ensure successful NAT traversal.

   The relay MUST return the value contained in the Request Nonce field
   of the Request message in the Request Nonce field of the Membership
   Query message.  The relay MUST compute a MAC value, as described in
   Section 5.3.5, and return that value in the Response MAC field of the
   Membership Query message.

   If a relay supports the Teardown message, it MUST set the G flag in
   the Membership Query message and return the source IP address and UDP
   port carried by the Request message in the corresponding Gateway IP
   Address and Gateway Port Number fields.  If the relay does not
   support the Teardown message, it SHOULD NOT set these fields, as this
   may cause the gateway to generate unnecessary Teardown messages.

   If the P flag in the Request message is 0, the relay MUST return an
   IPv4-encapsulated IGMPv3 General Query in the Membership Query
   message.  If the P flag is 1, the relay MUST return an
   IPv6-encapsulated MLDv2 General Query in the Membership Query
   message.

   If the relay is not accepting Membership Update messages that create
   new tunnel endpoints due to resource limitations, it SHOULD set the
   L flag in the Membership Query message to notify the gateway of this
   state.  Support for the L flag is OPTIONAL.  See Section 5.3.3.8.

Top      Up      ToC       Page 64 
   The encapsulated IGMPv3 General Query datagrams generated by a relay
   MUST conform to the descriptions found in Section 4.1 of [RFC3376].
   These datagrams MUST possess the IP headers, header options, and
   header values called for in [RFC3376], with the following exception:
   a relay MAY use any source IP address for an IGMP General Query
   datagram, including the "unspecified" address (all octets are zero).
   This exception is made because any source address that a relay might
   normally send may not be a valid link-local address on any gateway
   interface.  It is for this reason that a gateway must accept
   encapsulated IGMP queries regardless of the source address they
   carry.  See Section 5.2.1.

   The encapsulated MLDv2 General Query datagrams generated by a relay
   MUST conform to the descriptions found in Section 5.1 of [RFC3810].
   These datagrams MUST possess the IP headers, header options, and
   header values called for in [RFC3810], with the following exception:
   a relay MAY use any source IP address for an MLD General Query
   datagram, including the "unspecified" address (all octets are zero).
   This exception is made because any source address that a relay might
   normally send may not be a valid link-local address on any gateway
   interface.  As with IGMP, it is for this reason that a gateway must
   accept encapsulated MLD queries regardless of the source address they
   carry.  See Section 5.2.1.

   A relay MUST set the Querier's Query Interval Code (QQIC) field in
   the General Query to supply the gateway with a suggested time
   duration to use for the membership query timer.  The QQIC field is
   defined in Section 4.1.7 of [RFC3376] and Section 5.1.9 of [RFC3810].
   A relay MAY adjust this value to affect the rate at which the Request
   messages are sent from a gateway.  However, a gateway is allowed to
   use a shorter duration than the duration specified in the QQIC field,
   so a relay may be limited in its ability to spread out Requests
   coming from a gateway.

   A relay MUST set the Querier's Robustness Variable (QRV) field in the
   General Query to a non-zero value.  This value SHOULD be greater than
   one.  If a gateway retransmits membership state-change messages, it
   will retransmit them (Robustness Variable - 1) times.  The QRV field
   is defined in Section 4.1.6 of [RFC3376] and Section 5.1.8 of
   [RFC3810].

   A relay SHOULD set the Maximum Response Code field in the General
   Query to a value of 1 to trigger an immediate response from the
   gateway (some host IGMP/MLD implementations may not accept a value of
   zero).  A relay SHOULD NOT use the IGMPv3/MLDv2 Query Response
   Interval variable, if available, to generate the Maximum Response
   Code field value, as the Query Response Interval variable is used in
   setting the duration of group state timers and must not be set to

Top      Up      ToC       Page 65 
   such a small value.  The Maximum Response Code field is defined in
   Section 4.1.1 of [RFC3376] and Section 5.1.3 of [RFC3810].  See
   Section 5.3.3.7.

5.3.3.4.  Handling a Membership Update Message

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

   When a relay receives a Membership Update message, it must first
   determine whether it should accept or ignore the message.  A relay
   MUST NOT make any changes to group membership and forwarding state if
   the message fails to satisfy any of the following requirements:

   o  The IP datagram encapsulated within the message MUST be one of the
      following:

      *  IPv4 datagram carrying an IGMPv2 or IGMPv3 Membership Report
         message.

      *  IPv4 datagram carrying an IGMPv2 Leave Group message.

      *  IPv6 datagram carrying an MLDv1 or MLDv2 Multicast Listener
         Report message.

      *  IPv6 datagram carrying MLDv1 Multicast Listener Done message.

   o  The encapsulated IP datagram MUST satisfy the IP header
      requirements for the IGMP or MLD message type as described in
      Section 4 of [RFC3376], Section 2 of [RFC2236], Section 5 of
      [RFC3810], and Section 3 of [RFC2710], with the following
      exception: a relay MUST accept an IGMP or MLD message regardless
      of the IP source address carried by the datagram.

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

   o  The computed checksums for the encapsulated IP datagram and its
      payload MUST match the values contained therein.  Checksum
      computation and verification vary by protocol; see [RFC0791] for
      IPv4, [RFC3376] for IGMPv3, and [RFC4443] for MLD (ICMPv6).

   o  If processing of the encapsulated IGMP or MLD message would result
      in an allocation of new state or a modification of existing state,
      the relay MUST authenticate the source of the message by verifying
      that the value contained in the Response MAC field equals the MAC
      value computed from the fields in the Membership Update message

Top      Up      ToC       Page 66 
      datagram.  If a time-varying private secret is used in the
      computation of a Response MAC, the relay MUST retain the previous
      version of the private secret for use in authenticating Membership
      Updates sent during the subsequent query interval.  If the first
      attempt at Response MAC authentication fails, the relay MUST
      attempt to authenticate the Response MAC using the previous
      private secret value unless 2 * query_interval time has elapsed
      since the private secret change.  See Section 5.3.5.

   A relay MAY skip source authentication to reduce the computational
   cost of handling Membership Update messages if the relay can make a
   trivial determination that the IGMP/MLD message carried by the
   Membership Update message will produce no changes in group membership
   or forwarding state.  The relay does not need to compute and compare
   MAC values if it finds there are no group subscriptions for the
   source of the Membership Update message and either of the following
   is true:

   o  The encapsulated IP datagram is an IGMPv3 Membership Report or
      MLDv2 Multicast Listener Report message that contains no group
      records.  This may often be the case for gateways that
      continuously repeat the membership update cycle even though they
      have no group subscriptions to report.

   o  The encapsulated IP datagram is an IGMPv2 Leave Group or MLDv1
      Multicast Listener Done message.

   The IGMP and MLD protocol specifications indicate that senders SHOULD
   use a link-local source IP address in message datagrams.  This
   requirement must be relaxed for AMT because gateways and relays do
   not share a common subnet.  For this reason, a relay implementation
   MUST accept IGMP and MLD datagrams regardless of the source IP
   address they carry.

   Once a relay has determined that the Membership Update message is
   valid, it processes the encapsulated IGMP or MLD message to update
   group membership state and communicates with the multicast protocol
   to update forwarding state and possibly send multicast protocol
   messages towards upstream routers.  The relay MUST ignore any octets
   that might exist between the encapsulated IP datagram and the end of
   the Membership Update message.

   As described in Section 4.2.2, a relay uses the source IP address and
   source UDP port carried by a Membership Update message to identify a
   tunnel endpoint.  A relay uses the tunnel endpoint as the destination
   address for any Multicast Data messages it sends as a result of the

Top      Up      ToC       Page 67 
   group membership and forwarding state created by processing the IGMP/
   MLD messages contained in Membership Update messages received from
   the endpoint.

   If a Membership Update message originates from a new endpoint, the
   relay MUST determine whether it can accept updates from a new
   endpoint.  If a relay has been configured with a limit on the total
   number of endpoints, or a limit on the total number of endpoints for
   a given source address, then the relay MAY ignore the Membership
   Update message and possibly withdraw any Relay Discovery Address
   Prefix announcement that it might have made.  See Section 5.3.3.8.

   A relay MUST maintain some form of group membership database for each
   endpoint.  The per-endpoint databases are used to update a forwarding
   table containing entries that map a (*,G) or (S,G) subscription to a
   list of tunnel endpoints.

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

   A relay MUST maintain a forwarding table that maps each unique (*,G)
   and (S,G) subscription to a list of tunnel endpoints.  A relay uses
   this forwarding table to provide the destination address when
   performing UDP/IP encapsulation of the incoming multicast IP
   datagrams to form Multicast Data messages.

   If a group filter mode for a group entry on a tunnel endpoint is
   EXCLUDE, the relay SHOULD NOT forward datagrams that originate from
   sources in the filter source list unless the relay architecture does
   not readily support source filtering.  A relay MAY ignore the source
   list if necessary because gateways are expected to do their own
   source filtering.

5.3.3.5.  Handling a Teardown Message

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

   When a relay (that supports the Teardown message) receives a Teardown
   message, it MUST first authenticate the source of the Teardown
   message by verifying that the Response MAC carried by the Teardown
   message is equal to a MAC value computed from the fields carried by
   the Teardown message.  The method used to compute the MAC differs
   from that used to generate and validate the Membership Query and
   Membership Update messages in that the source IP address and source
   UDP port number used to compute the MAC are taken from the Gateway IP

Top      Up      ToC       Page 68 
   Address and Gateway Port Number fields in the Teardown message rather
   than from the IP and UDP headers in the datagram that carries the
   Teardown message.  The MAC computation is described in Section 5.3.5.
   A relay MUST ignore a Teardown message if the computed MAC does not
   equal the value of the Response MAC field.

   If a relay determines that a Teardown message is authentic, it MUST
   immediately stop transmitting Multicast Data messages to the endpoint
   identified by the Gateway IP Address and Gateway Port Number fields
   in the message.  The relay MUST eventually delete any group
   membership and forwarding state associated with the endpoint but MAY
   delay doing so to allow a gateway to recreate group membership state
   on a new endpoint and thereby avoid making unnecessary (temporary)
   changes in upstream routing/forwarding state.

   The state changes made by a relay when processing a Teardown message
   MUST be identical to those that would be made if the relay had
   received an IGMP/MLD report that would cause the IGMP or MLD protocol
   to delete all existing group records in the group membership database
   associated with the endpoint.  The processing of the Teardown message
   should trigger or mimic the normal interaction between IGMP or MLD
   and a multicast protocol to produce required changes in forwarding
   state and possibly send prune/leave messages towards upstream
   routers.

5.3.3.6.  Handling Multicast IP Datagrams

   When a multicast IP datagram is forwarded to the relay
   pseudo-interface, the relay MUST, for each gateway that has expressed
   an interest in receiving the datagram, encapsulate the IP datagram
   into a Multicast Data message or messages and send that message or
   messages to the gateway.  This process is highly implementation
   dependent but conceptually requires the following steps:

   o  Use the IP datagram source and destination address to look up the
      appropriate (*,G) or (S,G) entry in the endpoint forwarding table
      created for the pseudo-interface as a result of IGMP/MLD
      processing.

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

Top      Up      ToC       Page 69 
   o  If the multicast IP datagram size exceeds the Tunnel MTU as
      determined according to the procedure described in
      Section 5.3.3.6.1, the relay must execute the procedure described
      in Section 5.3.3.6.2.

   o  Encapsulate and transmit the IP datagram according to the
      procedure described in Section 5.3.3.6.3.

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

5.3.3.6.1.  Path and Tunnel MTU

   A relay MUST compute a Tunnel MTU (TMTU) value for each AMT tunnel
   that originates on the relay.  A relay will use the TMTU value to
   determine whether an incoming multicast IP datagram can be delivered
   downstream in a Membership Data message without fragmentation.  A
   relay MUST compute the TMTU by subtracting the size of the Membership
   Data message headers (IP, UDP, and AMT) from the current Path MTU
   (PMTU) associated with each AMT tunnel.  The relay MUST maintain a
   PMTU value on a per-tunnel or per-relay basis.  A relay MUST support
   one or both of the following methods for determining the PMTU value:

   o  The relay MAY provide a configuration option that establishes a
      fixed PMTU that will be applied to all AMT tunnels originating at
      the relay.

   o  The relay MAY dynamically adjust PMTU value(s) in response to
      receipt of ICMP/ICMPv6 Datagram Too Big messages as described in
      [RFC1191] and [RFC1981].

   If a relay supports dynamic adjustment of per-tunnel or per-relay
   PMTU values in response to ICMP messages, the relay MUST provide a
   configuration option that disables this feature and also provide a
   configuration option that establishes a minimum PMTU for all tunnels.
   These configuration options may be used to mitigate certain types of
   denial-of-service attacks (see Section 6).  When dynamic PMTU
   adjustments are disabled, the PMTU for all tunnels MUST default to
   the Link MTU (first hop) on the downstream interface.

Top      Up      ToC       Page 70 
5.3.3.6.2.  MTU Filtering Procedure

   This section defines procedures that a relay must execute when it
   receives a multicast datagram whose size is greater than the Tunnel
   MTU of the tunnel or tunnels through which it must be delivered.

5.3.3.6.2.1.  IPv4 Multicast IP Datagrams

   If the DF bit in the multicast datagram header is set to 1 (Don't
   Fragment), the relay MUST discard the packet and, if the datagram
   originated from an SSM source, send an ICMPv4 [RFC0792] Destination
   Unreachable message to the source, with code 4 (fragmentation needed
   and DF set).  The ICMP Destination Unreachable message MUST contain a
   Next-Hop MTU (as specified by [RFC1191]), and the relay MUST set the
   Next-Hop MTU to the TMTU associated with the tunnel or tunnels.  If
   the DF bit in the multicast datagram header is set to 0 (May
   Fragment), the relay MUST fragment the datagram and encapsulate each
   fragment within Multicast Data messages for transmission through the
   tunnel or tunnels.  This ensures that gateways will receive complete,
   non-fragmented Multicast Data messages, containing fragmented
   multicast datagram payloads.  The relay SHOULD avoid generating a
   separate ICMP message for each tunnel but instead send a single ICMP
   message with a Next-Hop MTU equal to the smallest TMTU of all tunnels
   to which the datagram was to be forwarded.

5.3.3.6.2.2.  IPv6 Multicast IP Datagrams

   The relay MUST discard the packet and, if the datagram originated
   from an SSM source, send an ICMPv6 [RFC4443] Packet Too Big message
   to the payload source.  The MTU specified in the Packet Too Big
   message MUST be equal to the TMTU associated with the tunnel or
   tunnels.  The relay SHOULD avoid generating a separate ICMPv6 message
   for each tunnel but instead send a single ICMPv6 message with a
   Next-Hop MTU equal to the smallest TMTU of all tunnels to which the
   datagram was to be forwarded.

5.3.3.6.3.  Encapsulation Procedure

   A relay encapsulates a multicast IP datagram in a UDP/IP Membership
   Data message, using the tunnel endpoint UDP/IP address as the
   destination address and the unicast Relay Address and port number as
   the source UDP/IP address.  To ensure successful NAT traversal, the
   source address and port MUST match the destination address and port
   carried by the Membership Update message sent by the gateway to
   create the forwarding table entry.

Top      Up      ToC       Page 71 
   If possible, the relay SHOULD compute a valid, non-zero checksum for
   the UDP datagram carrying the Multicast Data message.  See
   Section 4.2.2.3.

   The following sections describe additional requirements related to
   the IP protocol of the tunnel and that of the multicast IP datagram.

5.3.3.6.3.1.  Tunneling over IPv4

   When a relay delivers an IPv4 payload over an IPv4 tunnel and the
   DF bit in the payload header is set to 1 (Don't Fragment), the relay
   MUST set the DF bit in the Multicast Data IP header to 1.  When a
   relay delivers an IPv4 payload over an IPv4 tunnel and the DF bit in
   the payload header is set to 0 (May Fragment), by default, the relay
   MUST set the DF bit in the Multicast Data IP header to 1.  However, a
   relay MAY provide a configuration option that allows the DF bit to be
   copied from the payload header to the Multicast Data IP header to
   allow downstream fragmentation of the Multicast Data message.  When a
   relay delivers an IPv6 payload over an IPv4 tunnel, the relay MUST
   set the DF bit in the Multicast Data IP header to 1.  The relay MUST
   NOT transmit a Multicast Data message with an IP header in which the
   MF (More Fragments) bit is set to 1.

5.3.3.6.3.2.  Tunneling over IPv6

   When tunneling over IPv6, a relay MUST NOT emit a Multicast Data
   message datagram containing an IPv6 fragment header.

5.3.3.6.4.  Handling Destination Unreachable Messages

   If a relay receives a sequence of ICMP or ICMPv6 Destination
   Unreachable messages (excluding ICMP code 4; see below) in response
   to transmission of a sequence of AMT Multicast Data messages to a
   gateway, the relay SHOULD discontinue sending messages to that
   gateway and shut down the tunnel for that gateway.

   Handling of ICMP Destination Unreachable messages with code 4,
   "fragmentation needed and DF set" (i.e., "Datagram Too Big") is
   covered in Section 5.3.3.6.1.  If a relay provides this capability,
   it MUST provide a configuration option that indicates what number of
   sequential Destination Unreachable messages can be received and
   ignored before the relay will automatically shut down a tunnel.

Top      Up      ToC       Page 72 
5.3.3.7.  State Timers

   A relay MUST maintain a timer or timers whose expiration will trigger
   the removal of any group subscriptions and forwarding state
   previously created for a gateway endpoint should the gateway fail to
   refresh the group membership state within a specified time interval.

   A relay MAY use a variant of the IGMPv3/MLDv2 state management
   protocol described in Section 6 of [RFC3376] or Section 7 of
   [RFC3810] or may maintain a per-endpoint timer to trigger the
   deletion of group membership state.

   If a per-endpoint timer is used, the relay MUST restart this timer
   each time it receives a new Membership Update message from the
   gateway endpoint.

   The endpoint timer duration MAY be computed from tunable IGMP/MLD
   variables as follows:

   ((Robustness_Variable) * (Query_Interval)) + Query_Response_Interval

   If IGMP/MLD default values are used for these variables, the gateway
   will time out after 125s * 2 + 10s = 260s.  The timer duration MUST
   be greater than the query interval suggested in the last Membership
   Query message sent to the gateway endpoint.

   Regardless of the timers used (IGMPv3/MLDv2 or endpoint), the
   Query_Response_Interval value SHOULD be greater than or equal to 10s
   to allow for packet loss and round-trip time in the Request/
   Membership Query message exchange.

5.3.3.8.  Relay Resource Management

   A relay may be configured with various service limits to ensure a
   minimum level of performance for gateways that connect to it.

   If a relay has determined that it has reached or exceeded maximum
   allowable capacity or has otherwise exhausted resources required to
   support additional gateways, it SHOULD withdraw any Relay Discovery
   Address Prefix it has advertised into the unicast internetwork and
   SHOULD set the L flag in any Membership Query messages it returns to
   gateways while in this state.

   If the relay receives an update from a gateway that adds group
   membership or forwarding state for an endpoint that has already
   reached maximum allowable state entries, the relay SHOULD continue to
   accept updates from the gateway but ignore any group membership/
   forwarding state additions requested by that gateway.

Top      Up      ToC       Page 73 
   If the relay receives an update from a gateway that would create a
   new tunnel endpoint for a source IP address that has already reached
   the maximum allowable number of endpoints (maximum UDP ports), it
   should simply ignore the Membership Update.

5.3.4.  Shutdown

   The following steps should be treated as an abstract description of
   the shutdown procedure for a relay:

   o  Withdraw the Relay Discovery Address Prefix advertisement
      (if used).

   o  Stop listening for Relay Discovery messages.

   o  Stop listening for control messages from gateways.

   o  Stop sending data messages to gateways.

   o  Delete all AMT group membership and forwarding state created on
      the relay, coordinating with the multicast routing protocol to
      update the group membership state on upstream interfaces as
      required.

5.3.5.  Response MAC Generation

   A Response MAC value is computed by the relay.  A Response MAC
   computation is required in the following situations:

   o  To generate a Response MAC value from a Request message for
      inclusion in a Membership Query message.

   o  To generate a Response MAC value from a Membership Update message
      for use in authenticating the Response MAC carried within that
      message.

   o  To generate a Response MAC value from a Teardown message to
      authenticate the Response MAC carried within that message.

   Gateways treat the Response MAC field as an opaque value, so a relay
   implementation may generate the MAC using any method available to it.
   The RECOMMENDED method for computing the Response MAC is to compute a
   cryptographically secure hash or keyed-hash digest from the following
   values:

   o  The source IP address of the message (or Teardown Gateway IP
      Address field).

Top      Up      ToC       Page 74 
   o  The source UDP port of the message (or Teardown Gateway Port
      Number field).

   o  The Request Nonce contained in the message.

   o  A private secret or key known only to the relay.

5.3.6.  Private Secret Generation

   If the relay implementation uses a private secret (or key) to compute
   the Response MAC value, the relay SHOULD periodically compute a new
   private secret.  The RECOMMENDED maximum interval is 2 hours.  A
   relay MUST retain the prior secret for use in verifying MAC values
   that were sent to gateways just prior to the use of the new secret.

6.  Security Considerations

   AMT is not intended to be a strongly secure protocol.  In general,
   the protocol provides the same level of security and robustness as is
   provided by the UDP, IGMP, and MLD protocols on which it relies.  The
   lack of strong security features can be largely attributed to the
   desire to make the protocol lightweight by minimizing the state and
   computation required to service a single gateway, thereby allowing a
   relay to service a larger number of gateways.

   Many of the threats and vectors described in [RFC3552] may be
   employed against the protocol to launch various types of denial-of-
   service attacks that can affect the functioning of gateways or their
   ability to locate and communicate with a relay.  These scenarios are
   described below.

   As is the case for UDP, IGMP, and MLD, the AMT protocol provides no
   mechanisms for ensuring message delivery or integrity.  The protocol
   does not provide confidentiality -- multicast groups, sources, and
   streams requested by a gateway are sent in the clear.

   The protocol does use a three-way handshake to provide trivial source
   authentication for state allocation and updates (see below).  The
   protocol also requires gateways and relays to ignore malformed
   messages and those messages that do not carry expected address
   values, protocol payload types, or content.

6.1.  Relays

   The three-way handshake provided by the membership update message
   sequence (see Section 4.2.1.2) provides a defense against source-
   spoofing-based resource-exhaustion attacks on a relay by requiring
   source authentication before state allocation.  However, in an effort

Top      Up      ToC       Page 75 
   to consume computational resources, attackers may still attempt to
   flood a relay with Request and Membership Update messages to force
   the relay to make the MAC authentication computations.
   Implementations may choose to limit the frequency with which a relay
   responds to Request messages sent from a single IP address or IP
   address and UDP port pair, but support for this functionality is not
   required.  The three-way handshake provides no defense against an
   eavesdropping or man-in-the-middle attacker.

   Attackers that execute the gateway protocol may consume relay
   resources by instantiating a large number of tunnels or joining a
   large number of multicast streams.  A relay implementation should
   provide a mechanism for limiting the number of tunnels (Multicast
   Data message destinations) that can be created for a single gateway
   source address.  Relays should also provide a means for limiting the
   number of joins per tunnel instance as a defense against these
   attacks.

   Relays may withdraw their AMT anycast prefix advertisement when they
   reach configured maximum capacity or exhaust required resources.
   This behavior allows gateways to use the relay discovery process to
   find the next topologically nearest relay that has advertised the
   prefix.  This behavior also allows a successful resource-exhaustion
   attack to propagate from one relay to the next until all relays
   reachable using the anycast address have effectively been taken
   offline.  This behavior may also be used to acquire the unicast
   addresses for individual relays that can then be used to launch a
   DDoS attack on all of the relays without using the relay discovery
   process.  To prevent wider disruption of AMT-based distribution
   networks, relay anycast address advertisements can be limited to
   specific administrative routing domains.  This will isolate such
   attacks to a single domain.

   The Path and Tunnel MTU adjustment (discovery) procedure described in
   Section 5.3.3.6.1 is vulnerable to two denial-of-service attacks (see
   Section 8 of [RFC1191] for details).  Both attacks are based on a
   malicious party sending forged ICMPv4 Destination Unreachable or
   ICMPv6 Packet Too Big messages to a host.  In the first attack, the
   forged message indicates an inordinately small Path MTU.  In the
   second attack, the forged message indicates an inordinately large
   Path MTU.  In both cases, throughput is adversely affected.  In order
   to mitigate such attacks, relay implementations MUST include a
   configuration option to disable Path MTU adjustments on AMT tunnels.

Top      Up      ToC       Page 76 
6.2.  Gateways

   A passive eavesdropper may launch a denial-of-service attack on a
   gateway by capturing a Membership Query or Membership Update message
   and using the Request Nonce and message authentication code carried
   by the captured message to send a spoofed Membership Update or
   Teardown message to the relay.  The spoofed messages may be used to
   modify or destroy group membership state associated with the gateway,
   thereby changing or interrupting the multicast traffic flows.

   A passive eavesdropper may also spoof Multicast Data messages in an
   attempt to overload the gateway or to disrupt or supplant existing
   traffic flows.  A properly implemented gateway will filter Multicast
   Data messages that do not originate from the expected Relay Address
   and should filter non-multicast packets and multicast IP packets
   whose group or source addresses are not included in the current
   reception state for the gateway pseudo-interface.

   An active eavesdropper may launch a man-in-the-middle attack in which
   messages normally exchanged between a gateway and relay are
   intercepted, modified, spoofed, or discarded by the attacker.  The
   attacker may deny access to, modify, or replace requested multicast
   traffic.  The AMT protocol provides no means for detecting or
   defending against a man-in-the-middle attack -- any such
   functionality must be provided by multicast receiver applications
   through independent detection and validation of incoming multicast
   datagrams.

   The anycast discovery technique for finding relays (see
   Section 4.1.4) introduces a risk that a rogue router or a rogue
   Autonomous System (AS) could introduce a bogus route to a specific
   Relay Discovery Address Prefix and thus divert or absorb Relay
   Discovery messages sent by gateways.  Network managers must guarantee
   the integrity of their routing to a particular Relay Discovery
   Address Prefix in much the same way that they guarantee the integrity
   of all other routes.

6.3.  Encapsulated IP Packets

   An attacker forging or modifying a Membership Query or Membership
   Update message may attempt to embed something other than an IGMP or
   MLD message within the encapsulated IP packet carried by these
   messages in an effort to introduce these into the recipient's IP
   stack.  A properly implemented gateway or relay will ignore any such
   messages and may further choose to ignore Membership Query messages
   that do not contain IGMP/MLD General Query or Membership Update
   messages that do not contain IGMP/MLD membership reports.

Top      Up      ToC       Page 77 
   Properly implemented gateways and relays will also filter
   encapsulated IP packets that appear corrupted or truncated by
   verifying packet length and checksums.

7.  IANA Considerations

7.1.  IPv4 and IPv6 Anycast Prefix Allocation

   The following unicast prefixes have been assigned to provide anycast
   routing of Relay Discovery messages to public AMT relays as described
   in Section 4.1.4.  Address assignments within these prefixes are
   described in Section 4.1.5.2.

7.1.1.  IPv4

   IANA has assigned 192.52.193.0/24 from the "IANA IPv4 Special-Purpose
   Address Registry".  The block has been registered as follows:

                 +----------------------+----------------+
                 | Attribute            | Value          |
                 +----------------------+----------------+
                 | Address Block        |192.52.193.0/24 |
                 | Name                 | AMT            |
                 | RFC                  | [RFC7450]      |
                 | Allocation Date      | 2014-12        |
                 | Termination Date     | N/A            |
                 | Source               | True           |
                 | Destination          | True           |
                 | Forwardable          | True           |
                 | Global               | True           |
                 | Reserved-by-Protocol | False          |
                 +----------------------+----------------+

Top      Up      ToC       Page 78 
7.1.2.  IPv6

   IANA has registered the following special-purpose address block for
   IPv6 anycast AMT relay discovery.

                 +----------------------+----------------+
                 | Attribute            | Value          |
                 +----------------------+----------------+
                 | Address Block        | 2001:3::/32    |
                 | Name                 | AMT            |
                 | RFC                  | [RFC7450]      |
                 | Allocation Date      | 2014-12        |
                 | Termination Date     | N/A            |
                 | Source               | True           |
                 | Destination          | True           |
                 | Forwardable          | True           |
                 | Global               | True           |
                 | Reserved-by-Protocol | False          |
                 +----------------------+----------------+

7.2.  UDP Port Number

   The UDP port number 2268 has been reserved with IANA for use in the
   implementation and deployment of AMT.  The protocol described by this
   document continues to use this port number according to the intent of
   the original request.  IANA has updated the assignee, contact, and
   reference fields for this port number in accordance with this
   document.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol,
              Version 3", RFC 3376, October 2002,
              <http://www.rfc-editor.org/info/rfc3376>.

   [RFC3810]  Vida, R., Ed., and L. Costa, Ed., "Multicast Listener
              Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
              June 2004, <http://www.rfc-editor.org/info/rfc3810>.

Top      Up      ToC       Page 79 
   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006,
              <http://www.rfc-editor.org/info/rfc4291>.

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, August 2006,
              <http://www.rfc-editor.org/info/rfc4607>.

   [RFC4787]  Audet, F., Ed., and C. Jennings, "Network Address
              Translation (NAT) Behavioral Requirements for Unicast
              UDP", BCP 127, RFC 4787, January 2007,
              <http://www.rfc-editor.org/info/rfc4787>.

8.2.  Informative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981, <http://www.rfc-editor.org/info/rfc0791>.

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981,
              <http://www.rfc-editor.org/info/rfc0792>.

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, August 1989,
              <http://www.rfc-editor.org/info/rfc1112>.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990, <http://www.rfc-editor.org/info/rfc1191>.

   [RFC1546]  Partridge, C., Mendez, T., and W. Milliken, "Host
              Anycasting Service", RFC 1546, November 1993,
              <http://www.rfc-editor.org/info/rfc1546>.

   [RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
              for IP version 6", RFC 1981, August 1996,
              <http://www.rfc-editor.org/info/rfc1981>.

   [RFC2236]  Fenner, W., "Internet Group Management Protocol,
              Version 2", RFC 2236, November 1997,
              <http://www.rfc-editor.org/info/rfc2236>.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998,
              <http://www.rfc-editor.org/info/rfc2460>.

Top      Up      ToC       Page 80 
   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999,
              <http://www.rfc-editor.org/info/rfc2663>.

   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
              Listener Discovery (MLD) for IPv6", RFC 2710,
              October 1999, <http://www.rfc-editor.org/info/rfc2710>.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003, <http://www.rfc-editor.org/info/rfc3552>.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              January 2006, <http://www.rfc-editor.org/info/rfc4271>.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
              Control Message Protocol (ICMPv6) for the Internet
              Protocol Version 6 (IPv6) Specification", RFC 4443,
              March 2006, <http://www.rfc-editor.org/info/rfc4443>.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006,
              <http://www.rfc-editor.org/info/rfc4601>.

   [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast
              Services", BCP 126, RFC 4786, December 2006,
              <http://www.rfc-editor.org/info/rfc4786>.

   [RFC6935]  Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
              UDP Checksums for Tunneled Packets", RFC 6935, April 2013,
              <http://www.rfc-editor.org/info/rfc6935>.

   [RFC6936]  Fairhurst, G. and M. Westerlund, "Applicability Statement
              for the Use of IPv6 UDP Datagrams with Zero Checksums",
              RFC 6936, April 2013,
              <http://www.rfc-editor.org/info/rfc6936>.

Top      Up      ToC       Page 81 
Acknowledgments

   The author would like to thank the following individuals for their
   suggestions, comments, and corrections:

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

   The anycast discovery mechanism described in this document is based
   on similar work done by the NGTrans WG for obtaining automatic IPv6
   connectivity without explicit tunnels ("6to4").  Tony Ballardie
   provided helpful discussion that inspired this document.

   Juniper Networks was instrumental in funding several versions of this
   document as well as an open source implementation.

Top      Up      ToC       Page 82 
Contributors

   The following people provided significant contributions to the design
   of the protocol and earlier versions of this specification:

      Amit Aggarwal
      Microsoft Corporation
      One Microsoft Way
      Redmond, WA  98052-6399
      United States
      EMail: amitag@microsoft.com

      Thomas Morin
      Orange
      2, avenue Pierre Marzin
      Lannion  22300
      France
      EMail: thomas.morin@orange.com

      Dirk Ooms
      OneSparrow
      Robert Molsstraat 11; 2018 Antwerp
      Belgium
      EMail: dirk@onesparrow.com

      Tom Pusateri
      !j
      Wake Forest, NC
      United States
      EMail: pusateri@bangj.com

      Dave Thaler
      Microsoft Corporation
      One Microsoft Way
      Redmond, WA  98052-6399
      United States
      EMail: dthaler@microsoft.com

Author's Address

   Gregory Bumgardner

   Phone: +1 541 343 6790
   EMail: gbumgard@gmail.com