draft-ietf-mboned-mzap-02.txt		draft-ietf-mboned-mzap-03.txt
	MBoneD Working Group Mark Handley		MBoneD Working Group Mark Handley
	Internet Engineering Task Force ISI		Internet Engineering Task Force ISI
	INTERNET-DRAFT Dave Thaler		INTERNET-DRAFT Dave Thaler
	7 October 1998 Microsoft		17 February 1999 Microsoft
	Expires April 1999		Expires August 1999 Roger Kermode
			Motorola
	Multicast-Scope Zone Announcement Protocol (MZAP)		Multicast-Scope Zone Announcement Protocol (MZAP)
	<draft-ietf-mboned-mzap-02.txt>		<draft-ietf-mboned-mzap-03.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet Draft. Internet Drafts are working		This document is an Internet-Draft and is in full conformance with all
	documents of the Internet Engineering Task Force (IETF), its Areas, and		provisions of Section 10 of RFC2026.
	its Working Groups. Note that other groups may also distribute working
	documents as Internet Drafts.		Internet-Drafts are working documents of the Internet Engineering Task
			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		Internet Drafts are valid for a maximum of six months and may be
	updated, replaced, or obsoleted by other documents at any time. It is		updated, replaced, or obsoleted by other documents at any time. It is
	inappropriate to use Internet Drafts as reference material or to cite		inappropriate to use Internet Drafts as reference material or to cite
	them other than as a "work in progress".		them other than as a "work in progress".
			To view the list Internet-Draft Shadow Directories, see
			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 Announcement
	Protocol (MZAP), for discovering the multicast administrative scope		Protocol (MZAP), for discovering the multicast administrative scope
	zones that are relevant at a particular location. MZAP also provides		zones that are relevant at a particular location. MZAP also provides
	mechanisms whereby two common misconfigurations of administrative scope		mechanisms whereby two common misconfigurations of administrative scope
	zones can be discovered.		zones can be discovered.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (1998). All Rights Reserved.		Copyright (C) The Internet Society (1999). All Rights Reserved.
	Draft MZAP October 1998		Draft MZAP February 1998
	1. Introduction		1. Introduction
	IP Multicast groups can be of global scope, or they can be restricted in		IP Multicast groups can be of global scope, or they can be restricted in
	scope using a scoping mechanism. In this document, we only consider		scope using a scoping mechanism. In this document, we only consider
	administrative scoping, as defined in RFC 2365 [1]. An administrative		administrative scoping, as defined in RFC 2365 [1]. An administrative
	scope zone is defined by a set of routers surrounding a region of the		scope zone is defined by a set of routers surrounding a region of the
	network. These "border routers" are configured to not pass multicast		network. These "border routers" are configured to not pass multicast
	traffic destined for a particular range of multicast addresses to or		traffic destined for a particular range of multicast addresses to or
	from links leaving the scope zone.		from links leaving the scope zone.
	skipping to change at page 2, line ?		skipping to change at page 2, line ?
	Two problems make administrative scoping difficult to deploy and		Two problems make administrative scoping difficult to deploy and
	difficult to use:		difficult to use:
	o Misconfiguration is easy. It is difficult to detect scope zones that		o Misconfiguration is easy. It is difficult to detect scope zones that
	have been configured so as to not be convex (the shortest path		have been configured so as to not be convex (the shortest path
	between two nodes within the zone passes outside the zone), or to		between two nodes within the zone passes outside the zone), or to
	leak (one or more border routers were not configured correctly), or		leak (one or more border routers were not configured correctly), or
	to intersect in both area and address range.		to intersect in both area and address range.
	o Applications have no way to discover the scope zones that are		o Applications have no way to discover the scope zones that are
	relevant to them. This makes it difficult to use admin scope zones,		relevant to them. This makes it difficult to use administrative
	and hence reduces the incentive to deploy them.		scope zones, and hence reduces the incentive to deploy them.
	This document defines the Multicast Scope Zone Announcement Protocol
	Draft MZAP October 1998		Draft MZAP February 1998
			This document defines the Multicast Scope Zone Announcement Protocol
	(MZAP) which will provide applications with information about the scope		(MZAP) which will provide applications with information about the scope
	zones they are within, and also provide diagnostic information to detect		zones they are within, and also provide diagnostic information to detect
	misconfigured scope zones.		misconfigured scope zones.
	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 5.		summarized in section 5.
	2. Overview		2. Overview
	A multicast scope Zone Border Router (ZBR) is a router that is		A multicast scope Zone Border Router (ZBR) is a router that is
	configured to be a zone border on one or more of its interfaces. Any		configured to be a zone border on one or more of its interfaces. Any
	interface that is configured to be a border for any admin scope zone		interface that is configured to be a border for any administrative scope
	MUST also be a border for the Local Scope zone, as defined in [1].		zone MUST also be a border for the Local Scope zone, as defined in [1].
	Routers SHOULD be configured so that the router itself is within the		Routers SHOULD be configured so that the router itself is within the
	scope zone. This is should in figure 1(a), where router A is inside the		scope zone. This is should in figure 1(a), where router A is inside the
	scope zone and has the border configuration. It is possible for the		scope zone and has the border configuration. It is possible for the
	first router outside the scope zone to be configured with the border, as		first router outside the scope zone to be configured with the border, as
	illustrated in figure 1(b) where routers B and C are outside the zone		illustrated in figure 1(b) where routers B and C are outside the zone
	and have the border configuration, but this is NOT RECOMMENDED.		and have the border configuration, but this is NOT RECOMMENDED.
	............ ................		............ ................
	. . +B+--> . *B+-->		. . +B+--> . *B+-->
	skipping to change at page 3, line 46		skipping to change at page 3, line 47
	. <---+A*---+C+-> . <---+A+---*C+->		. <---+A*---+C+-> . <---+A+---*C+->
	. + . . + .		. + . . + .
	. / . . / .		. / . . / .
	. zone X <-- . . zone X <-- .		. zone X <-- . . zone X <-- .
	.............. ..................		.............. ..................
	A,B,C - routers * - border interface + - interface		A,B,C - routers * - border interface + - interface
	(a) Correct zone border (b) Incorrect zone border		(a) Correct zone border (b) Incorrect zone border
	Figure 1: Admin scope zone border placement		Figure 1: Administrative scope zone border placement
	This rule does not apply for Local Scope borders, but applies for all		This rule does not apply for Local Scope borders, but applies for all
	other admin scope border routers.		other administrative scope border routers.
	Draft MZAP October 1998		Draft MZAP February 1998
	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. It can		boundary is inside the scope zone and which side is outside it. It can
	also send messages into the scope zone, which it SHOULD NOT be able to		also send messages into the scope zone, which it SHOULD NOT be able to
	do if the router itself is considered outside the scope zone.		do if the router itself is considered outside the scope zone.
	Such a ZBR should then send periodic Zone Announcement Messages (ZAMs)		Such a ZBR should then send periodic Zone Announcement Messages (ZAMs)
	for the zone for which it is configured as a border from one of its		for the zone for which it is configured as a border from one of its
	interfaces that go into that scope zone. These messages are multicast		interfaces that go into that scope zone. These messages are multicast
	to the address [MZAP-LOCAL-GROUP] in the Local Scope.		to the address [MZAP-LOCAL-GROUP] in the Local Scope.
	skipping to change at page 5, line 5		skipping to change at page 5, line 5
	not already in the ZAM's path list, then the ZAM is immediately re-		not already in the ZAM's path list, then the ZAM is immediately re-
	originated within the Local Scope zone. It adds its own address and		originated within the Local Scope zone. It adds its own address and
	the zone-id of the Local Scope zone into which the message is being		the zone-id of the Local Scope zone into which the message is being
	forwarded to the ZAM path list before doing so. A ZBR receiving a ZAM		forwarded to the ZAM path list before doing so. A ZBR receiving a ZAM
	with a non-null path list MUST NOT forward that ZAM back into a Local		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		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		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		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.		list has { (E,1), (A,2), (B,3) } and hence Zone 2 already appears.
	Draft MZAP October 1998		Draft MZAP February 1998
	o In addition, the ZBR re-originates the ZAM out each interface with a		o 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		Local Scope boundary (except that it is not sent back out the
	interface over which it was received, nor is it sent into any local		interface over which it was received, nor is it sent into any local
	scope zone whose ID is known and appears in the path list). In each		scope zone whose ID is known and appears in the path list). In each
	such ZAM re-originated, the ZBR adds its own IP address to the path		such ZAM re-originated, the ZBR adds its own IP address to the path
	list, as well as the Zone ID Address of the Local Scope Zone into		list, as well as the Zone ID Address of the Local Scope Zone into
	which the ZAM is being sent, or 0 if the ID is unknown. (For example,		which the ZAM is being sent, or 0 if the ID is unknown. (For example,
	if the other end of a point-to-point link also has a boundary on the		if the other end of a point-to-point link also has a boundary on the
	interface, then the link has no Local Scope Zone ID.)		interface, then the link has no Local Scope Zone ID.)
	###########################		###########################
	# Zone1 = Zone2 # ##### = large scope zone border		# Zone1 = Zone2 # ##### = large scope zone border
	*E-----+--->A*-----+-x #		*E-----+--->A*-----+-x #
	# | = v # ===== = Local Scope boundaries		# | = v # ===== = Local Scope boundaries
	# | ======*===*==#		# | ======*===*==#
	# | = B F # ----> = path of ZAM origined by E		# | = B F # ----> = path of ZAM originated by E
	# +--->C*-> | ^ #		# +--->C*-> | ^ #
	# v = <-+---+ # ABCDE = ZBRs		# v = <-+---+ # ABCDE = ZBRs
	# D = Zone3 #		# D = Zone3 #
	#######*################### * = border interface		#######*################### * = border interface
	Figure 2: ZAM Flooding Example		Figure 2: ZAM Flooding Example
	The packet also contains a Zones Traveled Limit. If the number of Local		The packet also contains a Zones Traveled Limit. If the number of Local
	Zone IDs in the ZAM path becomes equal to the Zones Traveled Limit, the		Zone IDs in the ZAM path becomes equal to the Zones Traveled Limit, the
	packet should be dropped. Zones Traveled Limit is set when the packet is		packet should be dropped. Zones Traveled Limit is set when the packet is
	first sent, and defaults to 32, but can be set to a lower value if a		first sent, and defaults to 32, but can be set to a lower value if a
	network administrator knows the expected size of the zone.		network administrator knows the expected size of the zone.
	Additional messages called Zone Convexity Messages (ZCMs) SHOULD also be		Additional messages called Zone Convexity Messages (ZCMs) SHOULD also be
	sent to the [ZCM-RELATIVE-GROUP] in the scoped range itself. As these		sent to the [ZCM-RELATIVE-GROUP] in the scoped range itself. As these
	are not locally scoped packets, they are simply multicast across the		are not locally scoped packets, they are simply multicast across the
	scope zone itself, and require no path to be built up, nor any special		scope zone itself, and require no path to be built up, nor any special
	processing by Local Scope zone ZBRs. These messages are used to detect		processing by Local Scope zone ZBRs. These messages are used to detect
	non-convex admin scope zones, as illustrated in figure 3, where the path		non-convex administrative scope zones, as illustrated in figure 3, where
	between B and D goes outside the scope (through A and E). Here Router B		the path between B and D goes outside the scope (through A and E). Here
	and Router C originates ZCMs, each reporting each other's presence.		Router B and Router C originates ZCMs, each reporting each other's
	Router D cannot see Router B's messages, but can see C's report of B,		presence. Router D cannot see Router B's messages, but can see C's
	and so can conclude the zone is not convex.		report of B, and so can conclude the zone is not convex.
	Draft MZAP October 1998		Draft MZAP February 1998
	#####*####========		#####*####========
	# B # = ##### = non-convex scope boundary		# B # = ##### = non-convex scope boundary
	# |->A* =		# |->A* =
	# | # = ===== = other scope boundaries		# | # = ===== = other scope boundaries
	# | ####*####		# | ####*####
	# | E # ----> = path of B's ZAM		# | E # ----> = path of B's ZAM
	# v D*		# v D*
	# C # * = border interface		# C # * = border interface
	#####*############		#####*############
	Figure 3: Non-convexity detection		Figure 3: Non-convexity detection
			2.1. Nesting
			MZAP also provides the ability to discover the nesting relationships
			between scope zones. Two zones are nested if one is comprised of a
			subset of the routers in the other, as shown in Figure 4.
			+-----------+ +-----------+ +-------------+
			| 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 4: Zone nesting examples
			Nested scopes provide the ability 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].
			A ZBR cannot independently determine whether one zone is nested inside
			another. However, they can determine that one zone does NOT nest inside
			another. For example, in figure 4:
			Draft MZAP February 1998
			o ZBR A will pass ZAMs for zone 1 but will prevent ZAMs from zone 2
			from leaving zone 2. ZBR A can thus determine 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
			if one is nested inside the other. However, ZBR C can determine that
			zone 3 does not nest inside zone 4 since it is a ZBR for zone 4 and
			not zone 3.
			o ZBR D only acts as ZBR zone 6 and not 5, hence ZBR D can deduce that
			zone 6 does not nest inside zone 5. Similarly, ZBR E only acts as
			ZBR zone 5 and not 6, hence ZBR E can deduce that zone 5 does not
			nest inside zone 6.
			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
			nesting must be determined in a distributed fashion.
			When a ZBR receives a ZAM for a scope X for which it is NOT a border, it
			creates a local "X not inside" state entry, if such an entry does not
			already exist. It 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 border. If the entry's timer
			expires (because no more ZAMs for X are heard for [ZAM-HOLDTIME]), the
			entry is deleted.
			Periodically, at an interval of [NIM-INTERVAL], a router originates a
			Not-Inside Message (NIM) for each "X not inside" entry, for each scope
			zone Y for which it is a border. Like a ZAM, this message is multicast
			to the address [MZAP-LOCAL-GROUP] from one of its interfaces in Y.
			When a ZBR receives a NIM saying that "X is not inside Y", it is
			forwarded, unmodified, in a manner similar to ZAMs:
			o If the NIM was received on an interface with a boundary for either X
			or Y, the NIM is discarded.
			o Unlike ZAMs, if the NIM was not received on the interface towards the
			message origin (according to the Multicast RIB), the NIM is
			discarded.
			o 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] seconds,
			the NIM is not forwarded.
			Draft MZAP February 1998
			o Otherwise, the NIM is cached for at least [ZAM-DUP-TIME] seconds.
			o The ZBR then re-originates the NIM (unchanged) into each local scope
			zone in which it has interfaces, 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 with a boundary for either X or Y.
	3. Usage		3. Usage
	In this section, we summarize how to inform internal entities of scopes		In this section, we summarize how to inform internal entities of scopes
	in which they reside, as well as how to detect various error conditions.		in which they reside, as well as how to detect various error conditions.
	If any error is detected, the router should attempt to alert a network		If 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.
	3.1. Zone IDs		3.1. Zone IDs
	When a border router first starts up, it uses its lowest IP address		When a border router first starts up, it uses its lowest IP address
	which it considers to be inside a given zone as the Zone ID for that		which it considers to be inside a given zone as the Zone ID for that
	zone, and schedules the ZCM and ZAM messages to be sent in the future		zone, and schedules the ZCM and ZAM messages to be sent in the future
	(it does not send them immedately). When a ZAM or ZCM is received for		(it does not send them immediately). When a ZAM or ZCM is received for
	the given scope, the sender is added to the local list of ZBRs		the given scope, the sender is added to the local list of ZBRs
	(including itself) for that scope, and the Zone ID is updated to be the		(including itself) for that scope, and the Zone ID is updated to be the
	lowest IP address in the list. Entries in the list are eventually timed		lowest IP address in the list. Entries in the list are eventually timed
	out if no further messages are received from that ZBR, such that the		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		Zone ID will converge to the lowest address of any active ZBR for the
	scope.		scope.
	3.2. Informing internal entities of scopes		3.2. Informing internal entities of scopes
	Any host or application may listen to Zone Announcement Messages to		Any host or application may join the [MZAP-LOCAL-GROUP] to listen for
	build up a list of the scope zones that are relevant locally. However,		Zone Announcement Messages to build up a list of the scope zones that
	listening to Zone Announcement Messages is not the recommended method		are relevant locally, and for Not-Inside Messages if it wishes to learn
	for regular applications to discover this information. These		nesting information. However, listening for to such messages is not the
	applications will normally query a local Multicast Address Allocation		recommended method for regular applications to discover this
	Server [3], which in turn listens to Zone Announcement Messages to		information. These applications will normally query a local Multicast
			Address Allocation Server [3], which in turn listens to Zone
			Announcement Messages and Not-Inside Messages to maintain scope
			information.
	Draft MZAP October 1998		Draft MZAP February 1998
	maintain a list of scopes.		An internal entity may assume that X nests within Y if:
			a) it first heard ZAMs for both X and Y at least [NIM-HOLDTIME]
			seconds ago, AND
			b) it has not heard a NIM indicating that "X not inside Y" for at
			least [NIM-HOLDTIME] seconds.
	3.3. Detecting non-convex scope zones		3.3. Detecting non-convex scope zones
	Non-convex scope zones can be detected via two methods:		Non-convex scope zones can be detected via two 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, or		scope zone, or
	(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
	skipping to change at page 7, line 31		skipping to change at page 9, line 37
	configured ordinary hosts within a scope region, which may be a useful		configured ordinary hosts within a scope region, which may be a useful
	diagnostic facility that does not require privileged access.		diagnostic facility that does not require privileged access.
	3.4. Detecting leaky boundaries for non-local scopes		3.4. Detecting leaky boundaries for non-local scopes
	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 back		message must have escaped the zone through a leak, and flooded back
	around behind the boundary. This is illustrated in figure 4.		around behind the boundary. This is illustrated in Figure 5.
	=============#####*########		=============#####*########
	= Zone1 # A Zone2 # C = misconfigured router		= Zone1 # A Zone2 # C = misconfigured router
	= +---->*E v #		= +---->*E v #
	= | # B # ##### = leaky scope boundary		= | # B # ##### = leaky scope boundary
	=======*=====#====*=======#		=======*=====#====*=======#
	= D # | # ===== = other scope boundaries		= D # | # ===== = other scope boundaries
	= ^-----*C<--+ #		= ^-----*C<--+ #
	= Zone4 # Zone3 # ----> = path of ZAMs		= Zone4 # Zone3 # ----> = path of ZAMs
	=============##############		=============##############
	Figure 4: ZAM Leaking		Figure 5: ZAM Leaking
			Draft MZAP February 1998
	(2) If a ZLE message is received.		(2) If a ZLE message is received.
	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 path list included in the message		origin, or one of the routers in the path list included in the message
	Draft MZAP October 1998
	received.		received.
	3.5. Detecting a leaky Local Scope zone		3.5. Detecting a leaky Local Scope zone
	A local scope is leaky if a router has an admin scope boundary on some		A local scope is leaky if a router has an administrative scope boundary
	interface, but does not have a Local Scope boundary on that interface as		on some interface, but does not have a Local Scope boundary on that
	specified in RFC 2365. This can be detected via the following method:		interface as specified in RFC 2365. This can be detected via the
			following method:
	o If a ZAM for a given scope is received by a ZBR which is a border for		o If a ZAM for a given scope is received by a ZBR which is a border for
	that scope, it compares the Origin's Scope Zone ID in the ZAM with		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		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		is evidence of a misconfiguration. Since a temporary mismatch may
	result immediately after a recent change in the reachability of the		result immediately after a recent change in the reachability of the
	lowest-addressed ZBR, misconfiguration should be assumed only if the		lowest-addressed ZBR, misconfiguration should be assumed only if the
	mismatch is persistent.		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]
	skipping to change at page 8, line 45		skipping to change at page 11, line 4
	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 non-empty scope name for a given scope,		o If a ZBR is configured with a non-empty scope name for a given scope,
	and it receives a ZAM with a non-empty scope name for the same scope,		and it receives a ZAM with a non-empty scope name for the same scope,
	and the scope names do not match.		and 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 local
	router or router originating the message is misconfigured.		router or 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 end
	of each name to avoid accidental misconfiguration.
	Draft MZAP October 1998		Draft MZAP February 1998
			of each name to avoid accidental misconfiguration.
	3.7. Packet Formats		3.7. 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 [MZAP-
	PORT]. The common MZAP message header (which follows the UDP header),		PORT]. The common MZAP message header (which follows the UDP header),
	is shown below:		is shown below:
	Draft MZAP October 1998
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Version |B| PTYPE |Address Family | NameCount |		| Version |B| PTYPE |Address Family | NameCount |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Origin |		| Message Origin |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Zone ID Address |		| Zone ID Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Zone Start Address |		| Zone Start Address |
	skipping to change at page 10, line 38		skipping to change at page 12, line 5
	Version:		Version:
	The version defined in this document is version 0.		The version defined in this document is version 0.
	"Big" scope bit (B):		"Big" scope bit (B):
	If clear, indicates that the addresses in the scoped range are not		If clear, indicates that the addresses in the scoped range are not
	subdividable, and that address allocators may utilize the entire		subdividable, and that address allocators may utilize the entire
	range. If set, address allocators should not use the entire range,		range. If set, address allocators should not use the entire range,
	but should learn an appropriate sub-range via another mechanism		but should learn an appropriate sub-range via another mechanism
	(e.g., AAP [7]).		(e.g., AAP [7]).
			Draft MZAP February 1998
	Packet Type (PTYPE):		Packet Type (PTYPE):
	The packet types defined in this document are:		The packet types defined in this document are:
	0: Zone Announcement Message (ZAM)		0: Zone Announcement Message (ZAM)
	1: Zone Limit Exceeded (ZLE)		1: Zone Limit Exceeded (ZLE)
	2: Zone Convexity Message (ZCM)		2: Zone Convexity Message (ZCM)
			3: Not-Inside Message (NIM)
	Address Family:		Address Family:
	The IANA-assigned address family number identifying the address		The IANA-assigned address family number identifying the address
	family for all addresses in the packet. The families defined for IP		family for all addresses in the packet. The families defined for IP
	are:		are:
	1: IPv4		1: IPv4
	2: IPv6		2: IPv6
	Name Count:		Name Count:
	Draft MZAP October 1998
	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 may
	be zero.		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 border. For example,		This gives the start address for the scope zone border. For example,
	if the zone is a border for 239.1.0.0 to 239.1.0.255, then Zone Start		if the zone is a border for 239.1.0.0 to 239.1.0.255, then Zone Start
	Address is 239.1.0.0.		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 border. For		This gives the ending address for the scope zone border. For
	skipping to change at page 11, line 31		skipping to change at page 13, line 5
	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 been
	observed in the zone originating the message. Together with Zone		observed in the zone originating the message. Together with Zone
	Start Address and Zone End Address, it forms a unique ID for the		Start Address and Zone End Address, it forms a unique ID for the
	zone. Note that this ID is NOT the ID of the Local Scope zone in		zone. Note that this ID is NOT the ID of the Local Scope zone in
	which the origin resides.		which the origin resides.
			Draft MZAP February 1998
	Encoded Zone Name:		Encoded Zone Name:
	+--------------------+		+--------------------+
	|D| LangLen (7 bits) |		|D| Reserved (7 bits)|
			+--------------------+
			| 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 other bits are reserved (sent as 0, ignored on receipt).
	"Default Language" (D) bit:		"Default Language" (D) bit:
	If set, indicates a preference that the name in the following language		If set, indicates a preference that the name in the following
	should be used if no name is available in a desired language.		language should be used if no name is available in a desired
			language.
	Language tag length (LangLen): 7 bits		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 zone name.		The language tag, such as "en-US", indicating the language of the
	Language tags are described in [6].		zone name. Language tags are described in [6].
	Draft MZAP October 1998
	Name Len:		Name Len:
	The length, in bytes, of the Zone Name field.		The length, in bytes, of the Zone Name field. The length MUST NOT be
	The length MUST NOT be zero.		zero.
	Zone Name: multiple of 8 bits		Zone Name: multiple of 8 bits
	The Zone Name is an ISO 10646		The Zone Name is an ISO 10646 character string in UTF-8 encoding [4]
	character string in UTF-8 encoding [4] indicating the name given to the		indicating the name given to the scope zone (eg: ``ISI-West Site'').
	scope zone (eg: ``ISI-West Site''). It should be relatively short and		It should be relatively short and MUST be less than 256 bytes in
	MUST be less than 256 bytes in length. All the border routers to the		length. White space SHOULD be stripped from the beginning and end of
	same region SHOULD be configured to give the same Zone Name, or a zero		each name before encoding, to avoid accidental conflicts. All the
	length string MAY be given. A zero length string is taken to mean		border routers to the same region SHOULD be configured to give the
	that another router is expected to be configured with the zone name.		same Zone Name, or a zero length string MAY be given. A zero length
	Having ALL the ZBRs for a scope zone announce zero length names		string is taken to mean that another router is expected to be
	should be considered an error.		configured with the zone name. Having ALL the ZBRs for a scope zone
			announce zero length names should be considered an error.
	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-
	4-byte aligned.
			Draft MZAP February 1998
			byte aligned.
			Draft MZAP February 1998
	3.7.1. Zone Announcement Message		3.7.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 a
	ZBR for each scope for which it is a border, EXCEPT:		ZBR for each scope for which it is a border, EXCEPT:
	o the Global Scope		o the Global Scope
	o the Local Scope		o the Local Scope
	o the Link-local scope		o the Link-local scope
	The format of a Zone Announcement Message is shown below:		The format of a Zone Announcement Message is shown below:
	Draft MZAP October 1998
	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 |
	skipping to change at page 13, line 39		skipping to change at page 16, line 5
	The fields are defined as follows:		The fields are defined as follows:
	Zones Traveled (ZT): 8 bits		Zones Traveled (ZT): 8 bits
	This gives the number of Local Zone IDs contained in this message		This gives the number of Local Zone IDs contained in this message
	path.		path.
	Zones Traveled Limit (ZTL): 8 bits		Zones Traveled Limit (ZTL): 8 bits
	This gives the limit on number of local zones that the packet can		This gives the limit on number of local zones that the packet can
	traverse before it MUST be dropped. A value of 0 indicates that no		traverse before it MUST be dropped. A value of 0 indicates that no
	limit exists.		limit exists.
			Draft MZAP February 1998
	Hold Time:		Hold Time:
	The time, in seconds, after which the receiver may assume the scope		The time, in seconds, after which the receiver may assume the scope
	no longer exists, if no subsequent ZAM is received. This should be		no longer exists, if no subsequent ZAM is received. This should be
	set to [ZAM-HOLDTIME].		set to [ZAM-HOLDTIME].
	Zone Path: multiple of 64 bits (IPv4) or 256 bits (IPv6)		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		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		Address of a local zone) through which the ZAM has passed, and IP
	addresses of the router that forwarded the packet. The origin router		addresses of the router that forwarded the packet. The origin router
	fills in the "Local Zone ID Address 0" field when sending the ZAM.		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		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		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		the packet of the zone into which the message is being forwarded, and
	Draft MZAP October 1998
	its own IP address to the end of this list, and increment ZT		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.		accordingly. The zone path is empty which the ZAM is first sent.
	Authentication Block:		Authentication Block:
	If present, this provides information which can be used to		If present, this provides information which can be used to
	authenticate the sender of the ZAM (i.e. Router Address N, if ZT is		authenticate the sender of the ZAM (i.e. Router Address N, if ZT is
	non-zero, or Message Origin, if ZT is zero). (TBD: any reason not to		non-zero, or Message Origin, if ZT is zero). (TBD: any reason not to
	re-use SAP's "Authentication Header" here?)		re-use SAP's "Authentication Header" here?)
	3.7.2. Zone Limit Exceeded (ZLE)		3.7.2. Zone Limit Exceeded (ZLE)
	skipping to change at page 14, line 37		skipping to change at page 17, line 4
	and the ZLE is not sent. If the timer expires, the router sends a ZLE		and the ZLE is not sent. If the timer expires, the router sends a ZLE
	to the [MZAP-RELATIVE-GROUP] within the indicated scope.		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]		Choose a random value X from the uniform random interval [0:1]
	Let C = 256		Let C = 256
	Set T = [ZLE-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C)		Set T = [ZLE-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C)
	This method ensures that close to one ZBR will respond.		This method ensures that close to one ZBR will respond.
	The format of a ZLE is shown below:		The format of a ZLE is shown below:
			Draft MZAP February 1998
	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 | unused |		| ZT | ZTL | unused |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	.....		.....
	Draft MZAP October 1998
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 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.
	A router receiving ZLE messages SHOULD log them and attempt to alert the		A router receiving ZLE messages SHOULD log them and attempt to alert the
	network administrator that the scope zone is misconfigured.		network administrator that the scope zone is misconfigured.
	skipping to change at page 15, line 31		skipping to change at page 18, line 4
	ZBR for each scope for which it is a border, EXCEPT:		ZBR for each scope for which it is a border, EXCEPT:
	o the Global Scope		o the Global Scope
	o the Link-local scope		o the Link-local scope
	(Note that ZCM's ARE sent in the 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] in
	the scope zone itself. The format of a ZCM is shown below:		the scope zone itself. The format of a ZCM is shown below:
			Draft MZAP February 1998
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ZNUM | unused | Hold Time |		| ZNUM | unused | Hold Time |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ZBR Address 1 |		| ZBR Address 1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	.....		.....
	skipping to change at page 15, line 49		skipping to change at page 18, line 25
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	.....		.....
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ZBR Address N |		| ZBR Address N |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The fields are as follows:		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 may assume the sender
	Draft MZAP October 1998
	is no longer reachable, if no subsequent ZCM is received. This		is no longer reachable, if no subsequent ZCM is received. This
	should be set to [ZCM-HOLDTIME].		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 in
	the packet, preferring those which it has not included recently if		the packet, preferring those which it has not included recently if
	all do not fit.		all do not fit.
			3.7.4. Not-Inside Message
			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
			not inside Y"):
			The format of a Not Inside Message is shown below:
			Draft MZAP February 1998
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Not-Inside Zone Start Address |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Authentication Block (optional) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			The fields are as follows:
			MZAP Header:
			Header fields identifying the scope X. The Name Count may be 0.
			Not-Inside Zone Start Address: 32 bits (IPv4) or 128 bits (IPv6)
			This gives the start address for the scope Y.
			Authentication Block:
			If present, this provides information which can be used to
			authenticate the sender of the NIM (i.e. Message Origin in the MZAP
			Header).
	4. Message Timing		4. Message Timing
	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 for
	which it is a boundary every [ZAM-INTERVAL] seconds, +/- 30% of [ZAM-		which it is a boundary every [ZAM-INTERVAL] seconds, +/- 30% of [ZAM-
	INTERVAL] each time to avoid message synchronisation.		INTERVAL] each time to avoid message synchronisation.
	Each ZBR should send a Zone Convexity Message for each scope zone for		Each ZBR should send a Zone Convexity Message for each scope zone for
	which it is a boundary every [ZCM-INTERVAL] seconds, +/- 30% of [ZCM-		which it is a boundary every [ZCM-INTERVAL] seconds, +/- 30% of [ZCM-
	INTERVAL] each time to avoid message synchronisation.		INTERVAL] each time to avoid message synchronisation.
	A router SHOULD NOT send more than one Zone Limit Exceeded message every		A router SHOULD NOT send more than one Zone Limit Exceeded message every
	[ZLE-MIN-INTERVAL] regardless of destination.		[ZLE-MIN-INTERVAL] regardless of destination.
			Each ZBR should send a Zone State Session Message for each scope zone
			for which it is a boundary every [ZNSM-INTERVAL] seconds, +/- 30% of
			[ZNSM- INTERVAL] each time to avoid message synchronization.
	5. Constants		5. 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: TBD by IANA.		sent. Value: TBD by IANA.
			Draft MZAP February 1998
	[MZAP-LOCAL-GROUP]: The well-known group in the Local Scope to which		[MZAP-LOCAL-GROUP]: The well-known group in the Local Scope to which
	ZAMs are sent. All Multicast Address Allocation servers and Zone Border		ZAMs are sent. All Multicast Address Allocation servers and Zone Border
	Routers listen to this group. Value: TBD by IANA.		Routers listen to this group. Value: TBD by IANA.
	[ZCM-RELATIVE-GROUP]: The relative group in each scope zone, to which		[ZCM-RELATIVE-GROUP]: The relative group in each scope zone, to which
	ZCMs are sent. A Zone Border Router listens to the relative group in		ZCMs are sent. A Zone Border Router listens to the relative group in
	each scope for which it is a border. Value: TBD by IANA.		each scope for which it is a border. Value: TBD by IANA.
	[ZAM-INTERVAL]: The interval at which a Zone Border Router originates		[ZAM-INTERVAL]: The interval at which a Zone Border Router originates
	Zone Announcement Messages. Default value: 600 seconds (10 minutes).		Zone Announcement Messages. Default value: 600 seconds (10 minutes).
	[ZAM-HOLDTIME]: The holdtime to include in a ZAM. This SHOULD be set		[ZAM-HOLDTIME]: The holdtime to include in a ZAM. This SHOULD be set
	to at least 3 * [ZAM-INTERVAL]. Default value: 1860 seconds (31		to at least 3 * [ZAM-INTERVAL]. Default value: 1860 seconds (31
	minutes).		minutes).
	Draft MZAP October 1998
	[ZAM-DUP-TIME]: The time interval after forwarding a ZAM, during which		[ZAM-DUP-TIME]: The time interval after forwarding a ZAM, during which
	ZAMs for the same scope will not be forwarded. Default value: 30		ZAMs for the same scope will not be forwarded. Default value: 30
	seconds.		seconds.
	[ZCM-INTERVAL]: The interval at which a Zone Border Router originates		[ZCM-INTERVAL]: The interval at which a Zone Border Router originates
	Zone Convexity Messages. Default value: 600 seconds (10 minutes).		Zone Convexity Messages. Default value: 600 seconds (10 minutes).
	[ZCM-HOLDTIME]: The holdtime to include in a ZCM. This SHOULD be set		[ZCM-HOLDTIME]: The holdtime to include in a ZCM. This SHOULD be set
	to at least 3 * [ZCM-INTERVAL]. Default value: 1860 seconds (31		to at least 3 * [ZCM-INTERVAL]. Default value: 1860 seconds (31
	minutes).		minutes).
	[ZLE-SUPPRESSION-INTERVAL]: The interval over which to choose a random		[ZLE-SUPPRESSION-INTERVAL]: The interval over which to choose a random
	delay before sending a ZLE message. Default value: 300 seconds (5		delay before sending a ZLE message. Default value: 300 seconds (5
	minutes).		minutes).
	[ZLE-MIN-INTERVAL]: The minimum interval between sending ZLE messages,		[ZLE-MIN-INTERVAL]: The minimum interval between sending ZLE messages,
	regardless of destination. Default value: 300 seconds (5 minutes).		regardless of destination. Default value: 300 seconds (5 minutes).
			[NIM-INTERVAL]: The interval at which a Zone Border Router originates
			Zone Not Inside Messages. Default value is 1800 seconds (30 minutes)
			[NIM-HOLDTIME]: The holdtime to include the state within a NIM. This
			SHOULD be set to at least 3 * [NIM-INTERVAL]. Default value: 5460 (91
			minutes)
	6. Security Considerations		6. Security Considerations
	MZAP does not include authentication in its messages. Thus it is open		MZAP does not include authentication in its messages. Thus it is open
	to misbehaving hosts sending spoof ZAMs or ZCMs.		to misbehaving hosts sending spoof ZAMs, ZCMs, or NIMs.
			Draft MZAP February 1998
	In the case of ZCMs, these spoof messages can cause false logging of		In the case of ZCMs, these spoof messages can cause false logging of
	convexity problems. It is likely that is would be purely an annoyance,		convexity problems. It is likely that is would be purely an annoyance,
	and not cause any significant problem.		and not cause any significant problem.
	In the case of ZAMs, spoof messages can also cause false logging of		In the case of ZAMs, spoof messages can also cause false logging of
	configuration problems. This is also considered to not be a significant		configuration problems. This is also considered to not be a significant
	problem.		problem.
	Spoof zone announcements however might cause applications to believe		In the case of NIMs, spoof messages can also cause the false
			cancellation of nesting relationships. This would cause a section of the
			hierarchy of zones to flatten. Such a flattening would lessen the
			efficiency benefits afforded by the hierarchy but would not cause it to
			become unusable.
			Spoofed zone announcements however might cause applications to believe
	that a scope zone exists when it does not. If these were believed, then		that a scope zone exists when it does not. If these were believed, then
	applications may choose to use this non-existent admin scope zone for		applications may choose to use this non-existent administrative scope
	their uses. Such applications would be able to communicate		zone for their uses. Such applications would be able to communicate
	successfully, but would be unaware that their traffic may be traveling		successfully, but would be unaware that their traffic may be traveling
	further than they expected. As a result, applications MUST only take		further than they expected. As a result, applications MUST only take
	scope names as a guideline, and SHOULD assume that their traffic sent to		scope names as a guideline, and SHOULD assume that their traffic sent to
	non-local scope zones might travel anywhere. The confidentiality of		non-local scope zones might travel anywhere. The confidentiality of
	such traffic CANNOT be assumed from the fact that it was sent to a		such traffic CANNOT be assumed from the fact that it was sent to a
	scoped address that was discovered using MZAP.		scoped address that was discovered using MZAP.
	In addition, ZAMs are used to inform Multicast Address Allocation		In addition, ZAMs are used to inform Multicast Address Allocation
	Servers of names of scopes, and spoofed ZAMs would result in false names		Servers of names of scopes, and spoofed ZAMs would result in false names
	Draft MZAP October 1998
	being presented to users. To counter this, ZAMs may be authenticated as		being presented to users. To counter this, ZAMs may be authenticated as
	follows:		follows:
	(1) A ZBR signs all ZAMs it originates.		(1) A ZBR signs all ZAMs it originates.
	(2) A ZBR signs a ZAM it forwards if and only if it can authenticate		(2) A ZBR signs a ZAM it forwards 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
	autheticated ZAM even if an un-authenticated one was received with		authenticated ZAM even if an un-authenticated one was received with
	the last [ZAM-DUP-TIME] seconds.		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 has		unauthenticated ZAM if an authenticated one for the same scope has
	been received, and MAY ignore all unauthenticated ZAMs.		been received, and MAY ignore all unauthenticated ZAMs.
			Draft MZAP February 1998
	7. References		7. References
	[1] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July		[1] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July
	1998.		1998.
	[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", RFC 2119, March 1997.		Levels", RFC 2119, March 1997.
	[3] Handley, M., Thaler, D., and D. Estrin, "The Internet Multicast		[3] Handley, M., Thaler, D., and D. Estrin, "The Internet Multicast
	Address Allocation Architecture", Internet Draft, Dec 1997.		Address Allocation Architecture", Internet Draft, Dec 1997.
	skipping to change at page 19, line 5		skipping to change at page 22, line 31
	[5] Fenner, W., and S. Casner, "A ''traceroute'' facility for IP		[5] Fenner, W., and S. Casner, "A ''traceroute'' facility for IP
	Multicast", draft-ietf-idmr-traceroute-ipm-02.txt, Internet Draft,		Multicast", draft-ietf-idmr-traceroute-ipm-02.txt, Internet Draft,
	November 1997.		November 1997.
	[6] Alvestrand, H., "Tags for the Identification of Languages", RFC		[6] Alvestrand, H., "Tags for the Identification of Languages", RFC
	1766, March 1995.		1766, March 1995.
	[7] Handley, M., "Multicast Address Allocation Protocol (AAP)", draft-		[7] Handley, M., "Multicast Address Allocation Protocol (AAP)", draft-
	handley-aap-01.txt, Internet Draft, July 1998.		handley-aap-01.txt, Internet Draft, July 1998.
	Draft MZAP October 1998		[8] Kermode, R. "Scoped Hybrid Automatic Repeat reQuest with Forward
			Error Correction (SHARQFEC)", ACM SIGCOMM 98, September 1998,
			Vancouver, Canada.
	8. Full Copyright Statement		8. Acknowledgements
			This document is a product of the MBone Deployment Working Group, whose
			members provided many helpful comments and suggestions. The Multicast
			Address Allocation Working Group also provided useful feedback regarding
			scope names and interactions with applications.
			9. Authors' Addresses
			Mark Handley
			AT&T Center for Internet Research at ICSI
			1947 Center St, Suite 600
			Berkely, CA 94704
			USA
			Email: mjh@aciri.org
			Draft MZAP February 1998
			David Thaler
			Microsoft
			One Microsoft Way
			Redmond, WA 98052
			USA
			Email: dthaler@microsoft.com
			Roger Kermode
			Motorola Australian Research Centre
			12 Lord St,
			Botany, NSW 2109
			Australia
			Email: Roger_Kermode@email.mot.com
			10. Full Copyright Statement
	Copyright (C) The Internet Society (1998). All Rights Reserved.		Copyright (C) The Internet Society (1998). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it or		others, and derivative works that comment on or otherwise explain it or
	assist in its implmentation may be prepared, copied, published and		assist in its implementation may be prepared, copied, published and
	distributed, in whole or in part, without restriction of any kind,		distributed, in whole or in part, without restriction of any kind,
	provided that the above copyright notice and this paragraph are included		provided that the above copyright notice and this paragraph are included
	on all such copies and derivative works. However, this document itself		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		may not be modified in any way, such as by removing the copyright notice
	or references to the Internet Society or other Internet organizations,		or references to the Internet Society or other Internet organizations,
	except as needed for the purpose of developing Internet standards in		except as needed for the purpose of developing Internet standards in
	which case the procedures for copyrights defined in the Internet		which case the procedures for copyrights defined in the Internet
	languages other than English.		languages other than English.
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.		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 the information contained herein is provided on an "AS
	IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK		IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
	FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT		FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
	LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT		LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
	INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR		INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
	FITNESS FOR A PARTICULAR PURPOSE."		FITNESS FOR A PARTICULAR PURPOSE."
			Draft MZAP February 1998
	Table of Contents		Table of Contents
	1 Introduction .................................................... 2		1 Introduction .................................................... 2
	2 Overview ........................................................ 3		2 Overview ........................................................ 3
	3 Usage ........................................................... 6		2.1 Nesting ....................................................... 6
	3.1 Zone IDs ...................................................... 6		3 Usage ........................................................... 8
	3.2 Informing internal entities of scopes ......................... 6		3.1 Zone IDs ...................................................... 8
	3.3 Detecting non-convex scope zones .............................. 7		3.2 Informing internal entities of scopes ......................... 8
	3.4 Detecting leaky boundaries for non-local scopes ............... 7		3.3 Detecting non-convex scope zones .............................. 9
	3.5 Detecting a leaky Local Scope zone ............................ 8		3.4 Detecting leaky boundaries for non-local scopes ............... 9
	3.6 Detecting conflicting scope zones ............................. 8		3.5 Detecting a leaky Local Scope zone ............................ 10
	3.7 Packet Formats ................................................ 9		3.6 Detecting conflicting scope zones ............................. 10
	3.7.1 Zone Announcement Message ................................... 12		3.7 Packet Formats ................................................ 11
	3.7.2 Zone Limit Exceeded (ZLE) ................................... 14		3.7.1 Zone Announcement Message ................................... 15
	3.7.3 Zone Convexity Message ...................................... 15		3.7.2 Zone Limit Exceeded (ZLE) ................................... 16
	4 Message Timing .................................................. 16		3.7.3 Zone Convexity Message ...................................... 17
	5 Constants ....................................................... 16		3.7.4 Not-Inside Message .......................................... 18
			4 Message Timing .................................................. 19
	Draft MZAP October 1998		5 Constants ....................................................... 19
			6 Security Considerations ......................................... 20
	6 Security Considerations ......................................... 17		7 References ...................................................... 22
	7 References ...................................................... 18		8 Acknowledgements ................................................ 22
	8 Full Copyright Statement ........................................ 19		9 Authors' Addresses .............................................. 22
			10 Full Copyright Statement ....................................... 23
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/