Network Working Group                                        Dave                                          D. Thaler
Internet-Draft                                              Mohit                                                 M. Talwar
February 2005                                              Amit Aggarwal
Expires: August 21, 2005 April 23, 2006                                      A. Aggarwal
                                                   Microsoft
                                                        Lorenzo Corporation
                                                             L. Vicisano
                                                           Cisco Systems
                                                            Tom
                                                             T. Pusateri
                                                        Juniper Networks
                                                        October 20, 2005

         Automatic IP Multicast Without Explicit Tunnels (AMT)
		draft-ietf-mboned-auto-multicast-04.txt
                    draft-ietf-mboned-auto-multicast-05

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of RFC 3668. BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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
   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
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 23, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   Automatic Multicast Tunneling (AMT) allows multicast communication
   amongst isolated multicast-enabled sites or hosts, attached to a
   network which has no native multicast support.  It also enables them
   to exchange multicast traffic with the native multicast
   infrastructure (MBone) and does not require 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.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.

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 is 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" [6TO4, ANYCAST] to get automatic IPv6 connectivity.

   Effectively, AMT treats the unicast-only internetwork 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

Table of the same
   multicast packet will take place multiple times by necessity.

   The following problems are addressed: Contents

   1. Allowing isolated sites/hosts to receive the SSM flavor of
      multicast ([SSM]).

   2. Allowing isolated sites/hosts to transmit the SSM flavor of
      multicast.

   3. Allowing isolated sites/hosts to receive general multicast (ISM
      [RFC1112]).

      This document does not address allowing isolated sites/hosts to
      transmit general multicast.  We expect that other solutions (e.g.,
      Tunnel Brokers, a la [BROKER]) will be used for sites that desire
      this capability.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Requirements Terminology

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC-2119]. notation  . . . . . . . . . . . . . . . . . . . .  5
   3.  Definitions

    +---------------+        Internet            +---------------+
    |  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1   AMT Pseudo-Interface . . . . . . . . . . . . . . . . . . .  6
     3.2   AMT Gateway  . . . . . . . . . . . . . . . . . . . . . . .  6
     3.3   AMT Site      |                            | MBone         |
    |               | . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.4   AMT           |               |
    |        +------+----+ Relay    +----+----+ AMT      |
    |        |AMT Gateway|         Anycast  |AMT Relay| Subnet   |
    |        |     +-----+-+       Prefix +-+-----+   | Prefix   |
    |        |     |AMT IF |     <--------|AMT IF |   |--------> |
    |        |     +-----+-+              +-+-----+   |          |
    |        +------+----+                  +----+----+          |
    |               |                            |               |
    +---------------+                            +---------------+

               Figure 1: Automatic Multicast Definitions. Router . . . . . . . . . . . . . . . . . . . . .  6
     3.5   AMT Pseudo-Interface Relay Anycast Prefix . . . . . . . . . . . . . . . . .  7
     3.6   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. Relay Anycast Address  . . . . . . . . . . . . . . . .  7
     3.7   AMT Gateway
      A host, or a site gateway router, supporting an Unicast Autonomous System ID . . . . . . . . . . . . .  7
     3.8   AMT 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". Subnet Prefix  . . . . . . . . . . . . . . . . . . . .  7
     3.9   AMT Site
      A multicast-enabled network not connected to the multicast
      backbone served by an Gateway Anycast Address  . . . . . . . . . . . . . . .  7
     3.10  AMT Gateway.  It could also be a stand-
      alone AMT Gateway.

   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 internetwork, and an AMT pseudo-interface.
      It is simply referred to in this document as a "relay".

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

   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.

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

      This address corresponds to the lowest address in the AMT Relay
      Anycast Prefix.

   AMT Unicast Multicast Autonomous System ID
      A 16-bit Autonomous System ID, for use in BGP . . . . . . . . . . . .  8
   4.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.1   Receiving Multicast in accordance to
      this memo.  AS 10888 might be usable for this, but for now we'll
      assume it's different, to avoid confusion.  This number represents
      a "pseudo-AS" common to all AMT relays using the well known AMT
      Relay Anycast Prefix (private relays use their own ID).

      To protect themselves from erroneous advertisements, managers of
      border routers often use databases to check the relation between
      the advertised network and the last hop in the AS path.
      Associating a specific AS number with the AMT Relay Anycast
      Address allows us to enter this relationship in the databases used
      to check inter-domain routing [ANYCAST].

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

   AMT Gateway Anycast Address
      An anycast address in the AMT Subnet Prefix range, which is used
      by an AMT Gateway to enable sourcing SSM traffic Site . . . . . . . . . . . .  9
       4.1.1   Scalability Considerations . . . . . . . . . . . . . . 10
       4.1.2   Spoofing Considerations  . . . . . . . . . . . . . . . 10
     4.2   Sourcing Multicast from local
      applications. an AMT site  . . . . . . . . . . . 11
       4.2.1   Supporting Site-MBone Multicast Autonomous System ID
      A 16-bit Autonomous system ID, for use in MBGP in accordance to
      this memo. This number represents a "pseudo-AS" common to all AMT
      relays using the well known AMT Subnet Prefix (private relays use
      their own ID). We assume that the existing AS 10888 is suitable
      for this purpose.  (Note: if this is a problem, a different one
      would be fine.)

4.  Overview

4.1.  Receiving  . . . . . . . . . . . 12
       4.2.2   Supporting Site-Site Multicast in an AMT Site

                               Internet
    +---------------+                            +---------------+
    | . . . . . . . . . . . . 12
   5.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . . 14
     5.1   AMT Site      |     2. 3-way Membership    | MBone         |
    |               |          Handshake         |               |
    |   1. Join +---+---+ =================> +---+---+           |
    |     +---->|Gateway|                    | Relay |           |
    |     |     +---+---+ <================= +---+---+           |
    |   R-+         |       3. Receive Data      |               |
    +---------------+                            +---------------+

             Figure 2: Receiving Multicast in an AMT Site.

   AMT relays and gateways cooperate to transmit multicast traffic
   sourced within the native multicast infrastructure to Discovery  . . . . . . . . . . . . . . . . . . . 14
       5.1.1   Type . . . . . . . . . . . . . . . . . . . . . . . . . 14
       5.1.2   Reserved . . . . . . . . . . . . . . . . . . . . . . . 14
       5.1.3   Discovery Nonce  . . . . . . . . . . . . . . . . . . . 14
     5.2   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.  To work across NAT's, the encapsulation is done over UDP
   using the IANA reserved AMT port number.

   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 [IGMPv3/MLDv2] protocol, and the PIM-
   Sparse Mode [PIMSM] protocol.  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 5 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.

4.1.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 an anycast address to
   relays.  However, simply sending periodic membership reports to the
   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 allows the gateways to be spread out
   among more relays so as to keep the number of gateways per relay at a
   reasonable level.

4.1.2.  Spoofing Considerations

   An attacker could affect the group state in the relay or gateway by
   spoofing the source address in the join or leave reports. This can be
   used to launch reflection or denial of service attacks on the target.
   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 Relay Advertisement  . . . . . . . . . . . . . . . . . 14
       5.2.1   Type . . . . . . . . . . . . . . . . . . . . . . . . . 15
       5.2.2   Reserved . . . . . . . . . . . . . . . . . . . . . . . 15
       5.2.3   Discovery Nonce  . . . . . . . . . . . . . . . . . . . 15
       5.2.4   Relay Address  . . . . . . . . . . . . . . . . . . . . 15
     5.3   AMT Request with a request nonce in it. The receiving side
   (the respondent) can calculate a message authentication code (MAC)
   based on the source IP address of the Request, the source UDP port,
   the request nonce, and a secret key known only to the respondent.
   The algorithm used to calculate the MAC does not have to be
   standardized since the respondent generates and verifies the  . . . . . . . . . . . . . . . . . . . . . . . 15
       5.3.1   Type . . . . . . . . . . . . . . . . . . . . . . . . . 16
       5.3.2   Reserved . . . . . . . . . . . . . . . . . . . . . . . 16
       5.3.3   Request Nonce  . . . . . . . . . . . . . . . . . . . . 16
     5.4   AMT Membership Query . . . . . . . . . . . . . . . . . . . 16
       5.4.1   Type . . . . . . . . . . . . . . . . . . . . . . . . . 17
       5.4.2   Reserved . . . . . . . . . . . . . . . . . . . . . . . 17
       5.4.3   Response MAC and
   the originator simply echoes it.

   An . . . . . . . . . . . . . . . . . . . . . 17
       5.4.4   Request Nonce  . . . . . . . . . . . . . . . . . . . . 17
     5.5   AMT Membership Query is sent back including the request nonce and
   the MAC to the originator of the Request. The originator then sends
   the IGMP/MLD Membership/Listener Report or Leave/Done along with the
   request nonce and the received MAC back to the respondent finalizing
   the 3-way handshake.

   Upon reception, the respondent can recalculate the Update  . . . . . . . . . . . . . . . . . . 17
       5.5.1   Type . . . . . . . . . . . . . . . . . . . . . . . . . 18
       5.5.2   Reserved . . . . . . . . . . . . . . . . . . . . . . . 18
       5.5.3   Response MAC based on the
   source IP address, the source . . . . . . . . . . . . . . . . . . . . . 18
       5.5.4   Request Nonce  . . . . . . . . . . . . . . . . . . . . 18
     5.6   AMT Multicast Data . . . . . . . . . . . . . . . . . . . . 18
       5.6.1   Type . . . . . . . . . . . . . . . . . . . . . . . . . 19
       5.6.2   Reserved . . . . . . . . . . . . . . . . . . . . . . . 19
       5.6.3   UDP port, the request nonce, and the
   local secret. The IGMP/MLD message is only accepted if the received
   MAC matches the calculated MAC.

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

4.2.  Sourcing Multicast from an AMT site

   Two cases are discussed below: multicast traffic sourced in an AMT
   site and received in the MBone, and multicast traffic sourced in an
   AMT site and received in another Data . . . . . . . . . . . . . . . . . . 19
   6.  AMT site.

   In both cases only SSM sources are supported.  Furthermore this
   specification only deals Gateway Details  . . . . . . . . . . . . . . . . . . . . . 20
     6.1   At Startup Time  . . . . . . . . . . . . . . . . . . . . . 20
     6.2   Joining Groups with the source residing directly in the
   gateway.  To enable a generic node in an AMT site to source
   multicast, additional coordination between the gateway and the
   source-node is required.

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

   1. Applications residing in the gateway use addresses in the AMT
      Subnet Prefix MBone Sources  . . . . . . . . . . . . 20
     6.3   Responding to send multicast, as a result of sourcing traffic
      on the AMT pseudo-interface.

   2. The Relay Changes  . . . . . . . . . . . . . . . 21
     6.4   Creating SSM groups  . . . . . . . . . . . . . . . . . . . 22
     6.5   Joining SSM Groups with AMT Subnet 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 Sources  . . . . . . . . . . . 22
     6.6   Receiving IGMPv3/MLDv2 Reports at the gateway (source) Gateway  . . . . . . 22
     6.7   Sending data to which SSM groups . . . . . . . . . . . . . . . . 23
   7.  Relay Router Details . . . . . . . . . . . . . . . . . . . . . 24
     7.1   At Startup time  . . . . . . . . . . . . . . . . . . . . . 24
     7.2   Receiving Relay Discovery messages sent to encapsulate the join (see Section
      5 for more details). The membership reports use Anycast
           Address  . . . . . . . . . . . . . . . . . . . . . . . . . 24
     7.3   Receiving Membership Updates from AMT Gateways . . . . . . 24
     7.4   Receiving (S,G) Joins from the same three way
      handshake as outlined in Section 4.1.2.

4.2.1.  Supporting Site-MBone Multicast

                                Internet
    +---------------+                            +---------------+
    | Native Side, for AMT Site      |     2. 3-way Membership    | MBone         |
    |               |           Handshake        |               |
    |           +---+---+ <================= +---+---+
           Sources  . . . . . . . . . . . . . . . . . . . . . . . . . 25
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
   10.   Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
   11.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 29
   12.   References . . . . . . . . . . . . . . . . . . . . . . . . . 30
     12.1  Normative References . . . . . . . . . . . . . . . . . . . 30
     12.2  Informative References . . . . . . . . . . . . . . . . . . 30
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 31
       Intellectual Property and Copyright Statements . . . . . . . . 33

1. Join   |
    |           |Gateway|                    | Relay |<-----+    |
    |           +---+---+ =================> +---+---+      |    |
    |               |      3. Receive Data       |          +-R  |
    +---------------+                            +---------------+

                    Figure 3: Site-MBone Multicast.

   If a relay receives an explicit join from  Introduction

   The primary goal of this document is to foster the deployment of
   native infrastructure,
   for IP multicast by enabling a given (source, group) pair where the source address belongs potentially large number of nodes
   to connect to the AMT Subnet Prefix, then the relay will periodically (using already present multicast infrastructure.
   Therefore, the
   rules specified techniques discussed here should be viewed as an
   interim solution to help in Section 4.1.2) encapsulate membership updates for the group to various stages of the gateway.  The gateway must keep state per relay from
   which membership reports have been sent, and forward transition to a
   native multicast
   traffic from network.

   To allow fast deployment, the site solution presented here only requires
   small and concentrated changes to all relays from which membership reports
   have been received.  The choice of whether this state the network infrastructure, and replication
   is done no
   changes at the link-layer (i.e., by the tunnel interface) all to user applications or at to the
   network-layer is implementation dependent.

   If there are multiple relays present, socket API of end-
   nodes' operating systems.  The protocol introduced in this ensures
   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 data from 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 site is received via treats the closest relay to unicast-only internetwork as a large non-
   broadcast multi-access (NBMA) link layer, over which we require the receiver. This is
   necessary when
   ability to multicast.  To do this, multicast packets being sent to or
   from a site must be encapsulated in unicast packets.  If the routers group
   has members in multiple sites, AMT encapsulation of the native same
   multicast infrastructure
   employ Reverse-Path Forwarding (RPF) checks against the source
   address, such as occurs when [PIMSM] is used packet will take place multiple times by the multicast
   infrastructure. necessity.

   The solution above will scale following problems are addressed:

   1.  Allowing isolated sites/hosts to an arbitrary number receive the SSM flavor of relays, as
   long at
       multicast ([I-D.ietf-ssm-arch]).

   2.  Allowing isolated non-NAT sites/hosts to transmit the number SSM flavor
       of relays requiring multicast.

   3.  Allowing isolated sites/hosts to receive general multicast traffic from (ASM
       [RFC1112]).

   This document does not address allowing isolated sites/hosts to
   transmit general multicast.  We expect that other solutions (e.g.,
   Tunnel Brokers, a given
   AMT la [RFC3053]) will be used for sites that desire
   this capability.

   Implementors should be aware that site remains reasonable enough administrators may have
   configured administratively scoped multicast boundaries and a remote
   gateway may provide a means to not overly burden circumvent administrative boundaries.
   Therefore, implementations should allow for the site's
   gateway.

4.2.2.  Supporting Site-Site Multicast

                               Internet configuration of such
   boundaries on relays and gateways and perform filtering as needed.

2.  Requirements notation

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

3.  Definitions

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

                     Figure 4: Site-Site Multicast.

   Since

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

3.2  AMT Gateway

   A host, or a site gateway router, supporting an AMT 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".

3.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 AMT
   Gateway.

3.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 internetwork, and an AMT pseudo-interface.  It is
   simply referred to in this document as a "relay".

   As with [RFC3056], we require gateways assume that normal multicast routers do not
   want to accept membership reports, be tunnel endpoints (especially if this results in high
   fanout), and similarly that service providers do not want
   encapsulation to arbitrary routers.  Instead, we assume that special-
   purpose routers will be deployed that are suitable for serving 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

3.5  AMT Relay Anycast Prefix

   A well-known address belongs prefix used to advertise (into the AMT Subnet Prefix, then the gateway
   will periodically unicast encapsulate an IGMPv3/MLDv2 [IGMPv3/MLDv2]
   Report directly to the site gateway for the source.

   We note that this can result in a significant amount of state at
   routing infrastructure) a
   site gateway sourcing multicast route to a large number of other an available AMT sites.
   However, it is expected that this is Relay Router.
   This could also be private (i.e., not unreasonable well-known) for two
   reasons.  First, the gateway does not have native multicast
   connectivity, a private
   relay.

   Prefixes for both IPv4 and as IPv6 will be assigned in a result is likely doing unicast replication at
   present.  The amount future version
   of state this draft.

3.6  AMT Relay Anycast Address

   An anycast address which is thus used to reach the same as what such nearest AMT Relay
   Router.

   This address corresponds to the lowest address in the AMT Relay
   Anycast Prefix.

3.7  AMT Unicast Autonomous System ID

   A 16-bit Autonomous System ID, for use in BGP in accordance to this
   memo.  This number represents a site
   already deals with. Secondly, any site expecting "pseudo-AS" common to source traffic all AMT relays
   using the well known AMT Relay Anycast Prefix (private relays use
   their own ID).

   To protect themselves from erroneous advertisements, managers of
   border routers often use databases to check the relation between the
   advertised network and the last hop in the AS path.  Associating a large
   specific AS number of sites could get a point-to-point tunnel to with the
   native multicast infrastructure, and use that instead of AMT.

5.  Message Formats

5.1.  AMT Relay Discovery

   The AMT Relay Discovery message is a UDP packet sent from Anycast Address allows us to
   enter this relationship in the databases used to check inter-domain
   routing [RFC3068].

3.8  AMT
   gateway unicast Subnet Prefix

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

3.9  AMT Gateway Anycast Address

   An anycast address to discover in the unicast address of an AMT relay.

   The UDP source port Subnet Prefix range, which is uniquely selected used by the
   an AMT Gateway to enable sourcing SSM traffic from local host operating
   system. The UDP destination port is the IANA reserved
   applications.

3.10  AMT port
   number.

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

   Fields:

   Type
      The type of the message.

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

   Discovery Nonce Multicast Autonomous System ID

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

5.2.  AMT Relay Advertisement

   The AMT Relay Advertisement message is 16-bit Autonomous system ID, for use in MBGP in accordance to this
   memo.  This number represents a UDP packet sent from the AMT
   relay anycast address "pseudo-AS" common to the source of the discovery message.

   The UDP source port is the IANA reserved all AMT port number and the UDP
   destination port is relays
   using the source port received well known AMT Subnet Prefix (private relays use their own
   ID).

4.  Overview

4.1  Receiving Multicast in the Discovery
   message.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ an AMT Site

                               Internet
    +---------------+                            +---------------+
    |     Type=0x2 AMT Site      |     Reserved     2. 3-way Membership    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MBone         |            Discovery Nonce
    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |            Relay Address          Handshake         |               |
    |   1. Join +---+---+ =================> +---+---+           |
    |     +---->|Gateway|                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Fields:

   Type
      The type of the message.

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

   Discovery Nonce
      A 32-bit random value replayed from the discovery message. Relay Address
      The unicast IPv4 or IPv6 address of |           |
    |     |     +---+---+ <================= +---+---+           |
    |   R-+         |       3. Receive Data      |               |
    +---------------+                            +---------------+

   AMT relays and gateways cooperate to transmit multicast traffic
   sourced within the native multicast infrastructure to AMT relay. The family can
      be determined by sites:
   relays receive the length of traffic natively and unicast-encapsulate it to
   gateways; gateways decapsulate the traffic and possibly forward it
   into the Advertisement.

5.3. AMT Request

   A Request packet is sent to begin a 3-way handshake for sending site.

   Each gateway has an
   IGMP/MLD Membership/Listener Report or Leave/Done. It can be sent
   from AMT pseudo-interface that serves as a gateway default
   multicast route.  Requests to join a relay, from a gateway multicast session are sent to another gateway, or from
   a relay
   this interface and encapsulated to a gateway.

   It is sent from particular relay reachable
   across the originator's unique unicast address 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
   respondents' unique unicast address. relay.  The UDP source port AMT recipient-list is uniquely selected by the local host operating
   system. It can be different determined for each Request and different from
   multicast session.  This requires the
   source port used in Discovery messages but does not have relay to be.  The
   UDP destination port is keep state for each
   gateway which has joined a particular group or (source, group) pair).
   Multicast packets from the IANA reserved AMT port number.

   Fields:

   Type
      The type of native infrastructure behind the 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=0x3  |     Reserved                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Request Nonce                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

5.4.  AMT Membership Query

   An AMT Membership Query packet is relay
   will be sent from to each gateway which has requested them.

   All multicast packets (data and control) are encapsulated in unicast
   packets.  To work across NAT's, the relay back to encapsulation is done over UDP
   using the
   originator to solicit an IANA reserved AMT Membership Update while confirming port number.

   Each relay, plus the
   source set of all gateways using the original request. It contains relay, together
   are thought of as being on a relay Message
   Authentication Code (MAC) separate logical NBMA link.  This
   implies that the AMT recipient- list is a cryptographic hash list of a private
   secret, the originators "link layer"
   addresses which are (IP address, and UDP port) pairs.

   Since the request nonce.

   It 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 sent from the destination address received in the Request required for gateways to
   the source address received in the Request. communicate
   group membership information to a relay.  The UDP source port is two most likely
   candidates are the IANA reserved AMT port number IGMP/MLD [RFC3376] [RFC3810] protocol, and the UDP
   destination port is the source port received
   PIM-Sparse Mode [I-D.ietf-pim-sm-v2-new] protocol.  Since an AMT
   gateway may be a host, and hosts typically do not implement routing
   protocols, gateways will use IGMP/MLD as described in the Request 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 Section 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type=0x4  |    Reserved   |         Response MAC          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Response MAC (continued)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Request Nonce                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Fields:

   Type
      The type of
   below.  This allows a host kernel (or a pseudo device driver) to
   easily implement AMT gateway behavior, and obviates the message.

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

   Response MAC
      A 48-bit hash generated by relay from
   the respondent and sent need to know whether a given gateway is a host or a router.  From
   the
      originator for inclusion in the relay's perspective, all gateways are indistinguishable from
   hosts on an NBMA leaf network.

4.1.1  Scalability Considerations

   It is possible that millions of hosts will enable AMT Membership Update. The
      algorithm used for this gateway
   functionality and so an important design goal is chosen by not to create
   gateway state in each relay until the respondent. One algorithm gateway joins a multicast
   group.  But even the requirement that could a relay keep group state per
   gateway that has joined a group introduces potential scalability
   concerns.

   Scalability of AMT can be used achieved by adding more relays, and using
   an appropriate relay discovery mechanism for gateways to discover
   relays.  The solution we adopt is HMAC-MD5-48 [HMAC].

   Request Nonce
      A 32-bit identifier used to distinguish this request echoed back assign an anycast address to
   relays.  However, simply sending periodic membership reports to the originator.

5.5.  AMT Membership Update

   An AMT Membership Update is sent from
   anycast address can cause duplicates.  Specifically, if routing
   changes such that a different relay receives a periodic membership
   report, both the originator new and old relays will encapsulate data to the
   respondent containing AMT
   site until the original IGMP/MLD Membership/Listener
   Report or Leave/Done received over old relay's state times out.  This is obviously
   undesirable.  Instead, we use the AMT pseudo-interface.  It
   echoes anycast address merely to find the
   unicast address of a relay to which membership reports are sent.

   Since adding another relay has the Response MAC received in result of adding another
   independent NBMA link, this allows the AMT Membership Query gateways to be spread out
   among more relays so the
   respondent can verify return routability as to keep the originator.

   It is sent from number of gateways per relay at a
   reasonable level.

4.1.2  Spoofing Considerations

   An attacker could affect the destination address received group state in the Query to relay or gateway by
   spoofing the source address received in the Query which should both join or leave reports.  This can
   be used to launch reflection or denial of service attacks on the same as
   the original Request.

   The UDP source and destination port numbers should
   target.  Such attacks can be mitigated by using a three way handshake
   between the same ones
   sent in gateway and the original Request.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type=0x5  |    Reserved   |         Response MAC          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Response MAC (continued)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 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 Nonce                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            IGMP/MLD Message                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            ...                                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Fields:

   Type with a request nonce in it.  The type of the message.

   Reserved
      An 8-bit reserved field. Sent as 0, ignored receiving side
   (the respondent) can calculate a message authentication code (MAC)
   based on receipt.

   Response MAC
      The 48-bit MAC received in (for example) the Membership Query source IP address of the Request, the
   source UDP port, the request nonce, and echoed back in a secret key known only to
   the Membership Update.

   Request Nonce
      A 32-bit identifier respondent.  The algorithm and the input used to distinguish this request.

5.6.  AMT Multicast Data

   The AMT Data message is a UDP packet encapsulating calculate the data requested
   by
   MAC does not have to be standardized since the respondent generates
   and verifies the MAC and the originator based on a previous simply echoes it.

   An AMT Membership Update message.

   It Query is sent from back including the unicast destination address of request nonce and
   the Membership
   update MAC to the source address originator of the Membership Update. Request.  The UDP source originator then sends
   the IGMP/MLD Membership/Listener Report or Leave/Done along with the
   request nonce and destination port numbers should be the same ones
   sent in received MAC back to the original Query.

   The payload of respondent finalizing
   the UDP packet contains 3-way handshake.

   Upon reception, 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                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Multicast Data                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            ...                                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Fields:

   Type
      The type of respondent can recalculate the message.

   Reserved
      A 24-bit reserved field. Sent as 0, ignored MAC based on receipt. the
   source IP address, the source UDP Multicast Data port, the request nonce, and the
   local secret.  The original Multicast UDP data packet that IGMP/MLD message is being replicated by only accepted if the relay to received
   MAC matches the gateways.

6.  AMT Gateway Details

   This section details calculated MAC.

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

4.2  Sourcing Multicast from an AMT Gateway, which may be a
   router serving site

   Two cases are discussed below: multicast traffic sourced in an AMT site, or the
   site may consist of a single host,
   serving as its own gateway.

6.1.  At Startup Time

   At startup time, and received in the AMT gateway will bring up MBone, and multicast traffic sourced in an
   AMT pseudo-
   interface, to be used for encapsulation.  The gateway will then send
   a site and received in another AMT Relay Discovery message to site.

   In both cases only SSM sources are supported.  Furthermore this
   specification only deals with the AMT Relay Anycast Address, and
   note source residing directly in the unicast address (which is treated as
   gateway.  To enable a link-layer address to
   the encapsulation interface) from the generic node in an AMT Relay Advertisement
   message.  This discovery should be done periodically (e.g., once a
   day) site to re-resolve source
   multicast, additional coordination between the unicast address of a close relay.  The gateway
   also initializes a timer used to send periodic membership reports to
   a random value from the interval [0, [Query Interval]] before sending and the first periodic report, in order
   source-node is required.

   The general mechanism used to prevent startup
   synchronization (e.g., after a power outage).

   If the gateway join towards AMT sources is serving as a local router, it SHOULD also function
   as an IGMP/MLD Proxy, as described based on
   the following:

   1.  Applications residing in the gateway use addresses in [PROXY], with its IGMP/MLD
   host-mode interface being the AMT pseudo-interface.  This enables it
       Subnet Prefix to translate group memberships on its downstream interfaces into
   IGMP/MLD Reports.  The gateway MUST also advertise itself send multicast, as a result of sourcing traffic
       on the
   default route AMT pseudo-interface.

   2.  The AMT Subnet Prefix is advertised for multicast RPF reachability in the
       M-RIB (or it must be the default
   unicast router if unicast by relays and multicast topologies are congruent).
   Also, if gateways.

   3.  Relays or gateways that receive a shared tree routing protocol is used inside the AMT site,
   each tree-root must be join for a gateway, e.g., source/group pair
       use information encoded in PIM-SM each RP must be a
   gateway.

   Finally, the address pair to support sourcing traffic rebuild the
       address of the gateway (source) to SSM groups by which to encapsulate the join
       (see Section 5 for more details).  The membership reports use the
       same three way handshake as outlined in Section 4.1.2.

4.2.1  Supporting Site-MBone Multicast

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

   If a gateway with relay receives an explicit join from the native infrastructure,
   for a global unicast address, given (source, group) pair where the source address belongs to
   the AMT Subnet Prefix is treated as Prefix, then the relay will periodically (using the
   rules specified in Section 4.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
   subnet prefix site to all relays from which membership reports
   have been received.  The choice of the AMT pseudo-interface, whether this state and an anycast address replication
   is
   added on done at the interface.  This anycast address is formed link-layer (i.e., by
   concatenating the AMT Subnet Prefix followed by tunnel interface) or at the high bits of
   network-layer is implementation dependent.

   If there are multiple relays present, this ensures that data from the
   gateway's global unicast address.  For example, if IANA assigns
   AMT site is received via the
   IPv4 prefix x.y/16 as closest relay to the AMT Subnet Prefix, and receiver.  This is
   necessary when the gateway has
   global unicast address a.b.c.d, then routers in the AMT Gateway's Anycast
   Address will be x.y.a.b.  Note that multiple gateways might end up
   with native multicast infrastructure
   employ Reverse-Path Forwarding (RPF) checks against the same anycast address assigned to their pseudo-interfaces.

6.2.  Joining Groups with MBone Sources

   The IGMP/MLD protocol usually operates source
   address, such as occurs when [PIMSM] is used by having the Querier multicast
   infrastructure.

   The solution above will scale to an IGMP/MLD Query message on arbitrary number of relays, as
   long at the link.  This behavior does
   not work on NBMA links which do number of relays requiring multicast traffic from a given
   AMT site remains reasonable enough to not support multicast. overly burden the site's
   gateway.

4.2.2  Supporting Site-Site Multicast

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

   Since the set
   of we require gateways is typically unknown to the relay (and potentially quite
   large), unicasting the queries accept membership reports, as described
   above, it is also impractical.  The following
   behavior is used instead.

   Applications residing in possible to support multicast among AMT sites,
   without requiring assistance from any relays.

   When a gateway should join groups on the AMT
   pseudo-interface, causing IGMP/MLD Membership/Listener Reports wants to be
   sent over that interface.  When UDP encapsulating the membership
   reports (and in fact any other messages, unless specified otherwise
   in this document), join a given (source, group) pair, where the destination
   source address in belongs to the outer IP header is AMT Subnet Prefix, then the relay's gateway
   will periodically unicast address.  Robustness is provided by encapsulate an IGMPv3/MLDv2 [RFC3376]
   [RFC3810] Report directly to the
   underlying IGMP/MLD protocol messages sent on site gateway for the AMT pseudo-
   interface. In 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 words, AMT sites.
   However, it is expected that this is not unreasonable for two
   reasons.  First, the gateway does not need to retransmit
   IGMP/MLD Membership/Listener Reports have native multicast
   connectivity, and Leave/Done messages received
   on as a result is likely doing unicast replication at
   present.  The amount of state is thus the pseudo-interface since IGMP/MLD will same as what such a site
   already do this.  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 deals with.  Secondly, any site expecting to IGMP/MLD Queries, some mechanism source traffic
   to trigger periodic
   Membership/Listener Reports a large number of sites could get a point-to-point tunnel to the
   native multicast infrastructure, and Leave/Done messages are necessary.
   This can be achieved in any implementation-specific manner.  Some
   possibilities include:

   1. use that instead of AMT.

5.  Message Formats

5.1  AMT Relay Discovery

   The AMT pseudo-interface might periodically manufacture
      IGMPv3/MLDv2 Queries as if they had been received Relay Discovery message is a UDP packet sent from an IGMP/MLD
      Querier, and deliver them to the IP layer, after which normal
      IGMP/MLD behavior will cause the appropriate reports AMT
   gateway unicast address to be sent.

   2. The IGMP/MLD module itself might provide an option the AMT relay anycast address to operate in
      periodic mode on specific interfaces.

   If discover
   the gateway unicast address of an AMT relay.

   The UDP source port is behind a firewall device, uniquely selected by the firewall may require local host operating
   system.  The UDP destination port is the gateway to periodically refresh IANA reserved AMT port
   number.

   The payload of the UDP state in packet contains the firewall at
   a shorter interval than 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                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Fields:

5.1.1  Type

   The type of the standard IGMP/MLD Query interval.
   Therefore, this IGMP/MLD Query interval should be configurable to
   ensure message.

5.1.2  Reserved

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

5.1.3  Discovery Nonce

   A 32-bit random value generated by the firewall does not revert to blocking gateway and replayed by the UDP encapsulated
   multicast data packets.

6.3.  Responding to
   relay.

5.2  AMT Relay Changes

   When a gateway determines that its current relay Advertisement

   The AMT Relay Advertisement message is unreachable
   (e.g., upon receipt of a ICMP Unreachable message [ICMP] for UDP packet sent from the
   relay's unicast address), it may need to repeat AMT
   relay anycast address
   discovery.  However, care should be taken not to abandon the current
   relay too quickly due to transient network conditions. Some
   implementations may find it difficult to send a discovery packet to the anycast relay address while source of the gateway has an address configured
   on discovery message.

   The UDP source port is the IANA reserved AMT pseudo-interface on port number and the same anycast prefix. Therefore, it
   may be necessary to tear down UDP
   destination port is the AMT pseudo-interface to rediscover
   a new relay.

6.4.  Creating SSM groups

   When a gateway wants to create an SSM group (i.e., in 232/8) for
   which it can source traffic, port received in the remaining 24 bits MUST be generated
   as described below.  ([SSM] states that "the policy for allocating
   these bits is strictly locally determined at Discovery
   message.

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

   Fields:

5.2.1  Type

   The type of the sender's host.")

   When message.

5.2.2  Reserved

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

5.2.3  Discovery Nonce

   A 32-bit random value generated by the gateway determined its AMT Gateway Anycast Address as
   described above, it used and replayed by the high bits of its global unicast address.
   relay.

5.2.4  Relay Address

   The remaining bits of its global unicast IPv4 or IPv6 address are appended to of the
   232/8 prefix, and any spare bits may AMT relay.  The family can be allocated using any policy
   (again, strictly locally
   determined at by the sender's host).

   For example, if length of the IPv4 Advertisement.

5.3  AMT Subnet Prefix Request

   A Request packet is x.y/16, and sent 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 device
   has global originator's unique unicast address a.b.c.d, then it MUST allocate IPv4 SSM
   groups to the
   respondents' 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 port number.

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

   Fields:

5.3.1  Type

   The type of the range 232.c.d/24.

6.5.  Joining SSM Groups with message.

5.3.2  Reserved

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

5.3.3  Request Nonce

   A 32-bit identifier used to distinguish this request.

5.4  AMT Sources Membership Query

   An IGMPv3/MLDv2 Report for a given (source, group) pair MAY be
   encapsulated directly AMT Membership Query packet is sent from the relay back to the source, when
   originator to solicit an AMT Membership Update while confirming the
   source address belongs
   to of the AMT Subnet Prefix.

   The "link-layer" address to use as 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
   outer IP header is obtained as follows.  The Request to
   the source address received in the
   inclusion list of Request.

   The UDP source port is the IGMPv3/MLDv2 report will be an IANA reserved AMT Gateway
   Anycast Address with the high bits of the address, port number and the remaining
   bits will be UDP
   destination port is the source port received in the middle Request 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=0x4  |    Reserved   |         Response MAC          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Response MAC (continued)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Request Nonce                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Fields:

5.4.1  Type

   The type of the group address.

   For example, if the IPv4 AMT Subnet Prefix is x.y/16, message.

5.4.2  Reserved

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

5.4.3  Response MAC

   A 48-bit hash generated by the respondent and sent to the IGMPv3
   Report is originator
   for (x.y.a.b, 232.c.d.e), then inclusion in the "link layer" IPv4
   destination address AMT Membership Update.  The algorithm used for encapsulation
   this is a.b.c.d.

6.6.  Receiving IGMPv3/MLDv2 Reports at chosen by the Gateway

   When an AMT respondent.  One algorithm that could be used
   is HMAC-MD5-48 [RFC2104].

5.4.4  Request Nonce

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

5.5  AMT Membership Update

   An AMT Membership Update is received by sent from the gateway, it follows originator to the same
   3-way handshake procedure a relay would follow if it
   respondent containing the original IGMP/MLD Membership/Listener
   Report or Leave/Done received over the AMT
   Request. pseudo-interface.  It generates a
   echoes the Response MAC and responds with an AMT Membership
   Query. When received in the AMT Membership Update Query so the
   respondent can verify return routability to the originator.

   It is received, it verifies sent from the
   MAC and then processes destination address received in the IGMP/MLD Membership/Listener Report or
   Leave/Done.

   At Query to the gateway,
   source address received in the IGMP/MLD packet Query which should both be an IGMPv3/MLDv2 source
   specific (S,G) join or leave.

   If S is not the AMT Gateway Anycast Address, same as
   the packet is dropped.
   If G does not contain original Request.

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

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type=0x5  |    Reserved   |         Response MAC          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Response MAC (continued)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Request Nonce                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            IGMP/MLD Message                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            ...                                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Fields:

5.5.1  Type

   The type of the global unicast address (as
   described above), the packet is also dropped. message.

5.5.2  Reserved

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

5.5.3  Response MAC

   The gateway adds the source address (from 48-bit MAC received in the outer IP header) Membership Query and
   UDP port of echoed back in
   the report Membership Update.

5.5.4  Request Nonce

   A 32-bit identifier used to a membership list for G.  Maintaining distinguish this
   membership list may be done in any implementation-dependent manner.
   For example, it might be maintained by the "link-layer" inside the request.

5.6  AMT pseudo-interface, making it invisible to the normal IGMP/MLD
   module.

6.7.  Sending data to SSM groups

   When multicast packets are sent on the Multicast Data

   The AMT pseudo-interface, they are
   encapsulated as follows.  If the group address is not an SSM group,
   then the packet Data message is dropped (this memo does not currently provide a
   way to send to non-SSM groups).

   If the group address is an SSM group, then the UDP packet is unicast
   encapsulated to each remote node from which the gateway has received
   an IGMPv3/MLDv2 report for the packet's (source, group) pair.

7.  Relay Router Details

7.1.  At Startup time

   At startup time, encapsulating the relay router will bring up an NBMA-style AMT
   pseudo-interface.  It shall also add data requested
   by the AMT Relay Anycast Address originator based 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 previous AMT Membership Update message.

   It is sent from the advertisement is done using BGP, unicast destination address of the AS
   path leading Membership
   update to the AMT Relay Anycast Prefix shall include the
   identifier source address of the local AS Membership Update.

   The UDP source and destination port numbers should be the AMT Unicast Autonomous System ID. same ones
   sent in the original Query.

   The relay router shall also enable IGMPv3/MLDv2 on payload of the AMT pseudo-
   interface, except that it shall not multicast Queries (this might be
   done, for example, by having UDP packet contains the AMT pseudo-device drop them, or by
   having 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                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Multicast Data                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            ...                                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Fields:

5.6.1  Type

   The type of the IGMP/MLD module not send them in message.

5.6.2  Reserved

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

5.6.3  UDP Multicast Data

   The original Multicast UDP data packet that is being replicated by
   the first place).

   Finally, relay to support sourcing SSM traffic from AMT sites, the gateways.

6.  AMT
   Subnet Prefix is assigned to Gateway Details

   This section details the behavior of an AMT pseudo-interface, and the Gateway, which may be a
   router serving an AMT
   Subnet Prefix is injected into site, or the M-RIB site may consist of MBGP.

7.2.  Receiving Relay Discovery messages sent to the Anycast Address

   When a relay receives a single host,
   serving as its own gateway.

6.1  At Startup Time

   At startup time, the AMT gateway will bring up an AMT pseudo-
   interface, to be used for encapsulation.  The gateway will then send
   an AMT Relay Discovery message directed to the AMT Relay Anycast Address, it should respond with a AMT Relay
   Advertisement containing its unicast address.  The source and
   destination addresses of the advertisement should be
   note the same unicast address (which is treated as a link-layer address to
   the
   destination and source addresses of the discovery message
   respectively. Further, the nonce in encapsulation interface) from the AMT Relay Advertisement
   message.  This discovery message MUST SHOULD be
   copied into done periodically (e.g., once a
   day) to re-resolve the advertisement message.

7.3.  Receiving Membership Updates from AMT Gateways unicast address of a close relay.  The relay operates passively, sending no Queries but simply tracking gateway
   also SHOULD initialize a timer used to send periodic membership information according
   reports to Reports and Leave messages, as a
   router normally would.  In addition, random value from the relay must also do explicit
   membership tracking, as interval [0, [Query Interval]]
   before sending the first periodic report, in order to which gateways on prevent startup
   synchronization (e.g., after a power outage).

   If the AMT pseudo-
   interface have joined which groups. Once gateway is serving as a local router, it SHOULD also function
   as an IGMP/MLD Proxy, as described in [I-D.ietf-magma-igmp-proxy],
   with its IGMP/MLD host-mode interface being the AMT Membership Update has
   been successfully received, pseudo-interface.
   This enables it updates to translate group memberships on its downstream
   interfaces into IGMP/MLD Reports.  Hosts receiving multicast packets
   through a gateway should ensure that their M-RIB accepts multicast
   packets from the forwarding state gateway for the
   appropriate group and source (if provided).  When data arrives for
   that group, sources it is joining.

   Also, if a shared tree routing protocol is used inside the traffic AMT site,
   each tree-root must be encapsulated to a gateway, e.g., in PIM-SM each RP must be a
   gateway.

   Finally, to support sourcing traffic to SSM groups by a gateway which
   has joined that group.

   The explicit membership tracking and with
   a global 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 address, the replication at AMT Subnet Prefix is treated as 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.

7.4.  Receiving (S,G) Joins from
   subnet prefix of the Native Side, for AMT Sources

   The relay encapsulates pseudo-interface, and an IGMPv3/MLDv2 report to anycast address is
   added on the interface.  This anycast address is formed by
   concatenating the AMT source as
   described above in Section 4.1.2.

8.  IANA Considerations

   The Subnet Prefix followed by the high bits of the
   gateway's global unicast address.  For example, if IANA should allocate a assigns the
   IPv4 prefix dedicated to x.y/16 as the public AMT Relays
   to Subnet Prefix, and the native multicast backbone.  The prefix length should gateway has
   global unicast address a.b.c.d, then the AMT Gateway's Anycast
   Address will be
   determined x.y.a.b.  Note that multiple gateways might end up
   with the same anycast address assigned to their pseudo-interfaces.

6.2  Joining Groups with MBone Sources

   The IGMP/MLD protocol usually operates by having the IANA; Querier
   multicast an IGMP/MLD Query message on the prefix should be large enough to
   guarantee advertisement in link.  This behavior does
   not work on NBMA links which do not support multicast.  Since the default- free BGP networks; a length set
   of 16 will meet this requirement.  This gateways is a one time effort; there typically unknown to the relay (and potentially quite
   large), unicasting the queries is no need for any recurring assignment after this stage.

   The IANA should also allocate an Autonomous System ID which can be impractical.  The following
   behavior is used as instead.

   Applications residing in a pseudo-AS when advertising routes to the above prefix.
   Furthermore, to support sourcing SSM traffic from AMT gateways, the
   IANA gateway should allocate a subnet prefix dedicated to join groups on the AMT link.  The
   prefix length should
   pseudo-interface, causing IGMP/MLD Membership/Listener Reports to be determined by
   sent over that interface.  When UDP encapsulating the IANA; membership
   reports (and in fact any other messages, unless specified otherwise
   in this document), the prefix should be
   large enough to guarantee advertisement destination address in the default- free BGP
   networks; a length of 16 will meet this requirement.  This is a one
   time effort; there outer IP header is no need for any recurring assignment after this
   stage.  It should also be noted that this prefix length directly
   affects
   the number of groups available to be created relay's unicast address.  Robustness is provided by the
   underlying IGMP/MLD protocol messages sent on the AMT
   gateway: a length of 16 gives 256 groups, and a length of 8 gives
   65536 groups.  For diagnostic purposes, it is helpful to have a
   prefix length which is a multiple of 8, although this is pseudo-
   interface.  In other words, the gateway does not
   required.

   An autonomous system number dedicated need to a pseudo-AS for multicast is retransmit
   IGMP/MLD Membership/Listener Reports and Leave/Done messages received
   on the pseudo-interface since IGMP/MLD will already in use today (AS 10888), do this.  The
   gateway simply needs to encapsulate each IGMP/MLD Membership/Listener
   Report and so Leave/Done message it is expected that no
   additional AS number is required for this prefix.

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

9.  Security Considerations

   The anycast technique introduces a risk that a rogue router or a
   rogue AS could introduce a bogus route receives.

   However, since periodic IGMP/MLD Membership/Listener Reports are sent
   in response to the IGMP/MLD Queries, some mechanism to trigger periodic
   Membership/Listener Reports and Leave/Done messages are necessary.
   This can be achieved in any implementation-specific manner.  Some
   possibilities include:

   1.  The AMT Relay Anycast
   Prefix, pseudo-interface might periodically manufacture IGMPv3/
       MLDv2 Queries as if they had been received from an IGMP/MLD
       Querier, and thus divert the traffic.  Network managers have deliver them to
   guarantee the integrity of their routing to IP layer, after which normal
       IGMP/MLD behavior will cause the AMT Relay anycast
   prefix appropriate reports to be sent.

   2.  The IGMP/MLD module itself might provide an option to operate in much the same way that they guarantee the integrity of all
   other routes.

   Within
       periodic mode on specific interfaces.

   If the native MBGP infrastructure, there gateway is behind a risk that a rogue
   router or a rogue AS could introduce a bogus route to firewall device, the AMT Subnet
   Prefix, and thus divert joins and cause RPF failures of multicast
   traffic.  Again, network managers have firewall may require
   the gateway to guarantee periodically refresh the integrity of UDP state in the MBGP routing firewall at
   a shorter interval than the standard IGMP/MLD Query interval.
   Therefore, this IGMP/MLD Query interval should be configurable to
   ensure the AMT subnet prefix in much firewall does not revert to blocking the same way UDP encapsulated
   multicast data packets.

6.3  Responding to Relay Changes

   When a gateway determines that
   they guarantee the integrity its current relay is unreachable
   (e.g., upon receipt of all other routes in an ICMP Unreachable message [RFC0792] for the M-RIB.

   Gateways and relays will accept and decapsulate multicast traffic
   from any source from which regular
   relay's unicast traffic is accepted. If
   this is for any reason felt 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.

6.4  Creating SSM groups

   When a security risk, then additional gateway wants to create an SSM group (i.e., in 232/8) for
   which it can source address based packet filtering traffic, the remaining 24 bits MUST be applied:

   1. To prevent a rogue sender (that can't do traditional spoofing
      because generated
   as described below.  ([SSM] states that "the policy for allocating
   these bits is strictly locally determined at the sender's host.")

   When the gateway determined its AMT Gateway Anycast Address as
   described above, it used the high bits of e.g. access lists deployed by its ISP) from making use global unicast address.
   The remaining bits of AMT to send packets its global unicast address are appended to an the
   232/8 prefix, and any spare bits may be allocated using any policy
   (again, strictly locally determined at the sender's host).

   For example, if the IPv4 AMT Subnet Prefix is x.y/16, and the device
   has global unicast address a.b.c.d, then it MUST allocate IPv4 SSM
   groups in the range 232.c.d/24.

6.5  Joining SSM tree, Groups with AMT Sources

   An IGMPv3/MLDv2 Report for a relay that receives an given (source, group) pair MAY be
   encapsulated multicast packet MUST discard directly to the multicast packet if source, when the IPv4 source address belongs
   to the AMT Subnet Prefix.

   The "link-layer" address to use as the destination address in the
   outer IP header is not composed of the
      last 2 bytes of the obtained as follows.  The source address and the 2 middle bytes of in the
      destination address
   inclusion list of the inner header (i.e., a.b.c.d must IGMPv3/MLDv2 report will be
      composed of an AMT Gateway
   Anycast Address with the a.b high bits of x.y.a.b the address, and the c.d remaining
   bits will be in the middle of 232.c.d.e).

   2. A gateway MUST discard encapsulated multicast packets the group address.

   For example, if the
      source address in IPv4 AMT Subnet Prefix is x.y/16, and the outer header IGMPv3
   Report is not for (x.y.a.b, 232.c.d.e), then the "link layer" IPv4
   destination address to which used for encapsulation is a.b.c.d.

6.6  Receiving IGMPv3/MLDv2 Reports at the
      encapsulated join message was sent. An AMT Gateway that receives

   When an encapsulated IGMPv3/MLDv2 (S,G)-Join MUST discard AMT Request is received by the message gateway, it follows the same
   3-way handshake procedure a relay would follow if it received the IPv4 destination address in AMT
   Request.  It generates a MAC and responds with an AMT Membership
   Query.  When the outer header AMT Membership Update is received, it verifies the
   MAC and then processes the IGMP/MLD Membership/Listener Report or
   Leave/Done.

   At the gateway, the IGMP/MLD packet should be an IGMPv3/MLDv2 source
   specific (S,G) join or leave.

   If S is not the AMT Gateway Anycast Address, the packet is silently
   discarded.  If G does not
      composed of the last 2 bytes of S and contain the 2 middle bytes low bits of G
      (i.e. the destination global unicast
   address a.b.c.d must be composed of (as described above), the a.b
      of packet is also silently discarded.

   The gateway adds the multicast source x.y.a.b and address (from the c.d outer IP header) and
   UDP port of the multicast group
      232.c.d.e).

10.  Contributors

   The following people provided significant contributions report to earlier
   versions of a membership list for G. Maintaining this draft.

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

11.  Acknowledgments

   Most of the mechanisms described
   membership list may be done in this document any implementation-dependent manner.
   For example, it might be maintained by the "link-layer" inside the
   AMT pseudo-interface, making it invisible to the normal IGMP/MLD
   module.

6.7  Sending data to SSM groups

   When multicast packets are based sent 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.

12.  Normative References

   [ICMP]      Postel, J., "Internet Control Message Protocol", RFC 792,
               September 1981.

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

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

   [PROXY]     Fenner, W., He, H., Haberman, B., Sandick, H., "IGMP/MLD-
               based Multicast Forwarding ("IGMP/MLD Proxying")", Work
               in progress, draft-ietf-magma-igmp-proxy-06.txt, April
               2004.

   [SSM]       Holbrook, H., Cain, B., "Source-Specific Multicast for
               IP", Work in Progress, draft-ietf-ssm-arch-06.txt,
               September 2004.

13.  Informative References

   [ANYCAST]   Huitema, C., "An Anycast Prefix AMT pseudo-interface, they are
   encapsulated as follows.  If the group address is not an SSM group,
   then the packet is silently discarded (this memo does not currently
   provide a way to send to non-SSM groups).

   If the group address is an SSM group, then the packet is unicast
   encapsulated to each remote node from which the gateway has received
   an IGMPv3/MLDv2 report for 6to4 the packet's (source, group) pair.

7.  Relay Routers",
               RFC 3068, June 2001.

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

   [Brad88]    Braden, R., Borman, D., Partridge, C., "Computing Router Details

7.1  At Startup time

   At startup time, the
               Internet Checksum", RFC 1071, September 1988.

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

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

   [PIMSM]     Estrin, D. Farinacci, D., Helmy, A., Thaler, D., Deering,
               S., Handley, M., Jacobson, V., Liu, C., Sharma, P., Wei,
               L., "Protocol Independent Multicast-Sparse Mode (PIM-SM):
               Protocol Specification", RFC 2362, June 1998.

14.  Author's relay router will bring up an NBMA-style AMT
   pseudo-interface.  It shall also add the AMT Relay Anycast Address

   Dave Thaler
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052-6399
   Phone: +1 425 703 8835
   EMail: dthaler@microsoft.com

   Mohit Talwar
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052-6399
   Phone: +1 425 705 3131
   EMail: mohitt@microsoft.com

   Amit Aggarwal
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052-6399
   Phone: +1 425 706 0593
   EMail: amitag@microsoft.com

   Lorenzo Vicisano
   Cisco Systems
   170 West Tasman Dr.
   San Jose, CA 95134
   Phone: +1 408 525 2530
   EMail: lorenzo@cisco.com

   Tom Pusateri
   Juniper Networks, Inc.
   1194 North Mathilda Avenue
   Sunnyvale, CA 94089 USA
   Phone: +1 408 745 2000
   EMail: pusateri@juniper.net

15.  Intellectual Property Rights Notice on
   some interface.

   The IETF takes no position regarding 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 validity or scope advertisement is done using BGP, the AS
   path leading to the AMT Relay Anycast Prefix shall include the
   identifier of any
   Intellectual Property Rights or other rights the local AS and the AMT Unicast Autonomous System ID.

   The relay router shall also enable IGMPv3/MLDv2 on the AMT pseudo-
   interface, except that it shall not multicast Queries (this might be claimed to
   pertain to
   done, for example, by having the implementation AMT pseudo-device drop them, or use of by
   having the technology described IGMP/MLD module not send them in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort first place).

   Finally, to identify any such rights.  Information
   on support sourcing SSM traffic from AMT sites, the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made AMT
   Subnet Prefix is assigned to the IETF Secretariat AMT pseudo-interface, and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for AMT
   Subnet Prefix is injected into the use of
   such proprietary rights by implementers or users M-RIB of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required MBGP.

7.2  Receiving Relay Discovery messages sent to implement
   this standard.  Please address the information Anycast Address

   When a relay receives an AMT Relay Discovery message directed to the IETF at ietf-
   ipr@ietf.org."

16.  Full Copyright Statement

   Copyright (C)
   AMT Relay Anycast Address, it should respond with an AMT Relay
   Advertisement containing its unicast address.  The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, source and
   except
   destination addresses of the advertisement should be the same as set forth therein, the authors retain all their rights.

17.  Disclaimer

   This document
   destination and source addresses of the discovery message
   respectively.  Further, the nonce in the discovery message MUST be
   copied into the advertisement message.

7.3  Receiving Membership Updates from AMT Gateways

   The relay operates passively, sending no Queries but simply tracking
   membership information contained herein are provided according to Reports and Leave messages, as a
   router normally would.  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
   "AS IS" basis AMT Membership Update
   has been successfully received, it updates the forwarding state for
   the appropriate group and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
                             Table of Contents source (if provided).  When data arrives
   for that group, the traffic must be encapsulated to each gateway
   which has joined that group.

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

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   2  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. Requirements Terminology . . . . . . . . . . . . . . . . . . .   3
   3. Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.1.  The IGMP/MLD module might have native support for explicit
       membership tracking, especially if it supports other NBMA-style
       interfaces.

7.4  Receiving Multicast (S,G) Joins from the Native Side, for AMT Sources

   The relay encapsulates an IGMPv3/MLDv2 report to the AMT source as
   described above in Section 4.1.2.

8.  IANA Considerations

   The IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated
   to the public AMT Site . . . . . . . . . . . . .   5
   4.2. Sourcing Multicast from 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.  For IPv4, a prefix length of 16 will meet
   this requirement.  For IPv6, a prefix length of 64 will meet this
   requirement.  This is a one time effort and there will be no need for
   any recurring assignment after this stage.

   The IANA should also allocate an Autonomous System ID which can be
   used as a pseudo-AS when advertising routes to the above prefix.

   It should also be noted that this prefix length directly affects the
   number of groups available to be created by the AMT site  . . . . . . . . . . . .   7
   5. Message Formats  . . . . . . . . . . . . . . . . . . . . . . .  10
   5.1. gateway: a length
   of 16 gives 256 groups, and a length of 8 gives 65536 groups.  For
   diagnostic purposes, it is helpful to have a prefix length which is a
   multiple of 8, although this is not required.

   IANA has allocated UDP reserved port number 2268 for AMT Relay Discovery  . . . . . . . . . . . . . . . . . . . .  10
   5.2.
   encapsulation.

9.  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 Advertisement  . . . . . . . . . . . . . . . . . .  10
   5.3. AMT Request  . . . . . . . . . . . . . . . . . . . . . . . .  11
   5.4. Anycast
   Prefix, and thus divert the traffic.  Network managers have to
   guarantee the integrity of their routing to the AMT Membership Query . . . . . . . . . . . . . . . . . . . .  12
   5.5. 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 Membership Update  . . . . . . . . . . . . . . . . . . .  13
   5.6. Subnet
   Prefix, and thus divert joins and cause RPF failures of multicast
   traffic.  As the AMT Multicast Data . . . . . . . . . . . . . . . . . . . . .  14
   6. Subnet 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 Gateway Details  . . . . . . . . . . . . . . . . . . . . .  15
   6.1. At Startup Time  . . . . . . . . . . . . . . . . . . . . . .  15
   6.2. Joining Groups with MBone Sources  . . . . . . . . . . . . .  15
   6.3. Responding Subnet Prefix.

   Gateways and relays will accept and decapsulate multicast traffic
   from any source from which regular unicast traffic is accepted.  If
   this is for any reason felt to Relay Changes  . . . . . . . . . . . . . . . .  16
   6.4. Creating SSM groups  . . . . . . . . . . . . . . . . . . . .  17
   6.5. Joining SSM Groups with 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 of e.g. access lists deployed by its ISP) from making use
       of AMT Sources  . . . . . . . . . . . .  17
   6.6. Receiving IGMPv3/MLDv2 Reports at the Gateway  . . . . . . .  17
   6.7. Sending data to send packets to an SSM groups . . . . . . . . . . . . . . . . .  18
   7. Relay Router Details . . . . . . . . . . . . . . . . . . . . .  18
   7.1. At Startup time  . . . . . . . . . . . . . . . . . . . . . .  18
   7.2. Receiving Relay Discovery messages sent tree, a relay that receives an
       encapsulated multicast packet MUST discard the multicast packet
       if the IPv4 source address in the outer header is not composed of
       the last 2 bytes of the source address and the 2 middle bytes of
       the destination address of the inner header (i.e., a.b.c.d must
       be composed of the a.b of x.y.a.b and the c.d of 232.c.d.e).

   2.  A gateway MUST discard encapsulated multicast packets if the
       source address in the outer header is not the address to which
       the Anycast
   Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  19
   7.3. Receiving Membership Updates from encapsulated join message was sent.  An AMT Gateways . . . . . . .  19
   7.4. Receiving (S,G) Joins from Gateway that
       receives an encapsulated IGMPv3/MLDv2 (S,G)-Join MUST discard the Native Side, for AMT Sources
   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  19
   8. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  20
   9. Security Considerations  . . . . . . . . . . . . . . . . . . .  20
   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  21
       message if the IPv4 destination address in the outer header is
       not composed of the last 2 bytes of S and the 2 middle bytes of G
       (i.e. the destination address a.b.c.d must be composed of the a.b
       of the multicast source x.y.a.b and the c.d of the multicast
       group 232.c.d.e).

10.  Contributors

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

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

11.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  21

   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.

12.  References

12.1  Normative References  . . . . . . . . . . . . . . . . . . . .  21
   13.

   [I-D.ietf-magma-igmp-proxy]
              Fenner, B., He, H., Haberman, B., and H. Sandick, "IGMP/
              MLD-based Multicast Forwarding ('IGMP/MLD Proxying')",
              draft-ietf-magma-igmp-proxy-06 (work in progress),
              April 2004.

   [I-D.ietf-ssm-arch]
              Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", draft-ietf-ssm-arch-07 (work in progress),
              October 2005.

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

12.2  Informative References  . . . . . . . . . . . . . . . . . . .  22
   14. Author's Address  . . . . . . . . . . . . . . . . . . . . . .  22
   15.

   [I-D.ietf-pim-sm-v2-new]
              Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode PIM-SM):
              Protocol Specification  (Revised)",
              draft-ietf-pim-sm-v2-new-11 (work in progress),
              October 2004.

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

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

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
   Cisco Systems
   170 West Tasman Dr.
   San Jose, CA  95134
   USA

   Phone: +1 408 525 2530
   Email: lorenzo@cisco.com
   Tom Pusateri
   Juniper Networks
   1194 North Mathilda Avenue
   Sunnyvale, CA  94089
   USA

   Phone: +1 408 745 2000
   Email: pusateri@juniper.net

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights Notice . . . . . . . . . . . . .  23
   16. Full or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement  . . . . . . . . . . . . . . . . . .  24
   17. Disclaimer  . . . . . . . . . . . . . . . . . . . . . . . . .  24

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.