Network Working Group                                          D. Thaler
Internet-Draft                                                 M. Talwar
Intended status: Standards Track                             A. Aggarwal
Expires: September 8, 2010 January 12, 2012                          Microsoft Corporation
                                                             L. Vicisano
                                                           Qualcomm Inc.
                                                             T. Pusateri
                                                                      !j
                                                           March 7, 2010
                                                                T. Morin
                                                 France Telecom - Orange
                                                           July 11, 2011

                    Automatic IP Multicast Without Explicit Tunnels (AMT)
                  draft-ietf-mboned-auto-multicast-10 Tunneling
                  draft-ietf-mboned-auto-multicast-11

Abstract

   Automatic IP Multicast Tunneling (AMT) allows multicast communication
   amongst reception by
   isolated multicast-enabled sites or hosts, attached to a network
   which has no native multicast support.  It also enables them to exchange receive
   multicast traffic with from the native multicast infrastructure and does not require without
   requiring any manual configuration.  AMT uses an encapsulation
   interface so that no changes to a host stack or applications are
   required, all protocols (not just UDP) are handled, and there is no
   additional overhead in core routers.

Status of this Memo

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

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

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 8, 2010. January 12, 2012.

Copyright Notice

   Copyright (c) 2010 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

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

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Applicability  . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  7
   4.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  AMT Pseudo-Interface . . . . . . . . . . . . . . . . . . .  8
     4.2.  AMT Gateway  . . . . . . . . . . . . . . . . . . . . . . .  8
     4.3.  AMT Site . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.4.  AMT Relay Router  . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.5.  AMT Relay Anycast Prefix . . . . . . . . . . . . . . . . .  9
     4.6.  AMT Relay Anycast Address  . . . . . . . . . . . . . . . .  9
     4.7.  AMT Subnet Anycast Prefix  . . . . . . . . . . . . . . . .  9
     4.8.  AMT Gateway Anycast Address  . . . . . . . . . . . . . . .  9
   5.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  Receiving Multicast in an AMT Site . . . . . . . . . . . . 10
       5.1.1.  Scalability Considerations . . . . . . . . . . . . . . . . 11
       5.1.2.
     5.2.  Spoofing Considerations  . . . . . . . . . . . . . . . . . 11
       5.1.3.
     5.3.  Protocol Sequence for a Gateway Joining SSM
               Receivers to a Relay .  . . . . . . . . . . . . . . . . 12
     5.2.  Sourcing Multicast from an AMT site  . . . . . . . . . . 12
   6.  Message Formats  . 14
       5.2.1.  Supporting Site-MBone Multicast . . . . . . . . . . . 15
       5.2.2.  Supporting Site-Site Multicast . . . . . . . . . . . 15
     6.1.  Use of UDP . 16
   6.  Message Formats . . . . . . . . . . . . . . . . . . . . . . . 17
     6.1. 15
     6.2.  AMT Relay Discovery  . . . . . . . . . . . . . . . . . . . 17
       6.1.1. 15
       6.2.1.  Type . . . . . . . . . . . . . . . . . . . . . . . . . 17
       6.1.2. 15
       6.2.2.  Reserved . . . . . . . . . . . . . . . . . . . . . . . 17
       6.1.3. 15
       6.2.3.  Discovery Nonce  . . . . . . . . . . . . . . . . . . . 17
     6.2. 15
     6.3.  AMT Relay Advertisement  . . . . . . . . . . . . . . . . . 17
       6.2.1. 16
       6.3.1.  Type . . . . . . . . . . . . . . . . . . . . . . . . . 18
       6.2.2. 16
       6.3.2.  Reserved . . . . . . . . . . . . . . . . . . . . . . . 18
       6.2.3. 16
       6.3.3.  Discovery Nonce  . . . . . . . . . . . . . . . . . . . 18
       6.2.4. 16
       6.3.4.  Relay Address  . . . . . . . . . . . . . . . . . . . . 18
     6.3. 16
     6.4.  AMT Request  . . . . . . . . . . . . . . . . . . . . . . . 18
       6.3.1. 16
       6.4.1.  Type . . . . . . . . . . . . . . . . . . . . . . . . . 19
       6.3.2. 17
       6.4.2.  Reserved . . . . . . . . . . . . . . . . . . . . . . . 19
       6.3.3. 17
       6.4.3.  Request Nonce  . . . . . . . . . . . . . . . . . . . . 19
     6.4. 17
     6.5.  AMT Membership Query . . . . . . . . . . . . . . . . . . . 19
       6.4.1. 17
       6.5.1.  Type . . . . . . . . . . . . . . . . . . . . . . . . . 20
       6.4.2.  Reserved 18
       6.5.2.  Flags  . . . . . . . . . . . . . . . . . . . . . . . 20
       6.4.3. . 18
       6.5.3.  Response MAC . . . . . . . . . . . . . . . . . . . . . 20
       6.4.4. 19
       6.5.4.  Request Nonce  . . . . . . . . . . . . . . . . . . . . 20
       6.4.5. 19
       6.5.5.  IGMP/MLD Query (including IP Header) . . . . . . . . . 20
     6.5.  AMT Membership Update 19
       6.5.6.  Gateway information fields . . . . . . . . . . . . . . 19
     6.6.  AMT Membership Update  . . . . 21
       6.5.1.  Type . . . . . . . . . . . . . . 19
       6.6.1.  Type . . . . . . . . . . . 21
       6.5.2.  Reserved . . . . . . . . . . . . . . 20
       6.6.2.  Reserved . . . . . . . . . 22
       6.5.3.  Response . . . . . . . . . . . . . . 20
       6.6.3.  Response MAC . . . . . . . . . . . . . . . . . . . . . 22
       6.5.4. 20
       6.6.4.  Request Nonce  . . . . . . . . . . . . . . . . . . . . 22
       6.5.5. 21
       6.6.5.  IGMP/MLD Message (including IP Header) . . . . . . . . 22
     6.6. 21
     6.7.  AMT IP Multicast Data  . . . . . . . . . . . . . . . . . . 22
       6.6.1. 21
       6.7.1.  Type . . . . . . . . . . . . . . . . . . . . . . . . . 23
       6.6.2. 22
       6.7.2.  Reserved . . . . . . . . . . . . . . . . . . . . . . . 23
       6.6.3. 22
       6.7.3.  IP Multicast Data  . . . . . . . . . . . . . . . . . . 23
     6.7. 22

     6.8.  AMT Membership Teardown . . . . . . . . . . . . . . . . . 23
       6.7.1. . . . . . . 22
       6.8.1.  Type . . . . . . . . . . . . . . . . . . . . . . . . . 24
       6.7.2. 23
       6.8.2.  Reserved . . . . . . . . . . . . . . . . . . . . . . . 24
       6.7.3. 23
       6.8.3.  Original Response MAC  . . . . . . . . . . . . . . . . 24
       6.7.4. 23
       6.8.4.  Original Request Nonce . . . . . . . . . . . . . . . . 24
       6.7.5. 23
       6.8.5.  Original Source Port . . . . . . . . . . . . . . . . . 24
       6.7.6. 23
       6.8.6.  Original Source AFI . Address  . . . . . . . . . . . . . . . 23
   7.  AMT Gateway Details  . . . . . . 24
       6.7.7.  Original Source Address . . . . . . . . . . . . . . . 25
       6.7.8.  IGMP/MLD Message (including IP Header)
     7.1.  At Startup Time  . . . . . . . . 25
   7.  AMT Gateway Details . . . . . . . . . . . . . 25
     7.2.  Gateway identification . . . . . . . . 26
     7.1.  At Startup Time . . . . . . . . . . 25
     7.3.  Joining Multicast Groups . . . . . . . . . . . 26
     7.2.  Gateway Group and Source Addresses . . . . . . 26
     7.4.  Responding to Relay Changes  . . . . . . 26
       7.2.1.  IPv4 . . . . . . . . . 26
   8.  AMT Relay Details  . . . . . . . . . . . . . . . . 27
       7.2.2.  IPv6 . . . . . . 27
     8.1.  At Startup time  . . . . . . . . . . . . . . . . . . . 27
     7.3.  Joining Groups with MBone Sources . . 27
     8.2.  Receiving Relay Discovery messages sent to the Anycast
           Address  . . . . . . . . . . 28
     7.4.  Responding to Relay Changes . . . . . . . . . . . . . . . 28
     7.5.  Joining SSM Groups with 27
     8.3.  Receiving Membership Updates from AMT Gateway Sources  . Gateways . . . . . . 29
     7.6.  Receiving AMT Membership Updates by the Gateway 27
   9.  IANA Considerations  . . . . . 29
     7.7.  Sending data to SSM groups . . . . . . . . . . . . . . . . 29
   8.  Relay Router Details
     9.1.  IPv4 and IPv6 Anycast Prefix Allocation  . . . . . . . . . 29
       9.1.1.  IPv4 . . . . . . . . . . . . 30
     8.1.  At Startup time . . . . . . . . . . . . . 29
       9.1.2.  IPv6 . . . . . . . . 30
     8.2.  Receiving Relay Discovery messages sent to the Anycast
           Address . . . . . . . . . . . . . . . . . 29
     9.2.  UDP Port number  . . . . . . . . 30
     8.3.  Receiving Membership Updates from AMT Gateways . . . . . . 30
     8.4.  Receiving (S,G) Joins from the Native Side, for AMT
           Sources . . . . . . . 29
   10. Security Considerations  . . . . . . . . . . . . . . . . . . 31
   9.  IANA Considerations . 30
   11. Contributors . . . . . . . . . . . . . . . . . . . . 32
     9.1.  IPv4 and IPv6 Anycast Prefix Allocation . . . . . 31
   12. Acknowledgments  . . . . 32
       9.1.1.  IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 32
       9.1.2.  IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 32
     9.2.  IPv4 and IPv6 AMT Subnet Prefix Allocation . . . . . . . . 32
       9.2.1.  IPv4 . . . . . . . . . . . . 32
   13. References . . . . . . . . . . . . . 32
       9.2.2.  IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 32
     9.3.  UDP Port number  . . . . . . . . . . . . . . . . . . . . . 32
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 33
   11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34
   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 35
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 36 33
     13.2. Informative References . . . . . . . . . . . . . . . . . . 36 33
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 35

1.  Introduction

   The primary goal of this document is to foster the deployment of
   native IP multicast by enabling a potentially large number of nodes
   to connect to the already present multicast infrastructure.
   Therefore, the techniques discussed here should be viewed as an
   interim solution to help in the various stages of the transition to a
   native multicast network.

   To allow fast deployment, the solution presented here only requires
   small and concentrated changes to the network infrastructure, and no
   changes at all to user applications or to the socket API of end-
   nodes' operating systems.  The protocol introduced in this
   specification can be deployed in a few strategically-placed network
   nodes and in user-installable software modules (pseudo device drivers
   and/or user-mode daemons) that reside underneath the socket API of
   end-nodes' operating systems.  This mechanism is very similar to that
   used by "6to4" [RFC3056], [RFC3068] to get automatic IPv6
   connectivity.

   Effectively, AMT treats the unicast-only inter-network as a large
   non-broadcast multi-access (NBMA) link layer, over which we require
   the ability to multicast.  To do this, multicast packets being sent
   to or from a site must be encapsulated in unicast packets.  If the group has
   members in multiple sites, AMT encapsulation of the same multicast
   packet will take place multiple times by necessity.

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

2.  Applicability

   AMT is not a substitute for native multicast or a statically
   configured multicast tunnel for high traffic flow.  Unicast
   replication is required to reach multiple receivers that are not part
   of the native multicast infrastructure.  Unicast replication is also
   required by non-native sources to different parts of the native
   multicast infrastructure.  However, this  However, this is no worse
   than regular unicast distribution of streams and in most cases much
   better.

   The following problems are addressed:

   1.  Allowing

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

   Earlier versions of
       multicast ([RFC4607]).

   2.  Allowing this document were describing how to use AMT to
   allow isolated non-NAT sites/hosts to transmit the SSM flavor multicast ; the
   specifications for these functionalities have been left off the
   current document for the following reasons: the drawback that these
   specifications required a source site Gateway to replicate traffic to
   many Relays in the multicast-enabled part of multicast.

   3.  Allowing isolated sites/hosts the network, lack of
   contributors to receive general multicast (ASM
       [RFC1112]).

   This document does not address allowing isolated sites/hosts alternative proposals based on AMT,
   existence of ways to
   transmit general multicast.  We expect that other solutions (e.g., offer similar functionality using Tunnel Brokers, a la [RFC3053]) will be used for sites that desire
   this capability. Broker
   approaches [RFC3053], or at the application layer.

   Implementers should be aware that site administrators may have
   configured administratively scoped multicast boundaries and a remote
   gateway may provide a means to circumvent administrative boundaries.
   Therefore, implementations should allow for the configuration of such
   boundaries on relays and gateways and perform filtering as needed.

3.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

4.  Definitions

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

4.1.  AMT Pseudo-Interface

   AMT encapsulation of multicast packets inside unicast packets occurs
   at a point that is logically equivalent to an interface, with the
   link layer being the unicast-only network.  This point is referred to
   as a pseudo-interface.  Some implementations may treat it exactly
   like any other interface and others may treat it like a tunnel end-
   point.

4.2.  AMT Gateway

   A host, or a site gateway router, supporting an AMT Pseudo-
   Interface. Pseudo-Interface.
   It does not have native multicast connectivity to the native
   multicast backbone infrastructure.  It is simply referred to in this
   document as a "gateway".

4.3.  AMT Site

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

4.4.  AMT Relay Router

   A multicast router configured to support transit routing between AMT
   Sites and the native multicast backbone infrastructure.  The relay
   router has one or more interfaces connected to the native multicast
   infrastructure, zero or more interfaces connected to the non-
   multicast capable inter-network, and an AMT pseudo-interface.  It is
   simply referred to in this document as a "relay".

   As with [RFC3056], we assume that normal multicast routers do not
   want to be tunnel endpoints (especially if this results in high fan
   out), and similarly that service providers do not want encapsulation
   to arbitrary routers.
   out).  Instead, we assume that special-purpose routers will be
   deployed that are suitable for serving as relays.

4.5.  AMT Relay Anycast Prefix

   A well-known address prefix used to advertise (into the unicast
   routing infrastructure) a route to an available AMT Relay Router.
   This could also be private (i.e., not well-known) for a private
   relay.

   Prefixes for both IPv4 and IPv6 will be assigned in a future version
   of this draft.

4.6.  AMT Relay Anycast Address

   An anycast address which is used to reach the nearest AMT Relay
   Router.

   This address corresponds to the setting the low-order octet of the
   AMT Relay Anycast Prefix to 1 (for both IPv4 and IPv6).

4.7.  AMT Subnet Anycast Prefix

   A well-known address prefix used to advertise (into the M-RIB of the
   native multicast-enabled infrastructure) a route to AMT Sites.  This
   prefix will be used to enable sourcing SSM traffic from an AMT
   Gateway.

4.8.  AMT Gateway Anycast Address

   An anycast address in the AMT Subnet Anycast Prefix range, which is
   used by an AMT Gateway to enable sourcing SSM traffic from local
   applications.

5.  Overview

5.1.  Receiving Multicast in an AMT Site

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

                    Receiving Multicast in an AMT Site

   AMT relays and gateways cooperate to transmit multicast traffic
   sourced within the native multicast infrastructure to AMT sites:
   relays receive the traffic natively and unicast-encapsulate it to
   gateways; gateways decapsulate the traffic and possibly forward it
   into the AMT site.

   Each gateway has an AMT pseudo-interface that serves as a default
   multicast route.  Requests to join a multicast session are sent to
   this interface and encapsulated to a particular relay reachable
   across the unicast-only infrastructure.

   Each relay has an AMT pseudo-interface too.  Multicast traffic sent
   on this interface is encapsulated to zero or more gateways that have
   joined to the relay.  The AMT recipient-list is determined for each
   multicast session.  This requires the relay to keep state for each
   gateway which has joined a particular group or (source, group) pair.
   Multicast packets from the native infrastructure behind the relay
   will be sent to each gateway which has requested them.

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

   Each relay, plus the set of all gateways using the relay, together
   are thought of as being on a separate logical NBMA link.  This
   implies that the AMT recipient-list is a list of "link layer"
   addresses which are (IP address, UDP port) pairs.

   Since the number of gateways using a relay can be quite large, and we
   expect that most sites will not want to receive most groups, an
   explicit-joining protocol is required for gateways to communicate
   group membership information to a relay.  The two most likely
   candidates are the IGMP/MLD protocol [RFC3376], [RFC3810], and the
   PIM-Sparse Mode protocol [RFC4601].  Since an AMT gateway may be a
   host, and hosts typically do not implement routing protocols,
   gateways will use IGMP/MLD as described in Section 7 below.  This
   allows a host kernel (or a pseudo device driver) to easily implement
   AMT gateway behavior, and obviates the relay from the need to know
   whether a given gateway is a host or a router.  From the relay's
   perspective, all gateways are indistinguishable from hosts on an NBMA
   leaf network.

5.1.1.

5.1.  Scalability Considerations

   It is possible that millions of hosts will enable AMT gateway
   functionality and so an important design goal is not to create
   gateway state in each relay until the gateway joins a multicast
   group.  But even the requirement that a relay keep group state per
   gateway that has joined a group introduces potential scalability
   concerns.

   Scalability of AMT can be achieved by adding more relays, and using
   an appropriate relay discovery mechanism for gateways to discover
   relays.  The solution we adopt is to assign addresses in anycast
   fashion to relays [RFC1546], [RFC4291].  However, simply sending
   periodic membership reports to an anycast address can cause
   duplicates.  Specifically, if routing changes such that a different
   relay receives a periodic membership report, both the new and old
   relays will encapsulate data to the AMT site until the old relay's
   state times out.  This is obviously undesirable.  Instead, we use the
   anycast address merely to find the unicast address of a relay to
   which membership reports are sent.

   Since adding another relay has the result of adding another
   independent NBMA link, this

   This approach allows the gateways to be spread out among more relays
   so as to keep the number of gateways per relay at a reasonable level.

5.1.2.

5.2.  Spoofing Considerations

   An attacker could affect the group state in the relay or gateway by spoofing the
   source address in the AMT Update messages containing join or leave
   reports.  This can be used to launch reflection or denial of service
   attacks on the
   target. target Relay.  Such attacks can be mitigated by using
   a three way handshake between the gateway and the relay for each
   multicast membership report or leave.

   When a gateway or relay wants to send a membership report, it first sends an
   AMT Request with a request nonce in it.  The receiving side
   (the respondent) Relay can calculate a
   message authentication code (MAC) based on (for example) the example)the source IP
   address of the Request, the source UDP port, the request nonce, and a
   secret key known only to the respondent. Relay.  The algorithm and the input used to calculate the
   MAC does not have to
   be standardized since the respondent Relay generates and verifies the MAC and
   the originator Gateway simply echoes it. it back, but an algorithm such as
   HMAC-MD5-48 [RFC2104] SHOULD be used at a minimum.

   An AMT Membership Query is sent back to the gateway having originated
   the Request, including the request nonce and the MAC to the originator of the Request.  The originator then sends MAC.  The gateway
   then sends the IGMP/MLD Membership/Listener Report or Leave/Done
   (including the IP Header) along with the request nonce and the
   received MAC back to the respondent relay, finalizing the 3-way handshake.

   Upon reception, the respondent relay can recalculate the MAC based on the source
   IP address, the source UDP port, the request nonce, and the local
   secret.  The IGMP/MLD message is only accepted if the received MAC
   matches the calculated MAC.

   A relay MUST NOT create state for a gateway before successful
   validation of a MAC of an AMT Update from this gateway; a relay
   SHOULD delete all states for a gateway after a small timer after it
   stops having any AMT forwarding state for a Gateway (i.e. the Gateway
   left all multicast groups it had joined).

   The local secret never has to be shared with the other side.  It is
   only used to verify return routability of the originator.

   Since the same Request Nonce and source IP address can be re-used,
   the receiver relay SHOULD change its secret key at least once per hour.
   However, AMT Membership updates received with the previous secret
   MUST be accepted for up to the IGMP/MLD Query Interval.

   The condition might occur where the gateway or relay that initially sent the
   AMT Request dynamically changes its IP address.  This might occur due
   to a change in wireless networks, a DHCP assignment, or another
   network failure.  When this occurs, it is no longer possible to
   verify the MAC using the source address and source port.  Though, in
   order to reduce state, it is desirable to tear down the state that
   was created with the old source address.  A Teardown message with
   special considerations for calculating the MAC is described below to
   perform this function.

5.1.3.

5.3.  Protocol Sequence for a Gateway Joining SSM Receivers to a Relay

   This description assumes the Gateway can be a host joining as a
   receiver or a network device acting as a Gateway when a directly
   connected host joins as a receiver.

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

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

   o  Gateway receives report.  If it has no tunnel state with a Relay,
      it originates an AMT Relay Discovery message addressed to the
      Anycast Relay IP address.  The AMT Relay Discovery message can be
      sent on demand if no relay is known at this time or at startup and
      be periodically refreshed.

   o  The closest Relay topologically receives the AMT Relay Discovery
      message and returns the nonce from the Discovery in an AMT Relay
      Advertisement message so the Gateway can learn of the Relay's
      unique IP address.

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

   o  If the gateway has a valid Response MAC from a previous AMT Query
      message, it can send an AMT Membership Update message as described
      below.  Otherwise, the Gateway sends an AMT Request message to the
      Relay's unique IP address to begin the process of joining the
      (S,G).  The gateway also SHOULD initialize a timer used to send
      periodic Requests to a random value from the interval [0, [Query
      Interval]] before sending the first periodic report, in order to
      prevent startup synchronization.

   o  The Relay responds to the AMT Request message by returning the
      nonce from the Request in a AMT Query message.  The Query message
      contains an IGMP/MLD QUERY indicating how often the Gateway should
      repeat AMT Request messages so the (S,G) state can stay refreshed
      in the Relay.  The Query message also includes an opaque security
      code which is generated locally (with no external coordination).

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

   o  When the Relay receives the AMT Membership Update, it will add the
      tunnel to the Gateway in it's outgoing interface list for it's
      (S1,G1) entry stored in the multicast routing table.  If the
      (S1,G1) entry was created do to this interaction, the multicast
      routing protocol running on the Relay will trigger a Join message
      towards source S1 to build a native multicast tree in the native
      multicast infrastructure.

   o  As packets are sent from the host S1, they will travel natively
      down the multicast tree associated with (S1,G1) in the native
      multicast infrastructure to the Relay.  The Relay will replicate
      to all interfaces in it's outgoing interface list as well as the
      tunnel outgoing interface, which is encapsulated in a unicast AMT
      Multicast Data message.

   o  When the Gateway receives the AMT Multicast Data message, it will
      accept the packet since it was received over the pseudo-interface
      associated with the tunnel to the Relay it had attached to, and
      forward the packet to the outgoing interfaces joined by any
      attached receiver hosts (or deliver the packet to the application
      when the Gateway is the receiver).

   o  If later (S2,G2) is joined by a receiver, a 3-way handshake of
      Request/ Query/Update occurs for this entry.  The Discovery/
      Advertisement exchange is not required.

   o  To keep the state for (S1,G1) and (S2,G2) alive in the Relay, the
      Gateway will send periodic AMT Membership Updates.  The Membership
      Update can be sent directly if the sender has a valid nonce from a
      previous Request.  If not, an AMT Request messages should be sent
      to solicit a Query Message.  When sending a periodic state
      refresh, all joined state in the Gateway is packed in the fewest
      number of AMT Membership Update messages.

   o  When the Gateway leaves all (S,G) entries, the Relay can free
      resources associated with the tunnel.  It is assumed that when the
      Gateway would want to join an (S,G) again, it would start the
      Discovery/Advertisement tunnel establishment process over again.

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

5.2.  Sourcing Multicast from an

6.  Message Formats

6.1.  Use of UDP

   All AMT site

   Two cases messages are discussed below: multicast traffic sourced in an AMT
   site and received in UDP packets.

   Messages sent to the MBone, and multicast traffic sourced in an
   AMT site and received in another AMT site.

   In both cases only SSM sources Relay are supported.  Furthermore this
   specification only deals with sent to the IANA reserved AMT port
   number (Section 9), from a source residing directly in port uniquely selected by the
   gateway.  To enable a generic node host
   operating system of the Gateway.  Messages sent by the Relay are sent
   from the IANA reserved AMT port number.

   The UDP checksum MUST be valid in an all AMT site to source
   multicast, additional coordination between control messages (Relay
   Discovery, Relay Advertisement, Membership Request, Membership Query,
   Membership Update).  Section 6.7 specifies the gateway and behavior with
   reference to the
   source-node is required.

   The gateway SHOULD allow for filtering link-local and site-local
   traffic. UDP checksums of AMT IP Multicast Data messages.

6.2.  AMT Relay Discovery

   The general mechanism used to join towards AMT sources Relay Discovery message is based on
   the following:

   1.  Applications residing in sent from the AMT gateway use addresses in unicast
   address to the AMT
       Subnet Relay Anycast Prefix address to send multicast, as a result of sourcing
       traffic on the AMT pseudo-interface.

   2.  The AMT Subnet Anycast Prefix is advertised for RPF reachability
       in the M-RIB by relays and gateways.

   3.  Relays or gateways that receive a join for a source/group pair
       use information encoded in the address pair to rebuild the
       address of the gateway (source) to which to encapsulate the join
       (see Section 7.2 for more details).  The membership reports use
       the same three way handshake as outlined in Section 5.1.2

5.2.1.  Supporting Site-MBone Multicast

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

                           Site-MBone Multicast

   If a relay receives an explicit join from the native infrastructure,
   for a given (source, group) pair where the source address belongs to
   the AMT Subnet Anycast Prefix, then the relay will periodically
   (using the rules specified in Section 5.1.2) encapsulate membership
   updates for the group to the gateway.  The gateway must keep state
   per relay from which membership reports have been sent, and forward
   multicast traffic from the site to all relays from which membership
   reports have been received.  The choice of whether this state and
   replication is done at the link-layer (i.e., by the tunnel interface)
   or at the network-layer is implementation dependent.

   If there are multiple relays present, this ensures that data from the
   AMT site is received via the closest relay to the receiver.  This is
   necessary when the routers in the native multicast infrastructure
   employ Reverse-Path Forwarding (RPF) checks against the source
   address, such as occurs when PIM Sparse-Mode [RFC4601] is used by the
   multicast infrastructure.

   The solution above will scale to an arbitrary number of relays, as
   long at the number of relays requiring multicast traffic from a given
   AMT site remains reasonable enough to not overly burden the site's
   gateway.

   A source at or behind an AMT gateway requires the gateway to do the
   replication to one or more relays and receiving gateways.  If this
   places too much of a burden on the sourcing gateway, the source
   should join the native multicast infrastructure through a permanent
   tunnel so that replication occurs within the native multicast
   infrastructure.

5.2.2.  Supporting Site-Site Multicast

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

                            Site-Site Multicast

   Since we require gateways to accept membership reports, as described
   above, it is also possible to support multicast among AMT sites,
   without requiring assistance from any relays.

   When a gateway wants to join a given (source, group) pair, where the
   source address belongs to the AMT Subnet Anycast Prefix, then the
   gateway will periodically unicast encapsulate an IGMPv3/MLDv2 Report
   [RFC3376], [RFC3810] (including IP Header) directly to the site
   gateway for the source.

   We note that this can result in a significant amount of state at a
   site gateway sourcing multicast to a large number of other AMT sites.
   However, it is expected that this is not unreasonable for two
   reasons.  First, the gateway does not have native multicast
   connectivity, and as a result is likely doing unicast replication at
   present.  The amount of state is thus the same as what such a site
   already deals with.  Secondly, any site expecting to source traffic
   to a large number of sites could get a point-to-point tunnel to the
   native multicast infrastructure, and use that instead of AMT.

6.  Message Formats

6.1.  AMT Relay Discovery

   The AMT Relay Discovery message is a UDP packet sent from the AMT
   gateway unicast address to the AMT relay anycast address to discover discover the unicast
   address of an AMT relay.

   The UDP source port is uniquely selected by the local host operating
   system.  The UDP destination port is the IANA reserved AMT port
   number.  The UDP checksum MUST be valid in of an AMT control messages. relay.

   The payload of the UDP packet contains the following fields.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type=0x1  |     Reserved                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Discovery Nonce                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            AMT Relay Discovery

6.1.1.

6.2.1.  Type

   The type of the message.

6.1.2.

6.2.2.  Reserved

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

6.1.3.

6.2.3.  Discovery Nonce

   A 32-bit random value generated by the gateway and replayed by the
   relay.

6.2.

6.3.  AMT Relay Advertisement

   The AMT Relay Advertisement message is a UDP packet sent from the AMT relay anycast
   address to the source of the discovery message.

   The UDP source port is the IANA reserved AMT port number and the UDP
   destination port is the source port received in the Discovery
   message.

   The UDP CHECKSUM MUST be valid in AMT control messages.

   The payload of the UDP packet contains the following fields.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type=0x2  |     Reserved                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Discovery Nonce                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Relay Address                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          AMT Relay Advertisement

6.2.1.

6.3.1.  Type

   The type of the message.

6.2.2.

6.3.2.  Reserved

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

6.2.3.

6.3.3.  Discovery Nonce

   A 32-bit random value generated by the gateway and replayed by the
   relay.

6.2.4.

6.3.4.  Relay Address

   The unicast IPv4 or IPv6 address of the AMT relay.  The family can be
   determined by the length of the Advertisement.

6.3.

6.4.  AMT Request

   A Request packet is sent by a Gateway to a Relay to begin a 3-way
   handshake for sending an IGMP/MLD Membership/Listener Report or
   Leave/Done.

   It can be sent
   from a gateway to a relay, from a gateway to another gateway, or from
   a relay to a gateway.

   It is sent from the originator's unique unicast Gateway address to the
   respondents' Relay's unique unicast
   address.

   The UDP source port is uniquely selected by the local host operating
   system.  It can be different for each Request and different from the source port used in Discovery
   messages but does not have to be.  The UDP destination port is the IANA reserved AMT source port number.  The UDP
   checksum MUST must be valid in AMT control messages.

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

                          AMT Relay Advertisement

6.3.1.  Type

   The type of the message.

6.3.2.  Reserved

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

6.3.3.
   consistent across Request Nonce

   A 32-bit identifier used to distinguish this request.

6.4.  AMT Membership Query

   An AMT Membership Query packet is sent from the respondent back to
   the originator to solicit an AMT Membership Update while confirming
   the source of the original request.  It contains a relay Message
   Authentication Code (MAC) that is a cryptographic hash of a private
   secret, the originators address, and the request nonce.

   It is sent from the destination address received in the Request to
   the source address received in the Request which is the same address
   used in the Relay Advertisement. Update messages (see also Section 7.2).

   The UDP source destination port is the IANA reserved AMT port number and the UDP
   destination port is the source port received in the Request message.
   The UDP checksum MUST be valid in AMT control messages. number.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type=0x4     Type=0x3  |     Reserved                                  |         Response MAC          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Response MAC (continued)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Request Nonce                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            IGMP Membership Query or MLD Listener Query        |
   |            (including IP Header)                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            ...                                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                AMT Membership Query Request

6.4.1.  Type

   The type of the message.

6.4.2.  Reserved

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

6.4.3.  Response MAC

   A 48-bit hash generated by the respondent and sent to the originator
   for inclusion in the AMT Membership Update.  The algorithm used for
   this is chosen by the respondent but an algorithm such as HMAC-MD5-48
   [RFC2104] SHOULD be used at a minimum.

6.4.4.  Request Nonce

   A 32-bit identifier used to distinguish this request echoed back to
   the originator.

6.4.5.  IGMP/MLD Query (including IP Header)

   The message contains either an IGMP Query or an MLD Multicast
   Listener Query.  The IGMP or MLD version sent should default to
   IGMPv3 or MLDv2 unless explicitly configured to use IGMPv2 or MLDv1.
   The IGMP/MLD Query includes a full IP Header.  The IP source address
   of the query would match the anycast address on the pseudo interface.
   The TTL of the outer header should be sufficient to reach the tunnel
   endpoint and not mimic the inner header TTL which is typically 1 for
   IGMP/MLD messages. request.

6.5.  AMT Membership Update Query

   An AMT Membership Update Query packet is sent to report a membership after a valid
   Response MAC has been received.  It contains from the original IGMP/MLD
   Membership/Listener Report or Leave/Done received over Relay back to the
   Gateway to solicit an AMT
   pseudo-interface including the original IP header.  It echoes the
   Response MAC received in Membership Update while confirming the AMT Membership Query so
   source of the respondent
   can verify return routability to original request.  It contains a relay Message
   Authentication Code (MAC) that is a cryptographic hash of a private
   secret, the originator. originators address, and the request nonce.

   It is sent from the destination address received in the Query Request to
   the source address received in of the Query which should both be Request, i.e. the same as Relay Address advertised
   in the original Request. Relay Advertisement message.

   The UDP source and destination port numbers should be is the same ones
   sent in IANA reserved AMT port number and the original Request.

   The relay UDP
   destination port is not required to use the IP source address of port received in the IGMP
   Membership Report for any particular purpose.

   The same Request Nonce and Response MAC can be used across multiple
   AMT Membership Update messages without having to send individual AMT
   Membership Query messages. message.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type=0x5     Type=0x4  |    Reserved    Flags      |         Response MAC          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Response MAC (continued)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Request Nonce                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            IGMP Membership Query or MLD Message Listener Query        |
   |            (including IP header) Header)                              |
   |            ...                                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Gateway Port Number       |       Gateway Address ...     | ?
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?
   |                    ... Gateway Address (ctd) ...              | ?
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?
   |                    ... Gateway Address (ctd) ...              | ?
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?
   |                    ... Gateway Address (ctd) ...              | ?
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?
   |   ... Gateway Address (ctd)   |                                 ?
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           AMT Membership Update Query

6.5.1.  Type

   The type of the message.

6.5.2.  Reserved

   A  Flags

   An 8-bit reserved field.  Sent flags field having the following format:
                    0 1 2 3 4 5 6 7
                   +-+-+-+-+-+-+-+-+
                   |   Reserved  |G|
                   +-+-+-+-+-+-+-+-+

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

   Other flags are currently unused and reserved: they are sent as 0, zero
   and their value is ignored on receipt.

6.5.3.  Response MAC

   The

   A 48-bit MAC received in hash generated by the Membership Query Relay and echoed back sent to the Gateway for
   inclusion in the AMT Membership Update. Update (see Section 5.2).

6.5.4.  Request Nonce

   A 32-bit identifier echoed back to the originator to used to distinguish this request. identify
   the corresponding request (see Section 5.2).

6.5.5.  IGMP/MLD Message Query (including IP Header)

   The message contains either an IGMP Membership Report, an IGMP
   Membership Leave, an MLD Multicast Listener Report, Query or an MLD Multicast
   Listener Done. Query.  The IGMP or MLD version sent should be in response
   the version of the query received in the AMT Membership Query. default to
   IGMPv3 or MLDv2 unless explicitly configured to use IGMPv2 or MLDv1.
   The IGMP/MLD Message Query includes a full IP Header.

6.6.  AMT IP Multicast Data  The AMT Data message is a UDP packet encapsulating the IP Multicast
   data requested by source address
   of the originator based on a previous AMT Membership
   Update message.

   It is sent from query would match the unicast destination anycast address on the pseudo interface.
   The TTL of the Membership
   update outer IP header should be sufficient to reach the source address of
   tunnel endpoint and not mimic the Membership Update. inner IP header TTL which is
   typically 1 for IGMP/MLD messages.

6.5.6.  Gateway information fields

   The UDP source "Gateway Port Number" and destination port numbers should be "Gateway Address" fields are present in
   the same ones
   sent Query message if, and only if, the "G" flag is set in the original Query.  The Flags
   field.

6.5.6.1.  Gateway Port Number

   A 16-bit field containing a UDP checksum MUST be valid in AMT
   control messages. port value.

   The payload Relay sets this field to the value of the UDP packet contains source port of the following fields.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type=0x6  |    Reserved   |     IP Multicast Data ...     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            ...                                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           AMT IP Multicast Data

6.6.1.  Type

   The type
   Request message that triggered the Query message.

6.5.6.2.  Gateway Address

   A 16-byte field containing the IP source address of the Request
   message that triggered this Query message.

6.6.2.  Reserved

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

6.6.3.  IP Multicast Data  The original IP Multicast data packet that field contains an
   IPv4-compatible IPv6 address ([RFC4291], section 2.5.5.1) if the
   address is being replicated by an IPv4 address (i.e. the
   relay IPv4 address prefixed with 96
   bits set to the gateways including the original IP header.

6.7. zero), or an IPv6 address.

6.6.  AMT Membership Teardown Update

   An AMT Membership Teardown Update is sent to report an IGMP Membership Leave
   or MLD Listener Done a membership after a valid
   Response MAC has been received and
   after the source address that was used to generate the Response MAC
   is no longer available for sourcing packets.

   An AMT Membership Teardown from received.  It contains the original source address and
   source port is NOT valid and should be discarded if received.  Use an
   AMT Membership Update instead.

   An AMT Membership Teardown can only contain either an IGMP Membership
   Leave or an MLD Listener Done message.  The encapsulated IGMP/MLD
   message will have to be fabricated by the sender of
   Membership/Listener Report or Leave/Done received over the AMT
   Membership Teardown in
   pseudo-interface including the case where there wasn't an original IGMP/
   MLD message to be forwarded.

   In order for IP header.  It echoes the receiver to verify
   Response MAC received in the AMT Membership Teardown message,
   it must contain Query so the original source address and source port in
   addition respondent
   can verify return routability to the Original Request Nonce and Original Response MAC. originator.

   It is sent from the destination address received in the Query to the
   source address received in the original Query which should both be the same as
   the original Request.

   The UDP source and destination port numbers should be the same ones
   sent in the original Request.

   The UDP destination port number should be is the IANA reserved AMT port number and the
   UDP source port is the same one sent in source port used for the
   original Request. Request message.

   The relay Relay is not required to use the IP source address of the IGMP
   Membership Report for any particular purpose.

   The same Request Nonce and Response MAC can be used across multiple
   AMT Membership Update messages without having to send individual AMT
   Membership Query messages.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type=0x7     Type=0x5  |    Reserved   |    Original         Response MAC          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Original            Response MAC (continued)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Original            Request Nonce                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Original Source Port      |         Source AFI            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Original Source Address                            |
   |            ...                                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            IGMP Membership Leave or                           |
   | MLD Listener Done Message (including IP header)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            ...                                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           AMT Membership Teardown

6.7.1. Update

6.6.1.  Type

   The type of the message.

6.7.2.

6.6.2.  Reserved

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

6.7.3.  Original

6.6.3.  Response MAC

   The 48-bit MAC received in the Membership Query and echoed back in
   the Membership Update.

6.7.4.  Original Update (see Section 5.2).

6.6.4.  Request Nonce

   A 32-bit identifier used to distinguish this request.

6.7.5.  Original Source Port

   The 16-bit port number used in the original AMT Membership update
   that was used to generate the Original Response MAC.

6.7.6.  Source AFI

   A 16-bit Address Family Identifier (AFI) [RFC4760] used to determine
   the protocol address family of the following Original Source Address.

   Presently defined values for matching the Address Family Identifier field are
   specified in IANA's Address Family Numbers registry [IANA.AFN]

6.7.7.  Original Source Address

   The source address used nonce in the original AMT Membership update that
   was used to generate the Original Response MAC.

6.7.8. Request (see
   Section 5.2).

6.6.5.  IGMP/MLD Message (including IP Header)

   The message contains either an IGMP Membership Leave Report, an IGMP
   Membership Leave, an MLD Multicast Listener Report, or an MLD
   Listener Done.  The IGMP or MLD version sent should be in response
   the version of the query received in the original AMT Membership
   Query.  The IGMP/MLD Message includes a full IP Header.

7.  AMT Gateway Details

   This section details the behavior of an AMT Gateway, which may be a
   router serving an AMT site, or the site may consist of a single host,
   serving as its own gateway.

7.1.  At Startup Time

   At startup time, the AMT gateway will bring up an AMT pseudo-
   interface to be used for encapsulation.  The gateway needs to
   discover an function of
   the version of the query received in the AMT Relay to send Membership Requests.  It can send an
   AMT Relay Discovery at startup time or wait until it has Query.  The
   IGMP/MLD Message includes a group
   membership to report. full IP Header.

6.7.  AMT IP Multicast Data

   The AMT Relay Discovery Data message is sent to a UDP packet encapsulating the IP Multicast
   data requested by the originator based on a previous AMT Relay Anycast Address.  A Membership
   Update message.

   It is sent from the Relay's unique unicast address (which is treated as a
   link-layer (destination
   address of the Membership update) to the encapsulation interface) Gateway's unicast address
   (source address of the Membership Update).

   The UDP source port is received in the IANA reserved AMT Relay Advertisement message.  The discovery process SHOULD port number and the
   destination port should be
   done periodically (e.g., once a day) to re-resolve the unicast
   address same as the source port of a close relay.  To prevent startup synchronization, the
   timer
   Membership Update that resulted in the creation of forwarding state
   for the encapsulated IP packet.

   The UDP checksum SHOULD use at least 10 percent jitter.

   If be zero for AMT IP Multicast Data messages
   carried over IPv4, and MAY be zero for AMT IP Multicast Data messages
   carried over IPv6 [I-D.ietf-6man-udpchecksums].

   The payload of the UDP packet contains the following fields.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type=0x6  |    Reserved   |     IP Multicast Data ...     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            ...                                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           AMT IP Multicast Data

6.7.1.  Type

   The type of the gateway is serving as a local router, it SHOULD also function
   as an IGMP/MLD Proxy, message.

6.7.2.  Reserved

   An 8-bit reserved field.  Sent as described in [RFC4605], with its IGMP/MLD
   host-mode interface 0, ignored on receipt.

6.7.3.  IP Multicast Data

   The original IP Multicast data packet that is being replicated by the AMT pseudo-interface.  This enables it
   Relay to translate group memberships on its downstream interfaces into
   IGMP/MLD Reports.  Hosts receiving multicast packets through an AMT
   gateway acting as a proxy should ensure that their M-RIB accepts
   multicast packets from the AMT gateway for Gateway, including the sources it original IP header.

6.8.  AMT Teardown

   An AMT Teardown is joining.

7.2.  Gateway Group and Source Addresses

   To support sourcing traffic to SSM groups sent by a gateway with Gateway after a global
   unicast address, the AMT Subnet Anycast Prefix is treated as the
   subnet prefix of the AMT pseudo-interface, valid Response MAC has
   been received and an anycast after the source address that was used to generate
   the Response MAC is
   added on no longer available for sending packets.

   It is sent to the interface.  This anycast source address is formed by
   concatenating received in the AMT Subnet Anycast Prefix followed by original Query which
   should be the high bits
   of same as the gateway's global unicast address. original Request.

   The remaining bits of its global unicast address are appended to UDP destination port number should be the
   SSM prefix to create same one sent in the group
   original Request.

   An AMT Teardown from the original source address and any spare bits may source port is
   NOT valid and should be
   allocated using local policy.

   If a gateway wants discarded if received.  Use an AMT Membership
   Update instead.

   In order for the Relay to source multicast traffic, it verify the Teardown message, this message
   must select contain the
   gateway original source address and SSM group address source port in such a way that the
   AMT relay can have enough information addition
   to reconstruct the gateway's
   unicast address when it receives an SSM join for the source.

   Note that multiple gateways might end up with Original Request Nonce and Original Response MAC.  In
   situations where NAT is used, this information can be known by the same anycast
   address assigned
   Gateway thanks to their pseudo-interfaces.

7.2.1.  IPv4

   For example, if IANA assigns the IPv4 prefix x.y/16 as optional Gateway information fields in the AMT Subnet
   Anycast Prefix, and
   Query message (Section 6.5.6).  Hence, a Relay supporting the gateway has global unicast address a.b.c.d,
   then
   Teardown mechanism SHOULD include the AMT Gateway's Anycast Source Address will be x.y.a.b.  Since Gateway information fields in
   the IPv4 SSM group range is 232/8, Query messages it MUST allocate IPv4 SSM groups
   in sends.

   On reception of a valid Teardown message, a Relay should remove all
   state corresponding to the range 232.c.d/24.

           Group: gateway identified by the (original source
   address, original source port) tuple, and stop forwarding all traffic
   to this destination.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8                  16 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
           +------------+------------------------+-------------+ 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | SSM prefix     Type=0x7  |     Low 16 bits of    Reserved   |    Original Response MAC      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Local            Original Response MAC (continued)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   232/8            Original Request Nonce                             |  real source address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Policy     Original Source Port      |
           +------------+------------------------+-------------+

           Source:
           +-------------------------+-------------------------+
           |16-bit AMT unicast prefix| high 16 bits of real src|
           +-------------------------+-------------------------+

                                IPv4 format

   This allows for 2^8 (256) IPv4 group addresses for use by each AMT
   gateway.

7.2.2.  IPv6

   Similarly for IPv6, this is illustrated in the following figure.

           Group:
                 32                  64                 32
           +------------+------------------------+-------------+  Original Source Address ...  | SSM prefix
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Low 64 bits of                  Original Source Address (ctd) ...            |    Local
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             ...  Original Source Address (ctd) ...            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | FF3x::/32             ...  Original Source Address (ctd) ...            |  real source address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Policy ... Original Src Addr. (ctd)  |
           +------------+------------------------+-------------+

           Source:
           +-------------------------+-------------------------+
           |64-bit AMT unicast prefix| high 64 bits of real src|
           +-------------------------+-------------------------+

                                IPv6 format

   This allows for 2^32 (over 4 billion) IPv6 group addresses for use by
   each
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          AMT gateway.

7.3.  Joining Groups with MBone Sources Membership Teardown

6.8.1.  Type

   The IGMP/MLD protocol usually operates by having the Querier
   multicast an IGMP/MLD Query message on type of the link.  This behavior does
   not work message.

6.8.2.  Reserved

   A 8-bit reserved field.  Sent as 0, ignored on NBMA links which do not support multicast.  Since receipt.

6.8.3.  Original Response MAC

   The 48-bit MAC received in the set
   of gateways is typically unknown Membership Query.

6.8.4.  Original Request Nonce

   A 32-bit identifier corresponding to the relay (and potentially quite
   large), unicasting the queries is also impractical. original Request.

6.8.5.  Original Source Port

   The following
   behavior is 16-bit port number used instead.

   Applications residing in a gateway should join groups on the original AMT
   pseudo-interface, causing IGMP/MLD Membership/Listener Reports to be
   sent over Request message that interface.  When UDP encapsulating
   was used to generate the membership
   reports (and in fact any other messages, unless specified otherwise
   in this document), Original Response MAC.

6.8.6.  Original Source Address

   A 16-byte field containing the destination IP source address used in the outer IP header original
   AMT Request message that was used to generate the Original Response
   MAC of the Request message that triggered this Query message.  The
   field contains an IPv4-compatible IPv6 address ([RFC4291], section
   2.5.5.1) if the address is an IPv4 address (i.e. the relay's unicast IPv4 address
   prefixed with 96 bits set to zero), or an IPv6 address.  Robustness is provided by

7.  AMT Gateway Details

   This section details the
   underlying IGMP/MLD protocol messages sent on behavior of an AMT Gateway, which may be a
   router serving an AMT site, or the AMT pseudo-
   interface.  In other words, site may consist of a single host,
   serving as its own gateway.

7.1.  At Startup Time

   At startup time, the AMT gateway does not need to retransmit
   IGMP/MLD Membership/Listener Reports and Leave/Done messages received
   on the pseudo-interface since IGMP/MLD will already do this. bring up an AMT pseudo-
   interface to be used for encapsulation.  The gateway simply needs to encapsulate each IGMP/MLD Membership/Listener
   Report and Leave/Done message it receives.

   However, since periodic IGMP/MLD Membership/Listener Reports are sent
   in response
   discover an AMT Relay to IGMP/MLD Queries, send Membership Requests.  It can send an
   AMT Relay Discovery at startup time or wait until it has a mechanism group
   membership to trigger periodic
   Membership/Listener Reports and Leave/Done messages is necessary. report.  The gateway should use a timer to trigger periodic AMT Membership
   Updates.

   If Relay Discovery message is sent to the gateway
   AMT Relay Anycast Address.  A unicast address (which is behind treated as a firewall device,
   link-layer address to the firewall may require encapsulation interface) is received in the gateway to
   AMT Relay Advertisement message.  The discovery process SHOULD be
   done periodically refresh (e.g., once a day) to re-resolve the UDP state in unicast
   address of a close relay.  To prevent startup synchronization, the firewall
   timer SHOULD use at
   a shorter interval than least 10 percent jitter.

   If the standard gateway is serving as a local router, it SHOULD also function
   as an IGMP/MLD Query interval. Proxy, as described in [RFC4605], with its IGMP/MLD
   host-mode interface being the AMT
   Requests can be sent periodically pseudo-interface.  This enables it
   to solicit translate group memberships on its downstream interfaces into
   IGMP/MLD Queries.  The
   interval at which the Reports.  Hosts receiving multicast packets through an AMT Requests are sent
   gateway acting as a proxy should be configurable to ensure the firewall does not revert to blocking the UDP encapsulated
   IP Multicast data packets.  When that their M-RIB accepts
   multicast packets from the AMT Query is received, it can be
   ignored unless gateway for the sources it is time for joining.

7.2.  Gateway identification

   From the point of view of a periodic AMT Relay, a Gateway is identified by the (IP
   source address, UDP source port) tuple in Membership Update.

   The relay can Update messages.
   If an implementation of Gateway procedure was to use a different UDP
   source port and/or IP source address to join or leave different
   multicast groups, it would appear to the Querier's Robustness Variable (QRV) defined Relay as distinct Gateways.

   For instance, a Relay having forwarding state resulting in
   [RFC3376] and [RFC3810] to adjust the number
   forwarding of Membership/Listener
   Reports that are sent by the host joining the group.

7.4.  Responding (S,G) to Relay Changes

   When a said gateway determines that its current relay is unreachable
   (e.g., upon receipt of an ICMP Unreachable message [RFC0792] for the
   relay's unicast address), it may need to repeat relay address
   discovery.  However, care should be taken identified by a (IP source
   address, UDP source port) tuple, will not to abandon the current
   relay too quickly due to transient network conditions.

7.5.  Joining SSM Groups with remove this state if it
   receives an AMT Gateway Sources

   An IGMPv3/MLDv2 Report for Membership Update message from a given (source, group) pair MAY be
   encapsulated directly different (IP source
   address, UDP source port) tuple.

   It results that a Gateway has to use the source, when the same UDP source address belongs port for AMT
   Request and AMT Update messages related to the AMT Subnet Anycast Prefix.

   The "link-layer" address a same (S,G).  A said
   Gateway instance is typically expected to use as the destination address in the
   outer same UDP source
   port and IP header is obtained as follows.  The source address in the
   inclusion list of for all Request and Updates messages for
   all multicast groups.

7.3.  Joining Multicast Groups

   The IGMP/MLD protocol usually operates by having the IGMPv3/MLDv2 report will be Querier
   multicast an AMT Gateway
   Anycast Address with IGMP/MLD Query message on the high bits link.  This behavior does
   not work on NBMA links which do not support multicast.  Since the set
   of gateways is typically unknown to the address, and relay (and potentially quite
   large), unicasting the remaining
   bits will be queries is also impractical.  The following
   behavior is used instead.

   Applications residing in a gateway should join groups on the middle of AMT
   pseudo-interface, causing IGMP/MLD Membership/Listener Reports to be
   sent over that interface.  When UDP encapsulating the group address.

   Section 7.2 describes membership
   reports (and in fact any other messages, unless specified otherwise
   in this format to recover document), the gateway source
   address.

7.6.  Receiving AMT Membership Updates by destination address in the Gateway

   When an AMT Request outer IP header is received by the gateway from another gateway
   or relay, it follows
   the same 3-way handshake procedure a relay would
   follow if it received relay's unicast address.  Robustness is provided by the AMT Request.  It generates a MAC and
   responds with an AMT Membership Query.  When
   underlying IGMP/MLD protocol messages sent on the AMT Membership
   Update is received, it verifies pseudo-
   interface.  In other words, the MAC gateway does not need to retransmit
   IGMP/MLD Membership/Listener Reports and then processes Leave/Done messages received
   on the IGMP/
   MLD pseudo-interface since IGMP/MLD will already do this.  The
   gateway simply needs to encapsulate each IGMP/MLD Membership/Listener
   Report or Leave/Done.

   At the gateway, the and Leave/Done message it receives.

   However, since periodic IGMP/MLD packet should be an IGMPv3/MLDv2 source
   specific (S,G) join or leave.

   If S Membership/Listener Reports are sent
   in response to IGMP/MLD Queries, a mechanism to trigger periodic
   Membership/Listener Reports and Leave/Done messages is not the necessary.
   The gateway should use a timer to trigger periodic AMT Gateway Anycast Address, the packet is silently
   discarded. Membership
   Updates.

   If G does not contain the low bits of gateway is behind a firewall device, the global unicast
   address (as described above), firewall may require
   the packet is also silently discarded.

   The gateway adds the source address (from to periodically refresh the outer IP header) and UDP port of the report to a membership list for G. Maintaining this
   membership list may be done state in any implementation-dependent manner.
   For example, it might be maintained by the "link-layer" inside firewall at
   a shorter interval than the standard IGMP/MLD Query interval.  AMT pseudo-interface, making it invisible
   Requests can be sent periodically to the normal solicit IGMP/MLD
   module.

7.7.  Sending data to SSM groups

   When multicast packets are sent on Queries.  The
   interval at which the AMT pseudo-interface, they Requests are
   encapsulated as follows.  If sent should be configurable to
   ensure the group address is firewall does not an SSM group,
   then revert to blocking the packet UDP encapsulated
   IP Multicast data packets.  When the AMT Query is silently discarded (this memo does not currently
   provide received, it can be
   ignored unless it is time for a way to send periodic AMT Membership Update.

   The relay can use the Querier's Robustness Variable (QRV) defined in
   [RFC3376] and [RFC3810] to non-SSM groups).

   If adjust the group address is an SSM group, then number of Membership/Listener
   Reports that are sent by the host joining the packet is unicast
   encapsulated group.

7.4.  Responding to each remote node from which the Relay Changes

   When a gateway has received determines that its current relay is unreachable
   (e.g., upon receipt of an IGMPv3/MLDv2 report ICMP Unreachable message [RFC0792] for the packet's (source, group) pair.
   relay's unicast address), it may need to repeat relay address
   discovery.  However, care should be taken not to abandon the current
   relay too quickly due to transient network conditions.

8.  AMT Relay Router Details

8.1.  At Startup time

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

   The relay router shall then advertise the AMT Relay Anycast Prefix
   into the unicast-only Internet, as if it were a connection to an
   external network.  When the advertisement is done using BGP, the AS
   path leading to the AMT Relay Anycast Prefix shall include the
   identifier of the local AS.

   The relay router shall also enable IGMPv3/MLDv2 on the AMT pseudo-
   interface, except that it shall not multicast Queries (this might be
   done, for example, by having the AMT pseudo-device drop them, or by
   having the IGMP/MLD module not send them in the first place).

   Finally, to support sourcing SSM traffic from AMT sites, the AMT
   Subnet Anycast Prefix is assigned to the AMT pseudo-interface, and
   the AMT Subnet Anycast Prefix is injected by the AMT Relay into the
   M-RIB of MBGP.

8.2.  Receiving Relay Discovery messages sent to the Anycast Address

   When a relay receives an AMT Relay Discovery message directed to the
   AMT Relay Anycast Address, it should respond with an AMT Relay
   Advertisement containing its unicast address.  The source and
   destination addresses of the advertisement should be the same as the
   destination and source addresses of the discovery message
   respectively.  Further, the nonce in the discovery message MUST be
   copied into the advertisement message.

8.3.  Receiving Membership Updates from AMT Gateways

   The relay operates passively, sending no periodic IGMP/MLD Queries
   but simply tracking membership information according to AMT Request/
   Query/Membership Update tuples received.  As noted in Section 7.2,
   the Relay tracks Gateways based on the (IP source address, UDP source
   port) tuple.  In addition, the relay must also do explicit membership
   tracking, as to which gateways on the AMT pseudo-interface have
   joined which groups.  Once an AMT Membership Update has been
   successfully received, it updates the forwarding state for the
   appropriate group and source (if provided).  When data arrives for
   that group, the traffic must be encapsulated encapsulated, once to each (address,
   port) of each gateway which has joined that group or (S,G).

   The explicit membership tracking and unicast replication may be done
   in any implementation-specific manner.  Some examples are:

   1.  The AMT pseudo-device driver might track the group information
       and perform the replication at the "link-layer", with no changes
       to a pre-existing IGMP/MLD module.

   2.  The IGMP/MLD module might have native support for explicit
       membership tracking, especially if it supports other NBMA-style
       interfaces.

   If a relay wants to affect the rate at which the AMT Requests are
   originated from a gateway, it can tune the membership timeout by
   adjusting the Querier's Query Interval Code (QQIC) field in the IGMP/
   MLD Query contained within the AMT Membership Query message.  The
   QQIC field is defined in [RFC3376] and [RFC3810].  However, since the
   gateway may need to send AMT Requests frequently enough to prevent
   firewall state from timing out, the relay may be limited in its
   ability to spread out Requests coming from a gateway by adjusting the
   QQIC field.

8.4.  Receiving (S,G) Joins from the Native Side, for AMT Sources

   The relay sends an IGMPv3/MLDv2 report to the AMT source as described
   above in Section 5.1.2

9.  IANA Considerations

9.1.  IPv4 and IPv6 Anycast Prefix Allocation

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

9.1.1.  IPv4

   A prefix length of 16 will meet this requirement.

9.1.2.  IPv6

   A prefix length of 32 will meet this requirement.  IANA has
   previously set aside the range 2001::/16 for allocating prefixes for
   this purpose.

9.2.  IPv4 and IPv6 AMT Subnet Prefix Allocation

   It should also be noted that this prefix length directly affects the
   number of groups available to be created by the AMT gateway: in the
   IPv4 case, a prefix length of 16 gives 256 groups, and a prefix
   length of 8 gives 65536 groups.

   All allocations are a one time effort and there will be no need for
   any recurring assignment after this stage.

9.2.1.  IPv4

   As described above IANA; the
   prefix should be large enough to guarantee advertisement in Section 7.2.1 an the
   default-free BGP networks.

9.1.1.  IPv4

   A prefix with a length of 16 is requested for will meet this purpose.

9.2.2.  IPv6

   As described above in Section 7.2.2 an requirement.

9.1.2.  IPv6

   A prefix with a length of 32 is requested.

9.3. will meet this requirement.  IANA has
   previously set aside the range 2001::/16 for allocating prefixes for
   this purpose.

9.2.  UDP Port number

   IANA has previously allocated UDP reserved port number 2268 for AMT
   encapsulation.

10.  Security Considerations

   The anycast technique introduces a risk that a rogue router or a
   rogue AS could introduce a bogus route to the AMT Relay Anycast
   prefix, and thus divert the traffic.  Network managers have to
   guarantee the integrity of their routing to the AMT Relay Anycast
   prefix in much the same way that they guarantee the integrity of all
   other routes.

   Within the native MBGP infrastructure, there is a risk that a rogue
   router or a rogue AS could inject a false route to the AMT Subnet
   Anycast Prefix, and thus divert joins and cause RPF failures of
   multicast traffic.  As the AMT Subnet Anycast Prefix will be
   advertised by multiple entities, guaranteeing the integrity of this
   shared MBGP prefix is much more challenging than verifying the
   correctness of a regular unicast advertisement.  To mitigate this
   threat, routing operators should configure the BGP sessions to filter
   out any more specific advertisements for the AMT Subnet Anycast
   Prefix.

   Gateways and relays will accept and decapsulate multicast traffic from any
   source from which regular unicast traffic is accepted.  If this is is,
   for any reason reason, felt to be a security risk, then additional source
   address based packet filtering MUST be applied:

   1.  To prevent a rogue sender (that can't do traditional spoofing
       because applied: a gateway MUST
   discard encapsulated multicast packets if the source address in the
   outer header is not the address of the Relay to which the
   encapsulated join message was sent.  AMT Gateways MUST also drop non-
   multicast traffic incoming on an AMT pseudo-interface.

   AMT Relays MUST NOT process AMT Data messages.

   AMT Relays and Gateways MUST drop IP messages encapsulated in AMT
   Query and Update messages that are not IGMP/MLD messages.

   Even though a Relay does not need to maintain any state before
   completion of the three-way handshake (Section 5.2), if no mitigation
   is in place, it is still possible for one host to instantiate a large
   amount of Gateways instances that would each join one or more
   multicast groups to a Relay, thus resulting in a large amount of
   resources being used on the Relay.  Thus, AMT Relays MUST be
   implemented so as to allow the mitigation of e.g. access lists deployed by its ISP) from making use risks of denial of
   service attacks on their resources.  A Relay SHOULD NOT allow the
   instantiation of AMT to send packets to an SSM tree, unbounded number of AMT pseudo-interfaces for a relay that receives an
       encapsulated multicast packet MUST discard the multicast packet
       if the
   said gateway IP source address in the outer header does not match the
       source address that would be extracted using address.  For instance, an implementation may provide
   a way to set a configurable limit on the rules maximum number of
       Section 7.2.

   2.  A pseudo-
   interfaces to a same gateway MUST discard encapsulated multicast packets if IP address, with a default value for
   this limit being low enough to provide protection, and high enough to
   cope with the
       source possibility of an address in being shared by multiple
   devices.

   In the outer header case where a Relay is not reaching the address situation where it would
   stop accepting to which instantiate new pseudo-interfaces, it MAY stop
   advertising the encapsulated join message was sent.  An AMT Gateway that
       receives an encapsulated IGMPv3/MLDv2 (S,G)-Join MUST discard the
       message if the IP destination address in the outer header does
       not match the source address that would be extracted using Relay Anycast address; thanks to the
       rules of Section 7.2. AMT
   discovery procedures, this will allow legitimate AMT Gateways to fall
   back on another Relay.

11.  Contributors

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

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

12.  Acknowledgments

   Most of the mechanisms described in this document are 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.

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

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

   Greg Shepherd suggested the inclusion of the AMT Membership Teardown
   message based on field experience.

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

13.  References

13.1.  Normative References

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

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

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

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

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

   [I-D.ietf-6man-udpchecksums]
              Eubanks, M., "UDP Checksums for Tunneled Packets",
              draft-ietf-6man-udpchecksums-00 (work in progress),
              March 2011.

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

13.2.  Informative References

   [IANA.AFN]
              IANA, "Address Family Numbers", <http://www.iana.org/
              assignments/address-family-numbers/
              address-family-numbers.txt>.

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

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

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

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

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

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

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

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

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

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              January 2007.

Authors' Addresses

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

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

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

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

   Amit Aggarwal
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052-6399
   USA

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

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

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

   Email: pusateri@bangj.com

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

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