draft-ietf-mboned-auto-multicast-11.txt		draft-ietf-mboned-auto-multicast-12.txt
	Network Working Group D. Thaler		Network Working Group G. Bumgardner
	Internet-Draft M. Talwar		Internet-Draft Cisco
	Intended status: Standards Track A. Aggarwal		Intended status: Standards Track T. Morin
	Expires: January 12, 2012 Microsoft Corporation		Expires: August 19, 2012 France Telecom - Orange
	L. Vicisano		February 16, 2012
	Qualcomm Inc.
	T. Pusateri
	!j
	T. Morin
	France Telecom - Orange
	July 11, 2011
	Automatic IP Multicast Tunneling		Automatic Multicast Tunneling
	draft-ietf-mboned-auto-multicast-11		draft-ietf-mboned-auto-multicast-12
	Abstract		Abstract
	Automatic IP Multicast Tunneling (AMT) allows multicast reception by		This document describes Automatic Multicast Tunneling (AMT), a
	isolated multicast-enabled sites or hosts, attached to a network		protocol for delivering multicast traffic from sources in a
	which has no native multicast support. It enables them to receive		multicast-enabled network to receivers that lack multicast
	multicast traffic from the native multicast infrastructure without		connectivity to the source network. The protocol uses UDP
	requiring any manual configuration. AMT uses an encapsulation		encapsulation and unicast replication to provide this functionality.
	interface so that no changes to a host stack or applications are
	required, all protocols (not just UDP) are handled, and there is no		The AMT protocol is specifically designed to support rapid deployment
	additional overhead in core routers.		by requiring minimal changes to existing network infrastructure.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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."
	This Internet-Draft will expire on January 12, 2012.		This Internet-Draft will expire on August 19, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 3, line 7		skipping to change at page 3, line 7
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Requirements notation . . . . . . . . . . . . . . . . . . . . 7		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8		3.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6
	4.1. AMT Pseudo-Interface . . . . . . . . . . . . . . . . . . . 8		3.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
	4.2. AMT Gateway . . . . . . . . . . . . . . . . . . . . . . . 8		3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7
	4.3. AMT Site . . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9
	4.4. AMT Relay . . . . . . . . . . . . . . . . . . . . . . . . 8		4.1. General Architecture . . . . . . . . . . . . . . . . . . . 9
	4.5. AMT Relay Anycast Prefix . . . . . . . . . . . . . . . . . 9		4.2. General Operation . . . . . . . . . . . . . . . . . . . . 18
	4.6. AMT Relay Anycast Address . . . . . . . . . . . . . . . . 9		5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 33
	5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10		5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 33
	5.1. Scalability Considerations . . . . . . . . . . . . . . . . 11		5.2. Gateway Operation . . . . . . . . . . . . . . . . . . . . 47
	5.2. Spoofing Considerations . . . . . . . . . . . . . . . . . 11		5.3. Relay Operation . . . . . . . . . . . . . . . . . . . . . 61
	5.3. Protocol Sequence . . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 72
	6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 15		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75
	6.1. Use of UDP . . . . . . . . . . . . . . . . . . . . . . . . 15		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 76
	6.2. AMT Relay Discovery . . . . . . . . . . . . . . . . . . . 15		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 77
	6.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 15		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 78
	6.2.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 15		10.1. Normative References . . . . . . . . . . . . . . . . . . . 78
	6.2.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 15		10.2. Informative References . . . . . . . . . . . . . . . . . . 78
	6.3. AMT Relay Advertisement . . . . . . . . . . . . . . . . . 16		Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 81
	6.3.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 84
	6.3.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 16
	6.3.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 16
	6.3.4. Relay Address . . . . . . . . . . . . . . . . . . . . 16
	6.4. AMT Request . . . . . . . . . . . . . . . . . . . . . . . 16
	6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 17
	6.4.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 17
	6.4.3. Request Nonce . . . . . . . . . . . . . . . . . . . . 17
	6.5. AMT Membership Query . . . . . . . . . . . . . . . . . . . 17
	6.5.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 18
	6.5.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 18
	6.5.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 19
	6.5.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 19
	6.5.5. IGMP/MLD Query (including IP Header) . . . . . . . . . 19
	6.5.6. Gateway information fields . . . . . . . . . . . . . . 19
	6.6. AMT Membership Update . . . . . . . . . . . . . . . . . . 19
	6.6.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 20
	6.6.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 20
	6.6.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 20
	6.6.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 21
	6.6.5. IGMP/MLD Message (including IP Header) . . . . . . . . 21
	6.7. AMT IP Multicast Data . . . . . . . . . . . . . . . . . . 21
	6.7.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 22
	6.7.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 22
	6.7.3. IP Multicast Data . . . . . . . . . . . . . . . . . . 22
	6.8. AMT Teardown . . . . . . . . . . . . . . . . . . . . . . . 22
	6.8.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 23
	6.8.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 23
	6.8.3. Original Response MAC . . . . . . . . . . . . . . . . 23
	6.8.4. Original Request Nonce . . . . . . . . . . . . . . . . 23
	6.8.5. Original Source Port . . . . . . . . . . . . . . . . . 23
	6.8.6. Original Source Address . . . . . . . . . . . . . . . 23
	7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 25
	7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 25
	7.2. Gateway identification . . . . . . . . . . . . . . . . . . 25
	7.3. Joining Multicast Groups . . . . . . . . . . . . . . . . . 26
	7.4. Responding to Relay Changes . . . . . . . . . . . . . . . 26
	8. AMT Relay Details . . . . . . . . . . . . . . . . . . . . . . 27
	8.1. At Startup time . . . . . . . . . . . . . . . . . . . . . 27
	8.2. Receiving Relay Discovery messages sent to the Anycast
	Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
	8.3. Receiving Membership Updates from AMT Gateways . . . . . . 27
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
	9.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 29
	9.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 29
	9.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 29
	9.2. UDP Port number . . . . . . . . . . . . . . . . . . . . . 29
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 33
	13.2. Informative References . . . . . . . . . . . . . . . . . . 33
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
	1. Introduction		1. Introduction
	The primary goal of this document is to foster the deployment of		The advantages and benefits provided by multicast technologies are
	native IP multicast by enabling a potentially large number of nodes		well known. There are a number of application areas that are ideal
	to connect to the already present multicast infrastructure.		candidates for the use of multicast, including media broadcasting,
	Therefore, the techniques discussed here should be viewed as an		video conferencing, collaboration, real-time data feeds, data
	interim solution to help in the various stages of the transition to a		replication, and software updates. Unfortunately, many of these
	native multicast network.		applications must currently rely on unicast replication at or near
			sources because most clients lack multicast connectivity to the
	To allow fast deployment, the solution presented here only requires		network containing the sources. The reasons for the lack of
	small and concentrated changes to the network infrastructure, and no		connectivity vary, but are primarily the result of service provider
	changes at all to user applications or to the socket API of end-		policies and network limitations.
	nodes' operating systems. The protocol introduced in this
	specification can be deployed in a few strategically-placed network
	nodes and in user-installable software modules (pseudo device drivers
	and/or user-mode daemons) that reside underneath the socket API of
	end-nodes' operating systems. This mechanism is very similar to that
	used by "6to4" [RFC3056], [RFC3068] to get automatic IPv6
	connectivity.
	Effectively, AMT treats the unicast-only inter-network as a large
	non-broadcast multi-access (NBMA) link layer, over which we require
	the ability to multicast. To do this, multicast packets being sent
	to site must be encapsulated in unicast packets. If the group has
	members in multiple sites, AMT encapsulation of the same multicast
	packet will take place multiple times by necessity.
	A previous of this solution was previously "Automatic IP Multicast		Automatic Multicast Tunneling (AMT) is a protocol that uses UDP-based
	without explicit Tunnels", to highlight the fact that the tunneling		encapsulation to overcome the aforementioned lack of multicast
	used is lightweight and does not require statically configured		connectivity. AMT enables sites, hosts or applications that do not
	tunnels used as point to point interfaces.		have native multicast access to a multicast source network to request
			and receive SSM [RFC4607] and ASM [RFC1112] multicast traffic from
			sources in that network.
	2. Applicability		2. Applicability
	AMT is not a substitute for native multicast or a statically		This document describes a protocol that may be used to deliver
	configured multicast tunnel for high traffic flow. Unicast		multicast traffic from sources in a multicast enabled network to
	replication is required to reach multiple receivers that are not part		sites that lack multicast connectivity to the source network. This
	of the native multicast infrastructure. However, this is no worse		document does not describe any methods for sourcing multicast traffic
	than regular unicast distribution of streams and in most cases much		from isolated sites as this topic is out of scope.
	better.
	This document specifies procedures allowing isolated sites to receive
	both general Any Source Multicast (ASM, [RFC1112]), and Specific
	Source Multicast (SSM, [RFC4607]).
	Earlier versions of this document were describing how to use AMT to		AMT is not intended to be used as a substitute for native multicast,
	allow isolated non-NAT sites/hosts to transmit SSM multicast ; the		especially in conditions or environments requiring high traffic flow.
	specifications for these functionalities have been left off the		AMT uses unicast replication to reach multiple receivers and the
	current document for the following reasons: the drawback that these		bandwidth cost for this replication will be higher than that required
	specifications required a source site Gateway to replicate traffic to		if the receivers were reachable via native multicast.
	many Relays in the multicast-enabled part of the network, lack of
	contributors to document alternative proposals based on AMT,
	existence of ways to offer similar functionality using Tunnel Broker
	approaches [RFC3053], or at the application layer.
	Implementers should be aware that site administrators may have		3. Terminology
	configured administratively scoped multicast boundaries and a remote
	gateway may provide a means to circumvent administrative boundaries.
	Therefore, implementations should allow for the configuration of such
	boundaries on relays and gateways and perform filtering as needed.
	3. Requirements notation		3.1. Requirements Notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	4. Definitions		3.2. Definitions
	+---------------+ Internet +---------------+		This document adopts the following definitions for use in describing
	| AMT Site | | Native MCast |		the protocol:
	| | | |
	| +------+----+ AMT +----+----+ |
	| |AMT Gateway| Anycast |AMT Relay| |
	| | +-----+-+ Prefix +-+-----+ | |
	| | |AMT IF | <------------|AMT IF | | |
	| | +-----+-+ +-+-----+ | |
	| +------+----+ +----+----+ |
	| | | |
	+---------------+ +---------------+
	4.1. AMT Pseudo-Interface		Downstream:
			A downstream interface or connection that faces away from the
			multicast distribution root or towards multicast receivers.
	AMT encapsulation of multicast packets inside unicast packets occurs		Upstream:
	at a point that is logically equivalent to an interface, with the		An upstream interface or connection that faces a multicast
	link layer being the unicast-only network. This point is referred to		distribution root or source.
	as a pseudo-interface. Some implementations may treat it exactly
	like any other interface and others may treat it like a tunnel end-
	point.
	4.2. AMT Gateway		Non-Broadcast Multi-Access (NMBA):
			A non-broadcast multiple-access (NBMA) network or interface is one
			to which multiple network nodes (hosts or routers) are attached,
			but where packets are transmitted directly from one node to
			another node over a virtual circuit or physical link. NBMA
			networks do not support multicast or broadcast traffic - a node
			that sources multicast traffic must replicate the multicast
			packets for separate transmission to each node that has requested
			the multicast traffic.
	A host, or a site gateway router, supporting an AMT Pseudo-Interface.		Multicast Receiver:
	It does not have native multicast connectivity to the native		An entity that requests and receives multicast traffic. A
	multicast backbone infrastructure. It is simply referred to in this		receiver may be a router, host, application, or application
	document as a "gateway".		component. The method by which a receiver transmits group
			membership requests and receives multicast traffic varies
			according to receiver type.
	4.3. AMT Site		Group Membership Database:
			A group membership database describes the current multicast
			subscription/reception sate for an interface or system.
	A multicast-enabled network not connected to the multicast backbone		Reception State:
	served by an AMT Gateway. It could also be a stand-alone AMT		The multicast subscription state of a pseudo, virtual or physical
	Gateway.		network interface. See group membership database.
	4.4. AMT Relay		Subscription:
			A group or state entry in a group membership database or reception
			state table.
	A multicast router configured to support transit routing between AMT		Group Membership Protocol:
	Sites and the native multicast backbone infrastructure. The relay		The term "group membership protocol" is used as a generic
	router has one or more interfaces connected to the native multicast		reference to the Internet Group Management (IGMP) ([RFC1112],
	infrastructure, zero or more interfaces connected to the non-		[RFC2236], [RFC3376]) or Multicast Listener Discovery ([RFC2710],
	multicast capable inter-network, and an AMT pseudo-interface. It is		[RFC3810]) protocols.
	simply referred to in this document as a "relay".
	As with [RFC3056], we assume that normal multicast routers do not		Multicast Protocol:
	want to be tunnel endpoints (especially if this results in high fan		The term "multicast protocol" is used as a generic reference to
	out). Instead, we assume that special-purpose routers will be		multicast routing protocols used to join or leave multicast
	deployed that are suitable for serving as relays.		distribution trees such as PIM-SM [RFC4601].
	4.5. AMT Relay Anycast Prefix		Network Address Translation (NAT):
			Network Address Translation is the process of modifying the source
			IP address and port numbers carried by an IP packet while
			transiting a network node (See [RFC2663]). Intervening NAT
			devices may change the source address and port carried by messages
			sent from an AMT gateway to an AMT relay, possibly producing
			changes in protocol state and behavior.
	A well-known address prefix used to advertise (into the unicast		Anycast:
	routing infrastructure) a route to an available AMT Relay Router.		A network addressing and routing method in which packets from a
	This could also be private (i.e., not well-known) for a private		single sender are routed to the topologically nearest node in a
	relay.		group of potential receivers all identified by the same
			destination address. See [RFC4786].
	Prefixes for both IPv4 and IPv6 will be assigned in a future version		3.3. Abbreviations
	of this draft.
	4.6. AMT Relay Anycast Address		AMT - Automatic Multicast Tunneling Protocol.
	An anycast address which is used to reach the nearest AMT Relay		ASM - Any-Source Multicast.
	Router.
	This address corresponds to the setting the low-order octet of the		DoS - Denial-of-Service (attack) and DDoS for distributed-DoS.
	AMT Relay Anycast Prefix to 1 (for both IPv4 and IPv6).
	5. Overview		IGMP - Internet Group Management Protocol (v1, v2 and v3).
	Internet		IP - Internet Protocol (v4 and v6).
	+---------------+ +---------------+
	| AMT Site | 2. 3-way Membership | Native MCast |
	| | Handshake | |
	| 1. Join +---+---+ =================> +---+---+ |
	| +---->|Gateway| | Relay | |
	| | +---+---+ <================= +---+---+ |
	| R-+ | 3. Receive Data | |
	+---------------+ +---------------+
	Receiving Multicast in an AMT Site		MAC - Message Authentication Code (or Cookie).
	AMT relays and gateways cooperate to transmit multicast traffic		MLD - Multicast Listener Discovery protocol (v1 and v2).
	sourced within the native multicast infrastructure to AMT sites:
	relays receive the traffic natively and unicast-encapsulate it to
	gateways; gateways decapsulate the traffic and possibly forward it
	into the AMT site.
	Each gateway has an AMT pseudo-interface that serves as a default		NAT - Network Address Translation (or translation node).
	multicast route. Requests to join a multicast session are sent to
	this interface and encapsulated to a particular relay reachable
	across the unicast-only infrastructure.
	Each relay has an AMT pseudo-interface too. Multicast traffic sent		NBMA - Non-Broadcast Multi-Access (network, interface or mode)
	on this interface is encapsulated to zero or more gateways that have
	joined to the relay. The AMT recipient-list is determined for each
	multicast session. This requires the relay to keep state for each
	gateway which has joined a particular group or (source, group) pair.
	Multicast packets from the native infrastructure behind the relay
	will be sent to each gateway which has requested them.
	All multicast packets (data and control) are encapsulated in unicast		SSM - Source-Specific Multicast.
	packets. UDP encapsulation is used for all AMT control and data
	packets using the IANA reserved UDP port number for AMT.
	Each relay, plus the set of all gateways using the relay, together		PIM - Protocol Independent Multicast.
	are thought of as being on a separate logical NBMA link. This
	implies that the AMT recipient-list is a list of "link layer"
	addresses which are (IP address, UDP port) pairs.
	Since the number of gateways using a relay can be quite large, and we		4. Protocol Overview
	expect that most sites will not want to receive most groups, an
	explicit-joining protocol is required for gateways to communicate
	group membership information to a relay. The two most likely
	candidates are the IGMP/MLD protocol [RFC3376], [RFC3810], and the
	PIM-Sparse Mode protocol [RFC4601]. Since an AMT gateway may be a
	host, and hosts typically do not implement routing protocols,
	gateways will use IGMP/MLD as described in Section 7 below. This
	allows a host kernel (or a pseudo device driver) to easily implement
	AMT gateway behavior, and obviates the relay from the need to know
	whether a given gateway is a host or a router. From the relay's
	perspective, all gateways are indistinguishable from hosts on an NBMA
	leaf network.
	5.1. Scalability Considerations		This section provides an informative description of the protocol. A
			normative description of the protocol and implementation requirements
			may be found in section Section 5.
	It is possible that millions of hosts will enable AMT gateway		4.1. General Architecture
	functionality and so an important design goal is not to create
	gateway state in each relay until the gateway joins a multicast
	group. But even the requirement that a relay keep group state per
	gateway that has joined a group introduces potential scalability
	concerns.
	Scalability of AMT can be achieved by adding more relays, and using		Isolated Site | Unicast Network | Native Multicast
	an appropriate relay discovery mechanism for gateways to discover		| (Internet) |
	relays. The solution we adopt is to assign addresses in anycast		| |
	fashion to relays [RFC1546], [RFC4291]. However, simply sending		| |
	periodic membership reports to an anycast address can cause		| Group Membership |
	duplicates. Specifically, if routing changes such that a different		+-------+ ===========================> +-------+ Multicast +------+
	relay receives a periodic membership report, both the new and old		|Gateway| | | | Relay |<----//----|Source|
	relays will encapsulate data to the AMT site until the old relay's		+-------+ <=========================== +-------+ +------+
	state times out. This is obviously undesirable. Instead, we use the		| Multicast Data |
	anycast address merely to find the unicast address of a relay to		| |
	which membership reports are sent.		| |
	This approach allows the gateways to be spread out among more relays		Figure 1: Basic AMT Architecture
	so as to keep the number of gateways per relay at a reasonable level.
	5.2. Spoofing Considerations		The AMT protocol employs a client-server model in which a "gateway"
			sends requests to receive specific multicast traffic to a "relay"
			which responds by delivering the requested multicast traffic back to
			the gateway.
	An attacker could affect the group state in the relay by spoofing the		Gateways are generally deployed within networks that lack multicast
	source address in AMT Update messages containing join or leave		support or lack connectivity to a multicast-enabled network
	reports. This can be used to launch reflection or denial of service		containing multicast sources of interest.
	attacks on the target Relay. Such attacks can be mitigated by using
	a three way handshake between the gateway and the relay for each
	multicast membership report or leave.
	When a gateway wants to send a membership report, it first sends an		Relays are deployed within multicast-enabled networks that contain,
	AMT Request with a request nonce in it. The Relay can calculate a		or have connectivity to, multicast sources.
	message authentication code (MAC) based on (for example)the source IP
	address of the Request, the source UDP port, the request nonce, and a
	secret key known only to the Relay. The algorithm does not have to
	be standardized since the Relay generates and verifies the MAC and
	the Gateway simply echoes it back, but an algorithm such as
	HMAC-MD5-48 [RFC2104] SHOULD be used at a minimum.
	An AMT Membership Query is sent back to the gateway having originated		4.1.1. Relationship to IGMP and MLD Protocols
	the Request, including the request nonce and the MAC. The gateway
	then sends the IGMP/MLD Membership/Listener Report or Leave/Done
	(including the IP Header) along with the request nonce and the
	received MAC back to the relay, finalizing the 3-way handshake.
	Upon reception, the relay can recalculate the MAC based on the source		AMT relies on the Internet Group Management (IGMP) [RFC3376] and
	IP address, the source UDP port, the request nonce, and the local		Multicast Listener Discovery (MLD) [RFC3810] protocols to provide the
	secret. The IGMP/MLD message is only accepted if the received MAC		functionality required to manage, communicate, and act on changes in
	matches the calculated MAC.		multicast group membership. A gateway or relay implementation does
			not necessarily require a fully-functional, conforming implementation
			of IGMP or MLD to adhere to this specification, but the protocol
			description that appears in this document assumes that this is the
			case. The minimum functional and behavioral requirements for the
			IGMP and MLD protocols are described in Section 5.2.1 and
			Section 5.3.1.
	A relay MUST NOT create state for a gateway before successful		Gateway Relay
	validation of a MAC of an AMT Update from this gateway; a relay
	SHOULD delete all states for a gateway after a small timer after it
	stops having any AMT forwarding state for a Gateway (i.e. the Gateway
	left all multicast groups it had joined).
	The local secret never has to be shared with the other side. It is		General _____ _____
	only used to verify return routability of the originator.		___________ Query | | | | Query ___________
			| |<------| | | |<------| |
			| Host Mode | | AMT | | AMT | |Router Mode|
			| IGMP/MLD | | | UDP | | | IGMP/MLD |
			|___________|------>| |<----->| |------>|___________|
			Report | | | | Report
			Leave/Done | | | | Leave/Done
			| | | |
			IP Multicast <------| | | |<------ IP Multicast
			|_____| |_____|
	Since the same Request Nonce and source IP address can be re-used,		Multicast Reception State Managed By IGMP/MLD
	the relay SHOULD change its secret key at least once per hour.
	However, AMT Membership updates received with the previous secret
	MUST be accepted for up to the IGMP/MLD Query Interval.
	The condition might occur where the gateway that initially sent the		A gateway runs the host portion of the IGMP and MLD protocols to
	AMT Request dynamically changes its IP address. This might occur due		generate group membership updates that are sent via AMT messages to a
	to a change in wireless networks, a DHCP assignment, or another		relay. A relay runs the router portion of the IGMP and MLD protocols
	network failure. When this occurs, it is no longer possible to		to process the group membership updates to produce the required
	verify the MAC using the source address and source port. Though, in		changes in multicast forwarding state. A relay uses AMT messages to
	order to reduce state, it is desirable to tear down the state that		send incoming multicast IP datagrams to gateways according to their
	was created with the old source address. A Teardown message with		current group membership state.
	special considerations for calculating the MAC is described below to
	perform this function.
	5.3. Protocol Sequence		The primary function of AMT is to provide the handshaking,
			encapsulation and decapsulation required to transport the IGMP and
			MLD messages and multicast IP datagrams between the gateways and
			relays. The IGMP and MLD messages that are exchanged between
			gateways and relays are encapsulated as complete IP datagrams within
			AMT control messages. Multicast IP datagrams are replicated and
			encapsulated in AMT data messages. All AMT messages are sent via
			unicast UDP/IP.
	This description assumes the Gateway can be a host joining as a		4.1.2. Gateways
	receiver or a network device acting as a Gateway when a directly
	connected host joins as a receiver.
	Protocol sequence for a multicast SSM channel (S1,G1):		The downstream side of a gateway services multicast receivers - the
			gateway accepts group membership requests from receivers and forwards
			requested multicast traffic back to those receivers.
	o Receiver at AMT site sends IGMPv3/MLDv2 report joining (S1,G1).		The upstream side of a gateway connects to relays. A gateway sends
			encapsulated IGMP and MLD messages to a relay to indicate an interest
			in receiving specific multicast traffic.
	o Gateway receives report. If it has no tunnel state with a Relay,		4.1.2.1. Architecture
	it originates an AMT Relay Discovery message addressed to the
	Anycast Relay IP address. The AMT Relay Discovery message can be
	sent on demand if no relay is known at this time or at startup and
	be periodically refreshed.
	o The closest Relay topologically receives the AMT Relay Discovery		Each gateway possesses a logical pseudo-interface:
	message and returns the nonce from the Discovery in an AMT Relay
	Advertisement message so the Gateway can learn of the Relay's
	unique IP address.
	o When the Gateway receives the AMT Relay Advertisement message, it		join/leave ---+ +----------+
	now has an address to use for all subsequent (S,G) entries it will		| | |
	join on behalf of attached receivers (or itself).		V IGMPv3/MLDv2 | |
			+---------+ General Query| | AMT
			|IGMP/MLD |<-------------| AMT | Messages +------+
			|Host Mode| | Gateway |<-------->|UPD/IP|
			|Protocol |------------->|Pseudo I/F| +------+
			+---------+ IGMP/MLD | | ^
			Report | | |
			Leave/Done | | V
			IP Multicast <---------------------| | +---+
			+----------+ |I/F|
			+---+
	o If the gateway has a valid Response MAC from a previous AMT Query		Figure 2: AMT Gateway Pseudo-Interface
	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		The pseudo-interface is conceptually a network interface on which the
	nonce from the Request in a AMT Query message. The Query message		gateway executes the host portion of the IPv4/IGMP (v2 or v3) and
	contains an IGMP/MLD QUERY indicating how often the Gateway should		IPv6/MLD (v1 or v2) protocols. The multicast reception state of the
	repeat AMT Request messages so the (S,G) state can stay refreshed		pseudo-interface is manipulated using the IGMP or MLD service
	in the Relay. The Query message also includes an opaque security		interface. The IGMP and MLD host protocols produce IP datagrams
	code which is generated locally (with no external coordination).		containing group membership messages that the gateway will send to
			the relay. The IGMP and MLD protocols also supply the retransmission
			and timing behavior required for protocol robustness.
	o When the Gateway receives the AMT Query message it responds by		All AMT encapsulation, decapsulation and relay interaction is assumed
	copying the security code from the AMT Query message into a AMT		to occur within the pseudo-interface.
	Membership Update message. The Update message contains (S1,G1) in
	an IGMPv3/MLDv2 formatted packet with an IP header. The nonce
	from the AMT Request is also included in the AMT Membership Update
	message.
	o When the Relay receives the AMT Membership Update, it will add the		A gateway host or application may create separate interfaces for
	tunnel to the Gateway in it's outgoing interface list for it's		IPv4/IGMP and IPv6/MLD. A gateway host or application may also
	(S1,G1) entry stored in the multicast routing table. If the		require additional pseudo-interfaces for each source or domain-
	(S1,G1) entry was created do to this interaction, the multicast		specific relay address.
	routing protocol running on the Relay will trigger a Join message
	towards source S1 to build a native multicast tree in the native
	multicast infrastructure.
	o As packets are sent from the host S1, they will travel natively		Within this document, the term "gateway" may be used as a generic
	down the multicast tree associated with (S1,G1) in the native		reference to an entity executing the gateway protocol, a gateway
	multicast infrastructure to the Relay. The Relay will replicate		pseudo-interface, or a gateway device that has one or more interfaces
	to all interfaces in it's outgoing interface list as well as the		connected to a unicast inter-network and one or more AMT gateway
	tunnel outgoing interface, which is encapsulated in a unicast AMT		pseudo-interfaces.
	Multicast Data message.
	o When the Gateway receives the AMT Multicast Data message, it will		The following diagram illustrates how an existing host IP stack
	accept the packet since it was received over the pseudo-interface		implementation might be used to provide AMT gateway functionality to
	associated with the tunnel to the Relay it had attached to, and		a multicast application:
	forward the packet to the outgoing interfaces joined by any
	attached receiver hosts (or deliver the packet to the application
	when the Gateway is the receiver).
	o If later (S2,G2) is joined by a receiver, a 3-way handshake of		+-----------------------------------------------------+
	Request/ Query/Update occurs for this entry. The Discovery/		|Host |
	Advertisement exchange is not required.		| ______________________________________ |
			| | | |
			| | ___________________________ | |
			| | | | | |
			| | | v | |
			| | | +-----------+ +--------------+ |
			| | | |Application| | AMT Daemon | |
			| | | +-----------+ +--------------+ |
			| | | join/leave | ^ data ^ AMT |
			| | | | | | |
			| | | +----|---|-------------|-+ |
			| | | | __| |_________ | | |
			| | | | | | | | |
			| | | | | Sockets | | | |
			| | | +-|------+-------+-|---|-+ |
			| | | | | IGMP | TCP | |UDP| | |
			| | | +-|------+-------+-|---|-+ |
			| | | | | ^ IP | | | |
			| | | | | | ____________| | | |
			| | | | | | | | | |
			| | | +-|-|-|----------------|-+ |
			| | | | | | | |
			| | | IP(IGMP)| | |IP(UDP(data)) |IP(UDP(AMT)) |
			| | | v | | v |
			| | | +-----------+ +---+ |
			| | | |Virtual I/F| |I/F| |
			| | | +-----------+ +---+ |
			| | | | ^ ^ |
			| | | IP(IGMP)| |IP(UDP(data)) | |
			| | |_________| |IP(IGMP) | |
			| | | | |
			| |_________________| | |
			| | |
			+--------------------------------------|--------------+
			v
			AMT Relay
	o To keep the state for (S1,G1) and (S2,G2) alive in the Relay, the		Virtual Interface Implementation Example
	Gateway will send periodic AMT Membership Updates. The Membership
	Update can be sent directly if the sender has a valid nonce from a
	previous Request. If not, an AMT Request messages should be sent
	to solicit a Query Message. When sending a periodic state
	refresh, all joined state in the Gateway is packed in the fewest
	number of AMT Membership Update messages.
	o When the Gateway leaves all (S,G) entries, the Relay can free		In this example, the host IP stack uses a virtual network interface
	resources associated with the tunnel. It is assumed that when the		to interact with a gateway pseudo-interface implementation.
	Gateway would want to join an (S,G) again, it would start the
	Discovery/Advertisement tunnel establishment process over again.
	This same procedure would be used for receivers who operate in Any-		4.1.2.2. Use-Cases
	Source Multicast (ASM) mode.
	6. Message Formats		Use-cases for gateway functionality include:
	6.1. Use of UDP		IGMP/MLD Proxy
			An IGMP/MLD proxy that runs AMT on an upstream interface and
			router-mode IGMP/MLD on downstream interfaces to provide host
			access to multicast traffic via the IGMP and MLD protocols.
	All AMT messages are UDP packets.		Virtual Network Interface
			A virtual network interface or pseudo network device driver that
			runs AMT on a physical network interface to provide socket layer
			access to multicast traffic via the IGMP/MLD service interface
			provided by the host IP stack.
	Messages sent to the Relay are sent to the IANA reserved AMT port		Application
	number (Section 9), from a source port uniquely selected by the host		An application or application component that implements and
	operating system of the Gateway. Messages sent by the Relay are sent		executes IGMP/MLD and AMT internally to gain access to multicast
	from the IANA reserved AMT port number.		traffic.
	The UDP checksum MUST be valid in all AMT control messages (Relay		4.1.3. Relays
	Discovery, Relay Advertisement, Membership Request, Membership Query,
	Membership Update). Section 6.7 specifies the behavior with
	reference to the UDP checksums of AMT IP Multicast Data messages.
	6.2. AMT Relay Discovery		The downstream side of a relay services gateways - the relay accepts
			encapsulated IGMP and MLD group membership messages from gateways and
			encapsulates and forwards the requested multicast traffic back to
			those gateways.
	The AMT Relay Discovery message is sent from the AMT gateway unicast		The upstream side of a relay communicates with a native multicast
	address to the AMT Relay Anycast address to discover the unicast		infrastructure - the relay sends join and prune/leave requests
	address of an AMT relay.		towards multicast sources and accepts requested multicast traffic
			from those sources.
	The payload of the UDP packet contains the following fields.		4.1.3.1. Architecture
			Each relay possesses a logical pseudo-interface:
			+------------------------------+
			+--------+ | Multicast Control Plane |
			| |IGMP/MLD| |
			| | Query* | +------------+ +----------+ |
			| |<---//----|IGMPv3/MLDv2| | | |
			AMT | | | |Router Mode |->| PIM-SM |<-->
			+------+ Messages | AMT |----//--->|Protocol | | | |
			|UDP/IP|<-------->| Relay |IGMP/MLD| +------------+ +----------+ |
			+------+ | Pseudo | Report | | | |
			^ | I/F | Leave/ +------|---------------|-------+
			| | | Done | |
			| | | v |
			V | | IP +-----------+ |
			+---+ | | Multicast |Multicast |<------+
			|I/F| | |<---//-----|Forwarding |
			+---+ +--------+ |Plane |<--- IP Multicast
			+-----------+
			* Queries, if generated, are consumed by the pseudo-interface.
			AMT Relay Pseudo-Interface (Router-Based)
			The pseudo-interface is conceptually a network interface on which the
			relay runs the router portion of the IPv4/IGMPv3 and IPv6/MLDv2
			protocols. Relays do not send unsolicited IGMPv3/MLDv2 query
			messages to gateways so relays must consume or discard any local
			queries normally generated by IGMPv3 or MLDv2.
			A relay maintains group membership state for each gateway connected
			through the pseudo-interface as well as for the entire pseudo-
			interface (if multiple gateways are managed via a single interface).
			Multicast packets received on upstream interfaces on the relay are
			routed to the pseudo-interface where they are replicated,
			encapsulated and sent to interested gateways. Changes in the pseudo-
			interface group membership state may trigger the transmission of
			multicast protocol requests upstream towards a given source or
			rendezvous point and cause changes in internal routing/forwarding
			state.
			The relay pseudo-interface is a architectural abstraction used to
			describe AMT protocol operation. For the purposes of this document,
			the pseudo-interface is most easily viewed as an interface to a
			single gateway - encapsulation, decapsulation, and other AMT-specific
			processing occurs "within" the pseudo-interface while forwarding and
			replication occur outside of it.
			An alternative view is to treat the pseudo-interface as a non-
			broadcast multi-access (NBMA) network interface whose link layer is
			the unicast-only network over which AMT messages are exchanged with
			gateways. Individual gateways are conceptually treated as logical
			NBMA links on the interface. In this architectural model, group
			membership tracking, replication and forwarding functions occur in
			the pseudo-interface.
			This document does not specify any particular architectural solution
			- a relay developer may choose to implement and distribute protocol
			functionality as required to take advantage of existing relay
			platform services and architecture.
			Within this document, the term "relay" may be used as a generic
			reference to an entity executing the relay protocol, a relay pseudo-
			interface, or a relay device that has one or more network interfaces
			with multicast connectivity to a native multicast infrastructure,
			zero or more interfaces connected to a unicast inter-network, and one
			or more relay pseudo-interfaces.
			4.1.3.2. Use-Cases
			Use-cases for relay functionality include:
			Multicast Router
			A multicast router that runs AMT on a downstream interface to
			provide gateway access to multicast traffic. A "relay router"
			uses a multicast routing protocol (e.g. PIM-SM RFC4601 [RFC4601])
			to construct a forwarding path for multicast traffic by sending
			join and prune messages to neighboring routers to join or leave
			multicast distribution trees for a given SSM source or ASM
			rendezvous point.
			IGMP/MLD Proxy Router
			An IGMP/MLD proxy that runs AMT on a downstream interface and
			host-mode IGMPv3/MLDv2 on a upstream interface. This "relay
			proxy" sends group membership reports to a local, multicast-
			enabled router to join and leave specific SSM or ASM groups.
			4.1.4. Deployment
			The AMT protocol calls for a relay deployment model that uses anycast
			addressing [RFC1546][RFC4291] to pair gateways with relays.
			Under this approach, one or more relays advertise a route for the
			same IP address prefix. To find a relay with which to communicate, a
			gateway sends a message to an anycast IP address within that prefix.
			This message is routed to the topologically-nearest relay that has
			advertised the prefix. The relay that receives the message responds
			by sending its unicast address back to the gateway. The gateway uses
			this address as the destination address for any messages it
			subsequently sends to the relay.
			The use of anycast addressing provides the following benefits:
			o Relays may be deployed at multiple locations within a single
			multicast-enabled network. Relays might be installed "near"
			gateways to reduce bandwidth requirements, latency and limit the
			number of gateways that might be serviced by a single relay.
			o Relays may be added or removed at any time thereby allowing staged
			deployment, scaling and hot-swapping - the relay discovery process
			will always return the nearest operational relay.
			o Relays may take themselves offline when they exhaust resources
			required to service additional gateways. Existing gateway
			connections may be preserved, but new gateway requests would be
			routed to the next-nearest relay.
			4.1.4.1. Public Versus Private
			Ideally, the AMT protocol would provide a universal solution for
			connecting gateways to multicast sources - that any gateway would be
			able to access any globally advertised multicast source via publicly-
			accessible, widely-deployed relays. Unfortunately, today's internet
			does not yet allow this, as many relays will lack native multicast
			access to sources even though they may be globally accessible via
			unicast.
			In these cases, a provider may deploy relays within their own source
			network to allow for multicast distribution within that network.
			Gateways that use these relays must use a provider-specific relay
			discovery mechanism or a private anycast address to obtain access to
			these relays.
			4.1.5. Discovery
			To execute the gateway portion of the protocol, a gateway requires a
			unicast IP address of an operational relay. This address may be
			obtained using a number of methods - it may be statically assigned or
			dynamically chosen via some form of relay discovery process.
			As described in the previous section, the AMT protocol provides a
			relay discovery method that relies on anycast addressing. Gateways
			are not required to use AMT relay discovery, but all relay
			implementations must support it.
			The AMT protocol uses the following terminology when describing the
			discovery process:
			Relay Discovery Address Prefix:
			The anycast address prefix used to route discovery messages to a
			relay.
			Relay Discovery Address:
			The anycast destination address used when sending discovery
			messages.
			Relay Address:
			The unicast IP address obtained as a result of the discovery
			process.
			4.1.5.1. Relay Discovery Address Selection
			The selection of an anycast Relay Discovery Address may be source-
			dependent, as a relay located via relay discovery must have multicast
			connectivity to a desired source.
			Similarly, the selection of a unicast Relay address may be source-
			dependent, as a relay contacted by a gateway to supply multicast
			traffic must have native multicast connectivity to the traffic source
			Methods that might be used to perform source-specific or group-
			specific relay selection are highly implementation-dependent and are
			not further addressed by this document. Possible approaches include
			the use of static lookup tables, DNS-based queries, or a provision of
			a service interface that accepts join requests on (S,G,relay-
			discovery-address) or (S,G,relay-address) tuples.
			4.1.5.2. IANA-Assigned Relay Discovery Address Prefix
			This document calls for IANA to allocate an anycast address prefix
			for use in advertising and discovering publicly accessible relays.
			A relay discovery address is constructed from the anycast address
			prefix by setting the low-order octet of the prefix address to 1 (for
			both IPv4 and IPv6).
			Public relays must advertise a route to the anycast address prefix
			and configure an interface to respond to the relay discovery address.
			The IANA address assignments are discussed in Section 7.
			4.2. General Operation
			4.2.1. Message Sequences
			The AMT protocol defines the following messages for control and
			encapsulation. These messages are exchanged as UDP/IP datagrams, one
			message per datagram.
			Relay Discovery:
			Sent by gateways to solicit a Relay Advertisement from any relay
			in order to find a relay with which to communicate.
			Relay Advertisement:
			Sent by relays as a response to a Relay Discovery message. Used
			to deliver a relay address to a gateway.
			Request:
			Sent by gateways to solicit a Membership Query message from a
			relay.
			Membership Query:
			Sent by relays as a response to a Request message. Used to
			deliver an encapsulated IGMPv3 or MLDv2 query message to the
			gateway.
			Membership Update:
			Sent by gateways to deliver an encapsulated IGMP or MLD report/
			leave/done message to a relay.
			Multicast Data:
			Sent by relays to deliver an encapsulated IP multicast datagram to
			a gateway.
			Teardown:
			Sent by gateways to stop the delivery of Multicast Data messages
			requested in an earlier Membership Update message.
			The following sections describe how these messages are exchanged to
			execute the protocol.
			4.2.1.1. Relay Discovery Sequence
			Gateway Relay
			------- -----
			: :
			| |
			[1] |Relay Discovery |
			|------------------->|
			| |
			| Relay Advertisement| [2]
			|<-------------------|
			[3] | |
			: :
			AMT Relay Discovery Sequence
			The following sequence describes how the Relay Discovery and Relay
			Advertisement messages are used to find a relay with which to
			communicate:
			1. The gateway sends a Relay Discovery message containing a random
			nonce to the Relay Discovery Address. If the Relay Discovery
			Address is an anycast address, the message is routed to
			topologically-nearest network node that advertises that address.
			2. The node receiving the Relay Discovery message sends a Relay
			Advertisement message back to the source of the Relay Discovery
			message. The message carries a copy of the nonce contained in
			the Relay Discovery message and the unicast IP address of a
			relay.
			3. When the gateway receives the Relay Advertisement message it
			verifies that the nonce matches the one sent in the Relay
			Discovery message, and if it does, uses the relay address carried
			by the Relay Advertisement as the destination address for
			subsequent AMT messages.
			Note that the responder need not be a relay - the responder may
			obtain a relay address by some other means and return the result in
			the Relay Advertisement (i.e. the responder is a load-balancer or
			broker).
			4.2.1.2. Membership Update Sequence
			There exists a significant difference between normal IGMP and MLD
			behavior and that required by AMT. An IGMP/MLD router acting as a
			querier normally transmits query messages on a network interface to
			construct and refresh group membership state for the connected
			network. These query messages are multicast to all IGMP/MLD enabled
			hosts on the network. Each host responds by multicasting report
			messages that describe their current multicast reception state.
			However, AMT does not allow relays to send unsolicited query messages
			to gateways, as the set of active gateways may be unknown to the
			relay and potentially quite large. Instead, AMT requires each
			gateway to periodically send a message to a relay to solicit a
			general-query response. A gateway accomplishes this by sending a
			Request message to a relay. The relay responds by sending Membership
			Query message back to the gateway. The Membership Query message
			carries an encapsulated general query that is processed by the IGMP
			or MLD protocol implementation on the gateway to produce a
			membership/listener report. Each time the gateway receives a
			Membership Query message it starts a timer whose expiration will
			trigger the start of a new Request->Membership Query message
			exchange. This timer-driven sequence is used to mimic the
			transmission of a periodic general query by an IGMP/MLD router. This
			query cycle may continue indefinitely once started by sending the
			initial Request message.
			A membership update occurs when an IGMP or MLD report, leave or done
			message is passed to the gateway pseudo-interface. These messages
			may be produced as a result of the aforementioned general-query
			processing or as a result of receiver interaction with the IGMP/MLD
			service interface. Each report is encapsulated and sent to the relay
			after the gateway has successfully established communication with the
			relay via a Request and Membership Query message exchange. If a
			report is passed to the pseudo-interface before the gateway has
			received a Membership Query message from the relay, the gateway may
			discard the report or queue the report for delivery after a
			Membership Query is received. Subsequent IGMP/MLD report/leave/done
			messages that are passed to the pseudo-interface are immediately
			encapsulated and transmitted to the relay.
			IGMP/MLD Pseudo-I/F Relay
			-------- ---------- -----
			: : :
			| | Request |
			| 1|-------------------->|
			| | Membership Query |2
			Query | | Q(0,{}) |
			Timer | Start 3|<--------------------|
			(QT)<--------------------------| |
			| Q(0,{}) | |
			|<--------------------| |
			4| R({}) | Membership Update |
			|-------------------->|5 R({}) |
			| |====================>|6a
			Join(S,G) : : :
			()--------->|7 R({G:ALLOW({S})}) | Membership Update |
			|-------------------->|8 R({G:ALLOW({S})}) |
			| |====================>|9a Join(S,G)
			| | |---------->()
			: : :
			| ------------|---------------------|------------
			| | | | |
			| | | Multicast Data | IP(S,G) |
			| | | IP(S,G) 10|<--------() |
			| | IP(S,G) 11|<====================| |
			| | ()<--------| | |
			| | | | |
			: ------------:---------------------:------------
			| Expired | |
			(QT)-------------------------->|12 Request |
			| 1|-------------------->|
			| | Membership Query |2
			| | Q(0,{}) |
			| Start 3|<--------------------|
			(QT)<--------------------------| |
			| Q(0,{}) | |
			|<--------------------| |
			4| R({G:INCLUDE({S})}) | Membership Update |
			|-------------------->|5 R({G:INCLUDE({S})})|
			| |====================>|6b
			Leave(S,G) : : :
			()--------->|7 R({G:BLOCK({S})}) | Membership Update |
			|-------------------->|8 R({G:BLOCK({S})}) |
			| |====================>|9b Prune(S,G)
			| | |---------->()
			: : :
			Membership Update Sequence (IGMPv3/MLDv2 Example)
			The following sequence describes how the Request, Membership Query,
			and Membership Update messages are used to report current group
			membership state or changes in group membership state:
			1. A gateway sends a Request message to the relay that contains a
			random nonce and a flag indicating whether the relay should
			return an IGMPv3 or MLDv2 general query.
			2. When the relay receives a Request message, it generates a
			message authentication code (MAC) by computing a hash value from
			a private secret and the nonce, source IP address, and source
			UDP port carried by the Request message. The relay then sends a
			Membership Query message to the gateway that contains the
			request nonce, the MAC, and an IGMPv3 or MLDv2 general query.
			3. When the gateway receives a Membership Query message, it
			verifies that the request nonce matches the one sent in the last
			Request, and if it does, the gateway saves the request nonce and
			MAC for use in sending subsequent Membership Update messages.
			The gateway starts a timer whose expiration will trigger the
			transmission of a new Request message and extracts the
			encapsulated general query message for processing by the IGMP or
			MLD protocol. The query timer duration is specified by the
			relay in the QQIC field in the IGMPv3 or MLDv2 general query.
			4. The gateway's IGMP or MLD protocol implementation processes the
			general query to produce a current-state report.
			5. When an IGMP or MLD report is passed to the pseudo-interface,
			the gateway encapsulates the report in a Membership Update
			message and sends it to the relay. The request nonce and MAC
			fields in the Membership Update are assigned the values from the
			last Membership Query message received for the corresponding
			group membership protocol (IGMPv3 or MLDv2).
			6. When the relay receives a Membership Update message, it computes
			a MAC from a private secret and the request nonce, source IP
			address, and source UDP port carried by the message. The relay
			accepts the Membership Update message if the received MAC
			matches the computed MAC, otherwise the message is ignored. If
			the message is accepted, the relay may proceed to allocate,
			refresh, or modify tunnel state. This includes making any group
			membership, routing and forwarding state changes and issuing any
			upstream protocol requests required to satisfy the state change.
			The diagram illustrates two scenarios:
			A. The gateway has not previously reported any group
			subscriptions and the report does not contain any group
			subscriptions, so the relay takes no action.
			B. The gateway has previously reported a group subscription so
			the current-state report lists all current subscriptions.
			The relay responds by refreshing tunnel or group state and
			resetting any related timers.
			7. A receiver indicates to the gateway that it wishes to join
			(allow) or leave (block) specific multicast traffic. This
			request is typically made through some form IGMP/MLD service
			interface (as described in Section 2 of [RFC3376] or Section 3
			of [RFC3810]). The IGMP/MLD protocol responds by generating an
			IGMP or MLD state-change message.
			8. When an IGMP or MLD report/leave/done message is passed to the
			pseudo-interface, the gateway encapsulates the message in a
			Membership Update message and sends it to the relay. The
			request nonce and MAC fields in the Membership Update are
			assigned the values from the last Membership Query message
			received for the corresponding group membership protocol (IGMP
			or MLD).
			The IGMP and MLD protocols may generate multiple messages to
			provide robustness against packet loss - each of these must be
			encapsulated in a new Membership Update message and sent to the
			relay. The Querier Robustness Variable (QRV) field in the last
			IGMP/MLD query delivered to the IGMP/MLD protocol is typically
			used to specify the number of repetitions (i.e., the host adopts
			the QRV value as its own Robustness Variable value).
			9. When the relay receives a Membership Update message, it again
			computes a MAC from a private secret and the request nonce,
			source IP address, and source UDP port carried by the message.
			The relay accepts the Membership Update message if the received
			MAC matches the computed MAC, otherwise the message is ignored.
			If the message is accepted, the relay processes the encapsulated
			IGMP/MLD and allocates, modifies or deletes tunnel state
			accordingly. This includes making any group membership, routing
			and forwarding state changes and issuing any upstream protocol
			requests required to satisfy the state change. The diagram
			illustrates two scenarios:
			A. The gateway wishes to add a group subscription.
			B. The gateway wishes to delete a previously reported group
			subscription.
			10. Multicast datagrams transmitted by a source travel through the
			native multicast infrastructure to the relay. When the relay
			receives a multicast IP datagram that carries a source and
			destination address for which a gateway has expressed an
			interest in receiving (via the Membership Update message), it
			encapsulates the datagram into a Multicast Data message and
			sends it to the gateway using the source IP address and UDP port
			carried by the Membership Update message as the destination
			address.
			11. When the gateway receives a Multicast Data message, it extracts
			the multicast packet from the message and passes it on to the
			appropriate receivers.
			12. When the query timer expires the gateway sends a new Request
			message to the relay to start a new membership update cycle.
			The MAC-based source-authentication mechanism described above
			provides a simple defense against malicious attempts to exhaust relay
			resources via source-address spoofing. Flooding a relay with spoofed
			Request or Membership Update messages may consume computational
			resources and network bandwidth, but will not result in the
			allocation of state because the Request message is stateless and
			spoofed Membership Update messages will fail source-authentication
			and be rejected by the relay.
			A relay will only allocate new tunnel state if the IGMP/MLD report
			carried by the Membership Update message creates one or more group
			subscriptions.
			A relay deallocates tunnel state after one of the following events;
			the gateway sends a Membership Update message containing a report
			that results in the deletion of all remaining group subscriptions,
			the IGMP/MLD state expires (due to lack of refresh by the gateway),
			or the relay receives a valid Teardown message from the gateway.
			A gateway that accepts or reports group subscriptions for both IPv4
			and IPv6 addresses will send separate Request and Membership Update
			messages for each protocol (IPv4/IGMP and IPv6/MLD).
			4.2.1.3. Teardown Sequence
			A gateway sends a Teardown message to a relay to request that it stop
			delivering Multicast Data messages to a tunnel endpoint created by an
			earlier Membership Update message. This message is intended to be
			used following a gateway address change (See Section 4.2.2.1) to stop
			the transmission of undeliverable or duplicate multicast data
			messages. Support for the Teardown message is optional - gateways
			are not required to send them and relays are not required to act upon
			them.
			Gateway Relay
			------- -----
			: Request :
			[1] | N |
			|---------------------->|
			| Membership Query | [2]
			| N,MAC,gADDR,gPORT |
			|<======================|
			[3] | Membership Update |
			| ({G:INCLUDE({S})}) |
			|======================>|
			| |
			----------------------:-----------------------:----------------------
			| | | |
			| | *Multicast Data | *IP Packet(S,G) |
			| | gADDR,gPORT |<------------------() |
			| *IP Packet(S,G) |<======================| |
			| ()<------------------| | |
			| | | |
			----------------------:-----------------------:----------------------
			~ |
			~ Request |
			[4] | N' |
			|---------------------->|
			| Membership Query | [5]
			| N',MAC',gADDR',gPORT' |
			|<======================|
			[6] | |
			| Teardown |
			| N,MAC,gADDR,gPORT |
			|---------------------->|
			| | [7]
			| Membership Update |
			| ({G:INCLUDE({S})}) |
			|======================>|
			| |
			----------------------:-----------------------:----------------------
			| | | |
			| | *Multicast Data | *IP Packet(S,G) |
			| | gADDR',gPORT' |<------------------() |
			| *IP Packet (S,G) |<======================| |
			| ()<------------------| | |
			| | | |
			----------------------:-----------------------:----------------------
			| |
			: :
			Figure 3: Teardown Message Sequence (IGMPv3/MLDv2 Example)
			The following sequence describes how the Membership Query and
			Teardown message are used to detect an address change and stop the
			delivery of Multicast Data messages to an address:
			1. A gateway sends a Request message containing a random nonce to
			the relay.
			2. The relay sends a Membership Query message to the gateway that
			contains the source IP address (gADDR) and source UDP port
			(gPORT) values from the Request message. These values will be
			used to identify the tunnel should one be created by a subsequent
			Membership Update message.
			3. When the gateway receives a Membership Query message that carries
			the gateway address fields, it compares the gateway IP address
			and port number values with those received in the previous
			Membership Query (if any). If these values do not match, this
			indicates that the Request message arrived at the relay carrying
			a different source address than the one sent previously. At this
			point in the sequence, no change in source address or port has
			occurred.
			4. The gateway sends a new Request message to the relay. However,
			this Request message arrives at the relay carrying a different
			source address than that of the previous Request due to some
			change in network interface, address assignment, network topology
			or NAT mapping.
			5. The relay again responds by sending a Membership Query message to
			the gateway that contains the new source IP address (gADDR') and
			source UDP port (gPORT') values from the Request message.
			6. When the gateway receives the Membership Query message, it
			compares the gateway address and port number values against those
			returned in the previous Membership Query message.
			7. If the reported address or port has changed, the gateway sends a
			Teardown message to the relay that contains the request nonce,
			MAC, gateway IP address and gateway port number returned in the
			earlier Membership Query message. The gateway may send the
			Teardown message multiple times where the number of repetitions
			is governed by the Querier Robustness Variable (QRV) value
			contained in the IGMPv3/MLDv2 general query carried by the
			original Membership Query. The gateway continues to process the
			new Membership Query message as usual.
			8. When the relay receives a Teardown message, it computes a MAC
			from a private secret and the request nonce, gateway IP address,
			and gateway port number carried by the Teardown message. The
			relay accepts the Teardown message if the received MAC matches
			the computed MAC, otherwise the message is ignored. If the
			message is accepted, the relay makes any group membership,
			routing and forwarding state changes required to stop the
			transmission of Multicast Data messages to that address.
			4.2.1.4. Timeout and Retransmission
			The AMT protocol does not establish any requirements regarding what
			actions a gateway should take if it fails to receive a response from
			a relay. A gateway implementation may wait for an indefinite period
			of time to receive a response, may set a time limit on how long to
			wait for a response, may retransmit messages should the time limit be
			reached, may limit the number of retransmissions, or may simply
			report an error.
			For example, a gateway may retransmit a Request message if it fails
			to receive a Membership Query or expected Multicast Data messages
			within some time period. If the gateway fails to receive any
			response to a Request after several retransmissions or within some
			maximum period of time, it may reenter the relay discovery phase in
			an attempt to find a new relay. This topic is addressed in more
			detail in Section 5.2.
			4.2.2. Tunneling
			From the standpoint of a relay, an AMT "tunnel" is identified by the
			IP address and UDP port pair used as the destination address for
			sending encapsulated multicast IP datagrams to a gateway. This
			address is referred here as the tunnel endpoint address.
			A gateway sends a Membership Update message to a relay to add or
			remove group subscriptions to a tunnel endpoint. The tunnel endpoint
			is identified by the source IP address and source UDP port carried by
			the Membership Update message when it arrives at a relay (this
			address may differ from that carried by the message when it exited
			the gateway as a result of network address translation).
			The Membership Update messages sent by a single gateway host may
			originate from several source addresses or ports - each unique
			combination represents a unique tunnel endpoint. A single gateway
			host may legitimately create and accept traffic on multiple tunnel
			endpoints, e.g., the gateway may use separate ports for the IPv4/IGMP
			and IPv6/MLD protocols.
			A tunnel is "created" when a gateway sends a Membership Update
			message containing an IGMP or MLD membership report that creates one
			or more group subscriptions when none currently existed for that
			tunnel endpoint address.
			A tunnel ceases to exist when all group subscriptions for a tunnel
			endpoint are deleted. This may occur as a result of the following
			events:
			o The gateway sends an IGMP or MLD report, leave or done message to
			the relay that deletes the last group subscription linked to the
			tunnel endpoint.
			o The gateway sends a Teardown message to the relay that causes it
			to delete any and all subscriptions bound to the tunnel endpoint.
			o The relay stops receiving updates from the gateway until such time
			that per-group or per-tunnel timers expire, causing the relay to
			delete the subscriptions.
			The tunneling approach described above conceptually transforms a
			unicast-only inter-network into an NBMA link layer, over which
			multicast traffic may be delivered. Each relay, plus the set of all
			gateways using the relay, together may be thought of as being on a
			separate logical NBMA link, where the "link layer" address is a
			UDP/IP address-port pair provided by the Membership Update message.
			4.2.2.1. Address Roaming
			As described above, each time a relay receives a Membership Update
			message from a new source address-port pair, the group subscriptions
			described by that message apply to the tunnel endpoint identified by
			that address.
			This can cause problems for a gateway if the address carried by the
			messages it sends to a relay change unexpectedly. These changes may
			cause the relay to transmit duplicate, undeliverable or unrequested
			traffic back towards the gateway or an intermediate device. This may
			create congestion and have negative consequences for the gateway, its
			network, or multicast receivers, and in some cases, may also produce
			a significant amount of ICMP traffic directed back towards the relay
			by a NAT, router or gateway host.
			There are several scenarios in which the address carried by messages
			sent by a gateway may change without that gateway's knowledge, as for
			example, when:
			o The message originates from a different interface on a gateway
			that possesses multiple interfaces.
			o The DHCP assignment for a gateway interface changes.
			o The gateway roams to a different wireless network.
			o The address mapping applied by an intervening network-translation-
			device (NAT) changes as a result of mapping expiration or routing
			changes in a multi-homed network.
			In the case where the address change occurs between the transmission
			of a Request message and subsequent Membership Update messages, the
			relay will simply ignore any Membership Update messages from the new
			address because MAC authentication will fail (see Section 4.2.1.2).
			The relay may continue to transmit previously requested traffic, but
			no duplication will occur, i.e., the possibility for the delivery of
			duplicate traffic does not arise until a Request message is received
			from the new address.
			The protocol provides a method for a gateway to detect an address
			change and explicitly request that the relay stop sending traffic to
			a previous address. This process involves the Membership Query and
			Teardown messages and is described in Section 4.2.1.3.
			4.2.2.2. Network Address Translation
			The messages sent by a gateway to a relay may be subject to network
			address translation (NAT) - the source IP address and UDP port
			carried by an IP packet sent by the gateway may be modified multiple
			times before arriving at the relay. In the most restrictive form of
			NAT, the NAT device will create a new mapping for each combination of
			source and destination IP address and UDP port. In this case, bi-
			directional communication can only be conducted by sending outgoing
			packets to the source address and port carried by the last incoming
			packet.
			Membership Update Membership Update
			src: iADDR:iPORT src: eADDR:ePORT
			dst: rADDR:rPORT dst: rADDR:rPORT
			+---------+
			| NAT |
			+---------+ +-----------+ +---------+
			| |---------->| |--------->| |
			| Gateway | | Mapping | | Relay |
			| |<----------| |<---------| |
			+---------+ +-----------+ +---------+
			| |
			+---------+
			Multicast Data Multicast Data
			src: rADDR:rPORT src: rADDR:rPORT
			dst: iADDR:iPORT dst: eADDR:ePORT
			Network Address Translation in AMT
			AMT provides automatic NAT traversal by using the source IP address
			and UDP port carried by the Membership Update message as received at
			the relay as the destination address for any Multicast Data messages
			the relay sends back as a result.
			The NAT mapping created by a Membership Update message will
			eventually expire unless it is refreshed by a passing message. This
			refresh will occur each time the gateway performs the periodic update
			required to refresh group state within the relay (See
			Section 4.2.1.2).
			4.2.2.3. UDP Encapsulation
			Gateway Relay
			IP:IGMP IP:IGMP
			| AMT:IP:IGMP AMT:IP:IGMP |
			| | | |
			| | IP:UDP:AMT:IP:IGMP | |
			_______ | ___ | ______ | ______ | ___ | _______
			|IGMP|IP| v |AMT| v |UDP|IP| v |IP|UDP| v |AMT| v |IP|IGMP|
			| | | | | | | | | | | | | | | |
			| |<------------------------------------------------------->| |
			|____| | | | | | | | | | | | | |____|
			| |<--------------------------------------------------| |
			|_______| ^ |___| ^ |___|__| ^ |__|___| ^ |___| ^ |_______|
			| | | | |
			IP AMT:IP IP:UDP:AMT:IP AMT:IP IP
			AMT Encapsulation
			The IGMP and MLD messages used in AMT are exchanged as complete IP
			datagrams. These IP datagrams are encapsulated in AMT messages which
			are transmitted using UDP. The same holds true for multicast traffic
			- each multicast IP datagram that arrives at the relay is
			encapsulated in an AMT message and transmitted to one or more
			gateways via UDP.
			The IP protocol of the encapsulated packets need not match the IP
			protocol used to send the AMT messages. AMT messages sent via IPv4
			may carry IPv6/MLD packets and AMT messages sent via IPv6 may carry
			IPv4/IGMP packets.
			The checksum field contained in the UDP header of the messages
			requires special consideration. Of primary concern is the cost of
			computing a checksum on each replicated multicast packet after it is
			encapsulated for delivery to a gateway. Many routing/forwarding
			platforms do not possess the capability to compute checksums on UDP
			encapsulated packets as they may not have access to the entire
			datagram.
			To avoid placing an undue burden on the relay platform, the protocol
			specifically allows zero-valued UDP checksums on the multicast data
			messages. This is not an issue in UDP over IPv4 as the UDP checksum
			field may be set to zero. However, this is a problem for UDP over
			IPv6 as that protocol requires a valid, non-zero checksum in UDP
			datagrams [RFC2460]. Messages sent over IPv6 with a UDP checksum of
			zero may fail to reach the gateway. This is a well known issue for
			UDP-based tunneling protocols. See [I-D.ietf-6man-udpchecksums] and
			[I-D.ietf-6man-udpzero] for details.
			5. Protocol Description
			This section provides a normative description of the AMT protocol.
			5.1. Protocol Messages
			The AMT protocol defines seven message types for control and
			encapsulation. These messages are assigned the following names and
			numeric identifiers:
			+--------------+---------------------+
			| Message Type | Message Name |
			+--------------+---------------------+
			| 1 | Relay Discovery |
			| | |
			| 2 | Relay Advertisement |
			| | |
			| 3 | Request |
			| | |
			| 4 | Membership Query |
			| | |
			| 5 | Membership Update |
			| | |
			| 6 | Multicast Data |
			| | |
			| 7 | Teardown |
			+--------------+---------------------+
			These messages are exchanged as IPv4 or IPv6 UDP datagrams.
			5.1.1. Relay Discovery
			A Relay Discovery message is used to solicit a response from a relay
			in the form of a Relay Advertisement message.
			The UDP/IP datagram containing this message MUST carry a valid, non-
			zero UDP checksum and carry the following IP address and UDP port
			values:
			Source IP Address - The IP address of the gateway interface on which
			the gateway will listen for a relay response. Note: The value of
			this field may be changed as a result of network address
			translation before arriving at the relay.
			Source UDP Port - The UDP port number on which the gateway will
			listen for a relay response. Note: The value of this field may be
			changed as a result of network address translation before arriving
			at the relay.
			Destination IP Address - An anycast or unicast IP address, i.e. the
			Relay Discovery Address advertised by a relay.
			Destination UDP Port - The IANA-assigned AMT port number.
	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 |		| V=0 |Type=1 | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Discovery Nonce |		| Discovery Nonce |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	AMT Relay Discovery		Relay Discovery Message Format
	6.2.1. Type		5.1.1.1. Version (V)
	The type of the message.		The protocol version number for this message is 0.
	6.2.2. Reserved		5.1.1.2. Type
	A 24-bit reserved field. Sent as 0, ignored on receipt.		The type number for this message is 1.
	6.2.3. Discovery Nonce		5.1.1.3. Reserved
	A 32-bit random value generated by the gateway and replayed by the		Reserved bits that MUST be set to zero by the gateway and ignored by
	relay.		the relay.
	6.3. AMT Relay Advertisement		5.1.1.4. Discovery Nonce
	The AMT Relay Advertisement message sent from the AMT relay anycast		A 32-bit random value generated by the gateway and echoed by the
	address to the source of the discovery message.		relay in a Relay Advertisement message. This value is used by the
			gateway to correlate Relay Advertisement messages with Relay
			Discovery messages. Discovery nonce generation is described in
			Section 5.2.3.4.5.
	The UDP source port is the IANA reserved AMT port number and the UDP		5.1.2. Relay Advertisement
	destination port is the source port received in the Discovery
	message.
	The payload of the UDP packet contains the following fields.		The Relay Advertisement message is used to supply a gateway with a
			unicast IP address of a relay. A relay sends this message to a
			gateway when it receives a Relay Discovery message from that gateway.
			The UDP/IP datagram containing this message MUST carry a valid, non-
			zero UDP checksum and carry the following IP address and UDP port
			values:
			Source IP Address - The destination IP address carried by the Relay
			Discovery message (i.e. the Relay Discovery Address advertised by
			the relay).
			Source UDP Port - The destination UDP port carried by the Relay
			Discovery message (i.e. the IANA-assigned AMT port number).
			Destination IP Address - The source IP address carried by the Relay
			Discovery message. Note: The value of this field may be changed
			as a result of network address translation before arriving at the
			gateway.
			Destination UDP Port - The source UDP port carried by the Relay
			Discovery message. Note: The value of this field may be changed
			as a result of network address translation before arriving at the
			gateway.
	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 |		| V=0 |Type=2 | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Discovery Nonce |		| Discovery Nonce |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Relay Address |		| |
			~ Relay Address (IPv4 or IPv6) ~
			| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	AMT Relay Advertisement		Relay Advertisement Message Format
	6.3.1. Type		5.1.2.1. Version (V)
	The type of the message.		The protocol version number for this message is 0.
	6.3.2. Reserved		5.1.2.2. Type
	A 24-bit reserved field. Sent as 0, ignored on receipt.		The type number for this message is 2.
	6.3.3. Discovery Nonce		5.1.2.3. Reserved
	A 32-bit random value generated by the gateway and replayed by the		Reserved bits that MUST be set to zero by the relay and ignored by
	relay.		the gateway.
	6.3.4. Relay Address		5.1.2.4. Discovery Nonce
	The unicast IPv4 or IPv6 address of the AMT relay. The family can be		A 32-bit value copied from the Discovery Nonce field
	determined by the length of the Advertisement.		(Section 5.1.1.4) contained in the Relay Discovery message. The
			gateway uses this value to match a Relay Advertisement to a Relay
			Discovery message.
	6.4. AMT Request		5.1.2.5. Relay Address
	A Request packet is sent by a Gateway to a Relay to begin a 3-way		The unicast IPv4 or IPv6 address of the relay. A gateway uses the
	handshake for sending an IGMP/MLD Membership/Listener Report or		length of the UDP datagram containing the Relay Advertisement message
	Leave/Done.		to determine the address family; i.e. length - 8 = 4 (IPv4) or 16
			(IPv6).
	It is sent from the Gateway address to the Relay's unique unicast		5.1.3. Request
	address.
	The UDP source port is uniquely selected by the local host operating		A gateway sends a Request message to a relay to solicit a Membership
	system. It can be different from the source port used in Discovery		Query response.
	messages but does not have to be. The UDP source port must be
	consistent across Request and Update messages (see also Section 7.2).
	The UDP destination port is the IANA reserved AMT port number.		The successful delivery of this message marks the start of the first
			stage in the three-way handshake used to create or update state
			within a relay.
			The UDP/IP datagram containing this message MUST carry a valid, non-
			zero UDP checksum and carry the following IP address and UDP port
			values:
			Source IP Address - The IP address of the gateway interface on which
			the gateway will listen for a response from the relay. Note: The
			value of this field may be changed as a result of network address
			translation before arriving at the relay.
			Source UDP Port - The UDP port number on which the gateway will
			listen for a response from the relay. Note: The value of this
			field may be changed as a result of network address translation
			before arriving at the relay.
			Destination IP Address - The unicast IP address of the relay.
			Destination UDP Port - The IANA-assigned AMT port number.
	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 |		| V=0 |Type=3 | Reserved |P| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Request Nonce |		| Request Nonce |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Request Message Format
	AMT Request		5.1.3.1. Version (V)
	6.4.1. Type		The protocol version number for this message is 0.
	The type of the message.		5.1.3.2. Type
	6.4.2. Reserved		The type number for this message is 3.
	A 24-bit reserved field. Sent as 0, ignored on receipt.		5.1.3.3. Reserved
	6.4.3. Request Nonce		Reserved bits that MUST be set to zero by the gateway and ignored by
			the relay.
	A 32-bit identifier used to distinguish this request.		5.1.3.4. P Flag
	6.5. AMT Membership Query		The "P" flag is set to indicate which group membership protocol the
			gateway wishes the relay to use in the Membership Query response:
	An AMT Membership Query packet is sent from the Relay back to the		Value Meaning
	Gateway to solicit an AMT Membership Update while confirming the
	source of the original request. It contains a relay Message
	Authentication Code (MAC) that is a cryptographic hash of a private
	secret, the originators address, and the request nonce.
	It is sent from the destination address received in the Request to		0 The relay MUST respond with a Membership Query message that
	the source address of the Request, i.e. the Relay Address advertised		contains an IPv4 packet carrying an IGMPv3 general query
	in the Relay Advertisement message.		message.
	The UDP source port is the IANA reserved AMT port number and the UDP		1 The relay MUST respond with a Membership Query message that
	destination port is the source port received in the Request message.		contains an IPv6 packet carrying an MLDv2 general query
			message.
			5.1.3.5. Request Nonce
			A 32-bit random value generated by the gateway and echoed by the
			relay in a Membership Query message. This value is used by the relay
			to compute the Response MAC value and is used by the gateway to
			correlate Membership Query messages with Request messages. Request
			nonce generation is described in Section 5.2.3.5.6.
			5.1.4. Membership Query
			A relay sends a Membership Query message to a gateway to solicit a
			Membership Update response, but only after receiving a Request
			message from the gateway.
			The successful delivery of this message to a gateway marks the start
			of the second-stage in the three-way handshake used to create or
			update tunnel state within a relay.
			The UDP/IP datagram containing this message MUST carry a valid, non-
			zero UDP checksum and carry the following IP address and UDP port
			values:
			Source IP Address - The destination IP address carried by the
			Request message (i.e. the unicast IP address of the relay).
			Source UDP Port - The destination UDP port carried by the Request
			message (i.e. the IANA-assigned AMT port number).
			Destination IP Address - The source IP address carried by the
			Request message. Note: The value of this field may be changed as
			a result of network address translation before arriving at the
			gateway.
			Destination UDP Port - The source UDP port carried by the Request
			message. Note: The value of this field may be changed as a result
			of network address translation before arriving at the gateway.
	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=0x4 | Flags | Response MAC |		| V=0 |Type=4 | Reserved |L|G| Response MAC |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
	| Response MAC (continued) |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Request Nonce |		| Request Nonce |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IGMP Membership Query or MLD Listener Query |		| |
	| (including IP Header) |		| Encapsulated General Query Message |
	| ... |		~ IPv4:IGMPv3(Membership Query) ~
			| IPv6:MLDv2(Listener Query) |
			| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Gateway Port Number | Gateway Address ... | ?		| Gateway Port Number | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
	| ... Gateway Address (ctd) ... | ?		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?		+ +
	| ... Gateway Address (ctd) ... | ?		| Gateway IP Address (IPv4 or IPv6) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?		+ +
	| ... Gateway Address (ctd) ... | ?		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?		+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ... Gateway Address (ctd) | ?		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	AMT Membership Query		Membership Query Message Format
	6.5.1. Type		5.1.4.1. Version (V)
	The type of the message.		The protocol version number for this message is 0.
	6.5.2. Flags		5.1.4.2. Type
	An 8-bit flags field having the following format:		The type number for this message is 4.
	0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+
	| Reserved |G|
	+-+-+-+-+-+-+-+-+
	The "G" flag is set to 1 if Gateway information fields are present in		5.1.4.3. Reserved
	the Query message (see below Section 6.5.6), and to zero if they are
	not.
	Other flags are currently unused and reserved: they are sent as zero		Reserved bits that MUST be set to zero by the relay and ignored by
	and their value is ignored on receipt.		the gateway.
	6.5.3. Response MAC		5.1.4.4. Limit (L) Flag
	A 48-bit hash generated by the Relay and sent to the Gateway for		A 1-bit flag set to 1 to indicate that the relay is NOT accepting
	inclusion in the AMT Membership Update (see Section 5.2).		Membership Update messages from new gateway tunnel endpoints and that
			it will ignore any that are. A value of 0 has no special
			significance - the relay may or may not be accepting Membership
			Update messages from new gateway tunnel endpoints. A gateway checks
			this flag before attempting to create new group subscription state on
			the relay to determine whether it should restart relay discovery. A
			gateway that has already created group subscriptions on the relay may
			ignore this flag. Support for this flag is RECOMMENDED.
	6.5.4. Request Nonce		5.1.4.5. Gateway Address (G) Flag
	A 32-bit identifier echoed back to the originator to used to identify		A 1-bit flag set to 0 to indicate that the message does NOT carry the
	the corresponding request (see Section 5.2).		Gateway Port and Gateway IP Address fields, and 1 to indicate that it
			does. A relay implementation that supports the optional teardown
			procedure (See Section 5.3.3.5) SHOULD set this flag and and the
			Gateway Address field values. If a relay sets this flag, it MUST
			also include the Gateway Address fields in the message. A gateway
			implementation that does not support the optional teardown procedure
			(See Section 5.2.3.7) MAY ignore this flag and the Gateway Address
			fields if they are present.
	6.5.5. IGMP/MLD Query (including IP Header)		5.1.4.6. Response MAC
	The message contains either an IGMP Query or an MLD Multicast		A 48-bit source authentication hash generated by the relay as
	Listener Query. The IGMP or MLD version sent should default to		described in Section 5.3.5. The gateway echoes this value in
	IGMPv3 or MLDv2 unless explicitly configured to use IGMPv2 or MLDv1.		subsequent Membership Update messages to allow the relay to verify
	The IGMP/MLD Query includes a full IP Header. The IP source address		that the sender of a Membership Update message was the intended
	of the query would match the anycast address on the pseudo interface.		receiver of a Membership Query sent by the relay.
	The TTL of the outer IP header should be sufficient to reach the
	tunnel endpoint and not mimic the inner IP header TTL which is
	typically 1 for IGMP/MLD messages.
	6.5.6. Gateway information fields		5.1.4.7. Request Nonce
	The "Gateway Port Number" and "Gateway Address" fields are present in		A 32-bit value copied from the Request Nonce field (Section 5.1.3.5)
	the Query message if, and only if, the "G" flag is set in the Flags		carried by a Request message. The relay will have included this
	field.		value in the Response MAC hash computation. The gateway echoes this
			value in subsequent Membership Update messages. The gateway also
			uses this value to match a Membership Query to a Request message.
	6.5.6.1. Gateway Port Number		5.1.4.8. Encapsulated General Query Message
	A 16-bit field containing a UDP port value.		An IP-encapsulated IGMP or MLD message generated by the relay. This
			field will contain one of the following IP datagrams:
			IPv4:IGMPv3 Membership Query
			IPv6:MLDv2 Listener Query
			The source address carried by the query message SHOULD be set to zero
			to indicate that query originated from a non-querier.
			The Querier's Query Interval Code (QQIC) field in the general query
			is used by a relay to specify the time offset a gateway should use to
			schedule a new three-way handshake to refresh the group membership
			state within the relay (current time + Query Interval).
			The Querier's Robustness Variable (QRV) field in the general query is
			used by a relay to specify the number of times a gateway should
			retransmit unsolicited membership reports, encapsulated within
			Membership Update messages, and optionally, the number of times to
			send a Teardown message.
			5.1.4.9. Gateway Address Fields
			The Gateway Port Number and Gateway Address fields are present in the
			Membership Query message if, and only if, the "G" flag is set.
			A gateway need not parse the encapsulated IP datagram to determine
			the position of these fields within the UDP datagram containing the
			Membership Query messsage - if the G-flag is set, the gateway may
			simply subtract the total length of the fields (18 bytes) from the
			total length of the UDP datagram to obtain the offset.
			5.1.4.9.1. Gateway Port Number
			A 16-bit UDP port containing a UDP port value.
	The Relay sets this field to the value of the UDP source port of the		The Relay sets this field to the value of the UDP source port of the
	Request message that triggered the Query message.		Request message that triggered the Query message.
	6.5.6.2. Gateway Address		5.1.4.9.2. Gateway IP Address
	A 16-byte field containing the IP source address of the Request		A 16-byte IP address that, when combined with the value contained in
	message that triggered this Query message. The field contains an		the Gateway Port Number field, forms the gateway endpoint address
	IPv4-compatible IPv6 address ([RFC4291], section 2.5.5.1) if the		that the relay will use to identify the tunnel instance, if any,
	address is an IPv4 address (i.e. the IPv4 address prefixed with 96		created by a subsequent Membership Update message. This field may
	bits set to zero), or an IPv6 address.		contain an IPv6 address or an IPv4 address stored as an IPv4-
			compatible IPv6 address, where the IPv4 address is prefixed with 96
			bits set to zero (See [RFC4291]). This address must match that used
			by the relay to compute the value stored in the Response MAC field.
	6.6. AMT Membership Update		5.1.5. Membership Update
	An AMT Membership Update is sent to report a membership after a valid		A gateway sends a Membership Update message to a relay to report a
	Response MAC has been received. It contains the original IGMP/MLD		change in group membership state, or to report the current group
	Membership/Listener Report or Leave/Done received over the AMT		membership state in response to receiving a Membership Query message.
	pseudo-interface including the original IP header. It echoes the		The gateway encapsulates the IGMP or MLD message as an IP datagram
	Response MAC received in the AMT Membership Query so the respondent		within a Membership Update message and sends it to the relay, where
	can verify return routability to the originator.		it may (see below) be decapsulated and processed by the relay to
			update group membership and forwarding state.
	It is sent from the destination address received in the Query to the		A gateway cannot send a Membership Update message until a receives a
	source address received in the Query which should both be the same as		Membership Query from a relay because the gateway must copy the
	the original Request.		Request Nonce and Response MAC values carried by a Membership Query
			into any subsequent Membership Update messages it sends back to that
			relay. These values are used by the relay to verify that the sender
			of the Membership Update message was the recipient of the Membership
			Query message from which these values were copied.
	The UDP source and destination port numbers should be the same ones		The successful delivery of this message to the relay marks the start
	sent in the original Request.		of the final stage in the three-way handshake. This stage concludes
			when the relay successfully verifies that sender of the Message
			Update message was the recipient of a Membership Query message sent
			earlier. At this point, the relay may proceed to process the
			encapsulated IGMP or MLD message to create or update group membership
			and forwarding state on behalf of the gateway.
	The UDP destination port is the IANA reserved AMT port number and the		The UDP/IP datagram containing this message MUST carry a valid, non-
	UDP source port is the source port used for the Request message.		zero UDP checksum and carry the following IP address and UDP port
			values:
	The Relay is not required to use the IP source address of the IGMP		Source IP Address - The IP address of the gateway interface on which
	Membership Report for any particular purpose.		the gateway will listen for Multicast Data messages from the
			relay. The address must be the same address used to send the
			initial Request message or the message will be ignored. Note: The
			value of this field may be changed as a result of network address
			translation before arriving at the relay.
	The same Request Nonce and Response MAC can be used across multiple		Source UDP Port - The UDP port number on which the gateway will
	AMT Membership Update messages without having to send individual AMT		listen for Multicast Data messages from the relay. This port must
	Membership Query messages.		be the same port used to send the initial Request message or the
			message will be ignored. Note: The value of this field may be
			changed as a result of network address translation before arriving
			at the relay.
			Destination IP Address - The unicast IP address of the relay.
			Destination UDP Port - The IANA-assigned AMT UDP port number.
	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 |		| V=0 |Type=5 | Reserved | Response MAC |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
	| Response MAC (continued) |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Request Nonce |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IGMP or MLD Message (including IP header) |		| Request Nonce |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ... |		| |
			| Encapsulated Group Membership Update Message |
			~ IPv4:IGMP(Membership Report|Leave Group) ~
			| IPv6:MLD(Listener Report|Listener Done) |
			| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	AMT Membership Update		Membership Update Message Format
	6.6.1. Type		5.1.5.1. Version (V)
	The type of the message.		The protocol version number for this message is 0.
	6.6.2. Reserved		5.1.5.2. Type
	A 8-bit reserved field. Sent as 0, ignored on receipt.		The type number for this message is 5.
	6.6.3. Response MAC		5.1.5.3. Reserved
	The 48-bit MAC received in the Membership Query and echoed back in		Reserved bits that MUST be set to zero by the gateway and ignored by
	the Membership Update (see Section 5.2).		the relay.
	6.6.4. Request Nonce		5.1.5.4. Response MAC
	A 32-bit identifier matching the nonce in the AMT Request (see		A 48-bit value copied from the Response MAC field (Section 5.1.4.6)
	Section 5.2).		in a Membership Query message. Used by the relay to perform source
			authentication.
	6.6.5. IGMP/MLD Message (including IP Header)		5.1.5.5. Request Nonce
	The message contains either an IGMP Membership Report, an IGMP		A 32-bit value copied from the Request Nonce field in a Request or
	Membership Leave, an MLD Multicast Listener Report, or an MLD		Membership Query message. Used by the relay to perform source
	Listener Done. The IGMP or MLD version sent should be in function of		authentication.
	the version of the query received in the AMT Membership Query. The
	IGMP/MLD Message includes a full IP Header.
	6.7. AMT IP Multicast Data		5.1.5.6. Encapsulated Group Membership Update Message
	The AMT Data message is a UDP packet encapsulating the IP Multicast		An IP-encapsulated IGMP or MLD message produced by the host-mode IGMP
	data requested by the originator based on a previous AMT Membership		or MLD protocol running on a gateway pseudo-interface. This field
	Update message.		will contain of one of the following IP datagrams:
	It is sent from the Relay's unique unicast address (destination		IPv4:IGMPv2 Membership Report
	address of the Membership update) to the Gateway's unicast address
	(source address of the Membership Update).
	The UDP source port is the IANA reserved AMT port number and the		IPv4:IGMPv2 Leave Group
	destination port should be the same as the source port of the
	Membership Update that resulted in the creation of forwarding state
	for the encapsulated IP packet.
	The UDP checksum SHOULD be zero for AMT IP Multicast Data messages		IPv4:IGMPv3 Membership Report
	carried over IPv4, and MAY be zero for AMT IP Multicast Data messages
	carried over IPv6 [I-D.ietf-6man-udpchecksums].
	The payload of the UDP packet contains the following fields.		IPv6:MLDv1 Multicast Listener Report
			IPv6:MLDv1 Multicast Listener Done
			IPv6:MLDv2 Multicast Listener Report
			5.1.6. Multicast Data
			A relay sends a Multicast Data message to deliver an IP multicast
			packet to a gateway.
			The checksum field in the UDP header of this message MAY contain a
			value of zero when sent over IPv4 but SHOULD, if possible, contain a
			valid, non-zero value when sent over IPv6 (See Section 4.2.2.3).
			The UDP/IP datagram containing this message MUST carry the following
			IP address and UDP port values:
			Source IP Address - The unicast IP address of the relay.
			Source UDP Port - The IANA-assigned AMT port number.
			Destination IP Address - A tunnel endpoint IP address, i.e. the
			source IP address carried by the Membership Update message sent by
			a gateway to indicate an interest in receiving the multicast
			packet. Note: The value of this field may be changed as a result
			of network address translation before arriving at the gateway.
			Destination UDP Port - A tunnel endpoint UDP port, i.e. the source
			UDP port carried by the Membership Update message sent by a
			gateway to indicate an interest in receiving the multicast packet.
			Note: The value of this field may be changed as a result of
			network address translation before arriving at the gateway.
	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 ... |		| V=0 |Type=6 | Reserved | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
	| ... |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		~ IP Multicast Packet ~
			| |
			+ - - - - - - - - - - - - - - - - - - - - - - - -+
			| : : : :
			+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - - - - - - - - - -
	AMT IP Multicast Data		Multicast Data Message Format
	6.7.1. Type		5.1.6.1. Version (V)
	The type of the message.		The protocol version number for this message is 0.
	6.7.2. Reserved		5.1.6.2. Type
	An 8-bit reserved field. Sent as 0, ignored on receipt.		The type number for this message is 6.
	6.7.3. IP Multicast Data		5.1.6.3. Reserved
	The original IP Multicast data packet that is being replicated by the		Bits that MUST be set to zero by the relay and ignored by the
	Relay to the Gateway, including the original IP header.		gateway.
	6.8. AMT Teardown		5.1.6.4. IP Multicast Data
	An AMT Teardown is sent by a Gateway after a valid Response MAC has		A complete IPv4 or IPv6 Multicast datagram.
	been received and after the source address that was used to generate
	the Response MAC is no longer available for sending packets.
	It is sent to the source address received in the original Query which		5.1.7. Teardown
	should be the same as the original Request.
	The UDP destination port number should be the same one sent in the		A gateway sends a Teardown message to a relay to request that it stop
	original Request.		sending Multicast Data messages to a tunnel endpoint created by an
			earlier Membership Update message. A gateway sends this message when
			it detects that a Request message sent to the relay carries an
			address that differs from that carried by a previous Request message.
			The gateway uses the Gateway IP Address and Gateway Port Number
			Fields in the Membership Query message to detect these address
			changes.
	An AMT Teardown from the original source address and source port is		To provide backwards compatibility with early implementations of the
	NOT valid and should be discarded if received. Use an AMT Membership		AMT protocol, support for this message and associated procedures is
	Update instead.		considered OPTIONAL - gateways are not required to send this message
			and relays are not required to act upon it.
	In order for the Relay to verify the Teardown message, this message		The UDP/IP datagram containing this message MUST carry a valid, non-
	must contain the original source address and source port in addition		zero UDP checksum and carry the following IP address and UDP port
	to the Original Request Nonce and Original Response MAC. In		values:
	situations where NAT is used, this information can be known by the
	Gateway thanks to the optional Gateway information fields in the
	Query message (Section 6.5.6). Hence, a Relay supporting the
	Teardown mechanism SHOULD include the Gateway information fields in
	the Query messages it sends.
	On reception of a valid Teardown message, a Relay should remove all		Source IP Address - The IP address of the gateway interface used to
	state corresponding to the gateway identified by the (original source		send the message. This address may differ from that used to send
	address, original source port) tuple, and stop forwarding all traffic		earlier messages. Note: The value of this field may be changed as
	to this destination.		a result of network address translation before arriving at the
			relay.
			Source UDP Port - The UDP port number. This port number may differ
			from that used to send earlier messages. Note: The value of this
			field may be changed as a result of network address translation
			before arriving at the relay.
			Destination IP Address - The unicast IP address of the relay.
			Destination UDP Port - The IANA-assigned AMT port number.
	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=0x7 | Reserved | Original Response MAC |		| V=0 |Type=7 | Reserved | Response MAC |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
	| Original Response MAC (continued) |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Original Request Nonce |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Original Source Port | Original Source Address ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Original Source Address (ctd) ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ... Original Source Address (ctd) ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ... Original Source Address (ctd) ... |		| Request Nonce |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ... Original Src Addr. (ctd) |		| Gateway Port Number | |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
			| |
			+ +
			| Gateway IP Address (IPv4 or IPv6) |
			+ +
			| |
			+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	AMT Membership Teardown		Membership Teardown Message Format
	6.8.1. Type		5.1.7.1. Version (V)
	The type of the message.		The protocol version number for this message is 0.
	6.8.2. Reserved		5.1.7.2. Type
	A 8-bit reserved field. Sent as 0, ignored on receipt.		The type number for this message is 7.
	6.8.3. Original Response MAC		5.1.7.3. Reserved
	The 48-bit MAC received in the Membership Query.		Reserved bits that MUST be set to zero by the gateway and ignored by
			the relay.
	6.8.4. Original Request Nonce		5.1.7.4. Response MAC
	A 32-bit identifier corresponding to the original Request.		A 48-bit value copied from the Response MAC field (Section 5.1.4.6)
			in the last Membership Query message the relay sent to the gateway
			endpoint address of the tunnel to be torn down. The gateway endpoint
			address is provided by the Gateway IP Address and Gateway Port Number
			fields carried by the Membership Query message.
	6.8.5. Original Source Port		5.1.7.5. Request Nonce
	The 16-bit port number used in the original AMT Request message that		A 32-bit value copied from the Request Nonce field (Section 5.1.4.7)
	was used to generate the Original Response MAC.		in the last Membership Query message the relay sent to the gateway
			endpoint address of the tunnel to be torn down. The gateway endpoint
			address is provided by the Gateway IP Address and Gateway Port Number
			fields carried by the Membership Query message. This value must
			match that used by the relay to compute the value stored in the
			Response MAC field.
	6.8.6. Original Source Address		5.1.7.6. Gateway Port Number
	A 16-byte field containing the IP source address used in the original		A 16-bit UDP port number that, when combined with the value contained
	AMT Request message that was used to generate the Original Response		in the Gateway IP Address field, forms the tunnel endpoint address
	MAC of the Request message that triggered this Query message. The		that the relay will use to identify the tunnel instance to tear down.
	field contains an IPv4-compatible IPv6 address ([RFC4291], section		The relay provides this value to the gateway using the Gateway Port
	2.5.5.1) if the address is an IPv4 address (i.e. the IPv4 address		Number field (Section 5.1.4.9.1) in a Membership Query message. This
	prefixed with 96 bits set to zero), or an IPv6 address.		port number must match that used by the relay to compute the value
			stored in the Response MAC field.
	7. AMT Gateway Details		5.1.7.7. Gateway IP Address
	This section details the behavior of an AMT Gateway, which may be a		A 16-byte IP address that, when combined with the value contained in
	router serving an AMT site, or the site may consist of a single host,		the Gateway Port Number field, forms the tunnel endpoint address that
	serving as its own gateway.		the relay will used to identify the tunnel instance to tear down.
			The relay provides this value to the gateway using the Gateway IP
			Address field (Section 5.1.4.9.2) in a Membership Query message.
	7.1. At Startup Time		This field may contain an IPv6 address or an IPv4 address stored as
			an IPv4-compatible IPv6 address, where the IPv4 address is prefixed
			with 96 bits set to zero (See [RFC4291]). This address must match
			that used by the relay to compute the value stored in the Response
			MAC field.
	At startup time, the AMT gateway will bring up an AMT pseudo-		5.2. Gateway Operation
	interface to be used for encapsulation. The gateway needs to
	discover an AMT Relay to send Membership Requests. It can send an
	AMT Relay Discovery at startup time or wait until it has a group
	membership to report. The AMT Relay Discovery message is sent to the
	AMT Relay Anycast Address. A unicast address (which is treated as a
	link-layer address to the encapsulation interface) is received in the
	AMT Relay Advertisement message. The discovery process SHOULD be
	done periodically (e.g., once a day) to re-resolve the unicast
	address of a close relay. To prevent startup synchronization, the
	timer SHOULD use at least 10 percent jitter.
	If the gateway is serving as a local router, it SHOULD also function		The following sections describe gateway implementation requirements.
	as an IGMP/MLD Proxy, as described in [RFC4605], with its IGMP/MLD		A non-normative discussion of gateway operation may be found in
	host-mode interface being the AMT pseudo-interface. This enables it		Section 4.2.
	to translate group memberships on its downstream interfaces into
	IGMP/MLD Reports. Hosts receiving multicast packets through an AMT
	gateway acting as a proxy should ensure that their M-RIB accepts
	multicast packets from the AMT gateway for the sources it is joining.
	7.2. Gateway identification		5.2.1. IP/IGMP/MLD Protocol Requirements
	From the point of view of a Relay, a Gateway is identified by the (IP		Gateway operation requires a subset of host mode IPv4/IGMP and IPv6/
	source address, UDP source port) tuple in Membership Update messages.		MLD functionality to provide group membership tracking, general query
	If an implementation of Gateway procedure was to use a different UDP		processing, and report generation. A gateway MAY use IGMPv2 (ASM),
	source port and/or IP source address to join or leave different		IGMPv3 (ASM and SSM), MLDv1 (ASM) or MLDv2 (ASM and SSM).
	multicast groups, it would appear to the Relay as distinct Gateways.
	For instance, a Relay having forwarding state resulting in the		An application with embedded gateway functionality must provide its
	forwarding of (S,G) to a said gateway identified by a (IP source		own implementation of this subset of the IPv4/IGMP and IPv6/MLD
	address, UDP source port) tuple, will not remove this state if it		protocols. The service interface used to manipulate group membership
	receives an AMT Membership Update message from a different (IP source		state need not match that described in the IGMP and MLD
	address, UDP source port) tuple.		specifications, but the actions taken as a result SHOULD be similar
			to those described in Section 5.1 of [RFC3376] and Section 6.1 of
			[RFC3810]. The gateway application will likely need to implement
			many of the same functions as a host IP stack, including checksum
			verification, dispatching, datagram filtering and forwarding, and IP
			encapsulation/decapsulation. Applications that use AMT to join
			multicast UDP streams may also need to perform IP reassembly to
			reconstruct UDP datagrams that were fragmented prior to replication
			and encapsulation in the relay.
	It results that a Gateway has to use the same UDP source port for AMT		The IP-encapsulated IGMP/MLD messages generated by the gateway IPv4/
	Request and AMT Update messages related to a same (S,G). A said		IGMP or IPv6/MLD implementation MUST conform to the descriptions
	Gateway instance is typically expected to use the same UDP source		found in Section 4 of [RFC3376] and Section 5 of [RFC3810]. These
	port and IP source address for all Request and Updates messages for		datagrams MUST possess the IP headers, header options and header
	all multicast groups.		values called for in these RFCs, with the following exception; the
			source IP address for an IGMP/MLD report datagram MAY be set to the
			"unspecified" address (all octets are zero ). This exception is made
			because the gateway pseudo-interface might not possess an address,
			and even if such an address exists, that address would not be a valid
			source address on any relay interface. To allow for this exception,
			a relay must accept an IGMP or MLD report carried by a Membership
			Update message regardless of the source address it carries. See
			Section 5.3.1.
	7.3. Joining Multicast Groups		The gateway IGMP/MLD implementation SHOULD retransmit unsolicited
			membership state-change reports and merge new state change reports
			with pending reports as described in Section 5.1 of [RFC3376] and
			Section 6.1 of [RFC3810]. The number of retransmissions is specified
			by the relay in the Querier's Robustness Variable (QRV) field in the
			last general query forwarded by the pseudo-interface.
	The IGMP/MLD protocol usually operates by having the Querier		The gateway IGMP/MLD implementation SHOULD handle general query
	multicast an IGMP/MLD Query message on the link. This behavior does		messages as described in Section 5.2 of [RFC3376] and Section 6.2 of
	not work on NBMA links which do not support multicast. Since the set		[RFC3810], but MAY ignore the Max Resp Code field value and generate
	of gateways is typically unknown to the relay (and potentially quite		a current state report without any delay.
	large), unicasting the queries is also impractical. The following
	behavior is used instead.
	Applications residing in a gateway should join groups on the AMT		A gateway IPv4 implementation MUST accept IPv4 datagrams that carry
	pseudo-interface, causing IGMP/MLD Membership/Listener Reports to be		multicast data or the general query variant of the IGMPv3 Membership
	sent over that interface. When UDP encapsulating the membership		Query message, as described in Section 4 of [RFC3376].
	reports (and in fact any other messages, unless specified otherwise
	in this document), the destination address in the outer IP header is
	the relay's unicast address. Robustness is provided by the
	underlying IGMP/MLD protocol messages sent on the AMT pseudo-
	interface. In other words, the gateway does not need to retransmit
	IGMP/MLD Membership/Listener Reports and Leave/Done messages received
	on the pseudo-interface since IGMP/MLD will already do this. The
	gateway simply needs to encapsulate each IGMP/MLD Membership/Listener
	Report and Leave/Done message it receives.
	However, since periodic IGMP/MLD Membership/Listener Reports are sent		A gateway IPv6 implementations MUST accept IPv6 datagrams that carry
	in response to IGMP/MLD Queries, a mechanism to trigger periodic		multicast data or the general query variant of the MLDv2 Multicast
	Membership/Listener Reports and Leave/Done messages is necessary.		Listener Query message, as described in Section 5 of [RFC3810].
	The gateway should use a timer to trigger periodic AMT Membership
	Updates.
	If the gateway is behind a firewall device, the firewall may require		5.2.2. Pseudo-Interface Configuration
	the gateway to periodically refresh the UDP state in the firewall at
	a shorter interval than the standard IGMP/MLD Query interval. AMT
	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
	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		A gateway host may possess or create multiple gateway pseudo-
	[RFC3376] and [RFC3810] to adjust the number of Membership/Listener		interfaces, each with a unique configuration that describes a binding
	Reports that are sent by the host joining the group.		to a specific IP protocol, relay address, relay discovery address or
			upstream network interface.
	7.4. Responding to Relay Changes		5.2.2.1. Static Relay Address
	When a gateway determines that its current relay is unreachable		Before a gateway implementation can execute the AMT protocol to
	(e.g., upon receipt of an ICMP Unreachable message [RFC0792] for the		request and receive multicast traffic, it must be supplied with a
	relay's unicast address), it may need to repeat relay address		unicast relay address. A gateway implementation may rely on static
	discovery. However, care should be taken not to abandon the current		address assignment or support some form of dynamic address discovery.
	relay too quickly due to transient network conditions.		This specification does not require the use of any particular method
			to obtain a relay address - an implementation may employ any method
			that returns a suitable relay address.
	8. AMT Relay Details		5.2.2.2. Static Relay Discovery Address
	8.1. At Startup time		If a gateway implementation uses AMT relay discovery to obtain a
			relay address, it must first be supplied with a relay discovery
			address. The relay discovery address may be an anycast or unicast
			address. A gateway implementation may rely on a static address
			assignment or some form of dynamic address discovery. This
			specification does not require that a gateway implementation use any
			particular method to obtain a relay discovery address - an
			implementation may employ any method that returns a suitable relay
			discovery address.
	At startup time, the relay router will bring up an NBMA-style AMT		5.2.2.3. Upstream Interface Selection
	pseudo-interface. It shall also add the AMT Relay Anycast Address on
	some interface.
	The relay router shall then advertise the AMT Relay Anycast Prefix		A gateway host that possesses multiple network interfaces or
	into the unicast-only Internet, as if it were a connection to an		addresses may allow for an explicit selection of the interface to use
	external network. When the advertisement is done using BGP, the AS		when communicating with a relay. The selection might be made to
	path leading to the AMT Relay Anycast Prefix shall include the		satisfy connectivity, tunneling or IP protocol requirements.
	identifier of the local AS.
	The relay router shall also enable IGMPv3/MLDv2 on the AMT pseudo-		5.2.2.4. Optional Retransmission Parameters
	interface, except that it shall not multicast Queries (this might be
	done, for example, by having the AMT pseudo-device drop them, or by
	having the IGMP/MLD module not send them in the first place).
	8.2. Receiving Relay Discovery messages sent to the Anycast Address		A gateway implementation that supports retransmission MAY require the
			following information:
	When a relay receives an AMT Relay Discovery message directed to the		Discovery Timeout
	AMT Relay Anycast Address, it should respond with an AMT Relay		Initial time to wait for a response to a Relay Discovery message.
	Advertisement containing its unicast address. The source and
	destination addresses of the advertisement should be the same as the
	destination and source addresses of the discovery message
	respectively. Further, the nonce in the discovery message MUST be
	copied into the advertisement message.
	8.3. Receiving Membership Updates from AMT Gateways		Maximum Relay Discovery Retransmission Count
			Maximum number of Relay Discovery retransmissions to allow before
			terminating relay discovery and reporting an error.
	The relay operates passively, sending no periodic IGMP/MLD Queries		Request Timeout
	but simply tracking membership information according to AMT Request/		Initial time to wait for a response to a Request message.
	Query/Membership Update tuples received. As noted in Section 7.2,
	the Relay tracks Gateways based on the (IP source address, UDP source
	port) tuple. In addition, the relay must also do explicit membership
	tracking, as to which gateways on the AMT pseudo-interface have
	joined which groups. Once an AMT Membership Update has been
	successfully received, it updates the forwarding state for the
	appropriate group and source (if provided). When data arrives for
	that group, the traffic must be encapsulated, once to each (address,
	port) of each gateway which has joined that group or (S,G).
	The explicit membership tracking and unicast replication may be done		Maximum Request Retransmission Count
	in any implementation-specific manner. Some examples are:		Maximum number of Request retransmissions to allow before
			abandoning a relay and restarting relay discovery or reporting an
			error.
	1. The AMT pseudo-device driver might track the group information		Maximum Retries Count For "Destination Unreachable"
	and perform the replication at the "link-layer", with no changes		The maximum number of times a gateway should attempt to send the
	to a pre-existing IGMP/MLD module.		same Request or Membership Update message after receiving an ICMP
			"Destination Unreachable".
	2. The IGMP/MLD module might have native support for explicit		5.2.3. Gateway Service
	membership tracking, especially if it supports other NBMA-style
	interfaces.
	If a relay wants to affect the rate at which the AMT Requests are		In the following descriptions, a gateway pseudo interface is treated
	originated from a gateway, it can tune the membership timeout by		as a passive entity managed by a gateway service. The gateway
	adjusting the Querier's Query Interval Code (QQIC) field in the IGMP/		pseudo-interface provides the state and the gateway service provides
	MLD Query contained within the AMT Membership Query message. The		the processing. The term "gateway" is used when describing service
	QQIC field is defined in [RFC3376] and [RFC3810]. However, since the		behavior with respect to a single pseudo-interface.
	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.
	9. IANA Considerations		5.2.3.1. Startup
	9.1. IPv4 and IPv6 Anycast Prefix Allocation		When a gateway pseudo-interface is started, the gateway service
			begins listening for AMT messages sent to the UDP endpoint(s)
			associated with the pseudo-interface and for any locally-generated
			IGMP/MLD messages passed to the pseudo-interface. The handling of
			these messages is described below.
	The IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated		When the pseudo-interface is enabled, the gateway service MAY:
	to the public AMT Relays to advertise to the native multicast
	backbone. The prefix length should be determined by the IANA; the
	prefix should be large enough to guarantee advertisement in the
	default-free BGP networks.
	9.1.1. IPv4		o Optionally execute the relay discovery procedure described in
			Section 5.2.3.4.
	A prefix length of 16 will meet this requirement.		o Optionally execute the membership query procedure described in
			Section 5.2.3.5 to start the periodic membership update cycle.
	9.1.2. IPv6		5.2.3.2. Handling AMT Messages
	A prefix length of 32 will meet this requirement. IANA has		A gateway MUST ignore any datagram it receives that cannot be
	previously set aside the range 2001::/16 for allocating prefixes for		interpreted as a Relay Advertisement, Membership Query, or Multicast
	this purpose.		Data message. The handling of Relay Advertisement, Membership Query,
			and Multicast Data messages is addressed in the sections that follow.
	9.2. UDP Port number		While listening for AMT messages, a gateway may be notified that an
			ICMP Destination Unreachable message was received as a result of an
			AMT message transmission. Handling of ICMP Destination Unreachable
			messages is described in Section 5.2.3.9.
	IANA has previously allocated UDP reserved port number 2268 for AMT		5.2.3.3. Handling Multicast Data Messages
	encapsulation.
	10. Security Considerations		A gateway may receive Multicast Data messages after it sends a
			Membership Update message to a relay that adds a group subscription.
			The gateway may continue to receive Multicast Data messages long
			after the gateway sends a Membership Update message that deletes
			existing group subscriptions. The gateway MUST be prepared to
			receive these messages at any time, but MAY ignore them or discard
			their contents if the gateway no longer has any interest in receiving
			the multicast datagrams contained within them.
	The anycast technique introduces a risk that a rogue router or a		A gateway MUST ignore a Multicast Data message if it fails to satisfy
	rogue AS could introduce a bogus route to the AMT Relay Anycast		any of the following requirements:
	prefix, and thus divert the traffic. Network managers have to
	guarantee the integrity of their routing to the AMT Relay Anycast
	prefix in much the same way that they guarantee the integrity of all
	other routes.
	Gateways will accept and decapsulate multicast traffic from any		o The source IP address and UDP port carried by the Multicast Data
	source from which regular unicast traffic is accepted. If this is,		message MUST be equal to the destination IP address and UDP port
	for any reason, felt to be a security risk, then additional source		carried by the matching Membership Update message (i.e., the
	address based packet filtering MUST be applied: a gateway MUST		current relay address).
	discard encapsulated multicast packets if the source address in the
	outer header is not the address of the Relay to which the
	encapsulated join message was sent. AMT Gateways MUST also drop non-
	multicast traffic incoming on an AMT pseudo-interface.
	AMT Relays MUST NOT process AMT Data messages.		o The destination address carried by the encapsulated IP datagram
			MUST fall within the multicast address allocation assigned to the
			relavent IP protocol, i.e., 224.0.0.0/4 for IPv4 and FF00::/8 for
			IPv6.
	AMT Relays and Gateways MUST drop IP messages encapsulated in AMT		The gateway extracts the encapsulated IP datagram and forwards it to
	Query and Update messages that are not IGMP/MLD messages.		the local IP protocol implementation for checksum verification,
			fragmented datagram reassembly, source and group filtering, and
			transport-layer protocol processing.
	Even though a Relay does not need to maintain any state before		5.2.3.4. Relay Discovery Procedure
	completion of the three-way handshake (Section 5.2), if no mitigation
	is in place, it is still possible for one host to instantiate a large
	amount of Gateways instances that would each join one or more
	multicast groups to a Relay, thus resulting in a large amount of
	resources being used on the Relay. Thus, AMT Relays MUST be
	implemented so as to allow the mitigation of risks of denial of
	service attacks on their resources. A Relay SHOULD NOT allow the
	instantiation of an unbounded number of AMT pseudo-interfaces for a
	said gateway IP address. For instance, an implementation may provide
	a way to set a configurable limit on the maximum number of pseudo-
	interfaces to a same gateway IP address, with a default value for
	this limit being low enough to provide protection, and high enough to
	cope with the possibility of an address being shared by multiple
	devices.
	In the case where a Relay is reaching the situation where it would		This section describes gateway requirements related to the relay
	stop accepting to instantiate new pseudo-interfaces, it MAY stop		discovery message sequence described in Section 4.2.1.1.
	advertising the AMT Relay Anycast address; thanks to the AMT
	discovery procedures, this will allow legitimate AMT Gateways to fall
	back on another Relay.
	11. Contributors		5.2.3.4.1. Starting Relay Discovery
			A gateway may start or restart the relay discovery procedure in
			response to the following events:
			o When a gateway pseudo-interface is started (enabled).
			o When the gateway wishes to report a group subscription when none
			currently exist.
			o Before sending the next Request message in a membership update
			cycle, i.e. each time the query timer expires (see below).
			o After the gateway fails to receive a response to a Request
			message.
			o After the gateway receives a Membership Query message with the
			L-flag set to 1.
			5.2.3.4.2. Sending a Relay Discovery Message
			A gateway sends a Relay Discovery message to a relay to start the
			relay discovery process.
			The gateway MUST send the Relay Discovery message using the current
			Relay Discovery Address and IANA-assigned UDP port number as the
			destination. The Discovery Nonce value in the Relay Discovery
			message must be computed as described in Section 5.2.3.4.5.
			The gateway MUST save a copy of Relay Discovery message or save the
			Discovery Nonce value for possible retransmission and verification of
			a Relay Advertisement response.
			When a gateway sends a Relay Discovery message, it may be notified
			that an ICMP Destination Unreachable message was received as a result
			of an earlier AMT message transmission. Handling of ICMP Destination
			Unreachable messages is described in Section 5.2.3.9.
			5.2.3.4.3. Waiting for a Relay Advertisement Message
			A gateway MAY retransmit a Relay Discovery message if it does not
			receive a matching Relay Advertisement message within some timeout
			period. If the gateway retransmits the message multiple times, the
			timeout period SHOULD be adjusted to provide an random exponential
			back-off. The RECOMMENDED timeout is a random value in the range
			[initial_timeout, MIN(initial_timeout * 2^retry_count,
			maximum_timeout)], with a RECOMMENDED initial_timeout of 1 second and
			a RECOMMENDED maximum_timeout of 120 seconds (which is the
			recommended minimum NAT mapping timeout described in [RFC4787]).
			5.2.3.4.4. Handling a Relay Advertisement Message
			When a gateway receives a Relay Advertisement message it must first
			determine whether it should accept or ignore the message. A gateway
			MUST ignore a Relay Advertisement message if it fails to satisfy any
			of the following requirements:
			o The gateway MUST be waiting for a Relay Advertisement message.
			o The Discovery Nonce value contained in the Relay Advertisement
			message MUST equal to the Discovery Nonce value contained in the
			Relay Discovery message.
			o The source IP address and UDP port of the Relay Advertisement
			message MUST equal to the destination IP address and UDP port of
			the matching Relay Discovery message.
			Once a gateway receives a Relay Advertisement response to a Relay
			Discovery message, it SHOULD ignore any other Relay Advertisements
			that arrive on the AMT interface until it sends a new Relay Discovery
			message.
			If a gateway executes the relay discovery procedure at the start of
			each membership update cycle and the relay address returned in the
			latest Relay Advertisement message differs from the address returned
			in a previous Relay Advertisement message, then the gateway SHOULD
			send a Teardown message (if supported) to the old relay address,
			using information from the last Membership Query message received
			from that relay, as described in Section 5.2.3.7. This behavior is
			illustrated in the following diagram.
			Gateway Relay-1
			------- -------
			: :
			Query Expired | |
			Timer (QT)-------->| |
			| Relay Discovery |
			|------------------->|
			| |
			| Relay Advertisement|
			|<-------------------|
			| |
			| Request |
			|------------------->|
			| |
			| Membership Query |
			|<===================|
			Start | |
			(QT)<--------| Membership Update |
			|===================>|
			| |
			~ ~ Relay-2
			Expired | | -------
			(QT)-------->| | :
			| Relay Discovery | |
			|------------------------------------>|
			| | |
			| Relay Advertisement| |
			|<------------------------------------|
			| | |
			| Teardown | |
			|------------------->| |
			| | |
			| Request | |
			|------------------------------------>|
			| | |
			| Membership Query | |
			|<====================================|
			Start | | |
			(QT)<--------| Membership Update | |
			|====================================>|
			| | |
			: : :
			Teardown After Relay Address Change
			5.2.3.4.5. Discovery Nonce Generation
			The discovery nonce MUST be a random, non-zero, 32-bit value, and if
			possible, SHOULD be computed using a cryptographically secure pseudo
			random number generator. A new nonce SHOULD be generated each time
			the gateway restarts the relay discovery process. The same nonce
			SHOULD be used when retransmitting a Relay Discovery message.
			5.2.3.5. Membership Query Procedure
			This section describes gateway requirements related to the membership
			update message sequence described in Section 4.2.1.2.
			5.2.3.5.1. Starting the Membership Update Cycle
			A gateway may send a Request message to start a membership update
			cycle (following the optional relay discovery procedure) in response
			to the following events:
			o When the gateway pseudo-interface is activated.
			o When the gateway wishes to report a group subscription when none
			currently exist.
			Starting the membership update cycle when a gateway pseudo-interface
			is started provides several benefits:
			o Better performance by allowing state-change reports to be sent as
			they are generated, thus minimizing the time to join.
			o More robustness by relying on unsolicited state-change reports to
			update group membership state rather than the current-state
			reports generated by the membership update cycle. Unsolicited
			state-change reports are typically retransmitted multiple times
			while current-state reports are not.
			o Simplified implementation by eliminating any need to queue IGMP/
			MLD messages for delivery after a Membership Query is received,
			since the IGMP/MLD state-change messages may be sent as they are
			generated.
			However, this approach places an additional load on relays as a
			gateway will send periodic requests even when it has no multicast
			subscriptions. To reduce load on a relay, a gateway SHOULD only send
			a Membership Update message while it has active group subscriptions.
			A relay will still need to compute a Response MAC for each Request,
			but will not be required to recompute it a second time to
			authenticate a Membership Update message that contains no
			subscriptions.
			5.2.3.5.2. Sending a Request Message
			A gateway sends a Request message to a relay to solicit a Membership
			Query response and start the membership update cycle.
			A gateway constructs a Request message containing a Request Nonce
			value computed as described in Section 5.2.3.5.6. The gateway MUST
			set the "P" flag in the Request message to identify the protocol the
			gateway wishes the relay to use for the general query response.
			A gateway MUST send a Request message using the current Relay Address
			and IANA-assigned AMT port number as the destination.
			A gateway MUST save a copy of the Request message or save the Request
			Nonce and P-flag values for possible retransmission and verification
			of a Membership Query response.
			When a gateway sends a Request message, it may be notified that an
			ICMP Destination Unreachable message was received as a result of an
			earlier AMT message transmission. Handling of ICMP Destination
			Unreachable messages is described in Section 5.2.3.9.
			5.2.3.5.3. Waiting for a Membership Query Message
			A gateway MAY retransmit a Request message if it does not receive a
			matching Membership Query message within some timeout period. If the
			gateway retransmits the message multiple times, the timeout period
			SHOULD be adjusted to provide an random exponential back-off. The
			RECOMMENDED timeout is a random value in the range [initial_timeout,
			MIN(initial_timeout * 2^retry_count, maximum_timeout)], with a
			RECOMMENDED initial_timeout of 1 second and a RECOMMENDED
			maximum_timeout of 120 seconds (which is the recommended minimum NAT
			mapping timeout described in [RFC4787]).
			If a gateway that uses relay discovery does not receive a Membership
			Query within a specified time period or after a specified number of
			retries, the gateway SHOULD stop waiting for a Membership Query
			message and restart relay discovery to locate another relay.
			5.2.3.5.4. Handling a Membership Query Message
			When a gateway receives a Membership Query message it must first
			determine whether it should accept or ignore the message. A gateway
			MUST ignore a Membership Query message, or the encapsulated IP
			datagram within it, if the message fails to satisfy any of the
			following requirements:
			o The gateway MUST be waiting for a Membership Query message.
			o The Request Nonce value contained in the Membership Query MUST
			equal the Request Nonce value contained in the Request message.
			o The source IP address and UDP port of the Membership Query MUST
			equal the destination IP address and UDP port of the matching
			Request message (i.e. the current relay address).
			o The encapsulated IP datagram MUST carry an IGMPv3 or MLDv2
			message. The protocol MUST match the protocol identified by the
			"P" flag in the Request message.
			o The IGMPv3 or MLDv2 message MUST be a general query message.
			o The total length of the encapsulated IP datagram as computed from
			the lengths contained in the datagram header(s) MUST NOT exceed
			the available field length within the Membership Query message.
			Once a gateway receives a Membership Query response to a Request
			message, it SHOULD ignore any other Membership Query messages that
			arrive on the AMT interface until it sends a new Request message.
			The gateway MUST save the Membership Query message, or the Request
			Nonce, Response MAC, Gateway IP Address and Gateway Port Number
			fields for use in sending subsequent Membership Update and Teardown
			messages.
			The gateway extracts the encapsulated IP datagram and forwards it to
			the local IP protocol implementation for checksum verification and
			dispatching to the IGMP or MLD implementation running on the pseudo-
			interface. The gateway MUST NOT forward any octets that might exist
			between the encapsulated IP datagram and the end of the message or
			Gateway Address fields.
			An MLD datagram contained in a Membership Query message may require
			special handling. The encapsulated query generated by a relay will
			likely carry an unspecified or relay link-local source address. If a
			gateway relies on a standard host-mode MLD protocol implementation to
			process the query, that implementation will silently ignore the MLD
			query because it carries an unspecified or non-link-local source
			address - a gateway may need to construct its own query with a valid
			link-local address (e.g., a spoofed address in a virtual subnet
			defined by the address and netmask assigned to the gateway pseudo-
			interface) to ensure that the report will not be ignored by the MLD
			protocol implementation.
			The gateway must start a timer that will trigger the next iteration
			of the membership update cycle by executing the membership query
			procedure. The gateway SHOULD compute the timer duration from the
			Querier's Query Interval Code carried by the general-query. A
			gateway MAY use a smaller timer duration if required to refresh a NAT
			mapping that would otherwise timeout. A gateway MAY use a larger
			timer duration if it has no group subscriptions to report.
			If the gateway supports the Teardown message and the G-flag is set in
			the Membership Query message, the gateway MUST compare the Gateway IP
			Address and Gateway Port Number on the new Membership Query message
			with the values carried by the previous Membership Query message. If
			either value has changed the gateway MUST send a Teardown message to
			the relay as described in Section 5.2.3.7.
			If the L-flag is set in the Membership Query message, the relay is
			reporting that it is NOT accepting Membership Update messages that
			create new tunnel endpoints and will simply ignore any that do. If
			the L-flag is set and the gateway is not currently reporting any
			group subscriptions to the relay, the gateway SHOULD stop sending
			periodic Request messages and restart the relay discovery procedure
			(if discovery is enabled) to find a new relay with which to
			communicate. The gateway MAY continue to send updates even if the
			L-flag is set, if it has previously reported group subscriptions to
			the relay, one or more subscriptions still exist and the gateway
			endpoint address has not changed since the last Membership Query was
			received (see previous paragraph).
			5.2.3.5.5. Handling Query Timer Expiration
			When the query timer (started in the previous step) expires, the
			gateway should execute the membership query procedure again to
			continue the membership update cycle.
			5.2.3.5.6. Request Nonce Generation
			The request nonce MUST be a random value, and if possible, SHOULD be
			computed using a cryptographically secure pseudo random number
			generator. A new nonce MUST be generated each time the gateway
			starts the membership query process. The same nonce SHOULD be used
			when retransmitting a Request message.
			5.2.3.6. Membership Update Procedure
			This section describes gateway requirements related to the membership
			update message sequence described in Section 4.2.1.2.
			The membership update process is primarily driven by the host-mode
			IGMP or MLD protocol implementation running on the gateway pseudo-
			interface. The IGMP and MLD protocols produce current-state reports
			in response to general queries generated by the pseudo-interface via
			AMT and produce state-change reports in response to receiver requests
			made using the IGMP or MLD service interface.
			5.2.3.6.1. Handling an IGMP/MLD IP Datagram
			The gateway pseudo-interface MUST accept the following IP datagrams
			from the IPv4/IGMP and IPv6/MLD protocols running on the pseudo-
			interface:
			o IPv4 datagrams that carry an IGMPv2, or IGMPv3 Membership Report
			or an IGMPv2 Leave Group message as described in Section 4 of
			[RFC3376].
			o IPv6 datagrams that carry an MLDv1 or MLDv2 Multicast Listener
			Report or an MLDv1 Multicast Listener Done message as described in
			Section 5 of [RFC3810].
			The gateway must be prepared to receive these messages any time the
			pseudo-interface is running. The gateway MUST ignore any datagrams
			not listed above.
			A gateway that waits to start a membership update cycle until after
			it receives an IGMP/MLD state-change message MAY:
			o Discard datagrams containing IGMP/MLD messages until it receives a
			Membership Query message, at which time it processes the
			Membership Query message as normal to eventually produce a
			current-state report on the pseudo-interface which describes the
			end state (RECOMMENDED).
			o Insert IGMP/MLD messages into a queue for transmission after it
			receives a Membership Query message.
			If the datagram contains a valid IGMP or MLD message, the gateway
			sends it to the relay as described in the next section.
			5.2.3.6.2. Sending a Membership Update Message
			A gateway cannot send a Membership Update message to a relay until it
			has received a Membership Query message from a relay. If the gateway
			has not yet located a relay with which to communicate, it must first
			execute the relay discovery procedure described in Section 5.2.3.4 to
			obtain a relay address. If the gateway has a relay address, but has
			not yet received a Membership Query message, it must first execute
			the membership query procedure described in Section 5.2.3.5 to obtain
			a Request Nonce and Response MAC that can be used to send a
			Membership Update message.
			Once a gateway possesses a valid Relay Address, Request Nonce and
			Response MAC, it may encapsulate the IP datagram containing the IGMP/
			MLD message into a Membership Update message. The gateway MUST copy
			the Request Nonce and Response MAC values from the last Membership
			Query received from the relay into the corresponding fields in the
			Membership Update. The gateway MUST send the Membership Update
			message using the Relay Address and IANA-assigned AMT port number as
			the destination.
			When a gateway sends a Membership Update message, it may be notified
			that an ICMP Destination Unreachable message was received as a result
			of an earlier AMT message transmission. Handling of ICMP Destination
			Unreachable messages is described in Section 5.2.3.9.
			5.2.3.7. Teardown Procedure
			This section describes gateway requirements related to the teardown
			message sequence described in Section 4.2.1.3.
			Gateway support for the Teardown message is OPTIONAL but RECOMMENDED.
			A gateway that supports Teardown SHOULD make use of Teardown
			functionality if it receives a Membership Query message from a relay
			that has the "G" flag set to indicate that it contains valid gateway
			address fields.
			5.2.3.7.1. Handling a Membership Query Message
			As described in Section 5.2.3.5.4, if a gateway supports the Teardown
			message, has reported active group subscriptions, and receives a
			Membership Query message with the "G" flag set, the gateway MUST
			compare the Gateway IP Address and Gateway Port Number on the new
			Membership Query message with the values carried by the previous
			Membership Query message. If either value has changed the gateway
			MUST send a Teardown message as described in the next section.
			5.2.3.7.2. Sending a Teardown Message
			A gateway sends a Teardown message to a relay to request that it stop
			delivering Multicast Data messages to the gateway and delete any
			group memberships created by the gateway.
			When a gateway constructs a Teardown message, it MUST copy the
			Request Nonce, Response MAC, Gateway IP Address and Gateway Port
			Number fields from the Membership Query message that provided the
			Response MAC for the last Membership Update message sent, into the
			corresponding fields of the Teardown message.
			A gateway MUST send the Teardown message using the Relay Address and
			IANA-assigned AMT port number as the destination. A gateway MAY send
			the the Teardown message multiple times for robustness. The gateway
			SHOULD use the Querier's Robustness Variable (QRV) field contained in
			the query encapsulated within the last Membership Query to set the
			limit on the number of retransmissions. If the gateway sends the
			Teardown message multiple times, it SHOULD insert a delay between
			each transmission using the timing algorithm employed in IGMP/MLD for
			transmitting unsolicited state-change reports.
			When a gateway sends a Teardown message, it may be notified that an
			ICMP Destination Unreachable message was received as a result of an
			earlier AMT message transmission. Handling of ICMP Destination
			Unreachable messages is described in Section 5.2.3.9.
			5.2.3.8. Shutdown
			When a gateway pseudo-interface is stopped and the gateway has
			existing group subscriptions, the gateway SHOULD either:
			o Send a Teardown message to the relay as described in
			Section 5.2.3.7, but only if the gateway supports the Teardown
			message, and the current relay is returning gateway address fields
			in Membership Query messages, or
			o Send a Membership Update message to the relay that will delete
			existing group subscriptions.
			5.2.3.9. Handling ICMP Destination Unreachable Responses
			A gateway may receive an ICMP "Destination Unreachable" message
			[RFC0792] after sending an AMT message. Whether the gateway is
			notified that an ICMP message was received is highly dependent the
			gateway IP stack behavior and gateway implementation.
			If the reception of an ICMP Destination Unreachable message is
			reported to the gateway while waiting to receive an AMT message, the
			gateway may respond as follows, depending on platform capabilities
			and which outgoing message triggered the ICMP response:
			1. The gateway MAY simply abandon the current relay and restart
			relay discovery (if used). This is the least desirable approach
			as it does not allow for transient network changes.
			2. If the last message sent was a Relay Discovery or Request
			message, the gateway MAY simply ignore the ICMP response and
			continue waiting for incoming AMT messages. If the gateway is
			configured to retransmit Relay Discovery or Request messages, the
			normal retransmission behavior for those messages is preserved to
			prevent the gateway from prematurely abandoning a relay.
			3. If the last message sent was a Membership Update message, the
			gateway MAY start a new membership update and associated Request
			retransmission cycle.
			If the reception of an ICMP Destination Unreachable message is
			reported to the gateway when attempting to transmit a new AMT
			message, the gateway may respond as follows, depending on platform
			capabilities and which outgoing message triggered the ICMP response:
			1. The gateway MAY simply abandon the current relay and restart
			relay discovery (if used). This is the least desirable approach
			as it does not allow for transient network changes.
			2. If the last message sent was a Relay Discovery, Request or
			Teardown message, the gateway MAY attempt to transmit the new
			message. If the gateway is configured to retransmit Relay
			Discovery, Request or Teardown messages, the normal
			retransmission behavior for those messages is preserved to
			prevent the gateway from prematurely abandoning a relay.
			3. If the last message sent was a Membership Update message, the
			gateway SHOULD start a new membership update and associated
			Request retransmission cycle.
			5.3. Relay Operation
			The following sections describe relay implementation requirements. A
			non-normative discussion of relay operation may be found in
			Section 4.2.
			5.3.1. IP/IGMP/MLD Protocol Requirements
			A relay requires a subset of router-mode IGMP and MLD functionality
			to provide group membership tracking and report processing.
			A relay accessible via IPv4 MUST support IPv4/IGMPv3 and MAY support
			IPv6/MLDv2. A relay accessible via IPv6 MUST support IPv6/MLDv2 and
			MAY support IPv4/IGMPv3.
			A relay MUST apply the forwarding rules described in Section 6.3 of
			[RFC3376] and Section 7.3 of [RFC3810].
			A relay MUST handle incoming reports as described ,Section 6.4 of
			[RFC3376] and Section 7.4 of [RFC3810] with the exception that
			actions that lead to queries MAY be modified to eliminate query
			generation.
			All other aspects of IGMP/MLD router behavior, such as the handling
			of queries, querier election, etc., are not used or required for
			relay operation.
			5.3.2. Startup
			If a relay is deployed for anycast discovery, the relay MUST
			advertise an anycast Relay Discovery Address Prefix into the unicast
			routing system of the anycast domain. An address within that prefix,
			i.e., a Relay Discovery Address, MUST be assigned to a relay
			interface.
			A unicast IPv4 and/or IPv6 address MUST be assigned to the relay
			interface that will be used to send and receive AMT control and data
			messages. This address or addresses are returned in Relay
			Advertisement messages.
			The remaining details of relay "startup" are highly implementation-
			dependent and are not addressed in this document.
			5.3.3. Running
			When a relay is started, it begins listening for AMT messages on the
			interface to which the unicast Relay Address(es) has been assigned,
			i.e., the address returned in Relay Advertisement messages.
			5.3.3.1. Handling AMT Messages
			A relay MUST ignore any message other than a Relay Discovery,
			Request, Membership Update or Teardown message. The handling of
			Relay Discovery, Request, Membership Update, and Teardown messages is
			addressed in the sections that follow.
			Support for the Teardown message is OPTIONAL. If a relay does not
			support the Teardown message, it MUST also ignore this message.
			A relay that conforms to this specification MUST ignore any message
			with a Version field value other than zero.
			5.3.3.2. Handling a Relay Discovery Message
			This section describes relay requirements related to the relay
			discovery message sequence described in Section 4.2.1.1.
			A relay MUST accept and respond to Relay Discovery messages sent to
			an anycast relay discovery address or the unicast relay address. If
			a relay receives a Relay Discovery message sent to its unicast
			address, it must respond just as it would if the message had been
			sent to its anycast discovery address.
			When a relay receives a Relay Discovery message it responds by
			sending a Relay Advertisement message back to the source of the Relay
			Discovery message. The relay MUST use the source IP address and UDP
			port of the Relay Discovery message as the destination IP address and
			UDP port. The relay MUST use the destination IP address and UDP port
			of the Relay Discovery as the source IP address and UDP port to
			ensure successful NAT traversal.
			The relay MUST copy the value contained in the Discovery Nonce field
			of the Relay Discovery message into the Discovery Nonce field in the
			the Relay Advertisement message.
			If the Relay Discovery message was received as an IPv4 datagram, the
			relay MUST return an IPv4 address in the Relay Address field of the
			Relay Advertisement message. If the Relay Discovery message was
			received as an IPv6 datagram, the relay may return an IPv4 or IPv6
			address in the Relay Address field.
			5.3.3.3. Handling a Request Message
			This section describes relay requirements related to the membership
			query portion of the message sequence described in Section 4.2.1.2.
			When a relay receives a Request message it responds by sending a
			Membership Query message back to the source of the Request message.
			The relay MUST use the source IP address and UDP port of the Request
			message as the destination IP address and UDP port for the Membership
			Query message. The source IP address and UDP port carried by the
			Membership Query MUST match the destination IP address and UDP port
			of the Request to ensure successful NAT traversal.
			The relay MUST return the value contained in the Request Nonce field
			of the Request message in the Request Nonce field of the Membership
			Query message. The relay MUST compute a MAC value, as described in
			Section 5.3.5, and return that value in the Response MAC field of the
			Membership Query message.
			If a relay supports the Teardown message, it MUST set the G-flag in
			the Membership Query message and return the source IP address and UDP
			port carried by the Request message in the corresponding Gateway IP
			Address and Gateway Port Number fields. If the relay does not
			support the Teardown message it SHOULD NOT set these fields as this
			may cause the gateway to generate unnecessary Teardown messages.
			If the P-flag in the Request message is 0, the relay MUST return an
			IPv4-encapsulated IGMPv3 general query in the Membership Query
			message. If the P-flag is 1, the relay MUST return an IPv6-
			encapsulated MLDv2 general query in the Membership Query message.
			If the relay is not accepting Membership Update messages that create
			new tunnel endpoints due to resource limitations, it SHOULD set the
			L-flag in the Membership Query message to notify the gateway of this
			state. Support for the L-flag is OPTIONAL. See Section 5.3.3.8.
			The IGMPv3/MLDv2 general query datagram that a relay encapsulates
			within a Membership Query message MUST conform to the descriptions
			found in Section 4.1 of [RFC3376] and Section 5.1 of [RFC3810].
			These datagrams MUST possess the IP headers, header options and
			header values called for in these RFCs, with the following exception;
			the source IP address for an IGMP/MLD general query datagram MAY be
			set to the "unspecified" address (all octets are zero). This
			exception is made because any address that a relay might use will not
			be a valid source address on any gateway interface. To allow for
			this exception, gateways must accept an IGMP or MLD query regardless
			of the source address it carries. See Section 5.2.1.
			A relay MUST set the Querier's Query Interval Code (QQIC) field in
			the general query to supply the gateway with a suggested time
			duration to use for the membership query timer. The QQIC field is
			defined in Section 4.1.1 in [RFC3376] and Section 5.1.3 in [RFC3810].
			A relay MAY adjust this value to affect the rate at which the Request
			messages are sent from a gateway. However, a gateway is allowed to
			use a shorter duration than specified in the QQIC field, so a relay
			may be limited in its ability to spread out Requests coming from a
			gateway.
			A relay MUST set the Querier's Robustness Variable (QRV) field in the
			general query to a non-zero value. This value SHOULD be greater than
			one. If a gateway retransmits a membership state change messages, it
			will retransmit them (robustness variable - 1) times.
			A relay SHOULD set the Max Resp Code field in the general query to a
			value of 1 to trigger an immediate response from the gateway (some
			host IGMP/MLD implementations may not accept a value of zero). A
			relay SHOULD NOT use the IGMPv2/MLDv2 Query Response Interval
			variable, if available, to generate the Max Resp Code field value as
			the Query Response Interval variable is used in setting the duration
			of group state timers and must not be set to such a small value. See
			Section 5.3.3.7.
			5.3.3.4. Handling a Membership Update Message
			This section describes relay requirements related to the membership
			update portion of the message sequence described in Section 4.2.1.2.
			When a relay receives a Membership Update message it must first
			determine whether it should accept or ignore the message. A relay
			MUST NOT make any changes to group membership and forwarding state if
			the message fails to satisfy any of the following requirements:
			o The IP datagram encapsulated within the message MUST be one of the
			following:
			* IPv4 datagram carrying an IGMPv2 or IGMPv3 Membership Report
			message.
			* IPv4 datagram carrying an IGMPv2 Leave Group message.
			* IPv6 datagram carrying an MLDv1 or MLDv2 Multicast Listener
			Report message.
			* IPv6 datagram carrying MLDv1 Multicast Listener Done message.
			o The encapsulated IP datagram MUST satisfy the IP header
			requirements for the IGMP or MLD message type as described in
			Section 4 of [RFC3376], Section 2 of [RFC2236], Section 5 of
			[RFC3810], Section 3 of [RFC2710].
			o The total length of the encapsulated IP datagram as computed from
			the lengths contained in the datagram header(s) MUST NOT exceed
			the available field length within the Membership Update message.
			o The computed checksums for the encapsulated IP datagram and its
			payload MUST match the values contained therein. Checksum
			computation and verification varies by protocol; See [RFC0791] for
			IPv4, [RFC3376] for IGMPv3, and [RFC4443] for MLD (ICMPv6).
			o If processing of the encapsulated IGMP or MLD message would result
			in an allocation of new state or a modification of existing state,
			the relay MUST authenticate the source of the Membership message
			by verifying that the value contained in the Response MAC field
			equals the MAC value computed from the fields in the Membership
			Update message datagram. Because the private secret used to
			compute Response MAC values may change over time, the relay MUST
			retain the previous version of the private secret to use in
			authenticating Membership Updates sent during the subsequent query
			interval. If the first attempt at Response MAC authentication
			fails, the relay MUST attempt to authenticate the Response MAC
			using the previous private secret value unless 2*query_interval
			time has elapsed since the private secret change. See
			Section 5.3.5. An alternative approach to Response MAC generation
			that avoids repeated Response MAC computations may be found in
			Appendix A.1.
			A relay MAY skip source authentication to reduce the computational
			cost of handling Membership Update messages if the relay can make a
			trivial determination that the IGMP/MLD message carried by the
			Membership Update message will produce no changes in group membership
			or forwarding state. The relay does not need to compute and compare
			MAC values if it finds there are no group subscriptions for the
			source of the Membership Update message and either of the following
			is true:
			o The encapsulated IP datagram is an IGMPv3 Membership Report or
			MLDv2 Multicast Listener Report message that contains no group
			records. This may often be the case for gateways that
			continuously repeat the membership update cycle even though they
			have no group subscriptions to report.
			o The encapsulated IP datagram is an IGMPv2 Leave Group or MLDv1
			Multicast Listener Done message.
			An MLD datagram contained in a Membership Update message may require
			special handling. The encapsulated datagram generated by a gateway
			will likely carry an unspecified or link-local source address. If
			the relay relies on a standard router-mode MLD protocol
			implementation to process these reports, that implementation may
			silently ignore the MLD report because it carries an unspecified or
			non-link-local source address - a relay may need to use the contents
			of the encapsulated datagram to construct a new datagram with a valid
			link-local source address (e.g., a spoofed address in a virtual
			subnet defined by the address and netmask assigned to the relay
			pseudo-interface) to ensure that the report will not be ignored by
			the MLD protocol implementation.
			Once a relay has determined that the Membership Update message is
			valid, it processes the encapsulated IGMP or MLD membership message
			to update group membership state and communicates with the multicast
			protocol to update forwarding state and possibly send multicast
			protocol messages towards upstream routers. The relay MUST ignore
			any octets that might exist between the encapsulated IP datagram and
			the end of the Membership Update message.
			As described in Section 4.2.2, a relay uses the source IP address and
			source UDP port carried by a Membership Update messages to identify a
			tunnel endpoint. A relay uses the tunnel endpoint as the destination
			address for any Multicast Data messages it sends as a result of the
			group membership and forwarding state created by processing the IGMP/
			MLD messages contained in Membership Update messages received from
			the endpoint.
			If a Membership Update message originates from a new endpoint, the
			relay MUST determine whether it can accept updates from a new
			endpoint. If a relay has been configured with a limit on the total
			number of endpoints, or a limit on the total number of endpoints for
			a given source address, then the relay MAY ignore the Membership
			Update message and possibly withdraw any Relay Discovery Address
			Prefix announcement that it might have made. See Section 5.3.3.8.
			A relay MUST maintain some form of group membership database for each
			endpoint. The per-endpoint databases are used update a forwarding
			table containing entries that map an (*,G) or (S,G) subscription to a
			list of tunnel endpoints.
			A relay MUST maintain some form group membership database
			representing a merger of the group membership databases of all
			endpoints. The merged group membership database is used to update
			upstream multicast forwarding state.
			A relay MUST maintain a forwarding table that maps each unique (*,G)
			and (S,G) subscription to a list of tunnel endpoints. A relay uses
			this forwarding table to provide the destination address when
			performing UDP/IP encapsulation of the incoming multicast IP
			datagrams to form Multicast Data messages.
			If a group filter mode for a group entry on a tunnel endpoint is
			EXCLUDE, the relay SHOULD NOT forward datagrams that originate from
			sources in the filter source list unless the relay architecture does
			not readily support source filtering. A relay MAY ignore the source
			list if necessary because gateways are expected to do their own
			source filtering.
			5.3.3.5. Handling a Teardown Message
			This section describes relay requirements related to the teardown
			message sequence described in Section 4.2.1.3.
			When a relay (that supports the Teardown message) receives a Teardown
			message, it MUST first authenticate the source of the Teardown
			message by verifying that the Response MAC carried by the Teardown
			message is equal to a MAC value computed from the fields carried by
			the Teardown message. The method used to compute the MAC differs
			from that used to generate and validate the Membership Query and
			Membership Update messages in that the source IP address and source
			UDP port number used to compute the MAC are taken from the Gateway IP
			Address and Gateway Port Number field in the Teardown message rather
			than from the IP and UDP headers in the datagram that carries the
			Teardown message. The MAC computation is described Section 5.3.5. A
			relay MUST ignore a Teardown message If the computed MAC does not
			equal the value of the Response MAC field.
			If a relay determines that a Teardown message is authentic, it MUST
			immediately stop transmitting Multicast Data messages to the endpoint
			identified by the Gateway IP Address and Gateway Port Number fields
			in the message. The relay MUST eventually delete any group
			membership and forwarding state associated with the endpoint, but MAY
			delay doing so to allow a gateway to recreate group membership state
			on a new endpoint and thereby avoid making unnecessary (temporary)
			changes in upstream routing/forwarding state.
			The state changes made by a relay when processing a Teardown message
			MUST be identical to those that would be made as if the relay had
			received an IGMP/MLD report that would cause the IGMP or MLD protocol
			to delete all existing group records in the group membership database
			associated with the endpoint. The processing of the Teardown message
			should trigger or mimic the normal interaction between IGMP or MLD
			and a multicast protocol to produce required changes in forwarding
			state and possibly send prune/leave messages towards upstream
			routers.
			5.3.3.6. Handling Multicast IP Datagrams
			When a multicast IP datagram is forwarded to the relay pseudo-
			interface, the relay MUST, for each gateway that has expressed an
			interest in receiving the datagram, encapsulate the IP datagram into
			a Multicast Data message and send that message to the gateway. This
			process is highly implementation dependent, but conceptually requires
			the follow steps:
			o Use the IP datagram source and destination address to look up the
			appropriate (*,G) or (S,G) entry in the endpoint forwarding table
			created for the pseudo-interface as a result of IGMP/MLD
			processing.
			o Possibly replicate the datagram for each gateway endpoint listed
			for that (*,G) or (S,G) entry.
			o Encapsulate the IP datagram in a UDP/IP Membership Data message,
			using the endpoint UDP/IP address as the destination address and
			the unicast relay address and IANA-assigned port as the source
			UDP/IP address. To ensure successful NAT traversal, the source
			address and port MUST match the destination address and port
			carried by the Membership Update message sent by the gateway to
			create the forwarding table entry.
			o Send the message to the gateway.
			The relay pseudo-interface MUST ignore any other IP datagrams
			forwarded to the pseudo-interface.
			5.3.3.7. State Timers
			A relay MUST maintain a timer or timers whose expiration will trigger
			the removal of any group subscriptions and forwarding state
			previously created for a gateway endpoint should the gateway fail to
			refresh the group membership state within a specified time interval.
			A relay MAY use a variant of the IGMPv3/MLDv2 state management
			protocol described in Section 6 of [RFC3376] or Section 7 of
			[RFC3810], or may maintain a per-endpoint timer to trigger the
			deletion of group membership state.
			If a per-endpoint timer is used, the relay MUST restart this timer
			each time it receives a new Membership Update message from the
			gateway endpoint.
			The RECOMMENDED endpoint timer duration MAY be computed from tunable
			IGMP/MLD variables as follows:
			((Robustness_Variable) * (Query_Interval)) + Query_Response_Interval
			If IGMP/MLD default values are used for these variables, the gateway
			will timeout after 125s * 2 + 10s = 260s. The timer duration MUST be
			greater than the query interval suggested in the last Membership
			Query message sent to the gateway endpoint.
			Regardless of the timers used (IGMPv3/MLDv2 or endpoint), the
			Query_Response_Interval value SHOULD be greater than or equal to 10s
			to allow for packet loss and round-trip time in the Request/
			Membership Query message exchange.
			5.3.3.8. Relay Resource Management
			A relay may be configured with various service limits to ensure a
			minimum level of performance for gateways that connect to it.
			If a relay has determined that it has reached or exceeded maximum
			allowable capacity or has otherwise exhausted resources required to
			support additional gateways, it SHOULD withdraw any Relay Discovery
			Address Prefix it has advertised into the unicast internetwork and
			SHOULD set the L-flag in any Membership Query messages it returns to
			gateways while in this state.
			If the relay receives an update from a gateway that adds group
			membership or forwarding state for an endpoint that has already
			reached maximum allowable state entries, the relay SHOULD continue to
			accept updates from the gateway but ignore any group membership/
			forwarding state additions requested by that gateway.
			If the relay receives an update from a gateway that would create a
			new tunnel endpoint for a source IP address that has already reach
			maximum allowable number of endpoints (maximum UDP ports), it should
			simply ignore the Membership Update.
			5.3.4. Shutdown
			The following steps should be treated as an abstract description of
			the shutdown procedure for a relay:
			o Withdraw the Relay Discovery Address Prefix advertisement (if
			used).
			o Stop listening for Relay Discovery messages.
			o Stop listening for control messages from gateways.
			o Stop sending data messages to gateways.
			o Delete all AMT group membership and forwarding state created on
			the relay, coordinating with the multicast routing protocol to
			update the group membership state on upstream interfaces as
			required.
			5.3.5. Response MAC Generation
			A Response MAC is produced by a hash digest computation. A Response
			MAC value is computed from a Request message for inclusion in a
			Membership Query message, is computed from a Membership Update
			message to authenticate the Response MAC carried within that message,
			and is computed from fields in a Teardown message to authenticate the
			Response MAC carried within that message.
			Gateways treat the Response MAC field as an opaque value, so a relay
			implementation may generate the MAC using any method available to it.
			The hash function RECOMMENDED for use in computing the Response MAC
			is the MD5 hash digest [RFC1321], though hash functions or keyed-hash
			functions of greater cryptographic strength may be used.
			The digest MUST be computed over the following values:
			o The Source IP address of the message (or Teardown Gateway IP
			Address field)
			o The Source UDP port of the message (or Teardown Gateway Port
			Number field)
			o The Request Nonce contained in the message.
			o A private secret known only to the relay
			An Response MAC generation solution that satisfies these requirements
			is described in Appendix A.1.
			5.3.6. Private Secret Generation
			The private secret, or hash-key, is a random value that the relay
			includes in the Response MAC hash digest computation. A relay SHOULD
			periodically compute a new private secret. The RECOMMENDED maximum
			interval is 2 hours. A relay MUST retain the prior secret for use in
			verifying MAC values that were sent to gateways just prior to the use
			of the new secret.
			The private secret SHOULD be computed using a cryptographically-
			secure pseudo-random number generator. The private secret width
			SHOULD equal that of the hash function used to compute the Response
			MAC, e.g., 128-bits for an MD5 hash.
			6. Security Considerations
			AMT is not intended to be a strongly secured protocol. In general,
			the protocol provides the same level of security and robustness as is
			provided by the UDP, IGMP and MLD protocols on which it relies. The
			lack of strong security features can largely be attributed to the
			desire to make the protocol light-weight by minimizing the state and
			computation required to service a single gateway, thereby allowing a
			relay to service a larger number of gateways.
			Many of the threats and vectors described in [RFC3552] may be
			employed against the protocol to launch various types of denial-of-
			service attacks that can affect the functioning of gateways or their
			ability to locate and communicate with a relay. These scenarios are
			described below.
			As is the case for UDP, IGMP and MLD, the AMT protocol provides no
			mechanisms for ensuring message delivery or integrity. The protocol
			does not provide confidentiality - multicast groups, sources and
			streams requested by a gateway are sent in the clear.
			The protocol does use a three-way handshake to provide trivial source
			authentication for state allocation and updates (see below). The
			protocol also requires gateways and relays to ignore malformed
			messages and those messages that do not carry expected address values
			or protocol payload types or content.
			6.1. Relays
			The three-way handshake provided by the membership update message
			sequence (See (Section 4.2.1.2)) provides a defense against source-
			spoofing-based resource-exhaustion attacks on a relay by requiring
			source authentication before state allocation. However, attackers
			may still attempt to flood a relay with Request and Membership Update
			messages to force the relay to make the hash computations in an
			effort to consume computational resources. Implementations may
			choose to limit the frequency with which a relay responds to Request
			messages sent from a single IP address or IP address and UDP port
			pair, but support for this functionality is not required. The three-
			way handshake provides no defense against an eavesdropping or man-in-
			the-middle attacker.
			Attackers that execute the gateway protocol may consume relay
			resources by instantiating a large number of tunnels or joining a
			large number of multicast streams. A relay implementation should
			provide a mechanism for limiting the number of tunnels (Multicast
			Data message destinations) that can be created for a single gateway
			source address. Relays should also provide a means for limiting the
			number of joins per tunnel instance as a defense against these
			attacks.
			Relays may withdraw their AMT anycast prefix advertisement when they
			reach configured maximum capacity or exhaust required resources.
			This behavior allows gateways to use the relay discovery process to
			find the next topologically-nearest relay that has advertised the
			prefix. This behavior also allows a successful resource exhaustion
			attack to propagate from one relay to the next until all relays
			reachable using the anycast address have effectively been taken
			offline. This behavior may also be used to acquire the unicast
			addresses for individual relays which can then be used to launch a
			DDoS attack on all of the relays without using the relay discovery
			process. To prevent wider disruption of AMT-based distribution
			network, relay anycast address advertisements can be limited to
			specific administrative routing domains. This will isolate such
			attacks to a single domain.
			6.2. Gateways
			A passive eavesdropper may launch a denial-of-service attack on a
			gateway by capturing a Membership Query or Membership Update message
			and using the request nonce and message authentication code carried
			by the captured message to send a spoofed a Membership Update or
			Teardown message to the relay. The spoofed messages may be used to
			modify or destroy group membership state associated with the gateway,
			thereby changing or interrupting the multicast traffic flows.
			A passive eavesdropper may also spoof Multicast Data messages in an
			attempt to overload the gateway or disrupt or supplant existing
			traffic flows. A properly implemented gateway will filter Multicast
			Data messages that do not originate from the expected relay address
			and should filter non-multicast packets and multicast IP packets
			whose group or source addresses are not included in the current
			reception state for the gateway pseudo-interface.
			The anycast discovery technique for finding relays (see
			Section 4.1.4) introduces a risk that a rogue router or a rogue AS
			could introduce a bogus route to a specific Relay Discovery Address
			prefix, and thus divert or absorb Relay Discovery messages sent by
			gateways. Network managers must guarantee the integrity of their
			routing to a particular Relay Discovery Address prefix in much the
			same way that they guarantee the integrity of all other routes.
			6.3. Encapsulated IP Packets
			An attacker forging or modifying a Membership Query or Membership
			Update message may attempt to embed something other than an IGMP or
			MLD message within the encapsulated IP packet carried by these
			messages in an effort to introduce these into the recipient's IP
			stack. A properly implemented gateway or relay will ignore any such
			messages - and may further choose ignore Membership Query messages
			that do not contain a IGMP/MLD general queries or Membership Update
			messages that do not contain IGMP/MLD membership reports.
			Property implemented gateways and relays will also filter
			encapsulated IP packets that appear corrupted or truncated by
			verifying packet length and checksums.
			7. IANA Considerations
			7.1. IPv4 and IPv6 Anycast Prefix Allocation
			The IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated
			to the public AMT Relays to advertise to the native multicast
			backbone (as described in Section 4.1.4). The prefix length should
			be determined by the IANA; the prefix should be large enough to
			guarantee advertisement in the default-free BGP networks.
			7.1.1. IPv4
			A prefix length of 16 will meet this requirement.
			7.1.2. IPv6
			A prefix length of 32 will meet this requirement. IANA has
			previously set aside the range 2001::/16 for allocating prefixes for
			this purpose.
			7.2. UDP Port number
			IANA has reserved UDP port number 2268 for AMT.
			8. Contributors
	The following people provided significant contributions to earlier		The following people provided significant contributions to earlier
	versions of these specifications:		versions of this specification:
	Dirk Ooms		Dirk Ooms
	OneSparrow		OneSparrow
	Belegstraat 13; 2018 Antwerp; Belgium		Belegstraat 13; 2018 Antwerp;
			Belgium
	EMail: dirk@onesparrow.com		EMail: dirk@onesparrow.com
	12. Acknowledgments		Tom Pusateri
			!j
			2109 Mountain High Rd.
			Wake Forest, NC 27587
			USA
			Email: pusateri@bangj.com
	Most of the mechanisms described in this document are based on		Dave Thaler
	similar work done by the NGTrans WG for obtaining automatic IPv6		Microsoft Corporation
			One Microsoft Way
			Redmond, WA 98052-6399
			USA
			Email: dthaler@microsoft.com
			9. Acknowledgments
			The authors would like to thank the following individuals for their
			suggestions, comments, and corrections:
			Amit Aggarwal
			Mark Altom
			Toerless Eckert
			Marshall Eubanks
			Dino Farinacci
			Lenny Giuliano
			Andy Huang
			Tom Imburgia
			Patricia McCrink
			Han Nguyen
			Doug Nortz
			Pekka Savola
			Robert Sayko
			Greg Shepherd
			Steve Simlo
			Mohit Talwar
			Lorenzo Vicisano
			Kurt Windisch
			John Zwiebel
			The anycast discovery mechanism described in this document is based
			on similar work done by the NGTrans WG for obtaining automatic IPv6
	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
	Shepherd, Dino Farinacci, Toerless Eckert, Marshall Eubanks, John
	Zwiebel, Lenny Giuliano and Greg Bumgardner.
	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		10. References
	message based on field experience.
	Contributors from AT&T provided useful inputs and ideas that were
	integrated into these specifications: Mark Altom, Andy Huang, Tom
	Imburgia, Patricia McCrink, Han Nguyen, Doug Nortz and Robert Sayko.
	13. References		10.1. Normative References
	13.1. Normative References		[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
			August 1980.
	[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.
			[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
			April 1992.
	[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.
	[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery		[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
	Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.		Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
			[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
			Architecture", RFC 4291, February 2006.
	[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.
			[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
			(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
			RFC 4787, January 2007.
			10.2. Informative References
	[I-D.ietf-6man-udpchecksums]		[I-D.ietf-6man-udpchecksums]
	Eubanks, M., "UDP Checksums for Tunneled Packets",		Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled
	draft-ietf-6man-udpchecksums-00 (work in progress),		Packets", draft-ietf-6man-udpchecksums-01 (work in
	March 2011.		progress), October 2011.
	[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing		[I-D.ietf-6man-udpzero]
	Architecture", RFC 4291, February 2006.		Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum
			Considerations", draft-ietf-6man-udpzero-05 (work in
			progress), December 2011.
	13.2. Informative References		[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
			September 1981.
	[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.
	[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.
			[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
			2", RFC 2236, November 1997.
			[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
			(IPv6) Specification", RFC 2460, December 1998.
			[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
			Translator (NAT) Terminology and Considerations",
			RFC 2663, August 1999.
			[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
			Listener Discovery (MLD) for IPv6", RFC 2710,
			October 1999.
	[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.
			[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
			Text on Security Considerations", BCP 72, RFC 3552,
			July 2003.
			[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
			Independent Multicast - Dense Mode (PIM-DM): Protocol
			Specification (Revised)", RFC 3973, January 2005.
			[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
			Message Protocol (ICMPv6) for the Internet Protocol
			Version 6 (IPv6) Specification", RFC 4443, March 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,		[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
	"Multiprotocol Extensions for BGP-4", RFC 4760,		"Multiprotocol Extensions for BGP-4", RFC 4760,
	January 2007.		January 2007.
	Authors' Addresses		[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
			Services", BCP 126, RFC 4786, December 2006.
	Dave Thaler		Appendix A. Implementation Notes
	Microsoft Corporation
	One Microsoft Way
	Redmond, WA 98052-6399
	USA
	Phone: +1 425 703 8835		A.1. Response MAC Generation and Keying
	Email: dthaler@microsoft.com
	Mohit Talwar		This specification does not require relays to use any particular
	Microsoft Corporation		method to compute the Response MAC field value - only that it contain
	One Microsoft Way		a hash of the source IP address, source UDP port, request nonce, and
	Redmond, WA 98052-6399		a private secret known only to the relay. This allows the relay
	USA		implementor a significant amount of leeway in the computation and
			structure of the value stored in the Response MAC field.
	Phone: +1 425 705 3131		Section Section 5.3.6 states that a relay should periodically compute
	Email: mohitt@microsoft.com		a new private secret (or hash-key) for MAC generation. To prevent
			the relay from rejecting Membership Update messages that contain
			Response MAC values computed from an old secret, the relay is
			required to retain the previous secret so that it can re-attempt
			authentication using the old secret, should authentication fail after
			recomputing the MAC using the new secret. However, this approach
			requires a relay to do at least two hash computations for every
			Membership Update message that carries an old or a invalid MAC. A
			better approach would be to include information within the message
			that the relay could use to choose a single secret for authentication
			rather relying on sequential authentication failures to test all
			possible secrets.
	Amit Aggarwal		The solution proposed here is to compute and exchange an
	Microsoft Corporation		"authentication cookie" rather than a simple hash value in the
	One Microsoft Way		Response MAC field. The authentication cookie would combine a
	Redmond, WA 98052-6399		timestamp with a hash value. The timestamp is used to calculate the
	USA		age of the cookie, allowing the relay to reject a message if the
			cookie's age is greater than some maximum allowable value. If the
			cookie has not expired, the relay uses the timestamp to lookup the
			secret that was in use at that time and then compute and compare the
			hash portion of the cookie to authenticate the message source.
	Phone: +1 425 706 0593		A second purpose served by including the timestamp in the MAC field
	Email: amitag@microsoft.com		is that it allows the relay to contribute an unpredictable value to
			the authentication hash. This contribution provides a defense
			against attempts to use a hash reversal algorithm to determine the
			relay's private secret as the hash result will change over time even
			if the nonce carried by the Request message does not.
	Lorenzo Vicisano		0 1 2 3
	Qualcomm Inc.		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
	3165 Kifer Road		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Santa Clara, CA 95051		| V=0 |4 or 5| Reserved | | Response MAC |
	USA		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Request Nonce |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			: :
	Email: vicisano@qualcomm.com		The Opaque Response MAC Field
	Tom Pusateri
	!j		A relay may use the opaque Response MAC field to store a cookie as
	2109 Mountain High Rd.		follows:
	Wake Forest, NC 27587
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| V=0 |4 or 5| Reserved | | Timestamp |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| MD5(Secret,Timestamp,IP_ADDR,IP_PORT,Request-Nonce) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Request Nonce |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			: :
			Using The Response MAC Field To Carry An Authentication Cookie
			The timestamp is an unsigned integer measured relative to the start
			time of relay. The age of the MAC is computed by subtracting the MAC
			timestamp from the current system timestamp. The operands must be
			unsigned 16-bit integers and the subtraction must use unsigned
			arithmetic to allow for timestamp wrap-around. The timestamp
			resolution must provide range sufficient to handle the maximum
			allowable age for a MAC, e.g., a resolution of 1 second allows a
			maximum age of 18 hours. The timestamp should start at a random
			value by adding a random offset, computed at startup, to the current
			system time.
			+-------------------------+----------------/ /-----------------+
			-->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |
			| +-------------------------+----------------/ /-----------------+
			|_____________________________________________________________________
			|
			+-------------------------+----------------/ /-----------------+ |
			-->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |--
			| +-------------------------+----------------/ /-----------------+
			|_____________________________________________________________________
			|
			+-------------------------+----------------/ /-----------------+ |
			-->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |--
			| +-------------------------+----------------/ /-----------------+
			|
			|__ Current
			Secret
			Private Secret Queue
			The timestamp is not only used to compute the age of the MAC, but is
			also used to lookup the private secret used to generate the MAC.
			Each time a new private secret is computed, the value and the time at
			which the value was computed is pushed into a fixed-length queue of
			recent values (typically only 2-deep). The relay uses the timestamp
			contained in the MAC field to lookup the appropriate secret. The
			relay iterates over the list of secrets, starting with the newest
			entry, until it finds the first secret with a timestamp that is older
			than that contained in the MAC field. The relay then uses that
			secret to compute the MAC that will be compared with that carried by
			the message.
			Authors' Addresses
			Gregory Bumgardner
			Cisco
			3700 Cisco Way
			San Jose, CA 95134
	USA		USA
	Email: pusateri@bangj.com		Phone: +1 408 853 4993
			Email: gbumgard@cisco.com
	Thomas Morin		Thomas Morin
	France Telecom - Orange		France Telecom - Orange
	2, avenue Pierre Marzin		2, avenue Pierre Marzin
	Lannion 22300		Lannion 22300
	France		France
	Phone: +33 2 96 05 3734		Phone: +33 2 96 05 3734
	Email: thomas.morin@orange-ftgroup.com		Email: thomas.morin@orange.com
End of changes. 275 change blocks.
	889 lines changed or deleted		3099 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/