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/