draft-ietf-mboned-mzap-01.txt		draft-ietf-mboned-mzap-02.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
	3 August 1998 Microsoft		7 October 1998 Microsoft
	Expires February 1999		Expires April 1999
	Multicast-Scope Zone Announcement Protocol (MZAP)		Multicast-Scope Zone Announcement Protocol (MZAP)
	<draft-ietf-mboned-mzap-01.txt>		<draft-ietf-mboned-mzap-02.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. Internet Drafts are working
	documents of the Internet Engineering Task Force (IETF), its Areas, and		documents of the Internet Engineering Task Force (IETF), its Areas, and
	its Working Groups. Note that other groups may also distribute working		its Working Groups. Note that other groups may also distribute working
	documents as Internet Drafts.		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
	skipping to change at page 2, line ?		skipping to change at page 2, line ?
	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 (1998). All Rights Reserved.
	Draft MZAP August 1998		Draft MZAP October 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 3, line 5		skipping to change at page 3, line 5
	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 admin scope zones,
	and hence reduces the incentive to deploy them.		and hence reduces the incentive to deploy them.
	This document defines the Multicast Scope Zone Announcement Protocol		This document defines the Multicast Scope Zone Announcement Protocol
	Draft MZAP August 1998		Draft MZAP October 1998
	(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
	skipping to change at page 4, line 5		skipping to change at page 4, line 5
	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: Admin 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 admin scope border routers.
	Draft MZAP August 1998		Draft MZAP October 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 August 1998		Draft MZAP October 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), with its own IP address added		interface over which it was received, nor is it sent into any local
	to the path list, as well as the Zone ID Address of the Local Scope		scope zone whose ID is known and appears in the path list). In each
	Zone into which the ZAM is being sent, or 0 if the ID is unknown.		such ZAM re-originated, the ZBR adds its own IP address to the path
	(For example, if the other end of a point-to-point link also has a		list, as well as the Zone ID Address of the Local Scope Zone into
	boundary on the interface, then the link has no Local Scope Zone ID.)		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
			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 origined by E
	# +--->C*-> | ^ #		# +--->C*-> | ^ #
	# v = <-+---+ # ABCDE = ZBRs		# v = <-+---+ # ABCDE = ZBRs
	# D = Zone3 #		# D = Zone3 #
	skipping to change at page 6, line 5		skipping to change at page 6, line 5
	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 admin scope zones, as illustrated in figure 3, where the path
	between B and D goes outside the scope (through A and E). Here Router B		between B and D goes outside the scope (through A and E). Here Router B
	and Router C originates ZCMs, each reporting each other's presence.		and Router C originates ZCMs, each reporting each other's presence.
	Router D cannot see Router B's messages, but can see C's report of B,		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.		and so can conclude the zone is not convex.
	Draft MZAP August 1998		Draft MZAP October 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
	#####*############		#####*############
	skipping to change at page 7, line 5		skipping to change at page 7, line 5
	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 listen to Zone Announcement Messages to
	build up a list of the scope zones that are relevant locally. However,		build up a list of the scope zones that are relevant locally. However,
	listening to Zone Announcement Messages is not the recommended method		listening to Zone Announcement Messages is not the recommended method
	for regular applications to discover this information. These		for regular applications to discover this information. These
	applications will normally query a local Multicast Address Allocation		applications will normally query a local Multicast Address Allocation
	Server [3], which in turn listens to Zone Announcement Messages to		Server [3], which in turn listens to Zone Announcement Messages to
	Draft MZAP August 1998		Draft MZAP October 1998
	maintain a list of scopes.		maintain a list of scopes.
	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
	skipping to change at page 7, line 47		skipping to change at page 7, line 47
	=======*=====#====*=======#		=======*=====#====*=======#
	= 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 4: ZAM Leaking
	(2) If a ZLE message is received.		(2) If a ZLE message is received.
	In either case, the misconfigured router will be one of the routers in		In either case, the misconfigured router will be either the message
	the path list included in the message received.		origin, or one of the routers in the path list included in the message
	Draft MZAP August 1998		Draft MZAP October 1998
			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 admin scope boundary on some
	interface, but does not have a Local Scope boundary on that interface as		interface, but does not have a Local Scope boundary on that interface as
	specified in RFC 2365. This can be detected via the following method:		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
	skipping to change at page 8, line 42		skipping to change at page 8, line 44
	end addresses of a locally-configured scope.		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 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
			of each name to avoid accidental misconfiguration.
			Draft MZAP October 1998
	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 show below:		is shown below:
	Draft MZAP August 1998		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 | PTYPE |Address Family | NameLen |		| Version |B| PTYPE |Address Family | NameCount |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Origin |		| Message Origin |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Zone ID Address |		| Zone ID Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Zone Start Address |		| Zone Start Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Zone End Address |		| Zone End Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Zone Name |		| Encoded Zone Name-1 (variable length) |
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| | . . . |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| . . . | Encoded Zone Name-N (variable length) |
			+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | Padding (if needed) |		| | Padding (if needed) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Version:		Version:
	The version defined in this document is version 0.		The version defined in this document is version 0.
			"Big" scope bit (B):
			If clear, indicates that the addresses in the scoped range are not
			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):		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)
	Address Family:		Address Family:
	This indicates the format of the following packet. The following		The IANA-assigned address family number identifying the address
	values are defined by this document:		family for all addresses in the packet. The families defined for IP
	0: IPv4		are:
	1: IPv6		1: IPv4
			2: IPv6
			Name Count:
			Draft MZAP October 1998
			The number of encoded zone name blocks in this packet. The count 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 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
	example, if the zone is a border for 239.1.0.0 to 239.1.0.255, then		example, if the zone is a border for 239.1.0.0 to 239.1.0.255, then
	Zone End Address is 239.1.0.255.		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.
	Draft MZAP August 1998
	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.
			Encoded Zone Name:
			+--------------------+
			|D| LangLen (7 bits) |
			+--------------------+-----------+
			| Language Tag (variable size) |
			+--------------------+-----------+
			| NameLen (1 byte) |
			+--------------------+-----------+
			| Zone Name (variable size) |
			+--------------------------------+
			"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): 7 bits
			The length, in bytes, of the language tag.
			Language Tag: (variable size)
			The language tag, such as "en-US", indicating the language of the 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 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
	indicating the name given to the scope zone (eg: ``ISI-West Site'').		character string in UTF-8 encoding [4] indicating the name given to the
	It should be relatively short and MUST be less than 256 bytes in		scope zone (eg: ``ISI-West Site''). It should be relatively short and
	length. All the border routers to the same region SHOULD be		MUST be less than 256 bytes in length. All the border routers to the
	configured to give the same Zone Name, or a zero length string MAY be		same region SHOULD be configured to give the same Zone Name, or a zero
	given. A zero length string is taken to mean that another router is		length string MAY be given. A zero length string is taken to mean
	expected to be configured with the zone name. Having ALL the ZBRs		that another router is expected to be configured with the zone name.
	for a scope zone announce zero length names should be considered an		Having ALL the ZBRs for a scope zone announce zero length names
	error.		should be considered an error.
	Padding (if needed):		Padding (if needed):
	The MZAP header is padded with null bytes until it is 4-byte aligned.		The end of the MZAP header is padded with null bytes until it is
			4-byte aligned.
	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 August 1998		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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 12, line 5		skipping to change at page 14, line 5
	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 August 1998		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?)
	skipping to change at page 13, line 5		skipping to change at page 15, line 5
	| 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 August 1998		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
	skipping to change at page 14, line 5		skipping to change at page 16, line 5
	| 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 August 1998		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.
	skipping to change at page 15, line 5		skipping to change at page 17, line 5
	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 August 1998		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
	skipping to change at page 16, line 5		skipping to change at page 18, line 5
	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 August 1998		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		autheticated ZAM even if an un-authenticated one was received with
	skipping to change at page 16, line 41		skipping to change at page 18, line 41
	[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.
	[4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC		[4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
	2279, January 1998.		2279, January 1998.
	[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
			1766, March 1995.
			[7] Handley, M., "Multicast Address Allocation Protocol (AAP)", draft-
			handley-aap-01.txt, Internet Draft, July 1998.
			Draft MZAP October 1998
	8. Full Copyright Statement		8. 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 implmentation 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
	Draft MZAP August 1998
	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.
	skipping to change at page 17, line 35		skipping to change at page 19, line 44
	1 Introduction .................................................... 2		1 Introduction .................................................... 2
	2 Overview ........................................................ 3		2 Overview ........................................................ 3
	3 Usage ........................................................... 6		3 Usage ........................................................... 6
	3.1 Zone IDs ...................................................... 6		3.1 Zone IDs ...................................................... 6
	3.2 Informing internal entities of scopes ......................... 6		3.2 Informing internal entities of scopes ......................... 6
	3.3 Detecting non-convex scope zones .............................. 7		3.3 Detecting non-convex scope zones .............................. 7
	3.4 Detecting leaky boundaries for non-local scopes ............... 7		3.4 Detecting leaky boundaries for non-local scopes ............... 7
	3.5 Detecting a leaky Local Scope zone ............................ 8		3.5 Detecting a leaky Local Scope zone ............................ 8
	3.6 Detecting conflicting scope zones ............................. 8		3.6 Detecting conflicting scope zones ............................. 8
	3.7 Packet Formats ................................................ 8		3.7 Packet Formats ................................................ 9
	3.7.1 Zone Announcement Message ................................... 10		3.7.1 Zone Announcement Message ................................... 12
	3.7.2 Zone Limit Exceeded (ZLE) ................................... 12		3.7.2 Zone Limit Exceeded (ZLE) ................................... 14
	3.7.3 Zone Convexity Message ...................................... 13		3.7.3 Zone Convexity Message ...................................... 15
	4 Message Timing .................................................. 14		4 Message Timing .................................................. 16
	5 Constants ....................................................... 14		5 Constants ....................................................... 16
	6 Security Considerations ......................................... 15
	7 References ...................................................... 16		Draft MZAP October 1998
	8 Full Copyright Statement ........................................ 16
			6 Security Considerations ......................................... 17
			7 References ...................................................... 18
			8 Full Copyright Statement ........................................ 19
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/