MBoneD Working Group				       Dave Thaler
INTERNET-DRAFT					      Mohit Talwar
Expires August 2001	October	2002					 Microsoft
						  Lorenzo Vicisano
							     Cisco
							 Dirk Ooms
							   Alcatel
                                                  20 February 2001
							April 2002

     IPv4 Automatic Multicast Without Explicit Tunnels (AMT)
            <draft-ietf-mboned-auto-multicast-00.txt>
	    <draft-ietf-mboned-auto-multicast-01.txt>

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of	RFC2026.

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

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

Copyright Notice

Expires	October	2002					  [Page	1]

Draft			       AMT                  February 2001			April 2002

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

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

2.  Introduction

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.	Effectively, it	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 of the same multicast	packet
will take place	multiple times by necessity.

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 protocols
introduced in this specification are implemented 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"

Expires	October	2002					  [Page	2]

Draft			       AMT                  February 2001			April 2002

[6TO4, ANYCAST]	to get automatic IPv6 connectivity.

In order of importance,	the following problems are addressed:

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

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

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

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.

3.  Definitions

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

	    Figure 1: Automatic	Multicast Definitions.

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 implementors may treat it exactly like any other
     interface and others may treat it like a tunnel end-point.

Expires	October	2002					  [Page	3]

Draft			       AMT                  February 2001			April 2002

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

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

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.

     The value of this prefix is x.x.x.0/nn [length and	value TBD
     IANA].

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

     This address corresponds to host number 1 in the AMT Relay
     Anycast Prefix, x.x.x.1.

AMT Unicast Autonomous System ID
     A 16-bit Autonomous system	ID, for	use in BGP in accordance
     to	this memo.  AS 10888 might be usable for this, but for now

Expires	October	2002					  [Page	4]

Draft			       AMT                  February 2001			April 2002

     we'll assume it's different, to avoid confusion.  This number
     represents	a "pseudo-AS" common to	all AMT	relays.

     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 from
     local applications.

AMT Multicast Autonomous System	ID
     A 16-bit Autonomous system	ID, for	use in MBGP in accordance
     to	this memo.  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	Multicast in an	AMT Site

 +---------------+	  Internet	      +---------------+
 | AMT Site	 |			      |	MBone	      |
 |		 |	 3. Data	      |		      |
 |   1.	Join +---+---+ <================= +---+---+	      |
 |     +---->|Gateway|			  | Relay |	      |
 |     |     +---+---+ =================> +---+---+	      |
 |   R-+	 |	 2. IGMP Report	      |		      |
 +---------------+			      +---------------+

	  Figure 2: Receiving Multicast	in an AMT Site.

AMT relays and gateways	cooperate to transmit multicast	traffic
sourced	within the native multicast infrastructure to AMT sites:

Expires	October	2002					  [Page	5]

Draft			       AMT                  February 2001			April 2002

relays receive the traffic natively and	unicast-encapsulate it to
gateways; gateways decapsulate the traffic and possibly	re-
multicast it in	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 a well-known port number	[TBD IANA].

Each relay, plus the set of all	gateways (perhaps unknown to the
relay) using the relay,	together can be	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	[IGMP] 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 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.

Expires	October	2002					  [Page	6]

Draft			       AMT                  February 2001			April 2002

4.1.1.	Scalability Considerations

The requirement	that a relay keep group	state per gateway that has
joined the group introduces potential scalability concerns.

However, 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 IGMP Reports
to an anycast address can cause	duplicates.  Specifically, if
routing	changes	such that a different relay receives a periodic
IGMP 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	a unicast address which	can then be used.

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

In both	cases only SSM sources are supported.  Furthermore this
specification only deals 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:

o Applications residing	in the gateway use addresses in	the AMT
  Subnet Prefix	to send	multicast, as a	result of sourcing traffic
  on the AMT pseudo-interface.

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

Expires	October	2002					  [Page	7]

Draft			       AMT                  February 2001			April 2002

o Relays or gateways that receive a join for a source/group pair
  use information encoded in the address pair to rebuild the
  address of the gateway (source) to which to encapsulate the IGMP
  Report join
  (see section 5 for more details).

  It is	expected that this join	mechanism will be the identical	to
  that used to join back to a source on	normal media, as is being
  proposed in the SSM WG. WG [MSNIP].

4.2.1.	Supporting Site-MBone Multicast

 +---------------+	  Internet	      +---------------+
 | AMT Site	 |			      |	MBone	      |
 |		 |	 3. Data	      |		      |
 |	     +---+---+ =================> +---+---+ 1. Join   |
 |	     |Gateway|			  | Relay |<-----+    |
 |	     +---+---+ <================= +---+---+	 |    |
 |		 |	 2. IGMP Report	      |		 +-R  |
 +---------------+			      +---------------+

		 Figure	3: Site-MBone Multicast.

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

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

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

Expires	October	2002					  [Page	8]

Draft			       AMT                  February 2001			April 2002

site's gateway.

4.2.2.	Supporting Site-Site Multicast

 +---------------+	  Internet	      +---------------+
 | AMT Site	 |			      |	AMT Site      |
 |		 |	 3. Data	      |		      |
 |	     +---+---+ =================> +---+---+ 1. Join   |
 |	     |Gateway|			  |Gateway|<-----+    |
 |	     +---+---+ <================= +---+---+	 |    |
 |		 |	 2. IGMP Report	      |		 +-R  |
 +---------------+			      +---------------+

		  Figure 4: Site-Site Multicast.

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

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

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

5.  AMT	Gateway	Details

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

Expires	October	2002					  [Page	9]

Draft			       AMT                  February 2001			April 2002

5.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 a UDP encapsulated	ICMP Echo Request to the AMT Relay Anycast
Address, and note the unicast address (which is	treated	as a link-
layer
link-layer address to the encapsulation	interface) from	the UDP
encapsulated ICMP Echo Response.  These	"pings"	should be done
periodically (e.g., once a day)	to re-resolve the unicast address
of a close relay.  Note	that the ICMP messages are unicast
encapsulated, just as the multicast packets.

The gateway also initializes a timer used to send periodic IGMP
Reports	to a random value from the interval [0,	[Query Interval]]
before sending the first periodic report, in order to prevent
startup	synchronization	(e.g., after a power outage).

If the gateway is serving as a local router, it	SHOULD also
function as an IGMP Proxy, as described	in [IGMPPROXY],	with its
IGMP host-mode interface being the AMT pseudo-interface.  This
enables	it to translate	group memberships on its downstream
interfaces into	IGMP Reports.  The gateway MUST	also advertise
itself as the default route for	multicast in the M-RIB (or it must
be the default unicast router if unicast and multicast topologies
are congruent).	 Also, if a shared tree	routing	protocol is used
inside the AMT site, each tree-root must be a gateway, e.g., in
PIM-SM each RP must be a gateway.

Finally, to support sourcing traffic to	SSM groups by a	gateway
with a global unicast address, the AMT Subnet Prefix is	treated	as
the subnet prefix of the AMT pseudo-interface, and an anycast
address	is added on the	interface.  This anycast address is formed
by concatenating the AMT Subnet	Prefix followed	by the high bits
of the gateway's global	unicast	address.  For example, if IANA
assigns	the prefix x.y/16 as the AMT Subnet Prefix, and	the
gateway	has global unicast address a.b.c.d, then the AMT Gateway's
Anycast	Address	will be	x.y.a.b.  Note that multiple gateways
might end up with the same address assigned to their pseudo-
interfaces.

5.2.  Joining Groups with MBone	Sources

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

Draft			       AMT                  February 2001			April 2002

NBMA links which do not	support	multicast.  Since the set of
gateways is typically unknown to the relay (and	potentially quite
large),	unicasting the queries is also impractical.  The following
behavior is used instead.

Applications residing in a gateway should join groups on the AMT
pseudo-interface, causing IGMP Membership Reports to be	sent over
that interface.	 When UDP encapsulating	the IGMP Reports (and in
fact any other messages, unless	specified otherwise in this
document), the destination address in the outer	IP header is the
relay's	unicast	address.  To provide robustness, gateways unicast
IGMP Reports to	the relay every	[Query Interval] (defined as 125
in [IGMP]) seconds.

Generating periodic reports can	be done	in any implementation-
specific manner.  Some possibilities include:

o    The AMT pseudo-interface might periodically manufacture
     IGMPv3 Queries as if they had been	received from an IGMP
     Querier, and deliver them to the IP layer,	after which normal
     IGMP behavior will	cause the appropriate reports to be sent.

o    The IGMP module itself might provide an option to operate in
     periodic mode on specific interfaces.

5.3.  Responding to Relay Changes

When a gateway determines that its current relay is unreachable
(e.g., upon receipt of a ICMP Unreachable message for the relay's
unicast	address), it immediately repeats the unicast address
resolution step	by sending a UDP encapsulated ICMP Echo	Request	to
the AMT	Relay Anycast Address, and storing the source address of
the UDP	encapsulated ICMP Echo Response	as the new unicast address
to use as a "link-layer" destination.

5.4.  Creating SSM groups

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

Draft			       AMT                  February 2001			April 2002

When the gateway determined its	AMT Gateway Anycast Address as
described above, it used the high bits of its global unicast
address.  The remaining	bits of	its global unicast address are
appended to 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	IANA allocates x.y/16 as the AMT Subnet	Prefix,
and the	device has global unicast address a.b.c.d, then	it must
allocate SSM groups in the range 232.c.d/24.

5.5.  Joining SSM Groups with AMT Sources

An IGMPv3 Report for a given (source, group) pair MAY be
encapsulated directly to the source, when the source address
belongs	to the AMT Subnet Prefix.  (It is expected that	this
mechanism will be the same mechanism as	that used to join back to
a source on normal media, as is	being proposed in the SSM WG.)

The "link-layer" address to use	as the destination address in the
outer IP header	is obtained as follows.	 The source address in the
inclusion list of the IGMPv3 report will be an AMT Gateway Anycast
Address	with the high bits of the address, and the remaining bits
will be	in the middle of the group address.

For example, if	IANA assigns x.y/16 as the AMT Subnet Prefix, and
the IGMPv3 Report is for (x.y.a.b, 232.c.d.e), then the	"link
layer" destination address used	for encapsulation is a.b.c.d.

5.6.  Receiving	IGMPv3 Reports on the AMT Interface

When an	IGMPv3 report is received on the AMT pseudo-interface, and
the report is a	request	to join	a given	(S, G) pair, then the
following actions are taken.

If S is	not the	AMT Gateway Anycast Address of the gateway, the
packet is dropped.  If G does not contain the low bits of the
global unicast address (as described above), the packet	is also
dropped.

Otherwise, the gateway adds the	source address (from the outer IP
header)	and UDP	port of	the report to a	membership list	for G.
Maintaining this membership list may be	done in	any

Draft			       AMT                  February 2001			April 2002

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

5.7.  Sending data to SSM groups

When multicast packets are sent	on the AMT pseudo-interface, they
are encapsulated as follows.  If the group address is not an SSM
group, then the	packet 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 packet is unicast
encapsulated to	each remote node from which the	gateway	has
received an IGMPv3 report for the packet's (source, group) pair.

6.  Relay Router Details

6.1.  At startup time

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

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

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

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

Draft			       AMT                  February 2001			April 2002

6.2.  Receiving	Echo Requests to the Anycast Address

When a relay receives a	UDP encapsulated ICMP Echo Request
directed to the	AMT Relay Anycast Address, it should respond with
a UDP encapsulated ICMP	Echo Response from a unicast address
reachable on the unicast-only network (anycast addresses should
not be used as the source address of the ICMP Echo Response).

Unicast	encapsulation of the ICMP Echo Request ensures that the
message	will be	seen by	the AMT	pseudo-interface which can then
process	it.  Specifically, it needs to ensure that the ICMP Echo
Response contains the appropriate source address.

6.3.  Receiving	Joins from AMT Gateways

The relay operates passively, sending no Queries but simply
tracking membership information	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.	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:

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

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

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

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

Draft			       AMT                  February 2001			April 2002

7.  IANA Considerations

The IANA should	allocate a prefix dedicated to the AMT Relays 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; a
length of 16 will meet this requirement.  This is a one	time
effort;	there is 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.

Furthermore, to	support	sourcing SSM traffic from AMT gateways,
the IANA should	allocate a subnet prefix dedicated to the AMT
link.  The prefix length should	be determined by the IANA; the
prefix should be large enough to guarantee advertisement in the
default- free BGP networks; a length of	16 will	meet this
requirement.  This is a	one time effort; there 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	by 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	not required.

An autonomous system number dedicated to a pseudo-AS for multicast
is already in use today	(AS 10888), and	so it is expected that no
additional AS number is	required for this prefix.

Finally, IANA should reserve a well-known UDP port number for AMT
encapsulation.

8.  Security Considerations

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

Within the native MBGP infrastructure, there is	a risk that a
rogue router or	a rogue	AS could introduce a bogus route to the

Draft			       AMT                  February 2001			April 2002

AMT Subnet Prefix, and thus divert joins and cause RPF failures	of
multicast traffic.  Again, network managers have to guarantee the
integrity of the MBGP routing to the AMT subnet	prefix in much the
same way that they guarantee the integrity of all other	routes in
the M-RIB.

By default, gateways

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 be a security	risk, then
additional source address based	packet filtering could be
applied. applied:

o    To	avoid that a rogue sender (that	can't do traditional
     spoofing because of e.g. access lists deployed by its ISP)
     makes use of AMT to send packets to an SSM	tree, a	relay that
     receives an encapsulated multicast	packet COULD 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).

o    A gateway COULD discard encapsulated multicast packets if the
     source address in the outer header	is not the address to
     which the encapsulated join message was sent.

An AMT Gateway that receives an	encapsulated IGMPv3 (S,G)-Join
COULD discard the 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).	 The usefulness	of this	check will
depend on the security measures	taken in [MSNIP].

9.  Acknowledgements

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.

Draft			       AMT			April 2002

10.  Appendix A: Open Issues

Under the proposed mechanism, a	gateway	sends its IGMPv3 Reports
for MBone sources to the relay closest to itself (discovered using
the UDP	encapsulated "ping").  This ensures that, as far as
possible, multicast traffic flows through the native multicast
infrastructure and the automatic multicast encapsulation is short.

However, there might be	reasons	to create automatic tunnels to the
relay closest to the MBone source instead.  An ISP, for	example,
might be willing to provide a relay for	only its own customers,
those wishing to multicast their transmission to a much	wider
audience.  A mechanism,	complementary to the one described in this
document, might	be used	to provide this	facility.  It uses UDP
encapsulated ICMP Redirect messages as described below.

While injecting	routes for its sources into the	M-RIB, such an ISP
might, for example, use	a new BGP attribute to convey the address
of the preferred relay.	 This would let	other relays redirect any
IGMP Reports to	the preferred relay by sending a UDP encapsulated
ICMP Redirect.

An IGMP	Report sent by a gateway to the	relay closest to it would
consist	of the following packet:

Draft                           AMT                  February 2001

OuterIP	[UDP [InnerIP [IGMP Report]]]

The relay would	respond	with:

OuterIP' [UDP' [InnerIP' [ICMP Redirect	[InnerIP [IGMP Report]]]]]

An ICMP	Redirect contains the first 64 bits of the original packet
[ICMP].	 Hence the gateway would get 44	bytes (64 - sizeof(Inner
IP)) of	the IGMP Report, enough	to easily extract the (source,
group) pair, and redirect its report to	the preferred gateway.

Certainly additional complexity	is undesirable,	so it is an open
issue as to whether redirects are needed at all.

11.  Authors' Addresses

     Dave Thaler
     Microsoft Corporation
     One Microsoft Way

Draft			       AMT			April 2002

     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

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

     Dirk Ooms
     Alcatel
     F.	Wellesplein 1, 2018 Antwerp, Belgium
     Phone: +32	3 2404732
     EMail: dirk.ooms@alcatel.be

Draft                           AMT                  February 2001

12.  References

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

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

[ANYCAST]
     C.	Huitema, "An anycast prefix for	6to4 relay routers", Work
     in	progress, draft-ietf-ngtrans-6to4anycast-02.txt, February
     2001.

[BGMP]
     Thaler, D., Estrin, D., and D. Meyer, "Border Gateway
     Multicast Protocol	(BGMP):	Protocol Specification", Work in
     progress, draft-ietf-bgmp-spec-02.txt, November 2000.

Draft			       AMT			April 2002

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

[IGMPPROXY]
     W.	Fenner,	"IGMP-based Multicast Forwarding (``IGMP
     Proxying'')", Work	in progress, draft-fenner-igmp-
     proxy-03.txt, draft-fenner-igmp-proxy-
     03.txt, July 2000.

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

[IGMPv3]
     Cain, B., Deering,	S., Fenner, B.,	Kouvelas, I., and A.
     Thyagarajan, "Internet Group Management Protocol, Version 3",
     Work in progress, draft-ietf-idmr-igmp-v3-06.txt, January
     2001.

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

Draft                           AMT                  February 2001

[SSM]
     Holbrook, H., and B. Cain,	"Source-Specific Multicast for
     IP", Work in progress, draft-holbrook-ssm-arch-01.txt,
     November 2000.

[MSNIP]
     Fenner B.,	H. Holbrook, H., and I.	Kouvelas, "Multicast
     Source Notification of Interest Protocol (MSNIP)",	Work in
     progress, draft-ietf-idmr-msnip-01.txt, November 2001.

13.  Full Copyright Statement

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

This document and translations of it may be copied and furnished
to others, and derivative works	that comment on	or otherwise
explain	it or assist in	its implmentation may be prepared, copied,
published and distributed, in whole or in part,	without
restriction of any kind, provided that the above copyright notice

Draft			       AMT			April 2002

and this paragraph are included	on all such copies and derivative
works.	However, this document itself may not be modified in any
way, such as by	removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the	purpose	of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process	must be	followed, or as	required to translate it into
languages other	than English.

The limited permissions	granted	above are perpetual and	will not
be revoked by the Internet Society or its successors or	assigns.

This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS 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.