draft-ietf-mboned-auto-multicast-07.txt		draft-ietf-mboned-auto-multicast-08.txt
	Network Working Group D. Thaler		Network Working Group D. Thaler
	Internet-Draft M. Talwar		Internet-Draft M. Talwar
	Expires: May 20, 2007 A. Aggarwal		Intended status: Standards Track A. Aggarwal
	Microsoft Corporation		Expires: April 5, 2008 Microsoft Corporation
	L. Vicisano		L. Vicisano
	Cisco Systems		Cisco Systems
	T. Pusateri		T. Pusateri
	!j		!j
	November 16, 2006		October 3, 2007
	Automatic IP Multicast Without Explicit Tunnels (AMT)		Automatic IP Multicast Without Explicit Tunnels (AMT)
	draft-ietf-mboned-auto-multicast-07		draft-ietf-mboned-auto-multicast-08
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 39		skipping to change at page 1, line 39
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		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		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 May 20, 2007.		This Internet-Draft will expire on April 5, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	Automatic Multicast Tunneling (AMT) allows multicast communication		Automatic Multicast Tunneling (AMT) allows multicast communication
	amongst isolated multicast-enabled sites or hosts, attached to a		amongst isolated multicast-enabled sites or hosts, attached to a
	network which has no native multicast support. It also enables them		network which has no native multicast support. It also enables them
	to exchange multicast traffic with the native multicast		to exchange multicast traffic with the native multicast
	infrastructure and does not require any manual configuration. AMT		infrastructure and does not require any manual configuration. AMT
	uses an encapsulation interface so that no changes to a host stack or		uses an encapsulation interface so that no changes to a host stack or
	applications are required, all protocols (not just UDP) are handled,		applications are required, all protocols (not just UDP) are handled,
	and there is no additional overhead in core routers.		and there is no additional overhead in core routers.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Requirements notation . . . . . . . . . . . . . . . . . . . . 6		3. Requirements notation . . . . . . . . . . . . . . . . . . . . 7
	4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7		4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. AMT Pseudo-Interface . . . . . . . . . . . . . . . . . . . 7		4.1. AMT Pseudo-Interface . . . . . . . . . . . . . . . . . . . 8
	4.2. AMT Gateway . . . . . . . . . . . . . . . . . . . . . . . 7		4.2. AMT Gateway . . . . . . . . . . . . . . . . . . . . . . . 8
	4.3. AMT Site . . . . . . . . . . . . . . . . . . . . . . . . . 7		4.3. AMT Site . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.4. AMT Relay Router . . . . . . . . . . . . . . . . . . . . . 7		4.4. AMT Relay Router . . . . . . . . . . . . . . . . . . . . . 8
	4.5. AMT Relay Anycast Prefix . . . . . . . . . . . . . . . . . 8		4.5. AMT Relay Anycast Prefix . . . . . . . . . . . . . . . . . 9
	4.6. AMT Relay Anycast Address . . . . . . . . . . . . . . . . 8		4.6. AMT Relay Anycast Address . . . . . . . . . . . . . . . . 9
	4.7. AMT Subnet Anycast Prefix . . . . . . . . . . . . . . . . 8		4.7. AMT Subnet Anycast Prefix . . . . . . . . . . . . . . . . 9
	4.8. AMT Gateway Anycast Address . . . . . . . . . . . . . . . 8		4.8. AMT Gateway Anycast Address . . . . . . . . . . . . . . . 9
	5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.1. Receiving Multicast in an AMT Site . . . . . . . . . . . . 9		5.1. Receiving Multicast in an AMT Site . . . . . . . . . . . . 10
	5.1.1. Scalability Considerations . . . . . . . . . . . . . . 10		5.1.1. Scalability Considerations . . . . . . . . . . . . . . 11
	5.1.2. Spoofing Considerations . . . . . . . . . . . . . . . 10		5.1.2. Spoofing Considerations . . . . . . . . . . . . . . . 11
	5.1.3. Protocol Sequence for a Gateway Joining SSM		5.1.3. Protocol Sequence for a Gateway Joining SSM
	Receivers to a Relay . . . . . . . . . . . . . . . . . 11		Receivers to a Relay . . . . . . . . . . . . . . . . . 12
	5.2. Sourcing Multicast from an AMT site . . . . . . . . . . . 13		5.2. Sourcing Multicast from an AMT site . . . . . . . . . . . 14
	5.2.1. Supporting Site-MBone Multicast . . . . . . . . . . . 13		5.2.1. Supporting Site-MBone Multicast . . . . . . . . . . . 15
	5.2.2. Supporting Site-Site Multicast . . . . . . . . . . . . 14		5.2.2. Supporting Site-Site Multicast . . . . . . . . . . . . 16
	6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 16		6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 17
	6.1. AMT Relay Discovery . . . . . . . . . . . . . . . . . . . 16		6.1. AMT Relay Discovery . . . . . . . . . . . . . . . . . . . 17
	6.1.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 16		6.1.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 17
	6.1.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 16		6.1.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 17
	6.1.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 16		6.1.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 17
	6.2. AMT Relay Advertisement . . . . . . . . . . . . . . . . . 16		6.2. AMT Relay Advertisement . . . . . . . . . . . . . . . . . 17
	6.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 17		6.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 18
	6.2.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 17		6.2.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 18
	6.2.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 17		6.2.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 18
	6.2.4. Relay Address . . . . . . . . . . . . . . . . . . . . 17		6.2.4. Relay Address . . . . . . . . . . . . . . . . . . . . 18
	6.3. AMT Request . . . . . . . . . . . . . . . . . . . . . . . 17		6.3. AMT Request . . . . . . . . . . . . . . . . . . . . . . . 18
	6.3.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 18		6.3.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 19
	6.3.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 18		6.3.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 19
	6.3.3. Request Nonce . . . . . . . . . . . . . . . . . . . . 18		6.3.3. Request Nonce . . . . . . . . . . . . . . . . . . . . 19
	6.4. AMT Membership Query . . . . . . . . . . . . . . . . . . . 18		6.4. AMT Membership Query . . . . . . . . . . . . . . . . . . . 19
	6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 19		6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 20
	6.4.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 19		6.4.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 20
	6.4.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 19		6.4.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 20
	6.4.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 19		6.4.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 20
	6.4.5. IGMP/MLD Query (including IP Header) . . . . . . . . . 19		6.4.5. IGMP/MLD Query (including IP Header) . . . . . . . . . 20
	6.5. AMT Membership Update . . . . . . . . . . . . . . . . . . 20		6.5. AMT Membership Update . . . . . . . . . . . . . . . . . . 21
	6.5.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 20		6.5.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 21
	6.5.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 20		6.5.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 22
	6.5.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 20		6.5.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 22
	6.5.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 21		6.5.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 22
	6.5.5. IGMP/MLD Message (including IP Header) . . . . . . . . 21		6.5.5. IGMP/MLD Message (including IP Header) . . . . . . . . 22
	6.6. AMT IP Multicast Data . . . . . . . . . . . . . . . . . . 21		6.6. AMT IP Multicast Data . . . . . . . . . . . . . . . . . . 22
	6.6.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 21		6.6.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 23
	6.6.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 21		6.6.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 23
	6.6.3. IP Multicast Data . . . . . . . . . . . . . . . . . . 22		6.6.3. IP Multicast Data . . . . . . . . . . . . . . . . . . 23
	7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 23		7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 24
	7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 23		7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 24
	7.2. Gateway Group and Source Addresses . . . . . . . . . . . . 23		7.2. Gateway Group and Source Addresses . . . . . . . . . . . . 24
	7.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 24		7.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 25
	7.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 24		7.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 25
	7.3. Joining Groups with MBone Sources . . . . . . . . . . . . 24		7.3. Joining Groups with MBone Sources . . . . . . . . . . . . 26
	7.4. Responding to Relay Changes . . . . . . . . . . . . . . . 25		7.4. Responding to Relay Changes . . . . . . . . . . . . . . . 26
	7.5. Joining SSM Groups with AMT Gateway Sources . . . . . . . 26		7.5. Joining SSM Groups with AMT Gateway Sources . . . . . . . 27
	7.6. Receiving AMT Membership Updates by the Gateway . . . . . 26		7.6. Receiving AMT Membership Updates by the Gateway . . . . . 27
	7.7. Sending data to SSM groups . . . . . . . . . . . . . . . . 26		7.7. Sending data to SSM groups . . . . . . . . . . . . . . . . 27
	8. Relay Router Details . . . . . . . . . . . . . . . . . . . . . 28		8. Relay Router Details . . . . . . . . . . . . . . . . . . . . . 28
	8.1. At Startup time . . . . . . . . . . . . . . . . . . . . . 28		8.1. At Startup time . . . . . . . . . . . . . . . . . . . . . 28
	8.2. Receiving Relay Discovery messages sent to the Anycast		8.2. Receiving Relay Discovery messages sent to the Anycast
	Address . . . . . . . . . . . . . . . . . . . . . . . . . 28		Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
	8.3. Receiving Membership Updates from AMT Gateways . . . . . . 28		8.3. Receiving Membership Updates from AMT Gateways . . . . . . 28
	8.4. Receiving (S,G) Joins from the Native Side, for AMT		8.4. Receiving (S,G) Joins from the Native Side, for AMT
	Sources . . . . . . . . . . . . . . . . . . . . . . . . . 29		Sources . . . . . . . . . . . . . . . . . . . . . . . . . 29
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
	9.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 30		9.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 30
	9.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 30		9.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 30
	skipping to change at page 4, line 25		skipping to change at page 5, line 25
	small and concentrated changes to the network infrastructure, and no		small and concentrated changes to the network infrastructure, and no
	changes at all to user applications or to the socket API of end-		changes at all to user applications or to the socket API of end-
	nodes' operating systems. The protocol introduced in this		nodes' operating systems. The protocol introduced in this
	specification can be deployed in a few strategically-placed network		specification can be deployed in a few strategically-placed network
	nodes and in user-installable software modules (pseudo device drivers		nodes and in user-installable software modules (pseudo device drivers
	and/or user-mode daemons) that reside underneath the socket API of		and/or user-mode daemons) that reside underneath the socket API of
	end-nodes' operating systems. This mechanism is very similar to that		end-nodes' operating systems. This mechanism is very similar to that
	used by "6to4" [RFC3056], [RFC3068] to get automatic IPv6		used by "6to4" [RFC3056], [RFC3068] to get automatic IPv6
	connectivity.		connectivity.
	Effectively, AMT treats the unicast-only internetwork as a large non-		Effectively, AMT treats the unicast-only inter-network as a large
	broadcast multi-access (NBMA) link layer, over which we require the		non-broadcast multi-access (NBMA) link layer, over which we require
	ability to multicast. To do this, multicast packets being sent to or		the ability to multicast. To do this, multicast packets being sent
	from a site must be encapsulated in unicast packets. If the group		to or from a site must be encapsulated in unicast packets. If the
	has members in multiple sites, AMT encapsulation of the same		group has members in multiple sites, AMT encapsulation of the same
	multicast packet will take place multiple times by necessity.		multicast packet will take place multiple times by necessity.
	2. Applicability		2. Applicability
	AMT is not a substitute for native multicast or a statically		AMT is not a substitute for native multicast or a statically
	configured multicast tunnel for high traffic flow. Unicast		configured multicast tunnel for high traffic flow. Unicast
	replication is required to reach multiple receivers that are not part		replication is required to reach multiple receivers that are not part
	of the native multicast infrastructure. Unicast replication is also		of the native multicast infrastructure. Unicast replication is also
	required by non-native sources to different parts of the native		required by non-native sources to different parts of the native
	multicast infrastructure. However, this is no worse than regular		multicast infrastructure. However, this is no worse than regular
	skipping to change at page 7, line 47		skipping to change at page 8, line 47
	A multicast-enabled network not connected to the multicast backbone		A multicast-enabled network not connected to the multicast backbone
	served by an AMT Gateway. It could also be a stand- alone AMT		served by an AMT Gateway. It could also be a stand- alone AMT
	Gateway.		Gateway.
	4.4. AMT Relay Router		4.4. AMT Relay Router
	A multicast router configured to support transit routing between AMT		A multicast router configured to support transit routing between AMT
	Sites and the native multicast backbone infrastructure. The relay		Sites and the native multicast backbone infrastructure. The relay
	router has one or more interfaces connected to the native multicast		router has one or more interfaces connected to the native multicast
	infrastructure, zero or more interfaces connected to the non-		infrastructure, zero or more interfaces connected to the non-
	multicast capable internetwork, and an AMT pseudo-interface. It is		multicast capable inter-network, and an AMT pseudo-interface. It is
	simply referred to in this document as a "relay".		simply referred to in this document as a "relay".
	As with [RFC3056], we assume that normal multicast routers do not		As with [RFC3056], we assume that normal multicast routers do not
	want to be tunnel endpoints (especially if this results in high fan		want to be tunnel endpoints (especially if this results in high fan
	out), and similarly that service providers do not want encapsulation		out), and similarly that service providers do not want encapsulation
	to arbitrary routers. Instead, we assume that special-purpose		to arbitrary routers. Instead, we assume that special-purpose
	routers will be deployed that are suitable for serving as relays.		routers will be deployed that are suitable for serving as relays.
	4.5. AMT Relay Anycast Prefix		4.5. AMT Relay Anycast Prefix
	skipping to change at page 9, line 19		skipping to change at page 10, line 19
	Internet		Internet
	+---------------+ +---------------+		+---------------+ +---------------+
	| AMT Site | 2. 3-way Membership | MBone |		| AMT Site | 2. 3-way Membership | MBone |
	| | Handshake | |		| | Handshake | |
	| 1. Join +---+---+ =================> +---+---+ |		| 1. Join +---+---+ =================> +---+---+ |
	| +---->|Gateway| | Relay | |		| +---->|Gateway| | Relay | |
	| | +---+---+ <================= +---+---+ |		| | +---+---+ <================= +---+---+ |
	| R-+ | 3. Receive Data | |		| R-+ | 3. Receive Data | |
	+---------------+ +---------------+		+---------------+ +---------------+
			Receiving Multicast in an AMT Site
	AMT relays and gateways cooperate to transmit multicast traffic		AMT relays and gateways cooperate to transmit multicast traffic
	sourced within the native multicast infrastructure to AMT sites:		sourced within the native multicast infrastructure to AMT sites:
	relays receive the traffic natively and unicast-encapsulate it to		relays receive the traffic natively and unicast-encapsulate it to
	gateways; gateways decapsulate the traffic and possibly forward it		gateways; gateways decapsulate the traffic and possibly forward it
	into the AMT site.		into the AMT site.
	Each gateway has an AMT pseudo-interface that serves as a default		Each gateway has an AMT pseudo-interface that serves as a default
	multicast route. Requests to join a multicast session are sent to		multicast route. Requests to join a multicast session are sent to
	this interface and encapsulated to a particular relay reachable		this interface and encapsulated to a particular relay reachable
	across the unicast-only infrastructure.		across the unicast-only infrastructure.
	skipping to change at page 10, line 24		skipping to change at page 11, line 26
	It is possible that millions of hosts will enable AMT gateway		It is possible that millions of hosts will enable AMT gateway
	functionality and so an important design goal is not to create		functionality and so an important design goal is not to create
	gateway state in each relay until the gateway joins a multicast		gateway state in each relay until the gateway joins a multicast
	group. But even the requirement that a relay keep group state per		group. But even the requirement that a relay keep group state per
	gateway that has joined a group introduces potential scalability		gateway that has joined a group introduces potential scalability
	concerns.		concerns.
	Scalability of AMT can be achieved by adding more relays, and using		Scalability of AMT can be achieved by adding more relays, and using
	an appropriate relay discovery mechanism for gateways to discover		an appropriate relay discovery mechanism for gateways to discover
	relays. The solution we adopt is to assign addresses in anycast		relays. The solution we adopt is to assign addresses in anycast
	fashion to relays [RFC1546], [RFC2373]. However, simply sending		fashion to relays [RFC1546], [RFC4291]. However, simply sending
	periodic membership reports to an anycast address can cause		periodic membership reports to an anycast address can cause
	duplicates. Specifically, if routing changes such that a different		duplicates. Specifically, if routing changes such that a different
	relay receives a periodic membership report, both the new and old		relay receives a periodic membership report, both the new and old
	relays will encapsulate data to the AMT site until the old relay's		relays will encapsulate data to the AMT site until the old relay's
	state times out. This is obviously undesirable. Instead, we use the		state times out. This is obviously undesirable. Instead, we use the
	anycast address merely to find the unicast address of a relay to		anycast address merely to find the unicast address of a relay to
	which membership reports are sent.		which membership reports are sent.
	Since adding another relay has the result of adding another		Since adding another relay has the result of adding another
	independent NBMA link, this allows the gateways to be spread out		independent NBMA link, this allows the gateways to be spread out
	skipping to change at page 11, line 22		skipping to change at page 12, line 24
	the respondent finalizing the 3-way handshake.		the respondent finalizing the 3-way handshake.
	Upon reception, the respondent can recalculate the MAC based on the		Upon reception, the respondent can recalculate the MAC based on the
	source IP address, the source UDP port, the request nonce, and the		source IP address, the source UDP port, the request nonce, and the
	local secret. The IGMP/MLD message is only accepted if the received		local secret. The IGMP/MLD message is only accepted if the received
	MAC matches the calculated MAC.		MAC matches the calculated MAC.
	The local secret never has to be shared with the other side. It is		The local secret never has to be shared with the other side. It is
	only used to verify return routability of the originator.		only used to verify return routability of the originator.
			Since the same Request Nonce and source IP address can be re-used,
			the receiver SHOULD change its secret key at least once per hour.
			However, AMT Membership updates received with the previous secret
			MUST be accepted for up to the IGMP/MLD Query Interval.
	5.1.3. Protocol Sequence for a Gateway Joining SSM Receivers to a Relay		5.1.3. Protocol Sequence for a Gateway Joining SSM Receivers to a Relay
	This description assumes the Gateway can be a host joining as a		This description assumes the Gateway can be a host joining as a
	receiver or a network device acting as a Gateway when a directly		receiver or a network device acting as a Gateway when a directly
	connected host joins as a receiver.		connected host joins as a receiver.
	o Receiver at AMT site sends IGMPv3/MLDv2 report joining (S1,G1).		o Receiver at AMT site sends IGMPv3/MLDv2 report joining (S1,G1).
	o Gateway receives report has no tunnel state with a Relay so it		o Gateway receives report. If it has no tunnel state with a Relay,
	originates an AMT Relay Discovery message addressed to the Anycast		it originates an AMT Relay Discovery message addressed to the
	Relay IP address.		Anycast Relay IP address. The AMT Relay Discovery message can be
			sent on demand if no relay is known at this time or at startup and
			be periodically refreshed.
	o The closest Relay topologically receives the AMT Relay Discovery		o The closest Relay topologically receives the AMT Relay Discovery
	message and returns the nonce from the Discovery in an AMT Relay		message and returns the nonce from the Discovery in an AMT Relay
	Advertisement message so the Gateway can learn of the Relay's		Advertisement message so the Gateway can learn of the Relay's
	unique IP address.		unique IP address.
	o When the Gateway receives the AMT Relay Advertisement message, it		o When the Gateway receives the AMT Relay Advertisement message, it
	now has an address to use for all subsequent (S,G) entries it will		now has an address to use for all subsequent (S,G) entries it will
	join on behalf of attached receivers (or itself).		join on behalf of attached receivers (or itself).
	o The Gateway now sends an AMT Request message to the Relay's unique		o If the gateway has a valid Response MAC from a previous AMT Query
	IP address to begin the process of joining the (S,G).		message, it can send an AMT Membership Update message as described
			below. Otherwise, the Gateway sends an AMT Request message to the
			Relay's unique IP address to begin the process of joining the
			(S,G). The gateway also SHOULD initialize a timer used to send
			periodic Requests to a random value from the interval [0, [Query
			Interval]] before sending the first periodic report, in order to
			prevent startup synchronization.
	o The Relay responds to the AMT Request message by returning the		o The Relay responds to the AMT Request message by returning the
	nonce from the Request in a AMT Query message. The Query message		nonce from the Request in a AMT Query message. The Query message
	contains an IGMP/MLD QUERY indicating how often the Gateway should		contains an IGMP/MLD QUERY indicating how often the Gateway should
	repeat AMT Request messages so the (S,G) state can stay refreshed		repeat AMT Request messages so the (S,G) state can stay refreshed
	in the Relay. The Query message also includes an opaque security		in the Relay. The Query message also includes an opaque security
	code which is generated locally (with no external coordination).		code which is generated locally (with no external coordination).
	o When the Gateway receives the AMT Query message it responds by		o When the Gateway receives the AMT Query message it responds by
	copying the security code from the AMT Query message into a AMT		copying the security code from the AMT Query message into a AMT
	Membership Update message. In the Update message contains (S1,G1)		Membership Update message. The Update message contains (S1,G1) in
	in an IGMPv3/MLDv2 formatted packet with an IP header. The nonce		an IGMPv3/MLDv2 formatted packet with an IP header. The nonce
	from the AMT Request is also included in the AMT Membership Update		from the AMT Request is also included in the AMT Membership Update
	message.		message.
	o When the Relay receives the AMT Membership Update, it will add the		o When the Relay receives the AMT Membership Update, it will add the
	tunnel to the Gateway in it's outgoing interface list for it's		tunnel to the Gateway in it's outgoing interface list for it's
	(S1,G1) entry stored in the multicast routing table. If the		(S1,G1) entry stored in the multicast routing table. If the
	(S1,G1) entry was created do to this interaction, the multicast		(S1,G1) entry was created do to this interaction, the multicast
	routing protocol running on the Relay will trigger a Join message		routing protocol running on the Relay will trigger a Join message
	towards source S1 to build a native multicast tree in the native		towards source S1 to build a native multicast tree in the native
	multicast infrastructure.		multicast infrastructure.
	skipping to change at page 12, line 39		skipping to change at page 14, line 6
	associated with the tunnel to the Relay it had attached to, and		associated with the tunnel to the Relay it had attached to, and
	forward the packet to the outgoing interfaces joined by any		forward the packet to the outgoing interfaces joined by any
	attached receiver hosts (or deliver the packet to the application		attached receiver hosts (or deliver the packet to the application
	when the Gateway is the receiver).		when the Gateway is the receiver).
	o If later (S2,G2) is joined by a receiver, a 3-way handshake of		o If later (S2,G2) is joined by a receiver, a 3-way handshake of
	Request/ Query/Update occurs for this entry. The Discovery/		Request/ Query/Update occurs for this entry. The Discovery/
	Advertisement exchange is not required.		Advertisement exchange is not required.
	o To keep the state for (S1,G1) and (S2,G2) alive in the Relay, the		o To keep the state for (S1,G1) and (S2,G2) alive in the Relay, the
	Gateway will send periodic AMT Request messages which cause Query		Gateway will send periodic AMT Membership Updates. The Membership
	messages to be returned. And in response to the Query message all		Update can be sent directly if the sender has a valid nonce from a
	joined state in the Gateway is packed in the fewest number of AMT		previous Request. If not, an AMT Request messages should be sent
	Membership Update messages.		to solicit a Query Message. When sending a periodic state
			refresh, all joined state in the Gateway is packed in the fewest
			number of AMT Membership Update messages.
	o When the Gateway leaves all (S,G) entries, the Relay can free		o When the Gateway leaves all (S,G) entries, the Relay can free
	resources associated with the tunnel. It is assumed that when the		resources associated with the tunnel. It is assumed that when the
	Gateway would want to join an (S,G) again, it would start the		Gateway would want to join an (S,G) again, it would start the
	Discovery/Advertisement tunnel establishment process over again.		Discovery/Advertisement tunnel establishment process over again.
	This same procedure would be used for receivers who operate in Any-		This same procedure would be used for receivers who operate in Any-
	Source Multicast (ASM) mode.		Source Multicast (ASM) mode.
	5.2. Sourcing Multicast from an AMT site		5.2. Sourcing Multicast from an AMT site
	skipping to change at page 13, line 48		skipping to change at page 15, line 17
	Internet		Internet
	+---------------+ +---------------+		+---------------+ +---------------+
	| AMT Site | 2. 3-way Membership | MBone |		| AMT Site | 2. 3-way Membership | MBone |
	| | Handshake | |		| | Handshake | |
	| +---+---+ <================= +---+---+ 1. Join |		| +---+---+ <================= +---+---+ 1. Join |
	| |Gateway| | Relay |<-----+ |		| |Gateway| | Relay |<-----+ |
	| +---+---+ =================> +---+---+ | |		| +---+---+ =================> +---+---+ | |
	| | 3. Receive Data | +-R |		| | 3. Receive Data | +-R |
	+---------------+ +---------------+		+---------------+ +---------------+
			Site-MBone Multicast
	If a relay receives an explicit join from the native infrastructure,		If a relay receives an explicit join from the native infrastructure,
	for a given (source, group) pair where the source address belongs to		for a given (source, group) pair where the source address belongs to
	the AMT Subnet Anycast Prefix, then the relay will periodically		the AMT Subnet Anycast Prefix, then the relay will periodically
	(using the rules specified in Section 5.1.2) encapsulate membership		(using the rules specified in Section 5.1.2) encapsulate membership
	updates for the group to the gateway. The gateway must keep state		updates for the group to the gateway. The gateway must keep state
	per relay from which membership reports have been sent, and forward		per relay from which membership reports have been sent, and forward
	multicast traffic from the site to all relays from which membership		multicast traffic from the site to all relays from which membership
	reports have been received. The choice of whether this state and		reports have been received. The choice of whether this state and
	replication is done at the link-layer (i.e., by the tunnel interface)		replication is done at the link-layer (i.e., by the tunnel interface)
	or at the network-layer is implementation dependent.		or at the network-layer is implementation dependent.
	skipping to change at page 14, line 41		skipping to change at page 16, line 17
	Internet		Internet
	+---------------+ +---------------+		+---------------+ +---------------+
	| AMT Site | 2. 3-way Membership | AMT Site |		| AMT Site | 2. 3-way Membership | AMT Site |
	| | Handshake | |		| | Handshake | |
	| +---+---+ <================= +---+---+ 1. Join |		| +---+---+ <================= +---+---+ 1. Join |
	| |Gateway| |Gateway|<-----+ |		| |Gateway| |Gateway|<-----+ |
	| +---+---+ =================> +---+---+ | |		| +---+---+ =================> +---+---+ | |
	| | 3. Receive Data | +-R |		| | 3. Receive Data | +-R |
	+---------------+ +---------------+		+---------------+ +---------------+
			Site-Site Multicast
	Since we require gateways to accept membership reports, as described		Since we require gateways to accept membership reports, as described
	above, it is also possible to support multicast among AMT sites,		above, it is also possible to support multicast among AMT sites,
	without requiring assistance from any relays.		without requiring assistance from any relays.
	When a gateway wants to join a given (source, group) pair, where the		When a gateway wants to join a given (source, group) pair, where the
	source address belongs to the AMT Subnet Anycast Prefix, then the		source address belongs to the AMT Subnet Anycast Prefix, then the
	gateway will periodically unicast encapsulate an IGMPv3/MLDv2 Report		gateway will periodically unicast encapsulate an IGMPv3/MLDv2 Report
	[RFC3376], [RFC3810] (including IP Header) directly to the site		[RFC3376], [RFC3810] (including IP Header) directly to the site
	gateway for the source.		gateway for the source.
	skipping to change at page 16, line 27		skipping to change at page 17, line 27
	The payload of the UDP packet contains the following fields.		The payload of the UDP packet contains the following fields.
	0 1 2 3		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		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 |		| Type=0x1 | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Discovery Nonce |		| Discovery Nonce |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Fields:		AMT Relay Discovery
	6.1.1. Type		6.1.1. Type
	The type of the message.		The type of the message.
	6.1.2. Reserved		6.1.2. Reserved
	A 24-bit reserved field. Sent as 0, ignored on receipt.		A 24-bit reserved field. Sent as 0, ignored on receipt.
	6.1.3. Discovery Nonce		6.1.3. Discovery Nonce
	skipping to change at page 17, line 17		skipping to change at page 18, line 17
	0 1 2 3		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		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 |		| Type=0x2 | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Discovery Nonce |		| Discovery Nonce |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Relay Address |		| Relay Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Fields:		AMT Relay Advertisement
	6.2.1. Type		6.2.1. Type
	The type of the message.		The type of the message.
	6.2.2. Reserved		6.2.2. Reserved
	A 24-bit reserved field. Sent as 0, ignored on receipt.		A 24-bit reserved field. Sent as 0, ignored on receipt.
	6.2.3. Discovery Nonce		6.2.3. Discovery Nonce
	skipping to change at page 18, line 14		skipping to change at page 19, line 14
	checksum MUST be valid in AMT control messages.		checksum MUST be valid in AMT control messages.
	0 1 2 3		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		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 |		| Type=0x3 | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Request Nonce |		| Request Nonce |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Fields:		AMT Relay Advertisement
	6.3.1. Type		6.3.1. Type
	The type of the message.		The type of the message.
	6.3.2. Reserved		6.3.2. Reserved
	A 24-bit reserved field. Sent as 0, ignored on receipt.		A 24-bit reserved field. Sent as 0, ignored on receipt.
	6.3.3. Request Nonce		6.3.3. Request Nonce
	skipping to change at page 19, line 20		skipping to change at page 20, line 20
	| Response MAC (continued) |		| Response MAC (continued) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Request Nonce |		| Request Nonce |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IGMP Membership Query or MLD Listener Query |		| IGMP Membership Query or MLD Listener Query |
	| (including IP Header) |		| (including IP Header) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ... |		| ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Fields:		AMT Membership Query
	6.4.1. Type		6.4.1. Type
	The type of the message.		The type of the message.
	6.4.2. Reserved		6.4.2. Reserved
	A 8-bit reserved field. Sent as 0, ignored on receipt.		A 8-bit reserved field. Sent as 0, ignored on receipt.
	6.4.3. Response MAC		6.4.3. Response MAC
	A 48-bit hash generated by the respondent and sent to the originator		A 48-bit hash generated by the respondent and sent to the originator
	for inclusion in the AMT Membership Update. The algorithm used for		for inclusion in the AMT Membership Update. The algorithm used for
	this is chosen by the respondent. One algorithm that could be used		this is chosen by the respondent but an algorithm such as HMAC-MD5-48
	is HMAC-MD5-48 [RFC2104].		[RFC2104] SHOULD be used at a minimum.
	6.4.4. Request Nonce		6.4.4. Request Nonce
	A 32-bit identifier used to distinguish this request echoed back to		A 32-bit identifier used to distinguish this request echoed back to
	the originator.		the originator.
	6.4.5. IGMP/MLD Query (including IP Header)		6.4.5. IGMP/MLD Query (including IP Header)
	The message contains either an IGMP Query or an MLD Multicast		The message contains either an IGMP Query or an MLD Multicast
	Listener Query. The IGMP or MLD version sent should default to		Listener Query. The IGMP or MLD version sent should default to
	IGMPv3 or MLDv2 unless explicitly configured to use IGMPv2 or MLDv1.		IGMPv3 or MLDv2 unless explicitly configured to use IGMPv2 or MLDv1.
	The IGMP/MLD Query includes a full IP Header. The IP source address		The IGMP/MLD Query includes a full IP Header. The IP source address
	of the query would match the anycast address on the pseudo interface.		of the query would match the anycast address on the pseudo interface.
	The TTL of the outer header should be sufficient to reach the tunnel		The TTL of the outer header should be sufficient to reach the tunnel
	endpoint and not mimic the inner header TTL which is typically 1 for		endpoint and not mimic the inner header TTL which is typically 1 for
	IGMP/MLD messages.		IGMP/MLD messages.
	6.5. AMT Membership Update		6.5. AMT Membership Update
	An AMT Membership Update is sent in response to a previously received		An AMT Membership Update is sent to report a membership after a valid
	AMT Query message. It contains the original IGMP/MLD Membership/		Response MAC has been received. It contains the original IGMP/MLD
	Listener Report or Leave/Done received over the AMT pseudo-interface		Membership/Listener Report or Leave/Done received over the AMT
	including the original IP header. It echoes the Response MAC		pseudo-interface including the original IP header. It echoes the
	received in the AMT Membership Query so the respondent can verify		Response MAC received in the AMT Membership Query so the respondent
	return routability to the originator.		can verify return routability to the originator.
	It is sent from the destination address received in the Query to the		It is sent from the destination address received in the Query to the
	source address received in the Query which should both be the same as		source address received in the Query which should both be the same as
	the original Request.		the original Request.
	The UDP source and destination port numbers should be the same ones		The UDP source and destination port numbers should be the same ones
	sent in the original Request.		sent in the original Request.
	The relay is not required to use the IP source address of the IGMP		The relay is not required to use the IP source address of the IGMP
	Membership Report for any particular purpose.		Membership Report for any particular purpose.
			The same Request Nonce and Response MAC can be used across multiple
			AMT Membership Update messages without having to send individual AMT
			Membership Query messages.
	0 1 2 3		0 1 2 3
	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		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 |		| Type=0x5 | Reserved | Response MAC |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Response MAC (continued) |		| Response MAC (continued) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Request Nonce |		| Request Nonce |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IGMP or MLD Message (including IP header) |		| IGMP or MLD Message (including IP header) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ... |		| ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Fields:		AMT Membership Update
	6.5.1. Type		6.5.1. Type
	The type of the message.		The type of the message.
	6.5.2. Reserved		6.5.2. Reserved
	A 8-bit reserved field. Sent as 0, ignored on receipt.		A 8-bit reserved field. Sent as 0, ignored on receipt.
	6.5.3. Response MAC		6.5.3. Response MAC
	skipping to change at page 21, line 41		skipping to change at page 22, line 49
	The payload of the UDP packet contains the following fields.		The payload of the UDP packet contains the following fields.
	0 1 2 3		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		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type=0x6 | Reserved | IP Multicast Data ... |		| Type=0x6 | Reserved | IP Multicast Data ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ... |		| ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Fields:		AMT IP Multicast Data
	6.6.1. Type		6.6.1. Type
	The type of the message.		The type of the message.
	6.6.2. Reserved		6.6.2. Reserved
	An 8-bit reserved field. Sent as 0, ignored on receipt.		An 8-bit reserved field. Sent as 0, ignored on receipt.
	6.6.3. IP Multicast Data		6.6.3. IP Multicast Data
	skipping to change at page 23, line 14		skipping to change at page 24, line 14
	7. AMT Gateway Details		7. AMT Gateway Details
	This section details the behavior of an AMT Gateway, which may be a		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,		router serving an AMT site, or the site may consist of a single host,
	serving as its own gateway.		serving as its own gateway.
	7.1. At Startup Time		7.1. At Startup Time
	At startup time, the AMT gateway will bring up an AMT pseudo-		At startup time, the AMT gateway will bring up an AMT pseudo-
	interface, to be used for encapsulation. The gateway will then send		interface to be used for encapsulation. The gateway needs to
	an AMT Relay Discovery message to the AMT Relay Anycast Address, and		discover an AMT Relay to send Membership Requests. It can send an
	note the unicast address (which is treated as a link-layer address to		AMT Relay Discovery at startup time or wait until it has a group
	the encapsulation interface) from the AMT Relay Advertisement		membership to report. The AMT Relay Discovery message is sent to the
	message. This discovery SHOULD be done periodically (e.g., once a		AMT Relay Anycast Address. A unicast address (which is treated as a
	day) to re-resolve the unicast address of a close relay. The gateway		link-layer address to the encapsulation interface) is received in the
	also SHOULD initialize a timer used to send periodic membership		AMT Relay Advertisement message. The discovery process SHOULD be
	reports to a random value from the interval [0, [Query Interval]]		done periodically (e.g., once a day) to re-resolve the unicast
	before sending the first periodic report, in order to prevent startup		address of a close relay. To prevent startup synchronization, the
	synchronization (e.g., after a power outage).		timer SHOULD use at least 10 percent jitter.
	If the gateway is serving as a local router, it SHOULD also function		If the gateway is serving as a local router, it SHOULD also function
	as an IGMP/MLD Proxy, as described in [RFC4605], with its IGMP/MLD		as an IGMP/MLD Proxy, as described in [RFC4605], with its IGMP/MLD
	host-mode interface being the AMT pseudo-interface. This enables it		host-mode interface being the AMT pseudo-interface. This enables it
	to translate group memberships on its downstream interfaces into		to translate group memberships on its downstream interfaces into
	IGMP/MLD Reports. Hosts receiving multicast packets through an AMT		IGMP/MLD Reports. Hosts receiving multicast packets through an AMT
	gateway acting as a proxy should ensure that their M-RIB accepts		gateway acting as a proxy should ensure that their M-RIB accepts
	multicast packets from the AMT gateway for the sources it is joining.		multicast packets from the AMT gateway for the sources it is joining.
	7.2. Gateway Group and Source Addresses		7.2. Gateway Group and Source Addresses
	skipping to change at page 24, line 25		skipping to change at page 25, line 25
	+------------+------------------------+-------------+		+------------+------------------------+-------------+
	| SSM prefix | Low 16 bits of | Local |		| SSM prefix | Low 16 bits of | Local |
	| 232/8 | real source address | Policy |		| 232/8 | real source address | Policy |
	+------------+------------------------+-------------+		+------------+------------------------+-------------+
	Source:		Source:
	+-------------------------+-------------------------+		+-------------------------+-------------------------+
	|16-bit AMT unicast prefix| high 16 bits of real src|		|16-bit AMT unicast prefix| high 16 bits of real src|
	+-------------------------+-------------------------+		+-------------------------+-------------------------+
			IPv4 format
	This allows for 2^8 (256) IPv4 group addresses for use by each AMT		This allows for 2^8 (256) IPv4 group addresses for use by each AMT
	gateway. An allocation of a prefix with length 18 would allow for		gateway.
	2^6 (64) IPv4 group addresses.
	7.2.2. IPv6		7.2.2. IPv6
	Similarly for IPv6, this is illustrated in the following figure.		Similarly for IPv6, this is illustrated in the following figure.
	Group:		Group:
	32 64 32		32 64 32
	+------------+------------------------+-------------+		+------------+------------------------+-------------+
	| SSM prefix | Low 64 bits of | Local |		| SSM prefix | Low 64 bits of | Local |
	| FF3x::/32 | real source address | Policy |		| FF3x::/32 | real source address | Policy |
	+------------+------------------------+-------------+		+------------+------------------------+-------------+
	Source:		Source:
	+-------------------------+-------------------------+		+-------------------------+-------------------------+
	|64-bit AMT unicast prefix| high 64 bits of real src|		|64-bit AMT unicast prefix| high 64 bits of real src|
	+-------------------------+-------------------------+		+-------------------------+-------------------------+
			IPv6 format
	This allows for 2^32 (over 4 billion) IPv6 group addresses for use by		This allows for 2^32 (over 4 billion) IPv6 group addresses for use by
	each AMT gateway.		each AMT gateway.
	7.3. Joining Groups with MBone Sources		7.3. Joining Groups with MBone Sources
	The IGMP/MLD protocol usually operates by having the Querier		The IGMP/MLD protocol usually operates by having the Querier
	multicast an IGMP/MLD Query message on the link. This behavior does		multicast an IGMP/MLD Query message on the link. This behavior does
	not work on NBMA links which do not support multicast. Since the set		not work on NBMA links which do not support multicast. Since the set
	of gateways is typically unknown to the relay (and potentially quite		of gateways is typically unknown to the relay (and potentially quite
	large), unicasting the queries is also impractical. The following		large), unicasting the queries is also impractical. The following
	skipping to change at page 25, line 22		skipping to change at page 26, line 28
	in this document), the destination address in the outer IP header is		in this document), the destination address in the outer IP header is
	the relay's unicast address. Robustness is provided by the		the relay's unicast address. Robustness is provided by the
	underlying IGMP/MLD protocol messages sent on the AMT pseudo-		underlying IGMP/MLD protocol messages sent on the AMT pseudo-
	interface. In other words, the gateway does not need to retransmit		interface. In other words, the gateway does not need to retransmit
	IGMP/MLD Membership/Listener Reports and Leave/Done messages received		IGMP/MLD Membership/Listener Reports and Leave/Done messages received
	on the pseudo-interface since IGMP/MLD will already do this. The		on the pseudo-interface since IGMP/MLD will already do this. The
	gateway simply needs to encapsulate each IGMP/MLD Membership/Listener		gateway simply needs to encapsulate each IGMP/MLD Membership/Listener
	Report and Leave/Done message it receives.		Report and Leave/Done message it receives.
	However, since periodic IGMP/MLD Membership/Listener Reports are sent		However, since periodic IGMP/MLD Membership/Listener Reports are sent
	in response to IGMP/MLD Queries, some mechanism to trigger periodic		in response to IGMP/MLD Queries, a mechanism to trigger periodic
	Membership/Listener Reports and Leave/Done messages are necessary.		Membership/Listener Reports and Leave/Done messages is necessary.
	This can be achieved in any implementation-specific manner. Some		The gateway should use a timer to trigger periodic AMT Membership
	possibilities include:		Updates.
	1. The AMT pseudo-interface might periodically manufacture IGMPv3/
	MLDv2 Queries as if they had been received from an IGMP/MLD
	Querier, and deliver them to the IP layer, after which normal
	IGMP/MLD behavior will cause the appropriate reports to be sent.
	2. The IGMP/MLD module itself might provide an option to operate in
	periodic mode on specific interfaces.
	The Querier's Robustness Variable (QRV) defined in [RFC3376] and
	[RFC3810] can be used to adjust the number of Membership/Listener
	Reports that are sent by the host joining the group.
	If the gateway is behind a firewall device, the firewall may require		If the gateway is behind a firewall device, the firewall may require
	the gateway to periodically refresh the UDP state in the firewall at		the gateway to periodically refresh the UDP state in the firewall at
	a shorter interval than the standard IGMP/MLD Query interval.		a shorter interval than the standard IGMP/MLD Query interval. AMT
	Therefore, this IGMP/MLD Query interval should be configurable to		Requests can be sent periodically to solicit IGMP/MLD Queries. The
			interval at which the AMT Requests are sent should be configurable to
	ensure the firewall does not revert to blocking the UDP encapsulated		ensure the firewall does not revert to blocking the UDP encapsulated
	IP Multicast data packets.		IP Multicast data packets. When the AMT Query is received, it can be
			ignored unless it is time for a periodic AMT Membership Update.
			The relay can use the Querier's Robustness Variable (QRV) defined in
			[RFC3376] and [RFC3810] to adjust the number of Membership/Listener
			Reports that are sent by the host joining the group.
	7.4. Responding to Relay Changes		7.4. Responding to Relay Changes
	When a gateway determines that its current relay is unreachable		When a gateway determines that its current relay is unreachable
	(e.g., upon receipt of an ICMP Unreachable message [RFC0792] for the		(e.g., upon receipt of an ICMP Unreachable message [RFC0792] for the
	relay's unicast address), it may need to repeat relay address		relay's unicast address), it may need to repeat relay address
	discovery. However, care should be taken not to abandon the current		discovery. However, care should be taken not to abandon the current
	relay too quickly due to transient network conditions.		relay too quickly due to transient network conditions.
	7.5. Joining SSM Groups with AMT Gateway Sources		7.5. Joining SSM Groups with AMT Gateway Sources
	skipping to change at page 29, line 17		skipping to change at page 29, line 17
	to a pre-existing IGMP/MLD module.		to a pre-existing IGMP/MLD module.
	2. The IGMP/MLD module might have native support for explicit		2. The IGMP/MLD module might have native support for explicit
	membership tracking, especially if it supports other NBMA-style		membership tracking, especially if it supports other NBMA-style
	interfaces.		interfaces.
	If a relay wants to affect the rate at which the AMT Requests are		If a relay wants to affect the rate at which the AMT Requests are
	originated from a gateway, it can tune the membership timeout by		originated from a gateway, it can tune the membership timeout by
	adjusting the Querier's Query Interval Code (QQIC) field in the IGMP/		adjusting the Querier's Query Interval Code (QQIC) field in the IGMP/
	MLD Query contained within the AMT Membership Query message. The		MLD Query contained within the AMT Membership Query message. The
	QQIC field is defined in [RFC3376] and [RFC3810].		QQIC field is defined in [RFC3376] and [RFC3810]. However, since the
			gateway may need to send AMT Requests frequently enough to prevent
			firewall state from timing out, the relay may be limited in its
			ability to spread out Requests coming from a gateway by adjusting the
			QQIC field.
	8.4. Receiving (S,G) Joins from the Native Side, for AMT Sources		8.4. Receiving (S,G) Joins from the Native Side, for AMT Sources
	The relay sends an IGMPv3/MLDv2 report to the AMT source as described		The relay sends an IGMPv3/MLDv2 report to the AMT source as described
	above in Section 5.1.2		above in Section 5.1.2
	9. IANA Considerations		9. IANA Considerations
	9.1. IPv4 and IPv6 Anycast Prefix Allocation		9.1. IPv4 and IPv6 Anycast Prefix Allocation
	The IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated		The IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated
	to the public AMT Relays to advertise to the native multicast		to the public AMT Relays to advertise to the native multicast
	backbone. The prefix length should be determined by the IANA; the		backbone. The prefix length should be determined by the IANA; the
	prefix should be large enough to guarantee advertisement in the		prefix should be large enough to guarantee advertisement in the
	default-free BGP networks.		default-free BGP networks.
	9.1.1. IPv4		9.1.1. IPv4
	A prefix length of 18 will meet this requirement.		A prefix length of 16 will meet this requirement.
	9.1.2. IPv6		9.1.2. IPv6
	A prefix length of 32 will meet this requirement. IANA has		A prefix length of 32 will meet this requirement. IANA has
	previously set aside the range 2001::/16 for allocating prefixes for		previously set aside the range 2001::/16 for allocating prefixes for
	this purpose.		this purpose.
	9.2. IPv4 and IPv6 AMT Subnet Prefix Allocation		9.2. IPv4 and IPv6 AMT Subnet Prefix Allocation
	It should also be noted that this prefix length directly affects the		It should also be noted that this prefix length directly affects the
	number of groups available to be created by the AMT gateway: in the		number of groups available to be created by the AMT gateway: in the
	IPv4 case, a prefix length of 16 gives 256 groups, and a prefix		IPv4 case, a prefix length of 16 gives 256 groups, and a prefix
	length of 8 gives 65536 groups.		length of 8 gives 65536 groups.
	9.2.1. IPv4		9.2.1. IPv4
	As described above in Section 7.2.1 an IPv4 prefix with a length of		As described above in Section 7.2.1 an IPv4 prefix with a length of
	18 is requested for this purpose.		16 is requested for this purpose.
	9.2.2. IPv6		9.2.2. IPv6
	As described above in Section 7.2.2 an IPv6 prefix with a length of		As described above in Section 7.2.2 an IPv6 prefix with a length of
	48 is requested.		32 is requested.
	9.3. UDP Port number		9.3. UDP Port number
	IANA has previously allocated UDP reserved port number 2268 for AMT		IANA has previously allocated UDP reserved port number 2268 for AMT
	encapsulation.		encapsulation.
	All allocations are a one time effort and there will be no need for		All allocations are a one time effort and there will be no need for
	any recurring assignment after this stage.		any recurring assignment after this stage.
	10. Security Considerations		10. Security Considerations
	skipping to change at page 34, line 42		skipping to change at page 34, line 42
	[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host		[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host
	Anycasting Service", RFC 1546, November 1993.		Anycasting Service", RFC 1546, November 1993.
	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-		[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	Hashing for Message Authentication", RFC 2104,		Hashing for Message Authentication", RFC 2104,
	February 1997.		February 1997.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 2373, July 1998.
	[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6		[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
	Tunnel Broker", RFC 3053, January 2001.		Tunnel Broker", RFC 3053, January 2001.
	[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains		[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
	via IPv4 Clouds", RFC 3056, February 2001.		via IPv4 Clouds", RFC 3056, February 2001.
	[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",		[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
	RFC 3068, June 2001.		RFC 3068, June 2001.
			[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
			Architecture", RFC 4291, February 2006.
	[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,		[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
	"Protocol Independent Multicast - Sparse Mode (PIM-SM):		"Protocol Independent Multicast - Sparse Mode (PIM-SM):
	Protocol Specification (Revised)", RFC 4601, August 2006.		Protocol Specification (Revised)", RFC 4601, August 2006.
	Authors' Addresses		Authors' Addresses
	Dave Thaler		Dave Thaler
	Microsoft Corporation		Microsoft Corporation
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052-6399		Redmond, WA 98052-6399
	skipping to change at page 38, line 5		skipping to change at page 38, line 5
	Phone: +1 408 525 2530		Phone: +1 408 525 2530
	Email: lorenzo@cisco.com		Email: lorenzo@cisco.com
	Tom Pusateri		Tom Pusateri
	!j		!j
	222 E. Jones Ave.		222 E. Jones Ave.
	Wake Forest, NC 27587		Wake Forest, NC 27587
	USA		USA
	Email: pusateri@bangj.com		Email: pusateri@bangj.com
	Intellectual Property Statement		Full Copyright Statement
			Copyright (C) The IETF Trust (2007).
			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.
			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, THE IETF TRUST 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.
			Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 38, line 29		skipping to change at page 38, line 45
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		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
	Copyright (C) The Internet Society (2006). 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		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is provided by the IETF
	Internet Society.		Administrative Support Activity (IASA).
End of changes. 43 change blocks.
	153 lines changed or deleted		179 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/