draft-ietf-mboned-mtrace-v2-03.txt		draft-ietf-mboned-mtrace-v2-04.txt
	MBONED Working Group H. Asaeda		MBONED Working Group H. Asaeda
	Internet-Draft Keio University		Internet-Draft Keio University
	Intended status: Standards Track T. Jinmei		Intended status: Standards Track T. Jinmei
	Expires: September 10, 2009 ISC		Expires: January 14, 2010 ISC
	W. Fenner		W. Fenner
	Arastra, Inc.		Arastra, Inc.
	S. Casner		S. Casner
	Packet Design, Inc.		Packet Design, Inc.
	March 9, 2009		July 13, 2009
	Mtrace Version 2: Traceroute Facility for IP Multicast		Mtrace Version 2: Traceroute Facility for IP Multicast
	draft-ietf-mboned-mtrace-v2-03		draft-ietf-mboned-mtrace-v2-04
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly		from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the		available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF		copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the		Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from		IETF Standards Process. Without obtaining an adequate license from
	skipping to change at page 1, line 47		skipping to change at page 1, line 47
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 10, 2009.		This Internet-Draft will expire on January 14, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document.		and restrictions with respect to this document.
	skipping to change at page 4, line 17		skipping to change at page 4, line 17
	7.12. Src Prefix Len: 8 bits . . . . . . . . . . . . . . . . . . 19		7.12. Src Prefix Len: 8 bits . . . . . . . . . . . . . . . . . . 19
	7.13. Forwarding Code: 8 bits . . . . . . . . . . . . . . . . . 19		7.13. Forwarding Code: 8 bits . . . . . . . . . . . . . . . . . 19
	8. Mtrace2 Augmented Response Block . . . . . . . . . . . . . . . 20		8. Mtrace2 Augmented Response Block . . . . . . . . . . . . . . . 20
	9. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 21		9. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 21
	9.1. Traceroute Query . . . . . . . . . . . . . . . . . . . . . 21		9.1. Traceroute Query . . . . . . . . . . . . . . . . . . . . . 21
	9.1.1. Packet Verification . . . . . . . . . . . . . . . . . 21		9.1.1. Packet Verification . . . . . . . . . . . . . . . . . 21
	9.1.2. Normal Processing . . . . . . . . . . . . . . . . . . 21		9.1.2. Normal Processing . . . . . . . . . . . . . . . . . . 21
	9.2. Mtrace2 Request . . . . . . . . . . . . . . . . . . . . . 21		9.2. Mtrace2 Request . . . . . . . . . . . . . . . . . . . . . 21
	9.2.1. Packet Verification . . . . . . . . . . . . . . . . . 22		9.2.1. Packet Verification . . . . . . . . . . . . . . . . . 22
	9.2.2. Normal Processing . . . . . . . . . . . . . . . . . . 22		9.2.2. Normal Processing . . . . . . . . . . . . . . . . . . 22
	9.3. Forwarding Mtrace2 Requests . . . . . . . . . . . . . . . 23		9.3. Forwarding Mtrace2 Requests . . . . . . . . . . . . . . . 24
	9.4. Sending Mtrace2 Responses . . . . . . . . . . . . . . . . 24		9.4. Sending Mtrace2 Responses . . . . . . . . . . . . . . . . 24
	9.4.1. Destination Address . . . . . . . . . . . . . . . . . 24		9.4.1. Destination Address . . . . . . . . . . . . . . . . . 24
	9.4.2. Source Address . . . . . . . . . . . . . . . . . . . . 24		9.4.2. Source Address . . . . . . . . . . . . . . . . . . . . 24
	9.5. Hiding Information . . . . . . . . . . . . . . . . . . . . 24		9.5. Proxying Mtrace2 Queries . . . . . . . . . . . . . . . . . 24
	10. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 25		9.6. Hiding Information . . . . . . . . . . . . . . . . . . . . 25
	10.1. Sending Mtrace2 Query . . . . . . . . . . . . . . . . . . 25		10. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 26
	10.2. Determining the Path . . . . . . . . . . . . . . . . . . . 25		10.1. Sending Mtrace2 Queries . . . . . . . . . . . . . . . . . 26
	10.3. Collecting Statistics . . . . . . . . . . . . . . . . . . 25		10.2. Determining the Path . . . . . . . . . . . . . . . . . . . 26
	10.4. Last Hop Router . . . . . . . . . . . . . . . . . . . . . 25		10.3. Collecting Statistics . . . . . . . . . . . . . . . . . . 26
	10.5. First Hop Router . . . . . . . . . . . . . . . . . . . . . 26		10.4. Last Hop Router . . . . . . . . . . . . . . . . . . . . . 26
	10.6. Broken Intermediate Router . . . . . . . . . . . . . . . . 26		10.5. First Hop Router . . . . . . . . . . . . . . . . . . . . . 27
			10.6. Broken Intermediate Router . . . . . . . . . . . . . . . . 27
	10.7. Mtrace2 Termination . . . . . . . . . . . . . . . . . . . 27		10.7. Mtrace2 Termination . . . . . . . . . . . . . . . . . . . 27
	10.7.1. Arriving at source . . . . . . . . . . . . . . . . . . 27		10.7.1. Arriving at source . . . . . . . . . . . . . . . . . . 27
	10.7.2. Fatal error . . . . . . . . . . . . . . . . . . . . . 27		10.7.2. Fatal error . . . . . . . . . . . . . . . . . . . . . 27
	10.7.3. No previous hop . . . . . . . . . . . . . . . . . . . 27		10.7.3. No previous hop . . . . . . . . . . . . . . . . . . . 27
	10.7.4. Traceroute shorter than requested . . . . . . . . . . 27		10.7.4. Traceroute shorter than requested . . . . . . . . . . 28
	10.8. Continuing after an error . . . . . . . . . . . . . . . . 27		10.8. Continuing after an error . . . . . . . . . . . . . . . . 28
	11. Protocol-Specific Considerations . . . . . . . . . . . . . . . 29		11. Protocol-Specific Considerations . . . . . . . . . . . . . . . 29
	11.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . 29		11.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	11.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . . 29		11.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . . 29
	11.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . . 29		11.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	11.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . . 29		11.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . . 29
	11.5. AMT . . . . . . . . . . . . . . . . . . . . . . . . . . . 30		11.5. AMT . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
	12. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 31		12. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 31
	12.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . . 31		12.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . . 31
	12.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 31		12.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 31
	12.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 31		12.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 31
	12.4. Link Utilization . . . . . . . . . . . . . . . . . . . . . 32		12.4. Link Utilization . . . . . . . . . . . . . . . . . . . . . 32
	12.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . . 32		12.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . . 32
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
	13.1. Forwarding Codes . . . . . . . . . . . . . . . . . . . . . 33		13.1. Forwarding Codes . . . . . . . . . . . . . . . . . . . . . 33
	13.2. UDP Destination Port and IPv6 Address . . . . . . . . . . 33		13.2. UDP Destination Port and IPv6 Address . . . . . . . . . . 33
	14. Security Considerations . . . . . . . . . . . . . . . . . . . 34		14. Security Considerations . . . . . . . . . . . . . . . . . . . 34
	14.1. Topology Discovery . . . . . . . . . . . . . . . . . . . . 34		14.1. Topology Discovery . . . . . . . . . . . . . . . . . . . . 34
	14.2. Traffic Rates . . . . . . . . . . . . . . . . . . . . . . 34		14.2. Traffic Rates . . . . . . . . . . . . . . . . . . . . . . 34
			14.3. Limiting Query/Request Rates . . . . . . . . . . . . . . . 34
	15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35		15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36		16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
	16.1. Normative References . . . . . . . . . . . . . . . . . . . 36		16.1. Normative References . . . . . . . . . . . . . . . . . . . 36
	16.2. Informative References . . . . . . . . . . . . . . . . . . 37		16.2. Informative References . . . . . . . . . . . . . . . . . . 36
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
	1. Introduction		1. Introduction
	The unicast "traceroute" program allows the tracing of a path from		The unicast "traceroute" program allows the tracing of a path from
	one machine to another. The key mechanism for unicast traceroute is		one machine to another. The key mechanism for unicast traceroute is
	the ICMP TTL exceeded message, which is specifically precluded as a		the ICMP TTL exceeded message, which is specifically precluded as a
	response to multicast packets. On the other hand, the multicast		response to multicast packets. On the other hand, the multicast
	traceroute facility allows the tracing of an IP multicast routing		traceroute facility allows the tracing of an IP multicast routing
	paths. In this document, we specify the multicast "traceroute"		paths. In this document, we specify the multicast "traceroute"
	skipping to change at page 6, line 33		skipping to change at page 6, line 33
	o. To be able to isolate configuration problems (e.g., TTL		o. To be able to isolate configuration problems (e.g., TTL
	threshold).		threshold).
	o. To minimize packets sent (e.g. no flooding, no implosion).		o. To minimize packets sent (e.g. no flooding, no implosion).
	This document supports both IPv4 and IPv6 multicast traceroute		This document supports both IPv4 and IPv6 multicast traceroute
	facility. The protocol design, concept, and program behavior are		facility. The protocol design, concept, and program behavior are
	same between IPv4 and IPv6 mtrace2. While the original IPv4		same between IPv4 and IPv6 mtrace2. While the original IPv4
	multicast traceroute, mtrace, the query and response messages are		multicast traceroute, mtrace, the query and response messages are
	implemented as IGMP messages [4], all mtrace2 messages are carried on		implemented as IGMP messages [12], all mtrace2 messages are carried
	UDP. The packet formats of IPv4 and IPv6 mtrace2 are different		on UDP. The packet formats of IPv4 and IPv6 mtrace2 are different
	because of the different address families, but the syntax is similar.		because of the different address families, but the syntax is similar.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
	NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in		NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in
	this document are to be interpreted as described in RFC 2119 [1].		this document are to be interpreted as described in RFC 2119 [1].
	Since multicast traceroutes flow in the opposite direction to the		Since multicast traceroutes flow in the opposite direction to the
	data flow, we refer to "upstream" and "downstream" with respect to		data flow, we refer to "upstream" and "downstream" with respect to
	skipping to change at page 7, line 30		skipping to change at page 7, line 30
	The interface on which traffic is forwarded from the specified source		The interface on which traffic is forwarded from the specified source
	and group toward the destination. It is the interface on which the		and group toward the destination. It is the interface on which the
	multicast traceroute Request was received.		multicast traceroute Request was received.
	Previous-hop router:		Previous-hop router:
	The router that is on the link attached to the Incoming Interface and		The router that is on the link attached to the Incoming Interface and
	is responsible for forwarding traffic for the specified source and		is responsible for forwarding traffic for the specified source and
	group.		group.
	Group state:		Group state:
	It is the state in which a shared-tree protocol (e.g., PIM-SM [9])		It is the state in which a shared-tree protocol (e.g., PIM-SM [8])
	running on a router chooses the previous-hop router toward the core		running on a router chooses the previous-hop router toward the core
	router or Rendezvous Point (RP) as its parent router. In this state,		router or Rendezvous Point (RP) as its parent router. In this state,
	source-specific state is not available for the corresponding		source-specific state is not available for the corresponding
	multicast address on the router.		multicast address on the router.
	Source-specific state:		Source-specific state:
	It is the state in which a routing protocol running on a router		It is the state in which a routing protocol running on a router
	chooses the path that would be followed for a source-specific join.		chooses the path that would be followed for a source-specific join.
	ALL-[protocol]-ROUTERS.MCAST.NET:		ALL-[protocol]-ROUTERS.MCAST.NET:
	skipping to change at page 11, line 30		skipping to change at page 11, line 30
	source.		source.
	5.5. Query ID: 16 bits		5.5. Query ID: 16 bits
	This field is used as a unique identifier for this traceroute request		This field is used as a unique identifier for this traceroute request
	so that duplicate or delayed responses may be detected and to		so that duplicate or delayed responses may be detected and to
	minimize collisions when a multicast response address is used.		minimize collisions when a multicast response address is used.
	5.6. Client Port #		5.6. Client Port #
	Mtrace2 response is sent back to the address specified in a Response		Mtrace2 response is sent back to the address specified in a
	Address field. This field specifies the UDP port number the router		Destination Address field. This field specifies the UDP port number
	will send Mtrace2 Response. This client port number MUST NOT be		the router will send Mtrace2 Response. This client port number MUST
	changed by any router.		NOT be changed by any router.
	6. IPv4 Mtrace2 Standard Response Block		6. IPv4 Mtrace2 Standard Response Block
	Each intermediate IPv4 router in a trace path appends "response data		Each intermediate IPv4 router in a trace path appends "response data
	block" to the forwarded trace packet. The standard response data		block" to the forwarded trace packet. The standard response data
	block looks as follows.		block looks as follows.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 15, line 49		skipping to change at page 15, line 49
	0x09 RPF_IF Mtrace2 request arrived on the expected		0x09 RPF_IF Mtrace2 request arrived on the expected
	RPF interface for this source and group.		RPF interface for this source and group.
	0x0A NO_MULTICAST Mtrace2 request arrived on an interface		0x0A NO_MULTICAST Mtrace2 request arrived on an interface
	which is not enabled for multicast.		which is not enabled for multicast.
	0x0B INFO_HIDDEN One or more hops have been hidden from this		0x0B INFO_HIDDEN One or more hops have been hidden from this
	trace.		trace.
			0x0C REACHED_GW Mtrace2 request arrived on a gateway (e.g.,
			a NAT or firewall) that hides the
			information between this router and the
			mtrace2 querier
	0x81 NO_SPACE There was not enough room to insert another		0x81 NO_SPACE There was not enough room to insert another
	response data block in the packet.		response data block in the packet.
	0x82 OLD_ROUTER The previous-hop router does not understand		0x82 OLD_ROUTER The previous-hop router does not understand
	mtrace2 requests.		mtrace2 requests.
	0x83 ADMIN_PROHIB Mtrace2 is administratively prohibited.		0x83 ADMIN_PROHIB Mtrace2 is administratively prohibited.
	Note that if a router discovers there is not enough room in a packet		Note that if a router discovers there is not enough room in a packet
	to insert its response, it puts the NO_SPACE error code in the		to insert its response, it puts the NO_SPACE error code in the
	skipping to change at page 20, line 10		skipping to change at page 20, line 10
	7.13. Forwarding Code: 8 bits		7.13. Forwarding Code: 8 bits
	Same definition described in Section 6.13		Same definition described in Section 6.13
	8. Mtrace2 Augmented Response Block		8. Mtrace2 Augmented Response Block
	In addition to the standard response block, a multicast router on the		In addition to the standard response block, a multicast router on the
	path will be able to add "augumented response block" when it sends		path will be able to add "augumented response block" when it sends
	the request to its upstream router or sends the response to the		the request to its upstream router or sends the response to the
	Response Address. This augmented response block is flexible to add		Destination Address. This augmented response block is flexible to
	various information.		add various information.
	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 | Value .... |		| Type | Value .... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The augmented response block is always appended to mtrace2 TLV header		The augmented response block is always appended to mtrace2 TLV header
	(0x04). The 16 bits Type filed of the augmented response block is		(0x04). The 16 bits Type filed of the augmented response block is
	defined for various purposees, such as diagnosis (as in Section 12)		defined for various purposes, such as diagnosis (as in Section 12)
	and protocol verification. The packet length of the augmented		and protocol verification. The packet length of the augmented
	response block is specified in the augmented response block TLV		response block is specified in the augmented response block TLV
	header as see in Section 4.1.		header as seen in Section 4.1.
	This document does not define any augmented response block type.		The following augmented response block type is defined:
	Specifing how to deal with diagnosis information will be also
	described in separate documents.		Code Type
			====== =================================================
			0x01 # Mtrace2 Standard Response Blocks Returned
			When the NO_SPACE error occurs, the router sends back the mtrace2
			response with contained data (i.e., all appended response blocks),
			and continues the mtrace2 query by sending an mtrace2 request as will
			be described in Section 9.3. In this mtrace2 request, the router
			appends the augmented response block with the code "0x01" and the
			number of returned mtrace2 response blocks. Every router between
			this router and the first-hop router can recognize the limit number
			of hops by referring this number and the # hops in the header.
			This document only defines the above augmented response block type
			and does not define other augmented response block types. Specifing
			how to deal with diagnosis information will be also described in
			separate documents.
	9. Router Behavior		9. Router Behavior
	All of these actions are performed in addition to (NOT instead of)		All of these actions are performed in addition to (NOT instead of)
	forwarding the packet, if applicable. E.g. a multicast packet that		forwarding the packet, if applicable. E.g. a multicast packet that
	has TTL or the hop limit remaining MUST be forwarded normally, as		has TTL or the hop limit remaining MUST be forwarded normally, as
	MUST a unicast packet that has TTL or the hop limit remaining and is		MUST a unicast packet that has TTL or the hop limit remaining and is
	not addressed to this router.		not addressed to this router.
	9.1. Traceroute Query		9.1. Traceroute Query
	skipping to change at page 22, line 11		skipping to change at page 22, line 11
	response blocks filled in, and uses TLV type 0x1 for IPv4 and IPv6		response blocks filled in, and uses TLV type 0x1 for IPv4 and IPv6
	mtrace2. Routers can tell the difference between Queries and		mtrace2. Routers can tell the difference between Queries and
	Requests by checking the length of the packet.		Requests by checking the length of the packet.
	9.2.1. Packet Verification		9.2.1. Packet Verification
	If the mtrace2 Request does not come from an adjacent host or router,		If the mtrace2 Request does not come from an adjacent host or router,
	it MUST be silently ignored. If the mtrace2 Request is not addressed		it MUST be silently ignored. If the mtrace2 Request is not addressed
	to this router, or if the Request is addressed to a multicast group		to this router, or if the Request is addressed to a multicast group
	which is not a link-scoped group (i.e. 224/24 for IPv4, FFx2::/16 [3]		which is not a link-scoped group (i.e. 224/24 for IPv4, FFx2::/16 [3]
	for IPv6), it MUST be silently ignored.		for IPv6), it MUST be silently ignored. The router's neighbor
			information, e.g. ARP database or PIM neighbor list, should be used
			to determine whether the host or router is adjacent or not.
	9.2.2. Normal Processing		9.2.2. Normal Processing
	When a router receives an mtrace2 Request, it performs the following		When a router receives an mtrace2 Request, it performs the following
	steps. Note that it is possible to have multiple situations covered		steps. Note that it is possible to have multiple situations covered
	by the Forwarding Codes. The first one encountered is the one that		by the Forwarding Codes. The first one encountered is the one that
	is reported, i.e. all "note forwarding code N" should be interpreted		is reported, i.e. all "note forwarding code N" should be interpreted
	as "if forwarding code is not already set, set forwarding code to N".		as "if forwarding code is not already set, set forwarding code to N".
	1. If there is room in the current buffer (or the router can		1. If there is room in the current buffer (or the router can
	skipping to change at page 22, line 40		skipping to change at page 22, line 42
	Section 9.3.		Section 9.3.
	2. Attempt to determine the forwarding information for the source		2. Attempt to determine the forwarding information for the source
	and group specified, using the same mechanisms as would be used		and group specified, using the same mechanisms as would be used
	when a packet is received from the source destined for the		when a packet is received from the source destined for the
	group. State need not be instantiated, it can be "phantom"		group. State need not be instantiated, it can be "phantom"
	state created only for the purpose of the trace, such as "dry-		state created only for the purpose of the trace, such as "dry-
	run".		run".
	If using a shared-tree protocol and there is no source-specific		If using a shared-tree protocol and there is no source-specific
	state, or if the source is specified as "all 1", group state		state, or if no source-specific information is desired (i.e.,
	should be used. If there is no group state or the group is		"all 1" for IPv4 or unspecified address (::) for IPv6), group
	specified as 0, potential source state (i.e. the path that would		state should be used. If there is no group state or no group-
	be followed for a source-specific Join) should be used. If this		specific information is desired, potential source state (i.e.
	router is the Core or RP and no source-specific information is		the path that would be followed for a source-specific Join)
	available, note an error code of REACHED_RP.		should be used. If this router is the Core or RP and no source-
			specific state is available (e.g., this router has been
			receiving PIM Register messages from the first-hop router), note
			a code of REACHED_RP.
	3. If no forwarding information can be determined, the router notes		3. If no forwarding information can be determined, the router notes
	an error code of NO_ROUTE, sets the remaining fields that have		an error code of NO_ROUTE, sets the remaining fields that have
	not yet been filled in to zero, and then forwards the packet to		not yet been filled in to zero, and then forwards the packet to
	the requester as described in Section 9.3.		the requester as described in Section 9.3.
	4. Fill in the Incoming Interface Address, Previous-Hop Router		4. Fill in the Incoming Interface Address, Previous-Hop Router
	Address, Input Packet Count, Total Number of Packets, Routing		Address, Input Packet Count, Total Number of Packets, Routing
	Protocol, S, and Src Mask from the forwarding information that		Protocol, S, and Src Mask from the forwarding information that
	was determined.		was determined.
	skipping to change at page 23, line 41		skipping to change at page 23, line 46
	forwarding code of REACHED_RP is noted.		forwarding code of REACHED_RP is noted.
	9. If this router has sent a prune upstream which applies to the		9. If this router has sent a prune upstream which applies to the
	source and group in the mtrace2 Request, it notes forwarding		source and group in the mtrace2 Request, it notes forwarding
	code PRUNE_SENT. If the router has stopped forwarding		code PRUNE_SENT. If the router has stopped forwarding
	downstream in response to a prune sent by the next hop router,		downstream in response to a prune sent by the next hop router,
	it notes forwarding code PRUNE_RCVD. If the router should		it notes forwarding code PRUNE_RCVD. If the router should
	normally forward traffic for this source and group downstream		normally forward traffic for this source and group downstream
	but is not, it notes forwarding code NOT_FORWARDING.		but is not, it notes forwarding code NOT_FORWARDING.
	10. The packet is then sent on to the previous hop or the		10. If this router is a gateway (e.g., a NAT or firewall) that hides
			the information between this router and the mtrace2 querier, it
			notes forwarding code REACHED_GW.
			11. The packet is then sent on to the previous hop or the
	Destination Address as described in Section 9.3.		Destination Address as described in Section 9.3.
	9.3. Forwarding Mtrace2 Requests		9.3. Forwarding Mtrace2 Requests
	If the Previous-hop router is known for this request and the number		If the Previous-hop router is known for this request and the number
	of response blocks is less than the number requested (i.e., the "#		of response blocks is less than the number requested (i.e., the "#
	hops" field in mtrace2 header), the packet is sent to that router.		hops" field in mtrace2 header), the packet is sent to that router.
	If the Incoming Interface is known but the Previous-hop router is not		If the Incoming Interface is known but the Previous-hop router is not
	known, the packet is sent to an appropriate multicast address on the		known, the packet is sent to an appropriate multicast address on the
	Incoming Interface. The appropriate multicast address may depend on		Incoming Interface. The appropriate multicast address may depend on
	the routing protocol in use, MUST be a link-scoped group (i.e. 224/24		the routing protocol in use, MUST be a link-scoped group (i.e. 224/24
	for IPv4, FF02::/16 for IPv6), MUST NOT be ALL-SYSTEMS.MCAST.NET		for IPv4, FF02::/16 for IPv6), MUST NOT be ALL-SYSTEMS.MCAST.NET
	(224.0.0.1) for IPv4 and All Nodes Address (FF02::1) for IPv6, and		(224.0.0.1) for IPv4 and All Nodes Address (FF02::1) for IPv6, and
	MAY be ALL-ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers		MAY be ALL-ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers
	Address (FF02::2) for IPv6 if the routing protocol in use does not		Address (FF02::2) for IPv6 if the routing protocol in use does not
	define a more appropriate group. Otherwise, it is sent to the		define a more appropriate group. Otherwise, it is sent to the
	Destination Address in the header.		Destination Address in the header.
	When the NO_SPACE error occurs, the multicast routers sends back the		When the REACHED_GW code is noted, the router sends back the mtrace2
	mtrace2 response with contained data and the NO_SPACE error code to		response as in Section 9.4. In addition to that, it must continue
	the address specified in the Destination Address field in the mtrace2		the mtrace2 query by proxying the original querier as in Section 9.5.
	query header, and continues the mtrace2 query by sending an mtrace2
	request containing the same mtrace2 query header except the # hops		When the NO_SPACE error occurs, the router sends back the mtrace2
	field and its response block. The # hops field must be decreased		response with contained data and the NO_SPACE error code as in
	according to the number of standard response blocks in the mtrace2		Section 9.4, and continues the mtrace2 query by sending an mtrace2
	request received by the router.		request containing the same mtrace2 query header and its standard and
			augmented response blocks. The corresponding augmented response
			block type is "# Mtrace2 Response Blocks Returned" described in
			Section 8.
	9.4. Sending Mtrace2 Responses		9.4. Sending Mtrace2 Responses
	9.4.1. Destination Address		9.4.1. Destination Address
	An mtrace2 Response must be sent to the address specified in the		An mtrace2 Response must be sent to the address specified in the
	Destination Address field in the mtrace2 query header.		Destination Address field in the mtrace2 query header.
	9.4.2. Source Address		9.4.2. Source Address
	An mtrace2 Response must be sent with the address of the router's		An mtrace2 Response must be sent with the address of the router's
	reception interface.		reception interface.
	9.5. Hiding Information		9.5. Proxying Mtrace2 Queries
			When a gateway (e.g., a NAT or firewall) that needs to block unicast
			packets to the mtrace2 querier or hide information between the
			gateway and the mtrace2 querier receives mtrace2 query from an
			adjacent host or mtrace2 request from an adjacent router, it sends
			back the mtrace2 response with contained data and the REACHED_GW code
			to the address specified in the Destination Address field in the
			mtrace2 query header.
			At the same time, the gateway prepares a new mtrace2 query message.
			The gateway uses the original mtrace2 query header as the base for
			the new mtrace2 query; it sets the Destination Address to its
			Incoming Interface address and the Client Port # to its own port
			(which may be the same as the mtrace2 port as the gateway is
			listening on that port), and decreases # hops according to the number
			of standard response blocks in the returned mtrace2 response from the
			gateway. The mtrace2 query message is sent to the previous-hop
			router or to an appropriate multicast address on the Incoming
			Interface.
			When the gateway receives the mtrace2 response from the first-hop
			router or any intermediate router, it MUST forward the mtrace2
			response back to the mtrace2 querier with the original mtrace2 query
			header.
			9.6. Hiding Information
	Information about a domain's topology and connectivity may be hidden		Information about a domain's topology and connectivity may be hidden
	from multicast traceroute requests. The exact mechanism is not		from multicast traceroute requests. The INFO_HIDDEN forwarding code
	specified here; however, the INFO_HIDDEN forwarding code may be used		may be used to note that, for example, the incoming interface address
	to note that, for example, the incoming interface address and packet		and packet count are for the entrance to the domain and the outgoing
	count are for the entrance to the domain and the outgoing interface		interface address and packet count are the exit from the domain. The
	address and packet count are the exit from the domain. The source-		source-group packet count may be from either router or not specified
	group packet count may be from either router or not specified (all		(all 1).
	1).
	10. Client Behavior		10. Client Behavior
	10.1. Sending Mtrace2 Query		10.1. Sending Mtrace2 Queries
	When the destination of the mtrace2 is the machine running the		When the destination of the mtrace2 is the machine running the
	client, the mtrace2 Query packet can be sent to the ALL-		client, the mtrace2 Query packet can be sent to the ALL-
	ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers Address		ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers Address
	(FF02::2) for IPv6. This will ensure that the packet is received by		(FF02::2) for IPv6. This will ensure that the packet is received by
	the last-hop router on the subnet. Otherwise, if the proper last-hop		the last-hop router on the subnet. Otherwise, if the proper last-hop
	router is known for the mtrace2 destination, the Query could be		router is known for the mtrace2 destination, the Query could be
	unicasted to that router. Otherwise, the Query packet should be		unicasted to that router.
	multicasted to the group being queried; if the destination of the
	mtrace2 is a member of the group, this will get the Query to the
	proper last-hop router. In this final case, the packet should
	contain the Router Alert option [7][8], to make sure that routers
	that are not members of the multicast group notice the packet.
	See also Section 10.4 on determining the last-hop router.		See also Section 10.4 on determining the last-hop router.
	10.2. Determining the Path		10.2. Determining the Path
	The client could send a small number of initial query messages with a		The client could send a small number of initial query messages with a
	large "# hops" field, in order to try to trace the full path. If		large "# hops" field, in order to try to trace the full path. If
	this attempt fails, one strategy is to perform a linear search (as		this attempt fails, one strategy is to perform a linear search (as
	the traditional unicast traceroute program does); set the "# hops"		the traditional unicast traceroute program does); set the "# hops"
	field to 1 and try to get a response, then 2, and so on. If no		field to 1 and try to get a response, then 2, and so on. If no
	skipping to change at page 26, line 7		skipping to change at page 26, line 51
	10.4. Last Hop Router		10.4. Last Hop Router
	The mtrace2 querier may not know which is the last hop router, or		The mtrace2 querier may not know which is the last hop router, or
	that router may be behind a firewall that blocks unicast packets but		that router may be behind a firewall that blocks unicast packets but
	passes multicast packets. In these cases, the mtrace2 request should		passes multicast packets. In these cases, the mtrace2 request should
	be multicasted to ALL-ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All		be multicasted to ALL-ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All
	Routers Address (FF02::2) for IPv6. All routers except the correct		Routers Address (FF02::2) for IPv6. All routers except the correct
	last hop router should ignore any mtrace2 request received via		last hop router should ignore any mtrace2 request received via
	multicast. Mtrace2 requests which are multicasted to the group being		multicast. Mtrace2 requests which are multicasted to the group being
	traced must include the Router Alert option[7][8].		traced must include the Router Alert option[6][7].
	Another alternative is to unicast to the trace destination. Mtrace2		Another alternative is to unicast to the trace destination. Mtrace2
	requests which are unicasted to the trace destination must include		requests which are unicasted to the trace destination must include
	the Router Alert option, in order that the last-hop router is aware		the Router Alert option, in order that the last-hop router is aware
	of the packet.		of the packet.
	10.5. First Hop Router		10.5. First Hop Router
	The IANA assigned 224.0.1.32, MTRACE.MCAST.NET as the default		The IANA assigned 224.0.1.32, MTRACE.MCAST.NET as the default
	multicast group for IPv4 mtrace responses, in order to support mtrace		multicast group for IPv4 mtrace responses, in order to support mtrace
	queriers that are not unicast reachable from the first hop router.		queriers that are not unicast reachable from the first hop router.
	However, mtrace2 does not reserve any IPv4/IPv6 multicast addresses		However, mtrace2 does not reserve any IPv4/IPv6 multicast addresses
	for mtrace2 responses. Every mtrace2 response is sent to the unicast		for mtrace2 responses. Every mtrace2 response is sent to the unicast
	address specified in the Destination Address field of the mtrace2		address specified in the Destination Address field of the mtrace2
	query header.		query header.
	The mtrace2 querier may be behind a gateway (e.g., a NAT or firewall)
	that blocks unicast packets. When the gateway receives mtrace2 query
	from an adjacent host that is not unicast reachable, it sends back
	the mtrace2 response with contained data and the NO_SPACE error code
	to the address specified in the Destination Address field in the
	mtrace2 query header. And to continue the mtrace2 query, the gateway
	prepares the mtrace2 query containing the same mtrace2 query header,
	except the # hops field, the Destination Address, and its response
	block.
	The # hops field must be decreased according to the number of
	standard response blocks in the mtrace2 request received by the
	gateway. And the original Destination Address MUST be replaced with
	the gateway address that is unicast reachable from the first hop
	router. After that, the gateway restarts the mtrace2 query by
	sending an mtrace2 request. When the gateway receives the mtrace2
	response from the last hop router, it MUST forward the mtrace2
	response back to the original mtrace2 querier with the original
	Destination Address in the mtrace2 query header.
	10.6. Broken Intermediate Router		10.6. Broken Intermediate Router
	A broken intermediate router might simply not understand mtrace2		A broken intermediate router might simply not understand mtrace2
	packets, and drop them. The querier would then get no response at		packets, and drop them. The querier would then get no response at
	all from its mtrace2 requests. It should then perform a hop-by-hop		all from its mtrace2 requests. It should then perform a hop-by-hop
	search by setting the number of responses field until it gets a		search by setting the number of responses field until it gets a
	response (both linear and binary search are options, but binary is		response (both linear and binary search are options, but binary is
	likely to be slower because a failure requires waiting for a		likely to be slower because a failure requires waiting for a
	timeout).		timeout).
	skipping to change at page 29, line 19		skipping to change at page 29, line 19
	When a multicast traceroute reaches a PIM-SM RP and the RP does not		When a multicast traceroute reaches a PIM-SM RP and the RP does not
	forward the trace on, it means that the RP has not performed a		forward the trace on, it means that the RP has not performed a
	source-specific join so there is no more state to trace. However,		source-specific join so there is no more state to trace. However,
	the path that traffic would use if the RP did perform a source-		the path that traffic would use if the RP did perform a source-
	specific join can be traced by setting the trace destination to the		specific join can be traced by setting the trace destination to the
	RP, the trace source to the traffic source, and the trace group to 0.		RP, the trace source to the traffic source, and the trace group to 0.
	This trace Query may be unicasted to the RP.		This trace Query may be unicasted to the RP.
	11.2. Bi-Directional PIM		11.2. Bi-Directional PIM
	Bi-directional PIM [10] is a variant of PIM-SM that builds bi-		Bi-directional PIM [9] is a variant of PIM-SM that builds bi-
	directional shared trees connecting multicast sources and receivers.		directional shared trees connecting multicast sources and receivers.
	Along the bi-directional shared trees, multicast data is natively		Along the bi-directional shared trees, multicast data is natively
	forwarded from sources to the RPA (Rendezvous Point Address) and from		forwarded from sources to the RPA (Rendezvous Point Address) and from
	the RPA to receivers without requiring source-specific state. In		the RPA to receivers without requiring source-specific state. In
	contrast to PIM-SM, RP always has the state to trace.		contrast to PIM-SM, RP always has the state to trace.
	A Designated Forwarder (DF) for a given RPA is in charge of		A Designated Forwarder (DF) for a given RPA is in charge of
	forwarding downstream traffic onto its link, and forwarding upstream		forwarding downstream traffic onto its link, and forwarding upstream
	traffic from its link towards the RPL (Rendezvous Point Link) that		traffic from its link towards the RPL (Rendezvous Point Link) that
	the RPA belongs to. Hence mtrace2 reports DF addresses or RPA along		the RPA belongs to. Hence mtrace2 reports DF addresses or RPA along
	skipping to change at page 29, line 52		skipping to change at page 29, line 52
	When traffic is flowing, PIM Dense Mode routers know whether or not		When traffic is flowing, PIM Dense Mode routers know whether or not
	they are the last-hop forwarder for the link (because they won or		they are the last-hop forwarder for the link (because they won or
	lost an Assert battle) and know who the previous hop is (because it		lost an Assert battle) and know who the previous hop is (because it
	won an Assert battle). Therefore, multicast traceroute is always		won an Assert battle). Therefore, multicast traceroute is always
	able to follow the proper path when traffic is flowing.		able to follow the proper path when traffic is flowing.
	11.4. IGMP/MLD Proxy		11.4. IGMP/MLD Proxy
	When a mtrace2 Query packet reaches an incoming interface of IGMP/MLD		When a mtrace2 Query packet reaches an incoming interface of IGMP/MLD
	Proxy [11], it put a WRONG_IF (0x01) value in Forwarding Code of		Proxy [10], it put a WRONG_IF (0x01) value in Forwarding Code of
	mtrace2 standard response block (as in Section 6.13) and sends the		mtrace2 standard response block (as in Section 6.13) and sends the
	mtrace2 response back to the Response Address. When a mtrace2 Query		mtrace2 response back to the Destination Address. When a mtrace2
	packet reaches an outgoing interface of IGMP/MLD proxy, it is		Query packet reaches an outgoing interface of IGMP/MLD proxy, it is
	forwarded through its incoming interface towards the upstream router.		forwarded through its incoming interface towards the upstream router.
	11.5. AMT		11.5. AMT
	AMT [12] provides the multicast connectivity to the unicast-only		AMT [11] provides the multicast connectivity to the unicast-only
	inter-network. To do this, multicast packets being sent to or from a		inter-network. To do this, multicast packets being sent to or from a
	site are encapsulated in unicast packets. When a mtrace2 query		site are encapsulated in unicast packets. When a mtrace2 query
	packet reaches an AMT pseudo-interface of an AMT gateway, the AMT		packet reaches an AMT pseudo-interface of an AMT gateway, the AMT
	gateway encapsulats it to a particular AMT relay reachable across the		gateway encapsulats it to a particular AMT relay reachable across the
	unicast-only infrastructure. Then the AMT relay decapsulates the		unicast-only infrastructure. Then the AMT relay decapsulates the
	mtrace2 query packet and forwards the mtrace2 request to the		mtrace2 query packet and forwards the mtrace2 request to the
	appropriate multicast router.		appropriate multicast router.
	12. Problem Diagnosis		12. Problem Diagnosis
	skipping to change at page 33, line 8		skipping to change at page 33, line 8
	If the routers have synchronized clocks, it is possible to estimate		If the routers have synchronized clocks, it is possible to estimate
	propagation and queuing delay from the differences between the		propagation and queuing delay from the differences between the
	timestamps at successive hops. However, this delay includes control		timestamps at successive hops. However, this delay includes control
	processing overhead, so is not necessarily indicative of the delay		processing overhead, so is not necessarily indicative of the delay
	that data traffic would experience.		that data traffic would experience.
	13. IANA Considerations		13. IANA Considerations
	The following new assignments can only be made via a Standards Action		The following new assignments can only be made via a Standards Action
	as specified in [5].		as specified in [4].
	13.1. Forwarding Codes		13.1. Forwarding Codes
	New Forwarding codes must only be created by an RFC that modifies		New Forwarding codes must only be created by an RFC that modifies
	this document's Section 10, fully describing the conditions under		this document's Section 10, fully describing the conditions under
	which the new forwarding code is used. The IANA may act as a central		which the new forwarding code is used. The IANA may act as a central
	repository so that there is a single place to look up forwarding		repository so that there is a single place to look up forwarding
	codes and the document in which they are defined.		codes and the document in which they are defined.
	13.2. UDP Destination Port and IPv6 Address		13.2. UDP Destination Port and IPv6 Address
	skipping to change at page 35, line 5		skipping to change at page 34, line 20
	network topology is a secret, mtrace2 may be restricted at the border		network topology is a secret, mtrace2 may be restricted at the border
	of your domain, using the ADMIN_PROHIB forwarding code.		of your domain, using the ADMIN_PROHIB forwarding code.
	14.2. Traffic Rates		14.2. Traffic Rates
	Mtrace2 can be used to discover what sources are sending to what		Mtrace2 can be used to discover what sources are sending to what
	groups and at what rates. If this information is a secret, mtrace2		groups and at what rates. If this information is a secret, mtrace2
	may be restricted at the border of your domain, using the		may be restricted at the border of your domain, using the
	ADMIN_PROHIB forwarding code.		ADMIN_PROHIB forwarding code.
			14.3. Limiting Query/Request Rates
			Routers should limit mtrace2 queries and requests by ignoring the
			received messages. Routers MAY randomly ignore the received messages
			to minimize the processing overhead, i.e., to keep fairness in
			processing queries.
	15. Acknowledgements		15. Acknowledgements
	This specification started largely as a transcription of Van		This specification started largely as a transcription of Van
	Jacobson's slides from the 30th IETF, and the implementation in		Jacobson's slides from the 30th IETF, and the implementation in
	mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit Steve		mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit Steve
	Casner, Steve Deering, Dino Farinacci and Deb Agrawal. The original		Casner, Steve Deering, Dino Farinacci and Deb Agrawal. The original
	multicast traceroute client, mtrace (version 1), has been implemented		multicast traceroute client, mtrace (version 1), has been implemented
	by Ajit Thyagarajan, Steve Casner and Bill Fenner.		by Ajit Thyagarajan, Steve Casner and Bill Fenner.
	The idea of unicasting a multicast traceroute Query to the		The idea of unicasting a multicast traceroute Query to the
	skipping to change at page 36, line 18		skipping to change at page 36, line 18
	[1] Bradner, S., "Key words for use in RFCs to indicate requirement		[1] Bradner, S., "Key words for use in RFCs to indicate requirement
	levels", RFC 2119, March 1997.		levels", RFC 2119, March 1997.
	[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)		[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
	Specification", RFC 2460, December 1998.		Specification", RFC 2460, December 1998.
	[3] Hinden, R. and S. Deering, "IP Version 6 Addressing		[3] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 2373, July 1998.		Architecture", RFC 2373, July 1998.
	[4] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.		[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
	Thyagarajan, "Internet Group Management Protocol, Version 3",
	RFC 3376, October 2002.
	[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
	Considerations Section in RFCs", RFC 2434, October 1998.		Considerations Section in RFCs", RFC 2434, October 1998.
	[6] Braden, B., Borman, D., and C. Partridge, "Computing the		[5] Braden, B., Borman, D., and C. Partridge, "Computing the
	Internet Checksum", RFC 1071, September 1988.		Internet Checksum", RFC 1071, September 1988.
	[7] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.		[6] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
	[8] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",		[7] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
	RFC 2711, October 1999.		RFC 2711, October 1999.
	[9] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,		[8] 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.
	[10] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,		[9] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
	"Bidirectional Protocol Independent Multicast (BIDIR-PIM)",		"Bidirectional Protocol Independent Multicast (BIDIR-PIM)",
	RFC 5015, October 2007.		RFC 5015, October 2007.
	[11] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet		[10] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet
	Group Management Protocol (IGMP) / Multicast Listener Discovery		Group Management Protocol (IGMP) / Multicast Listener Discovery
	(MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")",		(MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")",
	RFC 4605, August 2006.		RFC 4605, August 2006.
	[12] Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T.		[11] Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T.
	Pusateri, "Automatic IP Multicast Without Explicit Tunnels		Pusateri, "Automatic IP Multicast Without Explicit Tunnels
	(AMT)", draft-ietf-mboned-auto-multicast-08.txt (work in		(AMT)", draft-ietf-mboned-auto-multicast-08.txt (work in
	progress), October 2007.		progress), October 2007.
	16.2. Informative References		16.2. Informative References
			[12] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
			Thyagarajan, "Internet Group Management Protocol, Version 3",
			RFC 3376, October 2002.
	[13] Draves, R. and D. Thaler, "Default Router Preferences and More-		[13] Draves, R. and D. Thaler, "Default Router Preferences and More-
	Specific Routes", RFC 4191, November 2005.		Specific Routes", RFC 4191, November 2005.
	[14] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",		[14] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
	RFC 2863, June 2000.		RFC 2863, June 2000.
	[15] McWalter, D., Thaler, D., and A. Kessler, "IP Multicast MIB",		[15] McWalter, D., Thaler, D., and A. Kessler, "IP Multicast MIB",
	RFC 5132, December 2007.		RFC 5132, December 2007.
	Authors' Addresses		Authors' Addresses
End of changes. 42 change blocks.
	100 lines changed or deleted		142 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/