draft-ietf-mboned-mzap-05.txt		rfc2776.txt
	MBoneD Working Group Mark Handley
	Internet Engineering Task Force ACIRI
	INTERNET-DRAFT Dave Thaler
	22 October 1999 Microsoft
	Expires April 2000 Roger Kermode
	Motorola
	Multicast-Scope Zone Announcement Protocol (MZAP)
	<draft-ietf-mboned-mzap-05.txt>
	Status of this Memo		Network Working Group M. Handley
			Request for Comments: 2776 ACIRI
			Category: Standards Track D. Thaler
			Microsoft
			R. Kermode
			Motorola
			February 2000
	This document is an Internet-Draft and is in full conformance with all		Multicast-Scope Zone Announcement Protocol (MZAP)
	provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering Task		Status of this Memo
	Force (IETF), its areas, and its working groups. Note that other groups
	may also distribute working documents as Internet-Drafts.
	Internet Drafts are valid for a maximum of six months and may be		This document specifies an Internet standards track protocol for the
	updated, replaced, or obsoleted by other documents at any time. It is		Internet community, and requests discussion and suggestions for
	inappropriate to use Internet Drafts as reference material or to cite		improvements. Please refer to the current edition of the "Internet
	them other than as a "work in progress".		Official Protocol Standards" (STD 1) for the standardization state
			and status of this protocol. Distribution of this memo is unlimited.
	The list of current Internet-Drafts can be accessed at		Copyright Notice
	http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		Copyright (C) The Internet Society (2000). All Rights Reserved.
	http://www.ietf.org/shadow.html.
	Abstract		Abstract
	This document defines a protocol, the Multicast-Scope Zone Announcement		This document defines a protocol, the Multicast-Scope Zone
	Protocol (MZAP), for discovering the multicast administrative scope		Announcement Protocol (MZAP), for discovering the multicast
	zones that are relevant at a particular location. MZAP also provides		administrative scope zones that are relevant at a particular
	mechanisms whereby common misconfigurations of administrative scope		location. MZAP also provides mechanisms whereby common
	zones can be discovered.		misconfigurations of administrative scope zones can be discovered.
	Copyright Notice
	Copyright (C) The Internet Society (1999). All Rights Reserved.		Table of Contents
	Draft MZAP October 1999		1 Introduction ................................................ 2
			2 Terminology ................................................. 4
			3 Overview .................................................... 5
			3.1 Scope Nesting ............................................. 6
			3.2 Other Messages ............................................ 7
			3.3 Zone IDs .................................................. 7
			4 Detecting Router Misconfigurations .......................... 8
			4.1 Detecting non-convex scope zones .......................... 8
			4.2 Detecting leaky boundaries for non-local scopes ........... 9
			4.3 Detecting a leaky Local Scope zone ........................ 10
			4.4 Detecting conflicting scope zones ......................... 10
			5 Packet Formats .............................................. 11
			5.1 Zone Announcement Message ................................. 14
			5.2 Zone Limit Exceeded (ZLE) ................................. 15
			5.3 Zone Convexity Message .................................... 15
			5.4 Not-Inside Message ........................................ 16
			6 Message Processing Rules .................................... 17
			6.1 Internal entities listening to MZAP messages .............. 17
			6.2 Sending ZAMs .............................................. 18
			6.3 Receiving ZAMs ............................................ 18
			6.4 Sending ZLEs .............................................. 20
			6.5 Receiving ZLEs ............................................ 20
			6.6 Sending ZCMs .............................................. 21
			6.7 Receiving ZCMs ............................................ 21
			6.8 Sending NIMs .............................................. 21
			6.9 Receiving NIMs ............................................ 22
			7 Constants ................................................... 22
			8 Security Considerations ..................................... 23
			9 Acknowledgements ............................................ 24
			10 References ................................................. 25
			11 Authors' Addresses ......................................... 26
			12 Full Copyright Statement ................................... 27
	1. Introduction		1. Introduction
	The use of administratively-scoped IP multicast, as defined in RFC 2365		The use of administratively-scoped IP multicast, as defined in RFC
	[1], allows packets to be addressed to a specific range of multicast		2365 [1], allows packets to be addressed to a specific range of
	addresses (e.g., 239.0.0.0 to 239.255.255.255 for IPv4) such that the		multicast addresses (e.g., 239.0.0.0 to 239.255.255.255 for IPv4)
	packets will not cross configured administrative boundaries, and also		such that the packets will not cross configured administrative
	allows such addresses to be locally assigned and hence are not required		boundaries, and also allows such addresses to be locally assigned and
	to be unique across administrative boundaries. This property of logical		hence are not required to be unique across administrative boundaries.
	naming both allows for address reuse, as well as provides the capability		This property of logical naming both allows for address reuse, as
	for infrastructure services such as address allocation, session		well as provides the capability for infrastructure services such as
	advertisement, and service location to use well-known addresses which		address allocation, session advertisement, and service location to
	are guaranteed to have local significance within every organization.		use well-known addresses which are guaranteed to have local
			significance within every organization.
	The range of administratively-scoped addresses can be subdivided by
	administrators so that multiple levels of administrative boundaries can
	be simultaneously supported. As a result, a "multicast scope" is
	defined as a particular range of addresses which has been given some
	topological meaning.
	To support such usage, a router at an administrative boundary is
	configured with one or more per-interface filters, or "multicast scope
	boundaries". Having such a boundary on an interface means that it will
	not forward packets matching a configured range of multicast addresses
	in either direction on the interface.
	A specific area of the network topology which is within a boundary for a
	given scope is known as a "multicast scope zone". Since the same ranges
	can be reused within disjoint areas of the network, there may be many
	"multicast scope zones" for any given multicast scope. A scope zone may
	have zero or more textual names (in different languages) for the scope,
	for human convenience. For example, if the range 239.192/14 were
	assigned to span an entire corporate network, it might be given
	(internally) the name "BigCo Private Scope".
	Administrative scope zones may be of any size, and a particular host may		The range of administratively-scoped addresses can be subdivided by
	be within many administrative scope zones (for different scopes, i.e.,		administrators so that multiple levels of administrative boundaries
	for non-overlapping ranges of addresses) of various sizes, as long as		can be simultaneously supported. As a result, a "multicast scope" is
	scope zones that intersect topologically do not intersect in address		defined as a particular range of addresses which has been given some
	range.		topological meaning.
	Applications and services are interested in various aspects of the		To support such usage, a router at an administrative boundary is
	scopes within which they reside:		configured with one or more per-interface filters, or "multicast
			scope boundaries". Having such a boundary on an interface means that
			it will not forward packets matching a configured range of multicast
			addresses in either direction on the interface.
	o Applications which present users with a choice of which scope in		A specific area of the network topology which is within a boundary
	which to operate (e.g., when creating a new session, whether it is		for a given scope is known as a "multicast scope zone". Since the
			same ranges can be reused within disjoint areas of the network, there
			may be many "multicast scope zones" for any given multicast scope. A
			scope zone may have zero or more textual names (in different
			languages) for the scope, for human convenience. For example, if the
			range 239.192/14 were assigned to span an entire corporate network,
			it might be given (internally) the name "BigCo Private Scope".
	Draft MZAP October 1999		Administrative scope zones may be of any size, and a particular host
			may be within many administrative scope zones (for different scopes,
			i.e., for non-overlapping ranges of addresses) of various sizes, as
			long as scope zones that intersect topologically do not intersect in
			address range.
	to be confined to a corporate intranet, or whether it should go out		Applications and services are interested in various aspects of the
	over the public Internet) are interested in the textual names which		scopes within which they reside:
	have significance to users.
	o Services which use "relative" multicast addresses (as defined in		o Applications which present users with a choice of which scope in
	[1]) in every scope are interested in the range of addresses used		which to operate (e.g., when creating a new session, whether it is
	by each scope, so that they can apply a constant offset and compute		to be confined to a corporate intranet, or whether it should go
	which address to use in each scope.		out over the public Internet) are interested in the textual names
			which have significance to users.
	o Address allocators are interested in the address range, and whether		o Services which use "relative" multicast addresses (as defined in
	they are allowed to allocate addresses within the entire range or		[1]) in every scope are interested in the range of addresses used
	not.		by each scope, so that they can apply a constant offset and
			compute which address to use in each scope.
	o Some applications and services may also be interested in the		o Address allocators are interested in the address range, and
	nesting relationships among scopes. For example, knowledge of the		whether they are allowed to allocate addresses within the entire
	nesting relationships can be used to perform "expanding-scope"		range or not.
	searches in a similar, but better behaved, manner to the well-known
	expanding ring search where the TTL of a query is steadily
	increased until a replier can be found. Studies have also shown
	that nested scopes can be useful in localizing multicast repair
	traffic [8].
	Two barriers currently make administrative scoping difficult to deploy		o Some applications and services may also be interested in the
	and use:		nesting relationships among scopes. For example, knowledge of the
			nesting relationships can be used to perform "expanding-scope"
			searches in a similar, but better behaved, manner to the well-
			known expanding ring search where the TTL of a query is steadily
			increased until a replier can be found. Studies have also shown
			that nested scopes can be useful in localizing multicast repair
			traffic [8].
	o Applications have no way to dynamically discover information on		Two barriers currently make administrative scoping difficult to
	scopes that are relevant to them. This makes it difficult to use		deploy and use:
	administrative scope zones, and hence reduces the incentive to deploy
	them.
	o Misconfiguration is easy. It is difficult to detect scope zones that		o Applications have no way to dynamically discover information on
	have been configured so as to not be convex (the shortest path		scopes that are relevant to them. This makes it difficult to use
	between two nodes within the zone passes outside the zone), or to		administrative scope zones, and hence reduces the incentive to
	leak (one or more boundary routers were not configured correctly), or		deploy them.
	to intersect in both area and address range.
	These two barriers are addressed by this document. In particular, this		o Misconfiguration is easy. It is difficult to detect scope zones
	document defines the Multicast Scope Zone Announcement Protocol (MZAP)		that have been configured so as to not be convex (the shortest
	which allows an entity to learn what scope zones it is within.		path between two nodes within the zone passes outside the zone),
	Typically servers will cache the information learned from MZAP and can		or to leak (one or more boundary routers were not configured
	then provide this information to applications in a timely fashion upon		correctly), or to intersect in both area and address range.
	request using other means, e.g., via MADCAP [9]. MZAP also provides
	diagnostic information to the boundary routers themselves that enables
	misconfigured scope zones to be detected.
	Draft MZAP October 1999		These two barriers are addressed by this document. In particular,
			this document defines the Multicast Scope Zone Announcement Protocol
			(MZAP) which allows an entity to learn what scope zones it is within.
			Typically servers will cache the information learned from MZAP and
			can then provide this information to applications in a timely fashion
			upon request using other means, e.g., via MADCAP [9]. MZAP also
			provides diagnostic information to the boundary routers themselves
			that enables misconfigured scope zones to be detected.
	2. Terminology		2. Terminology
	The "Local Scope" is defined in RFC 2365 [1] and represents the smallest		The "Local Scope" is defined in RFC 2365 [1] and represents the
	administrative scope larger than link-local, and the associated address		smallest administrative scope larger than link-local, and the
	range is defined as 239.255.0.0 to 239.255.255.255 inclusive (for IPv4,		associated address range is defined as 239.255.0.0 to 239.255.255.255
	FF03::/16 for IPv6). RFC 2365 specifies:		inclusive (for IPv4, FF03::/16 for IPv6). RFC 2365 specifies:
	"239.255.0.0/16 is defined to be the IPv4 Local Scope. The Local
	Scope is the minimal enclosing scope, and hence is not further
	divisible. Although the exact extent of a Local Scope is site
	dependent, locally scoped regions must obey certain topological
	constraints. In particular, a Local Scope must not span any other
	scope boundary. Further, a Local Scope must be completely contained
	within or equal to any larger scope. In the event that scope regions
	overlap in area, the area of overlap must be in its own Local Scope.
	This implies that any scope boundary is also a boundary for the Local
	Scope."
	A multicast scope Zone Boundary Router (ZBR) is a router that is
	configured with a boundary for a particular multicast scope on one or
	more of its interfaces. Any interface that is configured with a
	boundary for any administrative scope zone MUST also have a boundary for
	the Local Scope zone, as described above.
	Such routers SHOULD be configured so that the router itself is within		"239.255.0.0/16 is defined to be the IPv4 Local Scope. The Local
	the scope zone. This is shown in Figure 1(a), where router A is inside		Scope is the minimal enclosing scope, and hence is not further
	the scope zone and has the boundary configuration.		divisible. Although the exact extent of a Local Scope is site
			dependent, locally scoped regions must obey certain topological
			constraints. In particular, a Local Scope must not span any other
			scope boundary. Further, a Local Scope must be completely
			contained within or equal to any larger scope. In the event that
			scope regions overlap in area, the area of overlap must be in its
			own Local Scope. This implies that any scope boundary is also a
			boundary for the Local Scope."
	............ ................		A multicast scope Zone Boundary Router (ZBR) is a router that is
	. . +B+--> . *B+-->		configured with a boundary for a particular multicast scope on one or
	. . / . / .		more of its interfaces. Any interface that is configured with a
	. * . + .		boundary for any administrative scope zone MUST also have a boundary
	. <---+A*---+C+-> . <---+A+---*C+->		for the Local Scope zone, as described above.
	. + . . + .
	. / . . / .
	. zone X <-- . . zone X <-- .
	.............. ..................
	A,B,C - routers * - boundary interface + - interface		Such routers SHOULD be configured so that the router itself is within
			the scope zone. This is shown in Figure 1(a), where router A is
			inside the scope zone and has the boundary configuration.
	(a) Correct zone boundary (b) Incorrect zone boundary		............ ................
			. . +B+--> . *B+-->
			. . / . / .
			. * . + .
			. <---+A*---+C+-> . <---+A+---*C+->
			. + . . + .
			. / . . / .
			. zone X <-- . . zone X <-- .
			.............. ..................
	Figure 1: Administrative scope zone boundary placement		A,B,C - routers * - boundary interface + - interface
	It is possible for the first router outside the scope zone to be		(a) Correct zone boundary (b) Incorrect zone boundary
	configured with the boundary, as illustrated in Figure 1(b) where
	Draft MZAP October 1999		Figure 1: Administrative scope zone boundary placement
	routers B and C are outside the zone and have the boundary		It is possible for the first router outside the scope zone to be
	configuration, whereas A does not, but this is NOT RECOMMENDED. This		configured with the boundary, as illustrated in Figure 1(b) where
	rule does not apply for Local Scope boundaries, but applies for all		routers B and C are outside the zone and have the boundary
	other boundary routers.		configuration, whereas A does not, but this is NOT RECOMMENDED. This
			rule does not apply for Local Scope boundaries, but applies for all
			other boundary routers.
	We next define the term "Zone ID" to mean the lowest IP address used by		We next define the term "Zone ID" to mean the lowest IP address used
	any ZBR for a particular zone for sourcing MZAP messages into that scope		by any ZBR for a particular zone for sourcing MZAP messages into that
	zone. The combination of this IP address and the first multicast		scope zone. The combination of this IP address and the first
	address in the scope range serve to uniquely identify the scope zone.		multicast address in the scope range serve to uniquely identify the
	Each ZBR listens for messages from other ZBRs for the same boundary, and		scope zone. Each ZBR listens for messages from other ZBRs for the
	can determine the Zone ID based on the source addresses seen. The Zone		same boundary, and can determine the Zone ID based on the source
	ID may change over time as ZBRs come up and down.		addresses seen. The Zone ID may change over time as ZBRs come up and
			down.
	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 RFC 2119 [2].		document are to be interpreted as described in RFC 2119 [2].
	Constants used by this protocol are shown as [NAME-OF-CONSTANT], and		Constants used by this protocol are shown as [NAME-OF-CONSTANT], and
	summarized in section 7.		summarized in section 7.
	3. Overview		3. Overview
	When a ZBR is configured correctly, it can deduce which side of the		When a ZBR is configured correctly, it can deduce which side of the
	boundary is inside the scope zone and which side is outside it.		boundary is inside the scope zone and which side is outside it.
	Such a ZBR then sends periodic Zone Announcement Messages (ZAMs) for
	each zone for which it is configured as a boundary into that scope zone,
	containing information on the scope zone's address range, Zone ID, and
	textual names. These messages are multicast to the well-known address
	[MZAP-LOCAL-GROUP] in the Local Scope, and are relayed across Local
	Scope boundaries into all Local Scope zones within the scope zone
	referred to by the ZAM message, as shown in Figure 2.
	Draft MZAP October 1999		Such a ZBR then sends periodic Zone Announcement Messages (ZAMs) for
			each zone for which it is configured as a boundary into that scope
			zone, containing information on the scope zone's address range, Zone
			ID, and textual names. These messages are multicast to the well-
			known address [MZAP-LOCAL-GROUP] in the Local Scope, and are relayed
			across Local Scope boundaries into all Local Scope zones within the
			scope zone referred to by the ZAM message, as shown in Figure 2.
	###########################		###########################
	# Zone1 = Zone2 # ##### = large scope zone boundary		# Zone1 = Zone2 # ##### = large scope zone boundary
	*E-----+--->A*-----+-x #		*E-----+--->A*-----+-x #
	# | = v # ===== = Local Scope boundaries		# | = v # ===== = Local Scope boundaries
	# | ======*===*==#		# | ======*===*==#
	# | = B F # ----> = path of ZAM originated by E		# | = B F # ----> = path of ZAM originated by E
	G*<-----+--->C*-> | ^ #		G*<-----+--->C*-> | ^ #
	# v = <-+---+ # ABCDE = ZBRs		# v = <-+---+ # ABCDE = ZBRs
	# D = Zone3 #		# D = Zone3 #
	#######*################### * = boundary interface		#######*################### * = boundary interface
	Figure 2: ZAM Flooding Example		Figure 2: ZAM Flooding Example
	Any entity can thus listen on a single well-known group address and		Any entity can thus listen on a single well-known group address and
	learn about all scopes in which it resides.		learn about all scopes in which it resides.
	3.1. Scope Nesting		3.1. Scope Nesting
	MZAP also provides the ability to discover the nesting relationships		MZAP also provides the ability to discover the nesting relationships
	between scope zones. Two zones are nested if one is comprised of a		between scope zones. Two zones are nested if one is comprised of a
	subset of the routers in the other, as shown in Figure 3.		subset of the routers in the other, as shown in Figure 3.
	+-----------+ +-----------+ +-------------+
	| Zone 1 | | Zone 3 | | Zone 5 |
	| +------+| | +------+ | .........|..
	| |Zone 2|| | |Zone 4| | : Zone 6 | :
	| +--A---+| | C | | D | :
	+-----------+ +----+--B---+ +--------E----+ :
	:..........:
	(a) "Contained" (b) "Common Border" (c) "Overlap"
	Zone 2 nests Zone 4 nests Zones 5 and 6
	inside Zone 1 inside Zone 3 do not nest
	Figure 3: Zone nesting examples		+-----------+ +-----------+ +-------------+
			| Zone 1 | | Zone 3 | | Zone 5 |
			| +------+| | +------+ | .........|..
			| |Zone 2|| | |Zone 4| | : Zone 6 | :
			| +--A---+| | C | | D | :
			+-----------+ +----+--B---+ +--------E----+ :
			:..........:
	A ZBR cannot independently determine whether one zone is nested inside		(a) "Contained" (b) "Common Border" (c) "Overlap"
	another. However, it can determine that one zone does NOT nest inside		Zone 2 nests Zone 4 nests Zones 5 and 6
	another. For example, in Figure 3:		inside Zone 1 inside Zone 3 do not nest
	o ZBR A will pass ZAMs for zone 1 but will prevent ZAMs from zone 2		Figure 3: Zone nesting examples
	from leaving zone 2. When ZBR A first receives a ZAM for zone 1, it
	Draft MZAP October 1999		A ZBR cannot independently determine whether one zone is nested
			inside another. However, it can determine that one zone does NOT
			nest inside another. For example, in Figure 3:
	then knows that zone 1 does not nest within zone 2, but it cannot,		o ZBR A will pass ZAMs for zone 1 but will prevent ZAMs from zone 2
	however, determine whether zone 2 nests within zone 1.		from leaving zone 2. When ZBR A first receives a ZAM for zone 1,
			it then knows that zone 1 does not nest within zone 2, but it
			cannot, however, determine whether zone 2 nests within zone 1.
	o ZBR B acts as ZBR for both zones 3 and 4, and hence cannot determine		o ZBR B acts as ZBR for both zones 3 and 4, and hence cannot
	if one is nested inside the other. However, ZBR C can determine that		determine if one is nested inside the other. However, ZBR C can
	zone 3 does not nest inside zone 4 when it receives a ZAM for zone 3,		determine that zone 3 does not nest inside zone 4 when it receives
	since it is a ZBR for zone 4 but not zone 3.		a ZAM for zone 3, since it is a ZBR for zone 4 but not zone 3.
	o ZBR D only acts as ZBR zone 6 and not 5, hence ZBR D can deduce that		o ZBR D only acts as ZBR zone 6 and not 5, hence ZBR D can deduce
	zone 5 does not nest inside zone 6 upon hearing a ZAM for zone 5.		that zone 5 does not nest inside zone 6 upon hearing a ZAM for
	Similarly, ZBR E only acts as ZBR zone 5 and not 6, hence ZBR E can		zone 5. Similarly, ZBR E only acts as ZBR zone 5 and not 6, hence
	deduce that zone 6 does not nest inside zone 5 upon hearing a ZAM for		ZBR E can deduce that zone 6 does not nest inside zone 5 upon
	zone 6.		hearing a ZAM for zone 6.
	The fact that ZBRs can determine that one zone does not nest inside		The fact that ZBRs can determine that one zone does not nest inside
	another, but not that a zone does nest inside another, means that		another, but not that a zone does nest inside another, means that
	nesting must be determined in a distributed fashion. This is done by		nesting must be determined in a distributed fashion. This is done by
	sending Not-Inside Messages (NIMs) which express the fact that a zone X		sending Not-Inside Messages (NIMs) which express the fact that a zone
	is not inside a zone Y. Such messages are sent to the well-known [MZAP-		X is not inside a zone Y. Such messages are sent to the well-known
	LOCAL-GROUP] and are thus seen by the same entities listening to ZAM		[MZAP-LOCAL-GROUP] and are thus seen by the same entities listening
	messages (e.g., MADCAP servers). Such entities can then determine the		to ZAM messages (e.g., MADCAP servers). Such entities can then
	nesting relationship between two scopes based on a sustained absence of		determine the nesting relationship between two scopes based on a
	any evidence to the contrary.		sustained absence of any evidence to the contrary.
	3.2. Other Messages		3.2. Other Messages
	Two other message types, Zone Convexity Messages (ZCMs) and Zone Limit		Two other message types, Zone Convexity Messages (ZCMs) and Zone
	Exceeded (ZLE) messages, are used only by routers, and enable them to		Limit Exceeded (ZLE) messages, are used only by routers, and enable
	compare their configurations for consistency and detect		them to compare their configurations for consistency and detect
	misconfigurations. These messages are sent to MZAP's relative address		misconfigurations. These messages are sent to MZAP's relative
	within the scope range associated with the scope zone to which they		address within the scope range associated with the scope zone to
	refer, and hence are typically not seen by entities other than routers.		which they refer, and hence are typically not seen by entities other
	Their use in detecting specific misconfiguration scenarios will be		than routers. Their use in detecting specific misconfiguration
	covered in the next section.		scenarios will be covered in the next section.
	Packet formats for all messages are described in Section 5.		Packet formats for all messages are described in Section 5.
	3.3. Zone IDs		3.3. Zone IDs
	When a boundary router first starts up, it uses its lowest IP address		When a boundary router first starts up, it uses its lowest IP address
	which it considers to be inside a given zone, and which is routable		which it considers to be inside a given zone, and which is routable
	everywhere within the zone (for example, not a link-local address), as		everywhere within the zone (for example, not a link-local address),
	the Zone ID for that zone. It then schedules ZCM (and ZAM) messages to		as the Zone ID for that zone. It then schedules ZCM (and ZAM)
			messages to be sent in the future (it does not send them
	Draft MZAP October 1999		immediately). When a ZCM is received for the given scope, the sender
			is added to the local list of ZBRs (including itself) for that scope,
	be sent in the future (it does not send them immediately). When a ZCM		and the Zone ID is updated to be the lowest IP address in the list.
	is received for the given scope, the sender is added to the local list		Entries in the list are eventually timed out if no further messages
	of ZBRs (including itself) for that scope, and the Zone ID is updated to		are received from that ZBR, such that the Zone ID will converge to
	be the lowest IP address in the list. Entries in the list are		the lowest address of any active ZBR for the scope.
	eventually timed out if no further messages are received from that ZBR,
	such that the Zone ID will converge to the lowest address of any active
	ZBR for the scope.
	Note that the sender of ZAM messages MUST NOT be used in this way. This		Note that the sender of ZAM messages MUST NOT be used in this way.
	is because the procedure for detecting a leaky Local scope described in		This is because the procedure for detecting a leaky Local scope
	Section 4.3 below relies on two disjoint zones for the same scope range		described in Section 4.3 below relies on two disjoint zones for the
	having different Zone IDs. If ZAMs are used to compute Zone IDs, then		same scope range having different Zone IDs. If ZAMs are used to
	ZAMs leaking across a Local Scope boundary will cause the two zones to		compute Zone IDs, then ZAMs leaking across a Local Scope boundary
	converge to the same Zone ID.		will cause the two zones to converge to the same Zone ID.
	4. Detecting Router Misconfigurations		4. Detecting Router Misconfigurations
	In this section, we cover how to detect various error conditions. If		In this section, we cover how to detect various error conditions. If
	any error is detected, the router should attempt to alert a network		any error is detected, the router should attempt to alert a network
	administrator to the nature of the misconfiguration. The means to do		administrator to the nature of the misconfiguration. The means to do
	this lies outside the scope of MZAP.		this lies outside the scope of MZAP.
	4.1. Detecting non-convex scope zones		4.1. Detecting non-convex scope zones
	Zone Convexity Messages (ZCMs) are used by routers to detect non-convex		Zone Convexity Messages (ZCMs) are used by routers to detect non-
	administrative scope zones, which are one possible misconfiguration.		convex administrative scope zones, which are one possible
	Non-convex scope zones can cause problems for applications since a		misconfiguration. Non-convex scope zones can cause problems for
	receiver may never see administratively-scoped packets from a sender		applications since a receiver may never see administratively-scoped
	within the same scope zone, since packets travelling between them may be		packets from a sender within the same scope zone, since packets
	dropped at the boundary.		travelling between them may be dropped at the boundary.
	In the example illustrated in Figure 4, the path between B and D goes
	outside the scope (through A and E). Here, Router B and Router C send
	ZCMs within a given scope zone for which they each have a boundary, with
	each reporting the other boundary routers of the zone from which they
	have heard. In Figure 4, Router D cannot see Router B's messages, but
	can see C's report of B, and so can conclude the zone is not convex.
	Draft MZAP October 1999		In the example illustrated in Figure 4, the path between B and D goes
			outside the scope (through A and E). Here, Router B and Router C
			send ZCMs within a given scope zone for which they each have a
			boundary, with each reporting the other boundary routers of the zone
			from which they have heard. In Figure 4, Router D cannot see Router
			B's messages, but can see C's report of B, and so can conclude the
			zone is not convex.
	#####*####========		#####*####========
	# B # = ##### = non-convex scope boundary		# B # = ##### = non-convex scope boundary
	# |->A* =		# |->A* =
	# | # = ===== = other scope boundaries		# | # = ===== = other scope boundaries
	# | ####*####		# | ####*####
	# | E # ----> = path of B's ZCM		# | E # ----> = path of B's ZCM
	# v D*		# v D*
	# C # * = boundary interface		# C # * = boundary interface
	#####*############		#####*############
	Figure 4: Non-convexity detection		Figure 4: Non-convexity detection
	Non-convex scope zones can be detected via three methods:		Non-convex scope zones can be detected via three methods:
	(1) If a ZBR is listed in ZCMs received, but the next-hop interface		(1) If a ZBR is listed in ZCMs received, but the next-hop interface
	(according to the multicast RIB) towards that ZBR is outside the		(according to the multicast RIB) towards that ZBR is outside the
	scope zone,		scope zone,
	(2) If a ZBR is listed in ZCMs received, but no ZCM is received from		(2) If a ZBR is listed in ZCMs received, but no ZCM is received from
	that ZBR for [ZCM-HOLDTIME] seconds, as illustrated in Figure 4,		that ZBR for [ZCM-HOLDTIME] seconds, as illustrated in Figure 4,
	or		or
	(3) ZAM messages can also be used in a manner similar to that for		(3) ZAM messages can also be used in a manner similar to that for
	ZCMs in (1) above, as follows: if a ZAM is received from a ZBR on		ZCMs in (1) above, as follows: if a ZAM is received from a ZBR on
	an interface inside a given scope zone, and the next-hop		an interface inside a given scope zone, and the next-hop
	interface (according to the multicast RIB) towards that ZBR is		interface (according to the multicast RIB) towards that ZBR is
	outside the scope zone.		outside the scope zone.
	Zone Convexity Messages MAY also be sent and received by correctly		Zone Convexity Messages MAY also be sent and received by correctly
	configured ordinary hosts within a scope region, which may be a useful		configured ordinary hosts within a scope region, which may be a
	diagnostic facility that does not require privileged access.		useful diagnostic facility that does not require privileged access.
	4.2. Detecting leaky boundaries for non-local scopes		4.2. Detecting leaky boundaries for non-local scopes
	A "leaky" boundary is one which logically has a "hole" due to some		A "leaky" boundary is one which logically has a "hole" due to some
	router not having a boundary applied on an interface where one ought to		router not having a boundary applied on an interface where one ought
	exist. Hence, the boundary does not completely surround a piece of the		to exist. Hence, the boundary does not completely surround a piece
	network, resulting in scoped data leaking outside.		of the network, resulting in scoped data leaking outside.
	Leaky scope boundaries can be detected via two methods:		Leaky scope boundaries can be detected via two methods:
	(1) If it receives ZAMs originating inside the scope boundary on an		(1) If it receives ZAMs originating inside the scope boundary on an
	interface that points outside the zone boundary. Such a ZAM		interface that points outside the zone boundary. Such a ZAM
	message must have escaped the zone through a leak, and flooded		message must have escaped the zone through a leak, and flooded
	Draft MZAP October 1999
	back around behind the boundary. This is illustrated in Figure		back around behind the boundary. This is illustrated in Figure
	5.		5.
	=============#####*########
	= Zone1 # A Zone2 # C = misconfigured router
	= +---->*E v #
	= | # B # ##### = leaky scope boundary
	=======*=====#====*=======#
	= D # | # ===== = other scope boundaries
	= ^-----*C<--+ #
	= Zone4 # Zone3 # ----> = path of ZAMs
	=============##############
	Figure 5: ZAM Leaking		=============#####*########
			= Zone1 # A Zone2 # C = misconfigured router
			= +---->*E v #
			= | # B # ##### = leaky scope boundary
			=======*=====#====*=======#
			= D # | # ===== = other scope boundaries
			= ^-----*C<--+ #
			= Zone4 # Zone3 # ----> = path of ZAMs
			=============##############
	(2) If a Zone Length Exceeded (ZLE) message is received. The ZAM		Figure 5: ZAM Leaking
			(2) If a Zone Length Exceeded (ZLE) message is received. The ZAM
	packet also contains a Zones Traveled Limit. If the number of		packet also contains a Zones Traveled Limit. If the number of
	Local Scope zones traversed becomes equal to the Zones Traveled		Local Scope zones traversed becomes equal to the Zones Traveled
	Limit, a ZLE message is generated (the suppression mechanism for		Limit, a ZLE message is generated (the suppression mechanism for
	preventing implosion is described later in the Processing Rules		preventing implosion is described later in the Processing Rules
	section). ZLEs detect leaks where packets do not return to		section). ZLEs detect leaks where packets do not return to
	another part of the same scope zone, but instead reach other		another part of the same scope zone, but instead reach other
	Local Scope zones far away from the ZAM originator.		Local Scope zones far away from the ZAM originator.
	In either case, the misconfigured router will be either the message		In either case, the misconfigured router will be either the message
	origin, or one of the routers in the ZBR path list which is included in		origin, or one of the routers in the ZBR path list which is included
	the message received (or perhaps a router on the path between two such		in the message received (or perhaps a router on the path between two
	ZBRs which ought to have been a ZBR itself).		such ZBRs which ought to have been a ZBR itself).
	4.3. Detecting a leaky Local Scope zone		4.3. Detecting a leaky Local Scope zone
	A local scope is leaky if a router has an administrative scope boundary		A local scope is leaky if a router has an administrative scope
	on some interface, but does not have a Local Scope boundary on that		boundary on some interface, but does not have a Local Scope boundary
	interface as specified in RFC 2365. This can be detected via the		on that interface as specified in RFC 2365. This can be detected via
	following method:		the following method:
	o If a ZAM for a given scope is received by a ZBR which is a boundary
	for that scope, it compares the Origin's Scope Zone ID in the ZAM
	with its own Zone ID for the given scope. If the two do not match,
	this is evidence of a misconfiguration. Since a temporary mismatch
	may result immediately after a recent change in the reachability of
	the lowest-addressed ZBR, misconfiguration should be assumed only if
	the mismatch is persistent.
	Draft MZAP October 1999		o If a ZAM for a given scope is received by a ZBR which is a
			boundary for that scope, it compares the Origin's Scope Zone ID in
			the ZAM with its own Zone ID for the given scope. If the two do
			not match, this is evidence of a misconfiguration. Since a
			temporary mismatch may result immediately after a recent change in
			the reachability of the lowest-addressed ZBR, misconfiguration
			should be assumed only if the mismatch is persistent.
	The exact location of the problem can be found by doing an mtrace [5]		The exact location of the problem can be found by doing an mtrace [5]
	from the router detecting the problem, back to the ZAM origin, for any		from the router detecting the problem, back to the ZAM origin, for
	group within the address range identified by the ZAM. The router at		any group within the address range identified by the ZAM. The router
	fault will be the one reporting that a boundary was reached.		at fault will be the one reporting that a boundary was reached.
	4.4. Detecting conflicting scope zones		4.4. Detecting conflicting scope zones
	Conflicting address ranges can be detected via the following method:		Conflicting address ranges can be detected via the following method:
	o If a ZBR receives a ZAM for a given scope, and the included start and		o If a ZBR receives a ZAM for a given scope, and the included start
	end addresses overlap with, but are not identical to, the start and		and end addresses overlap with, but are not identical to, the
	end addresses of a locally-configured scope.		start and end addresses of a locally-configured scope.
	Conflicting scope names can be detected via the following method:		Conflicting scope names can be detected via the following method:
	o If a ZBR is configured with a textual name for a given scope and		o If a ZBR is configured with a textual name for a given scope and
	language, and it receives a ZAM or ZCM with a name for the same scope		language, and it receives a ZAM or ZCM with a name for the same
	and language, but the scope names do not match.		scope and language, but the scope names do not match.
	Detecting either type of conflict above indicates that either the local		Detecting either type of conflict above indicates that either the
	router or the router originating the message is misconfigured.		local router or the router originating the message is misconfigured.
	Configuration tools SHOULD strip white space from the beginning and end		Configuration tools SHOULD strip white space from the beginning and
	of each name to avoid accidental misconfiguration.		end of each name to avoid accidental misconfiguration.
	5. Packet Formats		5. Packet Formats
	All MZAP messages are sent over UDP, with a destination port of [MZAP-		All MZAP messages are sent over UDP, with a destination port of
	PORT] and an IPv4 TTL or IPv6 Hop Limit of 255.		[MZAP-PORT] and an IPv4 TTL or IPv6 Hop Limit of 255.
	When sending an MZAP message referring to a given scope zone, a ZBR MUST
	use a source address which will have significance everywhere within the
	scope zone to which the message refers. For example, link-local
	addresses MUST NOT be used.
	The common MZAP message header (which follows the UDP header), is shown
	below:
	Draft MZAP October 1999		When sending an MZAP message referring to a given scope zone, a ZBR
			MUST use a source address which will have significance everywhere
			within the scope zone to which the message refers. For example,
			link-local addresses MUST NOT be used.
	0 1 2 3		The common MZAP message header (which follows the UDP header), is
	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		shown below:
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Version |B| PTYPE |Address Family | NameCount |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Origin |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Zone ID Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Zone Start Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Zone End Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Encoded Zone Name-1 (variable length) |
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | . . . |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| . . . | Encoded Zone Name-N (variable length) |
	+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | Padding (if needed) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Version:		0 1 2 3
	The version defined in this document is version 0.		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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Version |B| PTYPE |Address Family | NameCount |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Message Origin |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Zone ID Address |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Zone Start Address |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Zone End Address |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Encoded Zone Name-1 (variable length) |
			+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| | . . . |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| . . . | Encoded Zone Name-N (variable length) |
			+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| | Padding (if needed) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	"Big" scope bit (B):		Version:
	If clear, indicates that the addresses in the scoped range are not		The version defined in this document is version 0.
	subdividable, and that address allocators may utilize the entire
	range. If set, address allocators should not use the entire range,
	but should learn an appropriate sub-range via another mechanism
	(e.g., AAP [7]).
	Packet Type (PTYPE):		"Big" scope bit (B):
	The packet types defined in this document are:		If clear, indicates that the addresses in the scoped range are not
	0: Zone Announcement Message (ZAM)		subdividable, and that address allocators may utilize the entire
	1: Zone Limit Exceeded (ZLE)		range. If set, address allocators should not use the entire
	2: Zone Convexity Message (ZCM)		range, but should learn an appropriate sub-range via another
	3: Not-Inside Message (NIM)		mechanism (e.g., AAP [7]).
	Address Family:		Packet Type (PTYPE):
	The IANA-assigned address family number [10,11] identifying the		The packet types defined in this document are:
	address family for all addresses in the packet. The families defined		0: Zone Announcement Message (ZAM)
	for IP are:		1: Zone Limit Exceeded (ZLE)
	1: IPv4		2: Zone Convexity Message (ZCM)
	2: IPv6		3: Not-Inside Message (NIM)
	Draft MZAP October 1999		Address Family:
			The IANA-assigned address family number [10,11] identifying the
			address family for all addresses in the packet. The families
			defined for IP are:
			1: IPv4
			2: IPv6
	Name Count:		Name Count:
	The number of encoded zone name blocks in this packet. The count may		The number of encoded zone name blocks in this packet. The count
	be zero.		may be zero.
	Zone Start Address: 32 bits (IPv4) or 128 bits (IPv6)		Zone Start Address: 32 bits (IPv4) or 128 bits (IPv6)
	This gives the start address for the scope zone boundary. For		This gives the start address for the scope zone boundary. For
	example, if the zone is a boundary for 239.1.0.0 to 239.1.0.255, then		example, if the zone is a boundary for 239.1.0.0 to 239.1.0.255,
	Zone Start Address is 239.1.0.0.		then Zone Start Address is 239.1.0.0.
	Zone End Address: 32 bits (IPv4) or 128 bits (IPv6)		Zone End Address: 32 bits (IPv4) or 128 bits (IPv6)
	This gives the ending address for the scope zone boundary. For		This gives the ending address for the scope zone boundary. For
	example, if the zone is a boundary for 239.1.0.0 to 239.1.0.255, then		example, if the zone is a boundary for 239.1.0.0 to 239.1.0.255,
	Zone End Address is 239.1.0.255.		then Zone End Address is 239.1.0.255.
	Message Origin: 32 bits (IPv4) or 128 bits (IPv6)		Message Origin: 32 bits (IPv4) or 128 bits (IPv6)
	This gives the IP address of the interface that originated the		This gives the IP address of the interface that originated the
	message.		message.
	Zone ID Address: 32 bits (IPv4) or 128 bits (IPv6)		Zone ID Address: 32 bits (IPv4) or 128 bits (IPv6)
	This gives the lowest IP address of a boundary router that has been		This gives the lowest IP address of a boundary router that has
	observed in the zone originating the message. Together with Zone		been observed in the zone originating the message. Together with
	Start Address and Zone End Address, it forms a unique ID for the		Zone Start Address and Zone End Address, it forms a unique ID for
	zone. Note that this ID is usually different from the ID of the		the zone. Note that this ID is usually different from the ID of
	Local Scope zone in which the origin resides.		the Local Scope zone in which the origin resides.
	Encoded Zone Name:		Encoded Zone Name:
	+--------------------+		+--------------------+
	|D| Reserved (7 bits)|		|D| Reserved (7 bits)|
	+--------------------+		+--------------------+
	| LangLen (1 byte) |		| LangLen (1 byte) |
	+--------------------+-----------+		+--------------------+-----------+
	| Language Tag (variable size) |		| Language Tag (variable size) |
	+--------------------+-----------+		+--------------------+-----------+
	| NameLen (1 byte) |		| NameLen (1 byte) |
	+--------------------+-----------+		+--------------------+-----------+
	| Zone Name (variable size) |		| Zone Name (variable size) |
	+--------------------------------+		+--------------------------------+
	The first byte contains flags, of which only the high bit is defined.		The first byte contains flags, of which only the high bit is
	The other bits are reserved (sent as 0, ignored on receipt).		defined. The other bits are reserved (sent as 0, ignored on
	"Default Language" (D) bit:		receipt).
	If set, indicates a preference that the name in the following
	language should be used if no name is available in a desired
	language.
	Draft MZAP October 1999		"Default Language" (D) bit:
			If set, indicates a preference that the name in the following
			language should be used if no name is available in a desired
			language.
	Language tag length (LangLen): 1 byte		Language tag length (LangLen): 1 byte
	The length, in bytes, of the language tag.		The length, in bytes, of the language tag.
	Language Tag: (variable size)		Language Tag: (variable size)
	The language tag, such as "en-US", indicating the language of the		The language tag, such as "en-US", indicating the language of the
	zone name. Language tags are described in [6].		zone name. Language tags are described in [6].
	Name Len:		Name Len:
	The length, in bytes, of the Zone Name field. The length MUST NOT be		The length, in bytes, of the Zone Name field. The length MUST NOT
	zero.		be zero.
	Zone Name: multiple of 8 bits		Zone Name: multiple of 8 bits
	The Zone Name is an ISO 10646 character string in UTF-8 encoding [4]		The Zone Name is an ISO 10646 character string in UTF-8 encoding
	indicating the name given to the scope zone (eg: ``ISI-West Site'').		[4] indicating the name given to the scope zone (eg: "ISI-West
	It should be relatively short and MUST be less than 256 bytes in		Site"). It should be relatively short and MUST be less than 256
	length. White space SHOULD be stripped from the beginning and end of		bytes in length. White space SHOULD be stripped from the
	each name before encoding, to avoid accidental conflicts.		beginning and end of each name before encoding, to avoid
			accidental conflicts.
	Padding (if needed):		Padding (if needed):
	The end of the MZAP header is padded with null bytes until it is		The end of the MZAP header is padded with null bytes until it is
	4-byte aligned.		4-byte aligned.
	5.1. Zone Announcement Message		5.1. Zone Announcement Message
	A Zone Announcement Message has PTYPE=0, and is periodically sent by a		A Zone Announcement Message has PTYPE=0, and is periodically sent by
	ZBR for each scope for which it is a boundary, EXCEPT:		a ZBR for each scope for which it is a boundary, EXCEPT:
	o the Local Scope
	o the Link-local scope		o the Local Scope
	The format of a Zone Announcement Message is shown below:		o the Link-local scope
	Draft MZAP October 1999		The format of a Zone Announcement Message is shown below:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	MZAP Header		MZAP Header
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ZT | ZTL | Hold Time |		| ZT | ZTL | Hold Time |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local Zone ID Address 0 |		| Local Zone ID Address 0 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Router Address 1 |		| Router Address 1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local Zone ID Address 1 |		| Local Zone ID Address 1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	.....		.....
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Router Address N |		| Router Address N |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local Zone ID Address N |		| Local Zone ID Address N |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The fields are defined as follows:		The fields are defined as follows:
	Zones Traveled (ZT): 8 bits
	This gives the number of Local Zone IDs contained in this message
	path.
	Zones Traveled Limit (ZTL): 8 bits		Zones Traveled (ZT): 8 bits
	This gives the limit on number of local zones that the packet can		This gives the number of Local Zone IDs contained in this message
	traverse before it MUST be dropped. A value of 0 indicates that no		path.
	limit exists.
	Hold Time:		Zones Traveled Limit (ZTL): 8 bits
	The time, in seconds, after which the receiver may assume the scope		This gives the limit on number of local zones that the packet can
	no longer exists, if no subsequent ZAM is received. This should be		traverse before it MUST be dropped. A value of 0 indicates that
	set to [ZAM-HOLDTIME].		no limit exists.
	Zone Path: multiple of 64 bits (IPv4) or 256 bits (IPv6)		Hold Time:
	The zone path is a list of Local Zone ID Addresses (the Zone ID		The time, in seconds, after which the receiver should assume the
	Address of a local zone) through which the ZAM has passed, and IP		scope no longer exists, if no subsequent ZAM is received. This
	addresses of the router that forwarded the packet. The origin router		should be set to [ZAM-HOLDTIME].
	fills in the "Local Zone ID Address 0" field when sending the ZAM.
	Every Local Scope router that forwards the ZAM across a Local Scope
	boundary MUST add the Local Zone ID Address of the local zone that
	the packet of the zone into which the message is being forwarded, and
	its own IP address to the end of this list, and increment ZT
	accordingly. The zone path is empty which the ZAM is first sent.
	Draft MZAP October 1999		Zone Path: multiple of 64 bits (IPv4) or 256 bits (IPv6)
			The zone path is a list of Local Zone ID Addresses (the Zone ID
			Address of a local zone) through which the ZAM has passed, and IP
			addresses of the router that forwarded the packet. The origin
			router fills in the "Local Zone ID Address 0" field when sending
			the ZAM. Every Local Scope router that forwards the ZAM across a
			Local Scope boundary MUST add the Local Zone ID Address of the
			local zone that the packet of the zone into which the message is
			being forwarded, and its own IP address to the end of this list,
			and increment ZT accordingly. The zone path is empty which the
			ZAM is first sent.
	5.2. Zone Limit Exceeded (ZLE)		5.2. Zone Limit Exceeded (ZLE)
	The format of a ZLE is shown below:		The format of a ZLE is shown below:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	MZAP Header		MZAP Header
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ZT | ZTL | Hold Time |		| ZT | ZTL | Hold Time |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local Zone ID Address 0 |		| Local Zone ID Address 0 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Router Address 1 |		| Router Address 1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local Zone ID Address 1 |		| Local Zone ID Address 1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	.....		.....
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Router Address N |		| Router Address N |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local Zone ID Address N |		| Local Zone ID Address N |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	All fields are copied from the ZAM, except PTYPE which is set to one.		All fields are copied from the ZAM, except PTYPE which is set to one.
	5.3. Zone Convexity Message		5.3. Zone Convexity Message
	A Zone Announcement Message has PTYPE=2, and is periodically sent by a		A Zone Announcement Message has PTYPE=2, and is periodically sent by
	ZBR for each scope for which it is a boundary (except the Link-local		a ZBR for each scope for which it is a boundary (except the Link-
	scope). Note that ZCM's ARE sent in the Local Scope.		local scope). Note that ZCM's ARE sent in the Local Scope.
	Unlike Zone Announcement Messages which are sent to the [MZAP-LOCAL-		Unlike Zone Announcement Messages which are sent to the [MZAP-LOCAL-
	GROUP], Zone Convexity Messages are sent to the [ZCM-RELATIVE-GROUP] in		GROUP], Zone Convexity Messages are sent to the [ZCM-RELATIVE-GROUP]
	the scope zone itself. The format of a ZCM is shown below:		in the scope zone itself. The format of a ZCM is shown below:
	Draft MZAP October 1999		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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			MZAP Header
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| ZNUM | unused | Hold Time |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| ZBR Address 1 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			.....
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| ZBR Address N |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	0 1 2 3		The fields are as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	MZAP Header
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ZNUM | unused | Hold Time |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ZBR Address 1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	.....
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ZBR Address N |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The fields are as follows:		Number of ZBR addresses (ZNUM): 8 bits
	Number of ZBR addresses (ZNUM): 8 bits		This field gives the number of ZBR Addresses contained in this
	This field gives the number of ZBR Addresses contained in this		message.
	message.
	Hold Time:		Hold Time:
	The time, in seconds, after which the receiver may assume the sender		The time, in seconds, after which the receiver should assume the
	is no longer reachable, if no subsequent ZCM is received. This		sender is no longer reachable, if no subsequent ZCM is received.
	should be set to [ZCM-HOLDTIME].		This should be set to [ZCM-HOLDTIME].
	ZBR Address: 32 bits (IPv4) or 128 bits (IPv6)		ZBR Address: 32 bits (IPv4) or 128 bits (IPv6)
	These fields give the addresses of the other ZBRs from which the		These fields give the addresses of the other ZBRs from which the
	Message Origin ZBR has received ZCMs but whose hold time has not		Message Origin ZBR has received ZCMs but whose hold time has not
	expired. The router should include all such addresses which fit in		expired. The router should include all such addresses which fit
	the packet, preferring those which it has not included recently if		in the packet, preferring those which it has not included recently
	all do not fit.		if all do not fit.
	5.4. Not-Inside Message		5.4. Not-Inside Message
	A Not-Inside Message (NIM) has PTYPE=3, and is periodically sent by a		A Not-Inside Message (NIM) has PTYPE=3, and is periodically sent by a
	ZBR which knows that a scope X does not nest within another scope Y ("X		ZBR which knows that a scope X does not nest within another scope Y
	not inside Y"):		("X not inside Y"):
	The format of a Not-Inside Message is shown below:
	Draft MZAP October 1999		The format of a Not-Inside Message is shown below:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	MZAP Header		MZAP Header
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Not-Inside Zone Start Address |		| Not-Inside Zone Start Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			The fields are as follows:
	The fields are as follows:		MZAP Header: Header fields identifying the scope X. The Name Count
	MZAP Header:		may be 0.
	Header fields identifying the scope X. The Name Count may be 0.
	Not-Inside Zone Start Address: 32 bits (IPv4) or 128 bits (IPv6)		Not-Inside Zone Start Address: 32 bits (IPv4) or 128 bits (IPv6) This
	This gives the start address for the scope Y.		gives the start address for the scope Y.
	6. Message Processing Rules		6. Message Processing Rules
	6.1. Internal entities listening to MZAP messages		6.1. Internal entities listening to MZAP messages
	Any host or application may join the [MZAP-LOCAL-GROUP] to listen for		Any host or application may join the [MZAP-LOCAL-GROUP] to listen for
	Zone Announcement Messages to build up a list of the scope zones that		Zone Announcement Messages to build up a list of the scope zones that
	are relevant locally, and for Not-Inside Messages if it wishes to learn		are relevant locally, and for Not-Inside Messages if it wishes to
	nesting information. However, listening to such messages is not the		learn nesting information. However, listening to such messages is
	recommended method for regular applications to discover this		not the recommended method for regular applications to discover this
	information. These applications will normally query a local Multicast		information. These applications will normally query a local
	Address Allocation Server (MAAS) [3], which in turn listens to Zone		Multicast Address Allocation Server (MAAS) [3], which in turn listens
	Announcement Messages and Not-Inside Messages to maintain scope		to Zone Announcement Messages and Not-Inside Messages to maintain
	information, and can be queried by clients via MADCAP messages.		scope information, and can be queried by clients via MADCAP messages.
	An entity (including a MAAS) lacking any such information can only
	assume that it is within the Global Scope, and the Local Scope, both of
	which have well-known address ranges defined in [1].
	An internal entity (e.g., an MAAS) receiving a ZAM will parse the		An entity (including a MAAS) lacking any such information can only
	information that is relevant to it, such as the address range, and the		assume that it is within the Global Scope, and the Local Scope, both
	names. An address allocator receiving such information MUST also use		of which have well-known address ranges defined in [1].
	the "B" bit to determine whether it can add the address range to the set
	of ranges from which it may allocate addresses (specifically, it may add
	them only if the bit is zero). Even if the bit is zero, an MAAS SHOULD
	still store the range information so that clients who use relative-
	addresses can still obtain the ranges by requesting them from the MAAS.
	An internal entity (e.g., an MAAS) may assume that X nests within Y if:		An internal entity (e.g., an MAAS) receiving a ZAM will parse the
			information that is relevant to it, such as the address range, and
			the names. An address allocator receiving such information MUST also
			use the "B" bit to determine whether it can add the address range to
			the set of ranges from which it may allocate addresses (specifically,
			it may add them only if the bit is zero). Even if the bit is zero,
			an MAAS SHOULD still store the range information so that clients who
			use relative- addresses can still obtain the ranges by requesting
			them from the MAAS.
	Draft MZAP October 1999		An internal entity (e.g., an MAAS) should assume that X nests within
			Y if:
	a) it first heard ZAMs for both X and Y at least [NIM-HOLDTIME]		a) it first heard ZAMs for both X and Y at least [NIM-HOLDTIME]
	seconds ago, AND		seconds ago, AND
	b) it has not heard a NIM indicating that "X not inside Y" for at		b) it has not heard a NIM indicating that "X not inside Y" for at
	least [NIM-HOLDTIME] seconds.		least [NIM-HOLDTIME] seconds.
	6.2. Sending ZAMs		6.2. Sending ZAMs
	Each ZBR should send a Zone Announcement Message for each scope zone for		Each ZBR should send a Zone Announcement Message for each scope zone
	which it is a boundary every [ZAM-INTERVAL] seconds, +/- 30% of [ZAM-		for which it is a boundary every [ZAM-INTERVAL] seconds, +/- 30% of
	INTERVAL] each time to avoid message synchronisation.		[ZAM-INTERVAL] each time to avoid message synchronisation.
	The ZAM packet also contains a Zones Traveled Limit (ZTL). If the		The ZAM packet also contains a Zones Traveled Limit (ZTL). If the
	number of Local Zone IDs in the ZAM path becomes equal to the Zones		number of Local Zone IDs in the ZAM path becomes equal to the Zones
	Traveled Limit, the packet will be dropped. The ZTL field is set when		Traveled Limit, the packet will be dropped. The ZTL field is set
	the packet is first sent, and defaults to 32, but can be set to a lower		when the packet is first sent, and defaults to 32, but can be set to
	value if a network administrator knows the expected size of the zone.		a lower value if a network administrator knows the expected size of
			the zone.
	6.3. Receiving ZAMs		6.3. Receiving ZAMs
	When a ZBR receives a ZAM for some scope zone X, it uses the following		When a ZBR receives a ZAM for some scope zone X, it uses the
	rules.		following rules.
	If the local ZBR does NOT have any configuration for scope X:
	(1) Check to see if the included start and end addresses overlap with,
	but are not identical to, the start and end addresses of any
	locally-configured scope Y, and if so, signal an address range
	conflict to a local administrator.
	(2) Create a local "X not inside" state entry, if such an entry does
	not already exist. The ZBR then restarts the entry's timer at
	[ZAM-HOLDTIME]. Existence of this state indicates that the ZBR
	knows that X does not nest inside any scope for which it is a
	boundary. If the entry's timer expires (because no more ZAMs for X
	are heard for [ZAM-HOLDTIME]), the entry is deleted.
	If the local ZBR does have configuration for scope X:		If the local ZBR does NOT have any configuration for scope X:
	(1) If the ZAM originated from OUTSIDE the scope (i.e., received over a		(1) Check to see if the included start and end addresses overlap
	boundary interface for scope X):		with, but are not identical to, the start and end addresses of
			any locally-configured scope Y, and if so, signal an address
			range conflict to a local administrator.
	Draft MZAP October 1999		(2) Create a local "X not inside" state entry, if such an entry does
			not already exist. The ZBR then restarts the entry's timer at
			[ZAM-HOLDTIME]. Existence of this state indicates that the ZBR
			knows that X does not nest inside any scope for which it is a
			boundary. If the entry's timer expires (because no more ZAMs for
			X are heard for [ZAM-HOLDTIME]), the entry is deleted.
	a) If the Scope Zone ID in the ZAM matches the ZBR's own Scope Zone		If the local ZBR does have configuration for scope X:
	ID, then signal a leaky scope misconfiguration.
	b) Drop the ZAM (perform no further processing below). For		(1) If the ZAM originated from OUTSIDE the scope (i.e., received over
	example, router G in Figure 2 will not forward the ZAM. This		a boundary interface for scope X):
	rule is primarily a safety measure, since the placement of G in
	Figure 2 is not a recommended configuration, as discussed
	earlier.
	(2) If the ZAM originated from INSIDE the scope:		a) If the Scope Zone ID in the ZAM matches the ZBR's own Scope
			Zone ID, then signal a leaky scope misconfiguration.
	a) If the next-hop interface (according to the multicast RIB)		b) Drop the ZAM (perform no further processing below). For
	towards the Origin is outside the scope zone, then signal a non-		example, router G in Figure 2 will not forward the ZAM. This
	convexity problem.		rule is primarily a safety measure, since the placement of G in
			Figure 2 is not a recommended configuration, as discussed
			earlier.
	b) If the Origin's Scope Zone ID in the ZAM does not match the		2) If the ZAM originated from INSIDE the scope:
	Scope Zone ID kept by the local ZBR, and this mismatch continues
	to occur, then signal a possible leaky scope warning.
	c) For each textual name in the ZAM, see if a name for the same		a) If the next-hop interface (according to the multicast RIB)
	scope and language is locally-configured; if so, but the scope		towards the Origin is outside the scope zone, then signal a
	names do not match, signal a scope name conflict to a local		non- convexity problem.
	administrator.
	d) If the ZAM was received on an interface which is NOT a Local		b) If the Origin's Scope Zone ID in the ZAM does not match the
	Scope boundary, and the last Local Zone ID Address in the path		Scope Zone ID kept by the local ZBR, and this mismatch
	list is 0, the ZBR fills in the Local Zone ID Address of the		continues to occur, then signal a possible leaky scope warning.
	local zone from which the ZAM was received.
	If a ZAM for the same scope (as identified by the origin Zone ID and		c) For each textual name in the ZAM, see if a name for the same
	first multicast address) was received in the last [ZAM-DUP-TIME]		scope and language is locally-configured; if so, but the scope
	seconds, the ZAM is then discarded. Otherwise, the ZAM is cached for at		names do not match, signal a scope name conflict to a local
	least [ZAM-DUP-TIME] seconds. For example, when router C in Figure 2		administrator.
	receives the ZAM via B, it will not be forwarded, since it has just
	forwarded the ZAM from E.
	The Zones Travelled count in the message is then incremented, and if the		d) If the ZAM was received on an interface which is NOT a Local
	updated count is equal to or greater than the ZTL field, schedule a ZLE		Scope boundary, and the last Local Zone ID Address in the path
	to be sent as described in the next subsection and perform no further		list is 0, the ZBR fills in the Local Zone ID Address of the
	processing below.		local zone from which the ZAM was received.
	If the Zone ID of the Local Scope zone in which the ZBR resides is not		If a ZAM for the same scope (as identified by the origin Zone ID and
	already in the ZAM's path list, then the ZAM is immediately re-		first multicast address) was received in the last [ZAM-DUP-TIME]
	originated within the Local Scope zone. It adds its own address and the		seconds, the ZAM is then discarded. Otherwise, the ZAM is cached for
	Zone ID of the Local Scope zone into which the message is being		at least [ZAM-DUP-TIME] seconds. For example, when router C in
			Figure 2 receives the ZAM via B, it will not be forwarded, since it
			has just forwarded the ZAM from E.
	Draft MZAP October 1999		The Zones Travelled count in the message is then incremented, and if
			the updated count is equal to or greater than the ZTL field, schedule
			a ZLE to be sent as described in the next subsection and perform no
			further processing below.
	forwarded to the ZAM path list before doing so. A ZBR receiving a ZAM		If the Zone ID of the Local Scope zone in which the ZBR resides is
	with a non-null path list MUST NOT forward that ZAM back into a Local		not already in the ZAM's path list, then the ZAM is immediately re-
	Scope zone that is contained in the path list. For example, in Figure		originated within the Local Scope zone. It adds its own address and
	2, router F, which did not get the ZAM via A due to packet loss, will		the Zone ID of the Local Scope zone into which the message is being
	not forward the ZAM from B back into Zone 2 since the path list has {		forwarded to the ZAM path list before doing so. A ZBR receiving a
	(E,1), (A,2), (B,3) } and hence Zone 2 already appears.		ZAM with a non-null path list MUST NOT forward that ZAM back into a
			Local Scope zone that is contained in the path list. For example, in
			Figure 2, router F, which did not get the ZAM via A due to packet
			loss, will not forward the ZAM from B back into Zone 2 since the path
			list has { (E,1), (A,2), (B,3) } and hence Zone 2 already appears.
	In addition, the ZBR re-originates the ZAM out each interface with a		In addition, the ZBR re-originates the ZAM out each interface with a
	Local Scope boundary (except that it is not sent back out the interface		Local Scope boundary (except that it is not sent back out the
	over which it was received, nor is it sent into any local scope zone		interface over which it was received, nor is it sent into any local
	whose ID is known and appears in the path list). In each such ZAM re-		scope zone whose ID is known and appears in the path list). In each
	originated, the ZBR adds its own IP address to the path list, as well as		such ZAM re-originated, the ZBR adds its own IP address to the path
	the Zone ID Address of the Local Scope Zone into which the ZAM is being		list, as well as the Zone ID Address of the Local Scope Zone into
	sent, or 0 if the ID is unknown. (For example, if the other end of a		which the ZAM is being sent, or 0 if the ID is unknown. (For
	point-to-point link also has a boundary on the interface, then the link		example, if the other end of a point-to-point link also has a
	has no Local Scope Zone ID.)		boundary on the interface, then the link has no Local Scope Zone ID.)
	6.4. Sending ZLEs		6.4. Sending ZLEs
	This packet is sent by a local-zone boundary router that would have		This packet is sent by a local-zone boundary router that would have
	exceeded the Zone Traveled Limit if it had forwarded a ZAM packet. To		exceeded the Zone Traveled Limit if it had forwarded a ZAM packet.
	avoid ZLE implosion, ZLEs are multicast with a random delay and		To avoid ZLE implosion, ZLEs are multicast with a random delay and
	suppressed by other ZLEs. It is only scheduled if at least [ZLE-MIN-		suppressed by other ZLEs. It is only scheduled if at least [ZLE-
	INTERVAL] seconds have elapsed since it previously sent a ZLE to any		MIN-INTERVAL] seconds have elapsed since it previously sent a ZLE to
	destination. To schedule a ZLE, the router sets a random delay timer		any destination. To schedule a ZLE, the router sets a random delay
	within the interval [ZLE-SUPPRESSION-INTERVAL], and listens to the		timer within the interval [ZLE-SUPPRESSION-INTERVAL], and listens to
	[MZAP-RELATIVE-GROUP] within the included scope for other ZLEs. If any		the [MZAP-RELATIVE-GROUP] within the included scope for other ZLEs.
	are received before the random delay timer expires, the timer is cleared		If any are received before the random delay timer expires, the timer
	and the ZLE is not sent. If the timer expires, the router sends a ZLE		is cleared and the ZLE is not sent. If the timer expires, the router
	to the [MZAP-RELATIVE-GROUP] within the indicated scope.		sends a ZLE to the [MZAP-RELATIVE-GROUP] within the indicated scope.
	The method used to choose a random delay (T) is as follows:		The method used to choose a random delay (T) is as follows:
	Choose a random value X from the uniform random interval [0:1]
	Let C = 256
	Set T = [ZLE-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C)
	This equation results in an exponential random distribution which
	ensures that close to one ZBR will respond. Using a purely uniform
	distribution would begin to exhibit scaling problems as the number of
	ZBRs rose. Since ZLEs are only suppressed if a duplicate ZLE arrives
	before the time chosen, two routers choosing delays which differ by an
	amount less than the propagation delay between them will both send
	messages, consuming excess bandwidth. Hence it is desirable to minimize
	the number of routers choosing a delay close to the lowest delay chosen,
	and an exponential distribution is suitable for this purpose.
	Draft MZAP October 1999		Choose a random value X from the uniform random interval [0:1]
			Let C = 256
			Set T = [ZLE-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C)
	A router SHOULD NOT send more than one Zone Limit Exceeded message every		This equation results in an exponential random distribution which
	[ZLE-MIN-INTERVAL] regardless of destination.		ensures that close to one ZBR will respond. Using a purely uniform
			distribution would begin to exhibit scaling problems as the number of
			ZBRs rose. Since ZLEs are only suppressed if a duplicate ZLE arrives
			before the time chosen, two routers choosing delays which differ by
			an amount less than the propagation delay between them will both send
			messages, consuming excess bandwidth. Hence it is desirable to
			minimize the number of routers choosing a delay close to the lowest
			delay chosen, and an exponential distribution is suitable for this
			purpose.
			A router SHOULD NOT send more than one Zone Limit Exceeded message
			every [ZLE-MIN-INTERVAL] regardless of destination.
	6.5. Receiving ZLEs		6.5. Receiving ZLEs
	When a router receives a ZLE, it performs the following actions:		When a router receives a ZLE, it performs the following actions:
	(1) If the router has a duplicate ZLE message scheduled to be sent,		(1) If the router has a duplicate ZLE message scheduled to be sent,
	it unschedules its own message so another one will not be sent.		it unschedules its own message so another one will not be sent.
	(2) If the ZLE contains the router's own address in the Origin field,		(2) If the ZLE contains the router's own address in the Origin field,
	it signals a leaky scope misconfiguration.		it signals a leaky scope misconfiguration.
	6.6. Sending ZCMs		6.6. Sending ZCMs
	Each ZBR should send a Zone Convexity Message (ZCM) for each scope zone		Each ZBR should send a Zone Convexity Message (ZCM) for each scope
	for which it is a boundary every [ZCM-INTERVAL] seconds, +/- 30% of		zone for which it is a boundary every [ZCM-INTERVAL] seconds, +/- 30%
	[ZCM-INTERVAL] each time to avoid message synchronisation.		of [ZCM-INTERVAL] each time to avoid message synchronisation.
	ZCMs are sent to the [ZCM-RELATIVE-GROUP] in the scoped range itself.		ZCMs are sent to the [ZCM-RELATIVE-GROUP] in the scoped range itself.
	(For example, if the scope range is 239.1.0.0 to 239.1.0.255, then these		(For example, if the scope range is 239.1.0.0 to 239.1.0.255, then
	messages should be sent to 239.1.0.252.) As these are not Locally-		these messages should be sent to 239.1.0.252.) As these are not
	Scoped packets, they are simply multicast across the scope zone itself,		Locally-Scoped packets, they are simply multicast across the scope
	and require no path to be built up, nor any special processing by		zone itself, and require no path to be built up, nor any special
	intermediate Local Scope ZBRs.		processing by intermediate Local Scope ZBRs.
	6.7. Receiving ZCMs		6.7. Receiving ZCMs
	When a ZCM is received for a given scope X, on an interface which is		When a ZCM is received for a given scope X, on an interface which is
	inside the scope, it follows the rules below:		inside the scope, it follows the rules below:
	(1) The Origin is added to the local list of ZBRs (including itself)		(1) The Origin is added to the local list of ZBRs (including itself)
	for that scope, and the Zone ID is updated to be the lowest IP		for that scope, and the Zone ID is updated to be the lowest IP
	address in the list. The new entry is scheduled to be timed out		address in the list. The new entry is scheduled to be timed out
	after [ZCM-HOLDTIME] if no further messages are received from		after [ZCM-HOLDTIME] if no further messages are received from
	that ZBR, so that the Zone ID will converge to the lowest address		that ZBR, so that the Zone ID will converge to the lowest address
	of any active ZBR for the scope.		of any active ZBR for the scope.
	(2) If a ZBR is listed in ZCMs received, but the next-hop interface		(2) If a ZBR is listed in ZCMs received, but the next-hop interface
	(according to the multicast RIB) towards that ZBR is outside the		(according to the multicast RIB) towards that ZBR is outside the
	scope zone, or if no ZCM is received from that ZBR for [ZCM-		scope zone, or if no ZCM is received from that ZBR for [ZCM-
	HOLDTIME] seconds, as in the example in Figure 4, then signal a		HOLDTIME] seconds, as in the example in Figure 4, then signal a
	Draft MZAP October 1999
	non-convexity problem.		non-convexity problem.
	(3) For each textual name in the ZCM, see if a name for the same		(3) For each textual name in the ZCM, see if a name for the same
	scope and language is locally-configured; if so, but the scope		scope and language is locally-configured; if so, but the scope
	names do not match, signal a scope name conflict to a local		names do not match, signal a scope name conflict to a local
	administrator.		administrator.
	6.8. Sending NIMs		6.8. Sending NIMs
	Periodically, for each scope zone Y for which it is a boundary, a router		Periodically, for each scope zone Y for which it is a boundary, a
	originates a Not-Inside Message (NIM) for each "X not inside" entry it		router originates a Not-Inside Message (NIM) for each "X not inside"
	has created when receiving ZAMs. Like a ZAM, this message is multicast		entry it has created when receiving ZAMs. Like a ZAM, this message
	to the address [MZAP-LOCAL-GROUP] from one of its interfaces inside Y.		is multicast to the address [MZAP-LOCAL-GROUP] from one of its
			interfaces inside Y.
	Each ZBR should send such a Not-Inside Message every [NIM-INTERVAL]		Each ZBR should send such a Not-Inside Message every [NIM-INTERVAL]
	seconds, +/- 30% of [NIM-INTERVAL] to avoid message synchronization.		seconds, +/- 30% of [NIM-INTERVAL] to avoid message synchronization.
	6.9. Receiving NIMs		6.9. Receiving NIMs
	When a ZBR receives a NIM saying that "X is not inside Y", it is		When a ZBR receives a NIM saying that "X is not inside Y", it is
	forwarded, unmodified, in a manner similar to ZAMs:		forwarded, unmodified, in a manner similar to ZAMs:
	(1) If the NIM was received on an interface with a boundary for		(1) If the NIM was received on an interface with a boundary for
	either X or Y, the NIM is discarded.		either X or Y, the NIM is discarded.
	(2) Unlike ZAMs, if the NIM was not received on the interface towards		(2) Unlike ZAMs, if the NIM was not received on the interface towards
	the message origin (according to the Multicast RIB), the NIM is		the message origin (according to the Multicast RIB), the NIM is
	discarded.		discarded.
	(3) If a NIM for the same X and Y (where each is identified by its		(3) If a NIM for the same X and Y (where each is identified by its
	first multicast address) was received in the last [ZAM-DUP-TIME]		first multicast address) was received in the last [ZAM-DUP-TIME]
	seconds, the NIM is not forwarded.		seconds, the NIM is not forwarded.
	(4) Otherwise, the NIM is cached for at least [ZAM-DUP-TIME] seconds.		(4) Otherwise, the NIM is cached for at least [ZAM-DUP-TIME] seconds.
	(5) The ZBR then re-originates the NIM (i.e., with the original UDP		(5) The ZBR then re-originates the NIM (i.e., with the original UDP
	payload) into each local scope zone in which it has interfaces,		payload) into each local scope zone in which it has interfaces,
	except that it is not sent back into the local scope zone from		except that it is not sent back into the local scope zone from
	which the message was received, nor is it sent out any interface		which the message was received, nor is it sent out any interface
	with a boundary for either X or Y.		with a boundary for either X or Y.
	Draft MZAP October 1999
	7. Constants		7. Constants
	[MZAP-PORT]: The well-known UDP port to which all MZAP messages are		[MZAP-PORT]: The well-known UDP port to which all MZAP messages are
	sent. Value: 2106.		sent. Value: 2106.
	[MZAP-LOCAL-GROUP]: The well-known group in the Local Scope to which
	ZAMs are sent. All Multicast Address Allocation servers and Zone
	Boundary Routers listen to this group. Value: 239.255.255.252 for IPv4;
	FF03:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFC for IPv6.
	[ZCM-RELATIVE-GROUP]: The relative group in each scope zone, to which		[MZAP-LOCAL-GROUP]: The well-known group in the Local Scope to which
	ZCMs are sent. A Zone Boundary Router listens to the relative group in		ZAMs are sent. All Multicast Address Allocation servers and Zone
	each scope for which it is a boundary. Value: (last IP address in scope		Boundary Routers listen to this group. Value: 239.255.255.252 for
	range) - 3. For example, in the Local Scope, the relative group is the		IPv4.
	same as the [MZAP-LOCAL-GROUP] address.
	[ZAM-INTERVAL]: The interval at which a Zone Boundary Router originates		[ZCM-RELATIVE-GROUP]: The relative group in each scope zone, to
	Zone Announcement Messages. Default value: 600 seconds (10 minutes).		which ZCMs are sent. A Zone Boundary Router listens to the relative
			group in each scope for which it is a boundary. Value: (last IP
			address in scope range) - 3. For example, in the Local Scope, the
			relative group is the same as the [MZAP-LOCAL-GROUP] address.
	[ZAM-HOLDTIME]: The holdtime to include in a ZAM. This SHOULD be set		[ZAM-INTERVAL]: The interval at which a Zone Boundary Router
	to at least 3 * [ZAM-INTERVAL]. Default value: 1860 seconds (31		originates Zone Announcement Messages. Default value: 600 seconds
	minutes).		(10 minutes).
	[ZAM-DUP-TIME]: The time interval after forwarding a ZAM, during which		[ZAM-HOLDTIME]: The holdtime to include in a ZAM. This SHOULD be
	ZAMs for the same scope will not be forwarded. Default value: 30		set to at least 3 * [ZAM-INTERVAL]. Default value: 1860 seconds (31
	seconds.		minutes).
	[ZCM-INTERVAL]: The interval at which a Zone Boundary Router originates		[ZAM-DUP-TIME]: The time interval after forwarding a ZAM, during
	Zone Convexity Messages. Default value: 600 seconds (10 minutes).		which ZAMs for the same scope will not be forwarded. Default value:
			30 seconds.
	[ZCM-HOLDTIME]: The holdtime to include in a ZCM. This SHOULD be set		[ZCM-INTERVAL]: The interval at which a Zone Boundary Router
	to at least 3 * [ZCM-INTERVAL]. Default value: 1860 seconds (31		originates Zone Convexity Messages. Default value: 600 seconds (10
	minutes).		minutes).
	[ZLE-SUPPRESSION-INTERVAL]: The interval over which to choose a random		[ZCM-HOLDTIME]: The holdtime to include in a ZCM. This SHOULD be
	delay before sending a ZLE message. Default value: 300 seconds (5		set to at least 3 * [ZCM-INTERVAL]. Default value: 1860 seconds (31
	minutes).		minutes).
	[ZLE-MIN-INTERVAL]: The minimum interval between sending ZLE messages,		[ZLE-SUPPRESSION-INTERVAL]: The interval over which to choose a
	regardless of destination. Default value: 300 seconds (5 minutes).		random delay before sending a ZLE message. Default value: 300
			seconds (5 minutes).
	[NIM-INTERVAL]: The interval at which a Zone Boundary Router originates		[ZLE-MIN-INTERVAL]: The minimum interval between sending ZLE
	Not-Inside Messages. Default value: 1800 seconds (30 minutes).		messages, regardless of destination. Default value: 300 seconds (5
			minutes).
	Draft MZAP October 1999		[NIM-INTERVAL]: The interval at which a Zone Boundary Router
			originates Not-Inside Messages. Default value: 1800 seconds (30
			minutes).
	[NIM-HOLDTIME]: The holdtime to include the state within a NIM. This		[NIM-HOLDTIME]: The holdtime to include the state within a NIM.
	SHOULD be set to at least 3 * [NIM-INTERVAL]. Default value: 5460 (91		This SHOULD be set to at least 3 * [NIM-INTERVAL]. Default value:
	minutes)		5460 (91 minutes)
	8. Security Considerations		8. Security Considerations
	While unauthorized reading of MZAP messages is relatively innocuous (so		While unauthorized reading of MZAP messages is relatively innocuous
	encryption is generally not an issue), accepting unauthenticated MZAP		(so encryption is generally not an issue), accepting unauthenticated
	messages can be problematic. Authentication of MZAP messages can be		MZAP messages can be problematic. Authentication of MZAP messages
	provided by using the IPsec Authentication Header (AH) [12].		can be provided by using the IPsec Authentication Header (AH) [12].
	In the case of ZCMs and ZLEs, an attacker can cause false logging of
	convexity and leakage problems. It is likely that is would be purely an
	annoyance, and not cause any significant problem. (Such messages could
	be authenticated, but since they may be sent within large scopes, the
	receiver may not be able to authenticate a non-malicious sender.)
	ZAMs and NIMs, on the other hand, are sent within the Local Scope, where		In the case of ZCMs and ZLEs, an attacker can cause false logging of
	assuming a security relationship between senders and receivers is more		convexity and leakage problems. It is likely that is would be purely
	practical.		an annoyance, and not cause any significant problem. (Such messages
			could be authenticated, but since they may be sent within large
			scopes, the receiver may not be able to authenticate a non-malicious
			sender.)
	In the case of NIMs, accepting unauthenticated messages can cause the		ZAMs and NIMs, on the other hand, are sent within the Local Scope,
	false cancellation of nesting relationships. This would cause a section		where assuming a security relationship between senders and receivers
	of the hierarchy of zones to flatten. Such a flattening would lessen		is more practical.
	the efficiency benefits afforded by the hierarchy but would not cause it
	to become unusable.
	Accepting unauthenticated ZAM messages, however, could cause		In the case of NIMs, accepting unauthenticated messages can cause the
	applications to believe that a scope zone exists when it does not. If		false cancellation of nesting relationships. This would cause a
	these were believed, then applications may choose to use this non-		section of the hierarchy of zones to flatten. Such a flattening
	existent administrative scope for their uses. Such applications would		would lessen the efficiency benefits afforded by the hierarchy but
	be able to communicate successfully, but would be unaware that their		would not cause it to become unusable.
	traffic may be traveling further than they expected. As a result, any
	application accepting unauthenticated ZAMs MUST only take scope names as
	a guideline, and SHOULD assume that their traffic sent to non-local
	scope zones might travel anywhere. The confidentiality of such traffic
	CANNOT be assumed from the fact that it was sent to a scoped address
	that was discovered using MZAP.
	In addition, ZAMs are used to inform Multicast Address Allocation		Accepting unauthenticated ZAM messages, however, could cause
	Servers (MAASs) of names and address ranges of scopes, and accepting		applications to believe that a scope zone exists when it does not.
	unauthenticated ZAMs could result in false names being presented to		If these were believed, then applications may choose to use this
	users, and in wrong addresses being allocated to users. To counter		non-existent administrative scope for their uses. Such applications
	this, MAAS's authenticate ZAMs as follows:		would be able to communicate successfully, but would be unaware that
			their traffic may be traveling further than they expected. As a
			result, any application accepting unauthenticated ZAMs MUST only take
			scope names as a guideline, and SHOULD assume that their traffic sent
			to non-local scope zones might travel anywhere. The confidentiality
			of such traffic CANNOT be assumed from the fact that it was sent to a
			scoped address that was discovered using MZAP.
	Draft MZAP October 1999		In addition, ZAMs are used to inform Multicast Address Allocation
			Servers (MAASs) of names and address ranges of scopes, and accepting
			unauthenticated ZAMs could result in false names being presented to
			users, and in wrong addresses being allocated to users. To counter
			this, MAAS's authenticate ZAMs as follows:
	(1) A ZBR signs all ZAMs it originates (using an AH).		(1) A ZBR signs all ZAMs it originates (using an AH).
	(2) A ZBR signs a ZAM it relays if and only if it can authenticate		(2) A ZBR signs a ZAM it relays if and only if it can authenticate
	the previous sender. A ZBR MUST still forward un-authenticated		the previous sender. A ZBR MUST still forward un-authenticated
	ZAMs (to provide leak detection), but should propagate an		ZAMs (to provide leak detection), but should propagate an
	authenticated ZAM even if an un-authenticated one was received		authenticated ZAM even if an un-authenticated one was received
	with the last [ZAM-DUP-TIME] seconds.		with the last [ZAM-DUP-TIME] seconds.
	(3) A MAAS SHOULD be configured with the public key of the local zone		(3) A MAAS SHOULD be configured with the public key of the local zone
	in which it resides. A MAAS thus configured SHOULD ignore an		in which it resides. A MAAS thus configured SHOULD ignore an
	unauthenticated ZAM if an authenticated one for the same scope		unauthenticated ZAM if an authenticated one for the same scope
	has been received, and MAY ignore all unauthenticated ZAMs.		has been received, and MAY ignore all unauthenticated ZAMs.
	9. Acknowledgements		9. Acknowledgements
	This document is a product of the MBone Deployment Working Group, whose		This document is a product of the MBone Deployment Working Group,
	members provided many helpful comments and suggestions, Van Jacobson		whose members provided many helpful comments and suggestions, Van
	provided some of the original ideas that led to this protocol. The		Jacobson provided some of the original ideas that led to this
	Multicast Address Allocation Working Group also provided useful feedback		protocol. The Multicast Address Allocation Working Group also
	regarding scope names and interactions with applications.		provided useful feedback regarding scope names and interactions with
			applications.
	10. References		10. References
	[1] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC		[1] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
	2365, July 1998.		2365, July 1998.
	[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.
	[3] Thaler, D., Handley, M., and D. Estrin, "The Internet Multicast		[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Address Allocation Architecture", Work in Progress, October 1999.		Levels", BCP 14, RFC 2119, March 1997.
	[4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC		[3] Thaler, D., Handley, M. and D. Estrin, "The Internet Multicast
	2279, January 1998.		Address Allocation Architecture", Work in Progress.
	[5] Fenner, W., and S. Casner, "A ''traceroute'' facility for IP		[4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
	Multicast", Work in Progress, November 1997.		2279, January 1998.
	[6] Alvestrand, H., "Tags for the Identification of Languages", RFC		[5] Fenner, W. and S. Casner, "A `traceroute' facility for IP
	1766, March 1995.		Multicast", Work in Progress.
	[7] Handley, M., and S. Hanna. "Multicast Address Allocation Protocol		[6] Alvestrand, H., "Tags for the Identification of Languages", RFC
	(AAP)", Work in Progress, October 1999.		1766, March 1995.
	Draft MZAP October 1999		[7] Handley, M. and S. Hanna. "Multicast Address Allocation
			Protocol (AAP)", Work in Progress.
	[8] Kermode, R. "Scoped Hybrid Automatic Repeat reQuest with Forward		[8] Kermode, R. "Scoped Hybrid Automatic Repeat reQuest with Forward
	Error Correction (SHARQFEC)", ACM SIGCOMM 98, September 1998,		Error Correction (SHARQFEC)", ACM SIGCOMM 98, September 1998,
	Vancouver, Canada.		Vancouver, Canada.
	[9] Patel, B., Shah, M., and S. Hanna. "Multicast Address Dynamic		[9] Hanna, S., Patel, B., and M. Shah. "Multicast Address Dynamic
	Client Allocation Protocol (MADCAP)", Work in progress, May 1999.		Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
	[10] J. Postel, "Assigned Numbers", RFC 1700, STD 2, October 1994.		[10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
			October 1994.
	[11] IANA, "Address Family Numbers", http://www.isi.edu/in-		[11] IANA, "Address Family Numbers", http://www.isi.edu/in-
	notes/iana/assignments/address-family-numbers		notes/iana/assignments/address-family-numbers
	[12] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402,		[12] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
	November 1998.		November 1998.
	11. Authors' Addresses		11. Authors' Addresses
	Mark Handley		Mark Handley
	AT&T Center for Internet Research at ICSI		AT&T Center for Internet Research at ICSI
	1947 Center St, Suite 600		1947 Center St, Suite 600
	Berkely, CA 94704		Berkely, CA 94704
	USA		USA
	Email: mjh@aciri.org
	David Thaler		EMail: mjh@aciri.org
	Microsoft
	One Microsoft Way
	Redmond, WA 98052
	USA
	Email: dthaler@microsoft.com
	Roger Kermode		David Thaler
	Motorola Australian Research Centre		Microsoft
	12 Lord St,		One Microsoft Way
	Botany, NSW 2019		Redmond, WA 98052
	Australia		USA
	Email: Roger_Kermode@email.mot.com
	12. Full Copyright Statement		EMail: dthaler@microsoft.com
	Copyright (C) The Internet Society (1999). All Rights Reserved.		Roger Kermode
			Motorola Australian Research Centre
			12 Lord St,
			Botany, NSW 2019
			Australia
	Draft MZAP October 1999		EMail: Roger.Kermode@motorola.com
	This document and translations of it may be copied and furnished to		12. Full Copyright Statement
	others, and derivative works that comment on or otherwise explain it or
	assist in its implementation may be prepared, copied, published and
	distributed, in whole or in part, without restriction of any kind,
	provided that the above copyright notice and this paragraph are included
	on all such copies and derivative works. However, this document itself
	may not be modified in any way, such as by removing the copyright notice
	or references to the Internet Society or other Internet organizations,
	except as needed for the purpose of developing Internet standards in
	which case the procedures for copyrights defined in the Internet
	languages other than English.
	The limited permissions granted above are perpetual and will not be		Copyright (C) The Internet Society (2000). All Rights Reserved.
	revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an "AS		This document and translations of it may be copied and furnished to
	IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK		others, and derivative works that comment on or otherwise explain it
	FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT		or assist in its implementation may be prepared, copied, published
	LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT		and distributed, in whole or in part, without restriction of any
	INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR		kind, provided that the above copyright notice and this paragraph are
	FITNESS FOR A PARTICULAR PURPOSE.		included on all such copies and derivative works. However, this
			document itself may not be modified in any way, such as by removing
			the copyright notice or references to the Internet Society or other
			Internet organizations, except as needed for the purpose of
			developing Internet standards in which case the procedures for
			copyrights defined in the Internet Standards process must be
			followed, or as required to translate it into languages other than
			English.
	Table of Contents		The limited permissions granted above are perpetual and will not be
			revoked by the Internet Society or its successors or assigns.
	1 Introduction .................................................... 2		This document and the information contained herein is provided on an
	2 Terminology ..................................................... 4		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	3 Overview ........................................................ 5		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	3.1 Scope Nesting ................................................. 6		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	3.2 Other Messages ................................................ 7		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	3.3 Zone IDs ...................................................... 7		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	4 Detecting Router Misconfigurations .............................. 8
	4.1 Detecting non-convex scope zones .............................. 8
	4.2 Detecting leaky boundaries for non-local scopes ............... 9
	4.3 Detecting a leaky Local Scope zone ............................ 10
	4.4 Detecting conflicting scope zones ............................. 11
	5 Packet Formats .................................................. 11
	5.1 Zone Announcement Message ..................................... 14
	5.2 Zone Limit Exceeded (ZLE) ..................................... 16
	5.3 Zone Convexity Message ........................................ 16
	5.4 Not-Inside Message ............................................ 17
	6 Message Processing Rules ........................................ 18
	6.1 Internal entities listening to MZAP messages .................. 18
	6.2 Sending ZAMs .................................................. 19
	Draft MZAP October 1999		Acknowledgement
	6.3 Receiving ZAMs ................................................ 19		Funding for the RFC Editor function is currently provided by the
	6.4 Sending ZLEs .................................................. 21		Internet Society.
	6.5 Receiving ZLEs ................................................ 22
	6.6 Sending ZCMs .................................................. 22
	6.7 Receiving ZCMs ................................................ 22
	6.8 Sending NIMs .................................................. 23
	6.9 Receiving NIMs ................................................ 23
	7 Constants ....................................................... 24
	8 Security Considerations ......................................... 25
	9 Acknowledgements ................................................ 26
	10 References ..................................................... 26
	11 Authors' Addresses ............................................. 27
	12 Full Copyright Statement ....................................... 27
End of changes. 218 change blocks.
	895 lines changed or deleted		866 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/