draft-ietf-mboned-auto-multicast-09.txt		draft-ietf-mboned-auto-multicast-10.txt
	Network Working Group D. Thaler		Network Working Group D. Thaler
	Internet-Draft M. Talwar		Internet-Draft M. Talwar
	Intended status: Standards Track A. Aggarwal		Intended status: Standards Track A. Aggarwal
	Expires: December 29, 2008 Microsoft Corporation		Expires: September 8, 2010 Microsoft Corporation
	L. Vicisano		L. Vicisano
	Cisco Systems		Qualcomm Inc.
	T. Pusateri		T. Pusateri
	!j		!j
	June 27, 2008		March 7, 2010
	Automatic IP Multicast Without Explicit Tunnels (AMT)		Automatic IP Multicast Without Explicit Tunnels (AMT)
	draft-ietf-mboned-auto-multicast-09		draft-ietf-mboned-auto-multicast-10
			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 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.
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79.
	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.
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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 December 29, 2008.		This Internet-Draft will expire on September 8, 2010.
	Abstract		Copyright Notice
	Automatic Multicast Tunneling (AMT) allows multicast communication		Copyright (c) 2010 IETF Trust and the persons identified as the
	amongst isolated multicast-enabled sites or hosts, attached to a		document authors. All rights reserved.
	network which has no native multicast support. It also enables them
	to exchange multicast traffic with the native multicast		This document is subject to BCP 78 and the IETF Trust's Legal
	infrastructure and does not require any manual configuration. AMT		Provisions Relating to IETF Documents
	uses an encapsulation interface so that no changes to a host stack or		(http://trustee.ietf.org/license-info) in effect on the date of
	applications are required, all protocols (not just UDP) are handled,		publication of this document. Please review these documents
	and there is no additional overhead in core routers.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
			include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
			described in the BSD License.
			This document may contain material from IETF Documents or IETF
			Contributions published or made publicly available before November
			10, 2008. The person(s) controlling the copyright in some of this
			material may not have granted the IETF Trust the right to allow
			modifications of such material outside the IETF Standards Process.
			Without obtaining an adequate license from the person(s) controlling
			the copyright in such materials, this document may not be modified
			outside the IETF Standards Process, and derivative works of it may
			not be created outside the IETF Standards Process, except to format
			it for publication as an RFC or to translate it into languages other
			than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Requirements notation . . . . . . . . . . . . . . . . . . . . 7		3. Requirements notation . . . . . . . . . . . . . . . . . . . . 7
	4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. AMT Pseudo-Interface . . . . . . . . . . . . . . . . . . . 8		4.1. AMT Pseudo-Interface . . . . . . . . . . . . . . . . . . . 8
	4.2. AMT Gateway . . . . . . . . . . . . . . . . . . . . . . . 8		4.2. AMT Gateway . . . . . . . . . . . . . . . . . . . . . . . 8
	4.3. AMT Site . . . . . . . . . . . . . . . . . . . . . . . . . 8		4.3. AMT Site . . . . . . . . . . . . . . . . . . . . . . . . . 8
	skipping to change at page 3, line 21		skipping to change at page 4, line 9
	6.5. AMT Membership Update . . . . . . . . . . . . . . . . . . 21		6.5. AMT Membership Update . . . . . . . . . . . . . . . . . . 21
	6.5.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 21		6.5.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 21
	6.5.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 22		6.5.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 22
	6.5.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 22		6.5.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 22
	6.5.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 22		6.5.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 22
	6.5.5. IGMP/MLD Message (including IP Header) . . . . . . . . 22		6.5.5. IGMP/MLD Message (including IP Header) . . . . . . . . 22
	6.6. AMT IP Multicast Data . . . . . . . . . . . . . . . . . . 22		6.6. AMT IP Multicast Data . . . . . . . . . . . . . . . . . . 22
	6.6.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 23		6.6.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 23
	6.6.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 23		6.6.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 23
	6.6.3. IP Multicast Data . . . . . . . . . . . . . . . . . . 23		6.6.3. IP Multicast Data . . . . . . . . . . . . . . . . . . 23
	7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 24		6.7. AMT Membership Teardown . . . . . . . . . . . . . . . . . 23
	7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 24		6.7.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 24
	7.2. Gateway Group and Source Addresses . . . . . . . . . . . . 24		6.7.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 24
	7.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 25		6.7.3. Original Response MAC . . . . . . . . . . . . . . . . 24
	7.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 25		6.7.4. Original Request Nonce . . . . . . . . . . . . . . . . 24
	7.3. Joining Groups with MBone Sources . . . . . . . . . . . . 26		6.7.5. Original Source Port . . . . . . . . . . . . . . . . . 24
	7.4. Responding to Relay Changes . . . . . . . . . . . . . . . 26		6.7.6. Source AFI . . . . . . . . . . . . . . . . . . . . . . 24
	7.5. Joining SSM Groups with AMT Gateway Sources . . . . . . . 27		6.7.7. Original Source Address . . . . . . . . . . . . . . . 25
	7.6. Receiving AMT Membership Updates by the Gateway . . . . . 27		6.7.8. IGMP/MLD Message (including IP Header) . . . . . . . . 25
	7.7. Sending data to SSM groups . . . . . . . . . . . . . . . . 27		7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 26
	8. Relay Router Details . . . . . . . . . . . . . . . . . . . . . 28		7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 26
	8.1. At Startup time . . . . . . . . . . . . . . . . . . . . . 28		7.2. Gateway Group and Source Addresses . . . . . . . . . . . . 26
			7.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 27
			7.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 27
			7.3. Joining Groups with MBone Sources . . . . . . . . . . . . 28
			7.4. Responding to Relay Changes . . . . . . . . . . . . . . . 28
			7.5. Joining SSM Groups with AMT Gateway Sources . . . . . . . 29
			7.6. Receiving AMT Membership Updates by the Gateway . . . . . 29
			7.7. Sending data to SSM groups . . . . . . . . . . . . . . . . 29
			8. Relay Router Details . . . . . . . . . . . . . . . . . . . . . 30
			8.1. At Startup time . . . . . . . . . . . . . . . . . . . . . 30
	8.2. Receiving Relay Discovery messages sent to the Anycast		8.2. Receiving Relay Discovery messages sent to the Anycast
	Address . . . . . . . . . . . . . . . . . . . . . . . . . 28		Address . . . . . . . . . . . . . . . . . . . . . . . . . 30
	8.3. Receiving Membership Updates from AMT Gateways . . . . . . 28		8.3. Receiving Membership Updates from AMT Gateways . . . . . . 30
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 31
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
	9.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 30		9.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 32
	9.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 30		9.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 32
	9.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 30		9.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 32
	9.2. IPv4 and IPv6 AMT Subnet Prefix Allocation . . . . . . . . 30		9.2. IPv4 and IPv6 AMT Subnet Prefix Allocation . . . . . . . . 32
	9.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 30		9.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 32
	9.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 30		9.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 32
	9.3. UDP Port number . . . . . . . . . . . . . . . . . . . . . 30		9.3. UDP Port number . . . . . . . . . . . . . . . . . . . . . 32
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 31		10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 34		13.1. Normative References . . . . . . . . . . . . . . . . . . . 36
	13.2. Informative References . . . . . . . . . . . . . . . . . . 34		13.2. Informative References . . . . . . . . . . . . . . . . . . 36
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
	Intellectual Property and Copyright Statements . . . . . . . . . . 38
	1. Introduction		1. Introduction
	The primary goal of this document is to foster the deployment of		The primary goal of this document is to foster the deployment of
	native IP multicast by enabling a potentially large number of nodes		native IP multicast by enabling a potentially large number of nodes
	to connect to the already present multicast infrastructure.		to connect to the already present multicast infrastructure.
	Therefore, the techniques discussed here should be viewed as an		Therefore, the techniques discussed here should be viewed as an
	interim solution to help in the various stages of the transition to a		interim solution to help in the various stages of the transition to a
	native multicast network.		native multicast network.
	skipping to change at page 12, line 29		skipping to change at page 12, line 29
	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,		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.		the receiver SHOULD change its secret key at least once per hour.
	However, AMT Membership updates received with the previous secret		However, AMT Membership updates received with the previous secret
	MUST be accepted for up to the IGMP/MLD Query Interval.		MUST be accepted for up to the IGMP/MLD Query Interval.
			The condition might occur where the gateway or relay that initially
			sent the AMT Request dynamically changes its IP address. This might
			occur due to a change in wireless networks, a DHCP assignment, or
			another network failure. When this occurs, it is no longer possible
			to verify the MAC using the source address and source port. Though,
			in order to reduce state, it is desirable to tear down the state that
			was created with the old source address. A Teardown message with
			special considerations for calculating the MAC is described below to
			perform this function.
	5.1.3. 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. If it has no tunnel state with a Relay,		o Gateway receives report. If it has no tunnel state with a Relay,
	it originates an AMT Relay Discovery message addressed to the		it originates an AMT Relay Discovery message addressed to the
	skipping to change at page 17, line 49		skipping to change at page 17, line 49
	A 32-bit random value generated by the gateway and replayed by the		A 32-bit random value generated by the gateway and replayed by the
	relay.		relay.
	6.2. AMT Relay Advertisement		6.2. AMT Relay Advertisement
	The AMT Relay Advertisement message is a UDP packet sent from the AMT		The AMT Relay Advertisement message is a UDP packet sent from the AMT
	relay anycast address to the source of the discovery message.		relay anycast address to the source of the discovery message.
	The UDP source port is the IANA reserved AMT port number and the UDP		The UDP source port is the IANA reserved AMT port number and the UDP
	destination port is the source port received in the Discovery		destination port is the source port received in the Discovery
	message. The UDP checksum MUST be valid in AMT control messages.		message. The UDP CHECKSUM MUST be valid in AMT control messages.
	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=0x2 | Reserved |		| Type=0x2 | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Discovery Nonce |		| Discovery Nonce |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 22, line 36		skipping to change at page 22, line 36
	6.6. AMT IP Multicast Data		6.6. AMT IP Multicast Data
	The AMT Data message is a UDP packet encapsulating the IP Multicast		The AMT Data message is a UDP packet encapsulating the IP Multicast
	data requested by the originator based on a previous AMT Membership		data requested by the originator based on a previous AMT Membership
	Update message.		Update message.
	It is sent from the unicast destination address of the Membership		It is sent from the unicast destination address of the Membership
	update to the source address of the Membership Update.		update to the source address of the Membership Update.
	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 Query. The UDP checksum SHOULD be 0 in the AMT		sent in the original Query. The UDP checksum MUST be valid in AMT
	IP Multicast Data message.		control messages.
	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 ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ... |		| ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 24, line 5		skipping to change at page 23, line 18
	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
	The original IP Multicast data packet that is being replicated by the		The original IP Multicast data packet that is being replicated by the
	relay to the gateways including the original IP header.		relay to the gateways including the original IP header.
			6.7. AMT Membership Teardown
			An AMT Membership Teardown is sent to report an IGMP Membership Leave
			or MLD Listener Done after a valid Response MAC has been received and
			after the source address that was used to generate the Response MAC
			is no longer available for sourcing packets.
			An AMT Membership Teardown from the original source address and
			source port is NOT valid and should be discarded if received. Use an
			AMT Membership Update instead.
			An AMT Membership Teardown can only contain either an IGMP Membership
			Leave or an MLD Listener Done message. The encapsulated IGMP/MLD
			message will have to be fabricated by the sender of the AMT
			Membership Teardown in the case where there wasn't an original IGMP/
			MLD message to be forwarded.
			In order for the receiver to verify the Membership Teardown message,
			it must contain the original source address and source port in
			addition to the Original Request Nonce and Original Response MAC.
			It is sent to the source address received in the original Query which
			should be the same as the original Request.
			The UDP destination port number should be the same one sent in the
			original Request.
			The relay is not required to use the IP source address of the IGMP
			Membership Report for any particular purpose.
			0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type=0x7 | Reserved | Original Response MAC |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Original Response MAC (continued) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Original Request Nonce |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Original Source Port | Source AFI |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Original Source Address |
			| ... |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| IGMP Membership Leave or |
			| MLD Listener Done (including IP header) |
			| ... |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			AMT Membership Teardown
			6.7.1. Type
			The type of the message.
			6.7.2. Reserved
			A 8-bit reserved field. Sent as 0, ignored on receipt.
			6.7.3. Original Response MAC
			The 48-bit MAC received in the Membership Query and echoed back in
			the Membership Update.
			6.7.4. Original Request Nonce
			A 32-bit identifier used to distinguish this request.
			6.7.5. Original Source Port
			The 16-bit port number used in the original AMT Membership update
			that was used to generate the Original Response MAC.
			6.7.6. Source AFI
			A 16-bit Address Family Identifier (AFI) [RFC4760] used to determine
			the protocol address family of the following Original Source Address.
			Presently defined values for the Address Family Identifier field are
			specified in IANA's Address Family Numbers registry [IANA.AFN]
			6.7.7. Original Source Address
			The source address used in the original AMT Membership update that
			was used to generate the Original Response MAC.
			6.7.8. IGMP/MLD Message (including IP Header)
			The message contains either an IGMP Membership Leave or an MLD
			Listener Done. The IGMP or MLD version sent should be in response
			the version of the query received in the original AMT Membership
			Query. The IGMP/MLD Message includes a full IP Header.
	7. AMT Gateway Details		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 needs to		interface to be used for encapsulation. The gateway needs to
	skipping to change at page 34, line 5		skipping to change at page 35, line 19
	connectivity without explicit tunnels ("6to4"). Tony Ballardie		connectivity without explicit tunnels ("6to4"). Tony Ballardie
	provided helpful discussion that inspired this document.		provided helpful discussion that inspired this document.
	In addition, extensive comments were received from Pekka Savola, Greg		In addition, extensive comments were received from Pekka Savola, Greg
	Shepherd, Dino Farinacci, Toerless Eckert, Marshall Eubanks, John		Shepherd, Dino Farinacci, Toerless Eckert, Marshall Eubanks, John
	Zwiebel, and Lenny Giuliano.		Zwiebel, and Lenny Giuliano.
	Juniper Networks was instrumental in funding several versions of this		Juniper Networks was instrumental in funding several versions of this
	draft as well as an open source implementation.		draft as well as an open source implementation.
			Greg Shepherd suggested the inclusion of the AMT Membership Teardown
			message based on field experience.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,		[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
	RFC 792, September 1981.		RFC 792, September 1981.
	[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.		[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
	Thyagarajan, "Internet Group Management Protocol, Version		Thyagarajan, "Internet Group Management Protocol, Version
	3", RFC 3376, October 2002.		3", RFC 3376, October 2002.
	skipping to change at page 34, line 29		skipping to change at page 36, line 29
	[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,		[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
	"Internet Group Management Protocol (IGMP) / Multicast		"Internet Group Management Protocol (IGMP) / Multicast
	Listener Discovery (MLD)-Based Multicast Forwarding		Listener Discovery (MLD)-Based Multicast Forwarding
	("IGMP/MLD Proxying")", RFC 4605, August 2006.		("IGMP/MLD Proxying")", RFC 4605, August 2006.
	[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for		[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
	IP", RFC 4607, August 2006.		IP", RFC 4607, August 2006.
	13.2. Informative References		13.2. Informative References
			[IANA.AFN]
			IANA, "Address Family Numbers", <http://www.iana.org/
			assignments/address-family-numbers/
			address-family-numbers.txt>.
	[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,		[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
	RFC 1112, August 1989.		RFC 1112, August 1989.
	[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.
	skipping to change at page 36, line 5		skipping to change at page 37, line 15
	[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		[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 4291, February 2006.		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.
			[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
			"Multiprotocol Extensions for BGP-4", RFC 4760,
			January 2007.
	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
	USA		USA
	Phone: +1 425 703 8835		Phone: +1 425 703 8835
	Email: dthaler@microsoft.com		Email: dthaler@microsoft.com
	skipping to change at page 36, line 35		skipping to change at page 38, line 35
	Amit Aggarwal		Amit Aggarwal
	Microsoft Corporation		Microsoft Corporation
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052-6399		Redmond, WA 98052-6399
	USA		USA
	Phone: +1 425 706 0593		Phone: +1 425 706 0593
	Email: amitag@microsoft.com		Email: amitag@microsoft.com
	Lorenzo Vicisano		Lorenzo Vicisano
	Cisco Systems		Qualcomm Inc.
	170 West Tasman Dr.		3165 Kifer Road
	San Jose, CA 95134		Santa Clara, CA 95051
	USA		USA
	Phone: +1 408 525 2530		Email: vicisano@qualcomm.com
	Email: lorenzo@cisco.com
	Tom Pusateri		Tom Pusateri
	!j		!j
	222 E. Jones Ave.		2109 Mountain High Rd.
	Wake Forest, NC 27587		Wake Forest, NC 27587
	USA		USA
	Email: pusateri@bangj.com		Email: pusateri@bangj.com
	Full Copyright Statement
	Copyright (C) The IETF Trust (2008).
	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
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.
End of changes. 22 change blocks.
	59 lines changed or deleted		205 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/