draft-ietf-mboned-mzap-04.txt   draft-ietf-mboned-mzap-05.txt 
MBoneD Working Group Mark Handley MBoneD Working Group Mark Handley
Internet Engineering Task Force AT&T Internet Engineering Task Force ACIRI
INTERNET-DRAFT Dave Thaler INTERNET-DRAFT Dave Thaler
22 June 1999 Microsoft 22 October 1999 Microsoft
Expires December 1999 Roger Kermode Expires April 2000 Roger Kermode
Motorola Motorola
Multicast-Scope Zone Announcement Protocol (MZAP) Multicast-Scope Zone Announcement Protocol (MZAP)
<draft-ietf-mboned-mzap-04.txt> <draft-ietf-mboned-mzap-05.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line ? skipping to change at page 2, line ?
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. 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".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.Abstract http://www.ietf.org/shadow.html.
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 common misconfigurations of administrative scope mechanisms whereby common misconfigurations of administrative scope
zones can be discovered. zones can be discovered.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
Draft MZAP June 1999 Draft MZAP October 1999
1. Introduction 1. Introduction
The use of administratively-scoped IP multicast, as defined in RFC 2365 The use of administratively-scoped IP multicast, as defined in RFC 2365
[1], allows packets to be addressed to a specific range of multicast [1], allows packets to be addressed to a specific range of multicast
addresses (e.g., 239.0.0.0 to 239.255.255.255 for IPv4) such that the addresses (e.g., 239.0.0.0 to 239.255.255.255 for IPv4) such that the
packets will not cross configured administrative boundaries, and also packets will not cross configured administrative boundaries, and also
allows such addresses to be locally assigned and hence are not required allows such addresses to be locally assigned and hence are not required
to be unique across administrative boundaries. This property of logical to be unique across administrative boundaries. This property of logical
naming both allows for address reuse, as well as provides the capability naming both allows for address reuse, as well as provides the capability
skipping to change at page 3, line 5 skipping to change at page 3, line 5
for non-overlapping ranges of addresses) of various sizes, as long as for non-overlapping ranges of addresses) of various sizes, as long as
scope zones that intersect topologically do not intersect in address scope zones that intersect topologically do not intersect in address
range. range.
Applications and services are interested in various aspects of the Applications and services are interested in various aspects of the
scopes within which they reside: scopes within which they reside:
o Applications which present users with a choice of which scope in o Applications which present users with a choice of which scope in
which to operate (e.g., when creating a new session, whether it is which to operate (e.g., when creating a new session, whether it is
Draft MZAP June 1999 Draft MZAP October 1999
to be confined to a corporate intranet, or whether it should go out to be confined to a corporate intranet, or whether it should go out
over the public Internet) are interested in the textual names which over the public Internet) are interested in the textual names which
have significance to users. have significance to users.
o Services which use "relative" multicast addresses (as defined in o Services which use "relative" multicast addresses (as defined in
[1]) in every scope are interested in the range of addresses used [1]) in every scope are interested in the range of addresses used
by each scope, so that they can apply a constant offset and compute by each scope, so that they can apply a constant offset and compute
which address to use in each scope. which address to use in each scope.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
These two barriers are addressed by this document. In particular, this These two barriers are addressed by this document. In particular, this
document defines the Multicast Scope Zone Announcement Protocol (MZAP) document defines the Multicast Scope Zone Announcement Protocol (MZAP)
which allows an entity to learn what scope zones it is within. which allows an entity to learn what scope zones it is within.
Typically servers will cache the information learned from MZAP and can Typically servers will cache the information learned from MZAP and can
then provide this information to applications in a timely fashion upon then provide this information to applications in a timely fashion upon
request using other means, e.g., via MADCAP [9]. MZAP also provides request using other means, e.g., via MADCAP [9]. MZAP also provides
diagnostic information to the boundary routers themselves that enables diagnostic information to the boundary routers themselves that enables
misconfigured scope zones to be detected. misconfigured scope zones to be detected.
Draft MZAP June 1999 Draft MZAP October 1999
2. Terminology 2. Terminology
The "Local Scope" is defined in RFC 2365 [1] and represents the smallest The "Local Scope" is defined in RFC 2365 [1] and represents the smallest
administrative scope larger than link-local, and the associated address administrative scope larger than link-local, and the associated address
range is defined as 239.255.0.0 to 239.255.255.255 inclusive (for IPv4, range is defined as 239.255.0.0 to 239.255.255.255 inclusive (for IPv4,
FF03::/16 for IPv6). RFC 2365 specifies: FF03::/16 for IPv6). RFC 2365 specifies:
"239.255.0.0/16 is defined to be the IPv4 Local Scope. The Local "239.255.0.0/16 is defined to be the IPv4 Local Scope. The Local
Scope is the minimal enclosing scope, and hence is not further Scope is the minimal enclosing scope, and hence is not further
divisible. Although the exact extent of a Local Scope is site divisible. Although the exact extent of a Local Scope is site
dependent, locally scoped regions must obey certain topological dependent, locally scoped regions must obey certain topological
constraints. In particular, a Local Scope must not span any other constraints. In particular, a Local Scope must not span any other
scope boundary. Further, a Local Scope must be completely contained scope boundary. Further, a Local Scope must be completely contained
within or equal to any larger scope. In the event that scope regions within or equal to any larger scope. In the event that scope regions
overlap in area, the area of overlap must be in its own Local Scope. overlap in area, the area of overlap must be in its own Local Scope.
This implies that any scope boundary is also a boundary for the Local This implies that any scope boundary is also a boundary for the Local
Scope." Scope."
A multicast scope Zone Boundary Router (ZBR) is a router that is A multicast scope Zone Boundary Router (ZBR) is a router that is
configured with a boundary for a particular multicast scope on one or configured with a boundary for a particular multicast scope on one or
more of its interfaces. Any interface that is configured with a boundary more of its interfaces. Any interface that is configured with a
for any administrative scope zone MUST also have a boundary for the boundary for any administrative scope zone MUST also have a boundary for
Local Scope zone, as described above. the Local Scope zone, as described above.
Such routers SHOULD be configured so that the router itself is within Such routers SHOULD be configured so that the router itself is within
the scope zone. This is shown in Figure 1(a), where router A is inside the scope zone. This is shown in Figure 1(a), where router A is inside
the scope zone and has the boundary configuration. the scope zone and has the boundary configuration.
............ ................ ............ ................
. . +B+--> . *B+--> . . +B+--> . *B+-->
. . / . / . . . / . / .
. * . + . . * . + .
. <---+A*---+C+-> . <---+A+---*C+-> . <---+A*---+C+-> . <---+A+---*C+->
skipping to change at page 5, line 5 skipping to change at page 5, line 5
A,B,C - routers * - boundary interface + - interface A,B,C - routers * - boundary interface + - interface
(a) Correct zone boundary (b) Incorrect zone boundary (a) Correct zone boundary (b) Incorrect zone boundary
Figure 1: Administrative scope zone boundary placement Figure 1: Administrative scope zone boundary placement
It is possible for the first router outside the scope zone to be It is possible for the first router outside the scope zone to be
configured with the boundary, as illustrated in Figure 1(b) where configured with the boundary, as illustrated in Figure 1(b) where
Draft MZAP June 1999 Draft MZAP October 1999
routers B and C are outside the zone and have the boundary routers B and C are outside the zone and have the boundary
configuration, whereas A does not, but this is NOT RECOMMENDED. This configuration, whereas A does not, but this is NOT RECOMMENDED. This
rule does not apply for Local Scope boundaries, but applies for all rule does not apply for Local Scope boundaries, but applies for all
other boundary routers. other boundary routers.
We next define the term "Zone ID" to mean the lowest IP address used by We next define the term "Zone ID" to mean the lowest IP address used by
any ZBR for a particular zone for sourcing MZAP messages into that scope any ZBR for a particular zone for sourcing MZAP messages into that scope
zone. The combination of this IP address and the first multicast zone. The combination of this IP address and the first multicast
address in the scope range serve to uniquely identify the scope zone. address in the scope range serve to uniquely identify the scope zone.
skipping to change at page 6, line 5 skipping to change at page 6, line 5
boundary is inside the scope zone and which side is outside it. boundary is inside the scope zone and which side is outside it.
Such a ZBR then sends periodic Zone Announcement Messages (ZAMs) for Such a ZBR then sends periodic Zone Announcement Messages (ZAMs) for
each zone for which it is configured as a boundary into that scope zone, each zone for which it is configured as a boundary into that scope zone,
containing information on the scope zone's address range, Zone ID, and containing information on the scope zone's address range, Zone ID, and
textual names. These messages are multicast to the well-known address textual names. These messages are multicast to the well-known address
[MZAP-LOCAL-GROUP] in the Local Scope, and are relayed across Local [MZAP-LOCAL-GROUP] in the Local Scope, and are relayed across Local
Scope boundaries into all Local Scope zones within the scope zone Scope boundaries into all Local Scope zones within the scope zone
referred to by the ZAM message, as shown in Figure 2. referred to by the ZAM message, as shown in Figure 2.
Draft MZAP June 1999 Draft MZAP October 1999
########################### ###########################
# Zone1 = Zone2 # ##### = large scope zone boundary # Zone1 = Zone2 # ##### = large scope zone boundary
*E-----+--->A*-----+-x # *E-----+--->A*-----+-x #
# | = v # ===== = Local Scope boundaries # | = v # ===== = Local Scope boundaries
# | ======*===*==# # | ======*===*==#
# | = B F # ----> = path of ZAM originated by E # | = B F # ----> = path of ZAM originated by E
G*<-----+--->C*-> | ^ # G*<-----+--->C*-> | ^ #
# v = <-+---+ # ABCDE = ZBRs # v = <-+---+ # ABCDE = ZBRs
# D = Zone3 # # D = Zone3 #
skipping to change at page 6, line 45 skipping to change at page 6, line 45
:..........: :..........:
(a) "Contained" (b) "Common Border" (c) "Overlap" (a) "Contained" (b) "Common Border" (c) "Overlap"
Zone 2 nests Zone 4 nests Zones 5 and 6 Zone 2 nests Zone 4 nests Zones 5 and 6
inside Zone 1 inside Zone 3 do not nest inside Zone 1 inside Zone 3 do not nest
Figure 3: Zone nesting examples Figure 3: Zone nesting examples
A ZBR cannot independently determine whether one zone is nested inside A ZBR cannot independently determine whether one zone is nested inside
another. However, it can determine that one zone does NOT nest inside another. However, it can determine that one zone does NOT nest inside
another. For example, in figure 4: another. For example, in Figure 3:
o ZBR A will pass ZAMs for zone 1 but will prevent ZAMs from zone 2 o ZBR A will pass ZAMs for zone 1 but will prevent ZAMs from zone 2
from leaving zone 2. When ZBR A first receives a ZAM for zone 1, it from leaving zone 2. When ZBR A first receives a ZAM for zone 1, it
Draft MZAP June 1999 Draft MZAP October 1999
then knows that zone 1 does not nest within zone 2, but it cannot, then knows that zone 1 does not nest within zone 2, but it cannot,
however, determine whether zone 2 nests within zone 1. however, determine whether zone 2 nests within zone 1.
o ZBR B acts as ZBR for both zones 3 and 4, and hence cannot determine o ZBR B acts as ZBR for both zones 3 and 4, and hence cannot determine
if one is nested inside the other. However, ZBR C can determine that if one is nested inside the other. However, ZBR C can determine that
zone 3 does not nest inside zone 4 when it receives a ZAM for zone 3, zone 3 does not nest inside zone 4 when it receives a ZAM for zone 3,
since it is a ZBR for zone 4 but not zone 3. since it is a ZBR for zone 4 but not zone 3.
o ZBR D only acts as ZBR zone 6 and not 5, hence ZBR D can deduce that o ZBR D only acts as ZBR zone 6 and not 5, hence ZBR D can deduce that
zone 5 does not nest inside zone 6 upon hearing a ZAM for zone 5. zone 5 does not nest inside zone 6 upon hearing a ZAM for zone 5.
Similarly, ZBR E only acts as ZBR zone 5 and not 6, hence ZBR E can Similarly, ZBR E only acts as ZBR zone 5 and not 6, hence ZBR E can
deduce that zone 6 does not nest inside zone 5 upon hearing a ZAM for deduce that zone 6 does not nest inside zone 5 upon hearing a ZAM for
zone 6. zone 6.
The fact that ZBRs can determine that one zone does not nest inside The fact that ZBRs can determine that one zone does not nest inside
another, but not that a zone does nest inside another, means that another, but not that a zone does nest inside another, means that
nesting must be determined in a distributed fashion. This is done by nesting must be determined in a distributed fashion. This is done by
sending Not-Inside Messages (NIMs) which express the fact that a zone X sending Not-Inside Messages (NIMs) which express the fact that a zone X
is not inside a zone Y. Such messages are sent to the well-known is not inside a zone Y. Such messages are sent to the well-known [MZAP-
[MZAP-LOCAL-GROUP] and are thus seen by the same entities listening to LOCAL-GROUP] and are thus seen by the same entities listening to ZAM
ZAM messages (e.g., MADCAP servers). Such entities can then determine messages (e.g., MADCAP servers). Such entities can then determine the
the nesting relationship between two scopes based on a sustained absence nesting relationship between two scopes based on a sustained absence of
of any evidence to the contrary. any evidence to the contrary.
3.2. Other Messages 3.2. Other Messages
Two other message types, Zone Convexity Messages (ZCMs) and Zone Limit Two other message types, Zone Convexity Messages (ZCMs) and Zone Limit
Exceeded (ZLE) messages, are used only by routers, and enable them to Exceeded (ZLE) messages, are used only by routers, and enable them to
compare their configurations for consistency and detect compare their configurations for consistency and detect
misconfigurations. These messages are sent to MZAP's relative address misconfigurations. These messages are sent to MZAP's relative address
within the scope range associated with the scope zone to which they within the scope range associated with the scope zone to which they
refer, and hence are typically not seen by entities other than routers. refer, and hence are typically not seen by entities other than routers.
Their use in detecting specific misconfiguration scenarios will be Their use in detecting specific misconfiguration scenarios will be
covered in the next section. covered in the next section.
Packet formats for all messages are described in Section 5. Packet formats for all messages are described in Section 5.
3.3. Zone IDs 3.3. Zone IDs
When a boundary router first starts up, it uses its lowest IP address When a boundary router first starts up, it uses its lowest IP address
which it considers to be inside a given zone, and which is routable which it considers to be inside a given zone, and which is routable
everywhere within the zone (for example, not a link-local address), as everywhere within the zone (for example, not a link-local address), as
the Zone ID for that zone. It then schedules ZCM and ZAM messages to be the Zone ID for that zone. It then schedules ZCM (and ZAM) messages to
Draft MZAP June 1999 Draft MZAP October 1999
sent in the future (it does not send them immediately). When a ZAM or be sent in the future (it does not send them immediately). When a ZCM
ZCM is received for the given scope, the sender is added to the local is received for the given scope, the sender is added to the local list
list of ZBRs (including itself) for that scope, and the Zone ID is of ZBRs (including itself) for that scope, and the Zone ID is updated to
updated to be the lowest IP address in the list. Entries in the list be the lowest IP address in the list. Entries in the list are
are eventually timed out if no further messages are received from that eventually timed out if no further messages are received from that ZBR,
ZBR, such that the Zone ID will converge to the lowest address of any such that the Zone ID will converge to the lowest address of any active
active ZBR for the scope. ZBR for the scope.
Note that the sender of ZAM messages MUST NOT be used in this way. This
is because the procedure for detecting a leaky Local scope described in
Section 4.3 below relies on two disjoint zones for the same scope range
having different Zone IDs. If ZAMs are used to compute Zone IDs, then
ZAMs leaking across a Local Scope boundary will cause the two zones to
converge to the same Zone ID.
4. Detecting Router Misconfigurations 4. Detecting Router Misconfigurations
In this section, we cover how to detect various error conditions. If any In this section, we cover how to detect various error conditions. If
error is detected, the router should attempt to alert a network any error is detected, the router should attempt to alert a network
administrator to the nature of the misconfiguration. The means to do administrator to the nature of the misconfiguration. The means to do
this lies outside the scope of MZAP. this lies outside the scope of MZAP.
4.1. Detecting non-convex scope zones 4.1. Detecting non-convex scope zones
Zone Convexity Messages (ZCMs) are used by routers to detect non-convex Zone Convexity Messages (ZCMs) are used by routers to detect non-convex
administrative scope zones, which are one possible misconfiguration. administrative scope zones, which are one possible misconfiguration.
Non-convex scope zones can cause problems for applications since a Non-convex scope zones can cause problems for applications since a
receiver may never see administratively-scoped packets from a sender receiver may never see administratively-scoped packets from a sender
within the same scope zone, since packets travelling between them may be within the same scope zone, since packets travelling between them may be
dropped at the boundary. dropped at the boundary.
In the example illustrated in Figure 4, the path between B and D goes In the example illustrated in Figure 4, the path between B and D goes
outside the scope (through A and E). Here, Router B and Router C send outside the scope (through A and E). Here, Router B and Router C send
ZCMs within a given scope zone for which they each have a boundary, with ZCMs within a given scope zone for which they each have a boundary, with
each reporting the other boundary routers of the zone from which they each reporting the other boundary routers of the zone from which they
have heard. In Figure 4, Router D cannot see Router B's messages, but have heard. In Figure 4, Router D cannot see Router B's messages, but
can see C's report of B, and so can conclude the zone is not convex. can see C's report of B, and so can conclude the zone is not convex.
Draft MZAP October 1999
#####*####======== #####*####========
# B # = ##### = non-convex scope boundary # B # = ##### = non-convex scope boundary
# |->A* = # |->A* =
# | # = ===== = other scope boundaries # | # = ===== = other scope boundaries
# | ####*#### # | ####*####
# | E # ----> = path of B's ZCM # | E # ----> = path of B's ZCM
# v D* # v D*
# C # * = boundary interface # C # * = boundary interface
#####*############ #####*############
Figure 4: Non-convexity detection Figure 4: Non-convexity detection
Draft MZAP June 1999 Non-convex scope zones can be detected via three 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,
(2) If a ZBR is listed in ZCMs received, but no ZCM is received from (2) If a ZBR is listed in ZCMs received, but no ZCM is received from
that ZBR for [ZCM-HOLDTIME] seconds, as illustrated in Figure 3. that ZBR for [ZCM-HOLDTIME] seconds, as illustrated in Figure 4,
or
(3) ZAM messages can also be used in a manner similar to that for
ZCMs in (1) above, as follows: if a ZAM is received from a ZBR on
an interface inside a given scope zone, and the next-hop
interface (according to the multicast RIB) towards that ZBR is
outside the scope zone.
Zone Convexity Messages MAY also be sent and received by correctly Zone Convexity Messages MAY also be sent and received by correctly
configured ordinary hosts within a scope region, which may be a useful configured ordinary hosts within a scope region, which may be a useful
diagnostic facility that does not require privileged access. diagnostic facility that does not require privileged access.
4.2. Detecting leaky boundaries for non-local scopes 4.2. Detecting leaky boundaries for non-local scopes
A "leaky" boundary is one which logically has a "hole" due to some A "leaky" boundary is one which logically has a "hole" due to some
router not having a boundary applied on an interface where one ought to router not having a boundary applied on an interface where one ought to
exist. Hence, the boundary does not completely surround a piece of the exist. Hence, the boundary does not completely surround a piece of the
network, resulting in scoped data leaking outside. network, resulting in scoped data leaking outside.
Leaky scope boundaries can be detected via two methods: Leaky scope boundaries can be detected via two methods:
(1) If it receives ZAMs originating inside the scope boundary on an (1) If it receives ZAMs originating inside the scope boundary on an
interface that points outside the zone boundary. Such a ZAM interface that points outside the zone boundary. Such a ZAM
message must have escaped the zone through a leak, and flooded back message must have escaped the zone through a leak, and flooded
around behind the boundary. This is illustrated in Figure 5.
Draft MZAP October 1999
back 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 5: ZAM Leaking Figure 5: ZAM Leaking
(2) If a Zone Length Exceeded (ZLE) message is received. The ZAM (2) If a Zone Length Exceeded (ZLE) message is received. The ZAM
packet also contains a Zones Traveled Limit. If the number of packet also contains a Zones Traveled Limit. If the number of
Local Scope zones traversed becomes equal to the Zones Traveled Local Scope zones traversed becomes equal to the Zones Traveled
Limit, a ZLE message is generated (the suppression mechanism for Limit, a ZLE message is generated (the suppression mechanism for
preventing implosion is described later in the Processing Rules preventing implosion is described later in the Processing Rules
section). ZLEs detect leaks where packets do not return to
Draft MZAP June 1999 another part of the same scope zone, but instead reach other
Local Scope zones far away from the ZAM originator.
section). ZLEs detect leaks where packets do not return to another
part of the same scope zone, but instead reach other Local Scope
zones far away from the ZAM originator.
In either case, the misconfigured router will be either the message In either case, the misconfigured router will be either the message
origin, or one of the routers in the ZBR path list which is included in origin, or one of the routers in the ZBR path list which is included in
the message received (or perhaps a router on the path between two such the message received (or perhaps a router on the path between two such
ZBRs which ought to have been a ZBR itself). ZBRs which ought to have been a ZBR itself).
4.3. Detecting a leaky Local Scope zone 4.3. Detecting a leaky Local Scope zone
A local scope is leaky if a router has an administrative scope boundary A local scope is leaky if a router has an administrative scope boundary
on some interface, but does not have a Local Scope boundary on that on some interface, but does not have a Local Scope boundary on that
skipping to change at page 10, line 31 skipping to change at page 11, line 5
following method: following method:
o If a ZAM for a given scope is received by a ZBR which is a boundary o If a ZAM for a given scope is received by a ZBR which is a boundary
for that scope, it compares the Origin's Scope Zone ID in the ZAM for that scope, it compares the Origin's Scope Zone ID in the ZAM
with its own Zone ID for the given scope. If the two do not match, with its own Zone ID for the given scope. If the two do not match,
this is evidence of a misconfiguration. Since a temporary mismatch this is evidence of a misconfiguration. Since a temporary mismatch
may result immediately after a recent change in the reachability of may 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. the mismatch is persistent.
Draft MZAP October 1999
The exact location of the problem can be found by doing an mtrace [5] The exact location of the problem can be found by doing an mtrace [5]
from the router detecting the problem, back to the ZAM origin, for any from the router detecting the problem, back to the ZAM origin, for any
group within the address range identified by the ZAM. The router at group within the address range identified by the ZAM. The router at
fault will be the one reporting that a boundary was reached. fault will be the one reporting that a boundary was reached.
4.4. Detecting conflicting scope zones 4.4. Detecting conflicting scope zones
Conflicting address ranges can be detected via the following method: Conflicting address ranges can be detected via the following method:
o If a ZBR receives a ZAM for a given scope, and the included start and o If a ZBR receives a ZAM for a given scope, and the included start and
end addresses overlap with, but are not identical to, the start and end addresses overlap with, but are not identical to, the start and
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 textual name for a given scope and o If a ZBR is configured with a textual name for a given scope and
language, and it receives a ZAM or ZCM with a name for the same scope language, and it receives a ZAM or ZCM with a name for the same scope
and language, but the scope names do not match. and language, but the scope names do not match.
Draft MZAP June 1999
Detecting either type of conflict above indicates that either the local Detecting either type of conflict above indicates that either the local
router or the router originating the message is misconfigured. router or the router originating the message is misconfigured.
Configuration tools SHOULD strip white space from the beginning and end Configuration tools SHOULD strip white space from the beginning and end
of each name to avoid accidental misconfiguration. of each name to avoid accidental misconfiguration.
5. Packet Formats 5. Packet Formats
All MZAP messages are sent over UDP, with a destination port of [MZAP- All MZAP messages are sent over UDP, with a destination port of [MZAP-
PORT] and an IPv4 TTL or IPv6 Hop Limit of 255. PORT] and an IPv4 TTL or IPv6 Hop Limit of 255.
When sending an MZAP message referring to a given scope zone, a ZBR MUST When sending an MZAP message referring to a given scope zone, a ZBR MUST
use a source address which will have significance everywhere within the use a source address which will have significance everywhere within the
scope zone to which the message refers. For example, link-local scope zone to which the message refers. For example, link-local
addresses MUST NOT be used. addresses MUST NOT be used.
The common MZAP message header (which follows the UDP header), is shown The common MZAP message header (which follows the UDP header), is shown
below: below:
Draft MZAP October 1999
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 12, line 4 skipping to change at page 12, line 34
| . . . | Encoded Zone Name-N (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): "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
Draft MZAP June 1999
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]).
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) 3: Not-Inside Message (NIM)
Address Family: Address Family:
The IANA-assigned address family number [10,11] identifying the The IANA-assigned address family number [10,11] identifying the
address family for all addresses in the packet. The families defined address family for all addresses in the packet. The families defined
for IP are: for IP are:
1: IPv4 1: IPv4
2: IPv6 2: IPv6
Draft MZAP October 1999
Name Count: Name Count:
The number of encoded zone name blocks in this packet. The count may The number of encoded zone name blocks in this packet. The count 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 boundary. For This gives the start address for the scope zone boundary. For
example, if the zone is a boundary for 239.1.0.0 to 239.1.0.255, then example, if the zone is a boundary for 239.1.0.0 to 239.1.0.255, then
Zone Start Address is 239.1.0.0. Zone Start Address is 239.1.0.0.
Zone End Address: 32 bits (IPv4) or 128 bits (IPv6) Zone End Address: 32 bits (IPv4) or 128 bits (IPv6)
skipping to change at page 13, line 4 skipping to change at page 13, line 33
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 usually different from the ID of the zone. Note that this ID is usually different from the ID of the
Local Scope zone in which the origin resides. Local Scope zone in which the origin resides.
Encoded Zone Name: Encoded Zone Name:
Draft MZAP June 1999
+--------------------+ +--------------------+
|D| Reserved (7 bits)| |D| Reserved (7 bits)|
+--------------------+ +--------------------+
| LangLen (1 byte) | | LangLen (1 byte) |
+--------------------+-----------+ +--------------------+-----------+
| Language Tag (variable size) | | Language Tag (variable size) |
+--------------------+-----------+ +--------------------+-----------+
| NameLen (1 byte) | | NameLen (1 byte) |
+--------------------+-----------+ +--------------------+-----------+
| Zone Name (variable size) | | Zone Name (variable size) |
+--------------------------------+ +--------------------------------+
The first byte contains flags, of which only the high bit is defined. The first byte contains flags, of which only the high bit is defined.
The other bits are reserved (sent as 0, ignored on receipt). 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 If set, indicates a preference that the name in the following
language should be used if no name is available in a desired language should be used if no name is available in a desired
language. language.
Draft MZAP October 1999
Language tag length (LangLen): 1 byte Language tag length (LangLen): 1 byte
The length, in bytes, of the language tag. The length, in bytes, of the language tag.
Language Tag: (variable size) Language Tag: (variable size)
The language tag, such as "en-US", indicating the language of the The language tag, such as "en-US", indicating the language of the
zone name. Language tags are described in [6]. zone name. Language tags are described in [6].
Name Len: Name Len:
The length, in bytes, of the Zone Name field. The length MUST NOT be The length, in bytes, of the Zone Name field. The length MUST NOT be
zero. zero.
Zone Name: multiple of 8 bits Zone Name: multiple of 8 bits
The Zone Name is an ISO 10646 character string in UTF-8 encoding [4] The Zone Name is an ISO 10646 character string in UTF-8 encoding [4]
indicating the name given to the scope zone (eg: ``ISI-West Site''). indicating the name given to the scope zone (eg: ``ISI-West Site'').
It should be relatively short and MUST be less than 256 bytes in It should be relatively short and MUST be less than 256 bytes in
length. White space SHOULD be stripped from the beginning and end of length. White space SHOULD be stripped from the beginning and end of
each name before encoding, to avoid accidental conflicts. each name before encoding, to avoid accidental conflicts.
Padding (if needed): Padding (if needed):
The end of the MZAP header is padded with null bytes until it is 4- The end of the MZAP header is padded with null bytes until it is
byte aligned. 4-byte aligned.
Draft MZAP June 1999
5.1. Zone Announcement Message 5.1. Zone Announcement Message
A Zone Announcement Message has PTYPE=0, and is periodically sent by a A Zone Announcement Message has PTYPE=0, and is periodically sent by a
ZBR for each scope for which it is a boundary, EXCEPT: ZBR for each scope for which it is a boundary, EXCEPT:
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 1999
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 15, line 5 skipping to change at page 15, line 42
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.
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].
Draft MZAP June 1999
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
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.
Draft MZAP October 1999
5.2. Zone Limit Exceeded (ZLE) 5.2. Zone Limit Exceeded (ZLE)
The format of a ZLE is shown below: The format of a ZLE is shown below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MZAP Header MZAP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZT | ZTL | Hold Time | | ZT | ZTL | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 5 skipping to change at page 16, line 38
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All fields are copied from the ZAM, except PTYPE which is set to one. All fields are copied from the ZAM, except PTYPE which is set to one.
5.3. Zone Convexity Message 5.3. Zone Convexity Message
A Zone Announcement Message has PTYPE=2, and is periodically sent by a A Zone Announcement Message has PTYPE=2, and is periodically sent by a
ZBR for each scope for which it is a boundary (except the Link-local ZBR for each scope for which it is a boundary (except the Link-local
scope). Note that ZCM's ARE sent in the Local Scope. scope). Note that ZCM's ARE sent in the Local Scope.
Draft MZAP June 1999
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 October 1999
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 17, line 5 skipping to change at page 18, line 5
all do not fit. all do not fit.
5.4. Not-Inside Message 5.4. Not-Inside Message
A Not-Inside Message (NIM) has PTYPE=3, and is periodically sent by a A Not-Inside Message (NIM) has PTYPE=3, and is periodically sent by a
ZBR which knows that a scope X does not nest within another scope Y ("X ZBR which knows that a scope X does not nest within another scope Y ("X
not inside Y"): not inside Y"):
The format of a Not-Inside Message is shown below: The format of a Not-Inside Message is shown below:
Draft MZAP June 1999 Draft MZAP October 1999
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MZAP Header MZAP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Not-Inside Zone Start Address | | Not-Inside Zone Start Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are as follows: The fields are as follows:
skipping to change at page 18, line 5 skipping to change at page 19, line 5
information that is relevant to it, such as the address range, and the information that is relevant to it, such as the address range, and the
names. An address allocator receiving such information MUST also use names. An address allocator receiving such information MUST also use
the "B" bit to determine whether it can add the address range to the set the "B" bit to determine whether it can add the address range to the set
of ranges from which it may allocate addresses (specifically, it may add of ranges from which it may allocate addresses (specifically, it may add
them only if the bit is zero). Even if the bit is zero, an MAAS SHOULD them only if the bit is zero). Even if the bit is zero, an MAAS SHOULD
still store the range information so that clients who use relative- still store the range information so that clients who use relative-
addresses can still obtain the ranges by requesting them from the MAAS. addresses can still obtain the ranges by requesting them from the MAAS.
An internal entity (e.g., an MAAS) may assume that X nests within Y if: An internal entity (e.g., an MAAS) may assume that X nests within Y if:
Draft MZAP June 1999 Draft MZAP October 1999
a) it first heard ZAMs for both X and Y at least [NIM-HOLDTIME] a) it first heard ZAMs for both X and Y at least [NIM-HOLDTIME]
seconds ago, AND seconds ago, AND
b) it has not heard a NIM indicating that "X not inside Y" for at b) it has not heard a NIM indicating that "X not inside Y" for at
least [NIM-HOLDTIME] seconds. least [NIM-HOLDTIME] seconds.
6.2. Sending ZAMs 6.2. Sending ZAMs
Each ZBR should send a Zone Announcement Message for each scope zone for Each ZBR should send a Zone Announcement Message for each scope zone for
skipping to change at page 19, line 5 skipping to change at page 20, line 5
[ZAM-HOLDTIME]. Existence of this state indicates that the ZBR [ZAM-HOLDTIME]. Existence of this state indicates that the ZBR
knows that X does not nest inside any scope for which it is a knows that X does not nest inside any scope for which it is a
boundary. If the entry's timer expires (because no more ZAMs for X boundary. If the entry's timer expires (because no more ZAMs for X
are heard for [ZAM-HOLDTIME]), the entry is deleted. are heard for [ZAM-HOLDTIME]), the entry is deleted.
If the local ZBR does have configuration for scope X: If the local ZBR does have configuration for scope X:
(1) If the ZAM originated from OUTSIDE the scope (i.e., received over a (1) If the ZAM originated from OUTSIDE the scope (i.e., received over a
boundary interface for scope X): boundary interface for scope X):
Draft MZAP June 1999 Draft MZAP October 1999
a) a) If the Scope Zone ID in the ZAM matches the ZBR's own Scope Zone
If the Scope Zone ID in the ZAM matches the ZBR's own Scope Zone
ID, then signal a leaky scope misconfiguration. ID, then signal a leaky scope misconfiguration.
b) b) Drop the ZAM (perform no further processing below). For
Drop the ZAM (perform no further processing below). For
example, router G in Figure 2 will not forward the ZAM. This example, router G in Figure 2 will not forward the ZAM. This
rule is primarily a safety measure, since the placement of G in rule is primarily a safety measure, since the placement of G in
Figure 2 is not a recommended configuration, as discussed Figure 2 is not a recommended configuration, as discussed
earlier. earlier.
(2) If the ZAM originated from INSIDE the scope: (2) If the ZAM originated from INSIDE the scope:
a) a) If the next-hop interface (according to the multicast RIB)
Add the Origin to the local list of ZBRs (including the local towards the Origin is outside the scope zone, then signal a non-
ZBR) for scope X, and update the Zone ID is to be the lowest IP convexity problem.
address in the list. Set the ZBR list entry added to time out
after [ZAM-HOLDTIME] if no further messages are received from
that ZBR, so that the Zone ID will converge to the lowest
address of any active ZBR for the scope.
b) b) If the Origin's Scope Zone ID in the ZAM does not match the
If the Origin's Scope Zone ID in the ZAM does not match the
Scope Zone ID kept by the local ZBR, and this mismatch continues Scope Zone ID kept by the local ZBR, and this mismatch continues
to occur, then signal a possible leaky scope warning. to occur, then signal a possible leaky scope warning.
c) c) For each textual name in the ZAM, see if a name for the same
For each textual name in the ZAM, see if a name for the same
scope and language is locally-configured; if so, but the scope scope and language is locally-configured; if so, but the scope
names do not match, signal a scope name conflict to a local names do not match, signal a scope name conflict to a local
administrator. administrator.
d) d) If the ZAM was received on an interface which is NOT a Local
If the ZAM was received on an interface which is NOT a Local
Scope boundary, and the last Local Zone ID Address in the path Scope boundary, and the last Local Zone ID Address in the path
list is 0, the ZBR fills in the Local Zone ID Address of the list is 0, the ZBR fills in the Local Zone ID Address of the
local zone from which the ZAM was received. local zone from which the ZAM was received.
If a ZAM for the same scope (as identified by the origin Zone ID and If a ZAM for the same scope (as identified by the origin Zone ID and
first multicast address) was received in the last [ZAM-DUP-TIME] first multicast address) was received in the last [ZAM-DUP-TIME]
seconds, the ZAM is then discarded. Otherwise, the ZAM is cached for at seconds, the ZAM is then discarded. Otherwise, the ZAM is cached for at
least [ZAM-DUP-TIME] seconds. For example, when router C in Figure 2 least [ZAM-DUP-TIME] seconds. For example, when router C in Figure 2
receives the ZAM via B, it will not be forwarded, since it has just receives the ZAM via B, it will not be forwarded, since it has just
forwarded the ZAM from E. forwarded the ZAM from E.
Draft MZAP June 1999
The Zones Travelled count in the message is then incremented, and if the The Zones Travelled count in the message is then incremented, and if the
updated count is equal to or greater than the ZTL field, schedule a ZLE updated count is equal to or greater than the ZTL field, schedule a ZLE
to be sent as described in the next subsection and perform no further to be sent as described in the next subsection and perform no further
processing below. processing below.
If the Zone ID of the Local Scope zone in which the ZBR resides is not If the Zone ID of the Local Scope zone in which the ZBR resides is not
already in the ZAM's path list, then the ZAM is immediately re- 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 the 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 Zone ID of the Local Scope zone into which the message is being
Draft MZAP October 1999
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 Figure Scope zone that is contained in the path list. For example, in Figure
2, router F, which did not get the ZAM via A due to packet loss, will 2, router F, which did not get the ZAM via A due to packet loss, will
not forward the ZAM from B back into Zone 2 since the path list has { 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. (E,1), (A,2), (B,3) } and hence Zone 2 already appears.
In addition, the ZBR re-originates the ZAM out each interface with a In addition, the ZBR re-originates the ZAM out each interface with a
Local Scope boundary (except that it is not sent back out the interface Local Scope boundary (except that it is not sent back out the interface
over which it was received, nor is it sent into any local scope zone over which it was received, nor is it sent into any local scope zone
skipping to change at page 21, line 4 skipping to change at page 21, line 42
within the interval [ZLE-SUPPRESSION-INTERVAL], and listens to the within the interval [ZLE-SUPPRESSION-INTERVAL], and listens to the
[MZAP-RELATIVE-GROUP] within the included scope for other ZLEs. If any [MZAP-RELATIVE-GROUP] within the included scope for other ZLEs. If any
are received before the random delay timer expires, the timer is cleared are received before the random delay timer expires, the timer is cleared
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)
Draft MZAP June 1999
This equation results in an exponential random distribution which This equation results in an exponential random distribution which
ensures that close to one ZBR will respond. Using a purely uniform ensures that close to one ZBR will respond. Using a purely uniform
distribution would begin to exhibit scaling problems as the number of distribution would begin to exhibit scaling problems as the number of
ZBRs rose. Since ZLEs are only suppressed if a duplicate ZLE arrives ZBRs rose. Since ZLEs are only suppressed if a duplicate ZLE arrives
before the time chosen, two routers choosing delays which differ by an before the time chosen, two routers choosing delays which differ by an
amount less than the propagation delay between them will both send amount less than the propagation delay between them will both send
messages, consuming excess bandwidth. Hence it is desirable to minimize messages, consuming excess bandwidth. Hence it is desirable to minimize
the number of routers choosing a delay close to the lowest delay chosen, the number of routers choosing a delay close to the lowest delay chosen,
and an exponential distribution is suitable for this purpose. and an exponential distribution is suitable for this purpose.
Draft MZAP October 1999
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.
6.5. Receiving ZLEs 6.5. Receiving ZLEs
When a router receives a ZLE, it performs the following actions: When a router receives a ZLE, it performs the following actions:
(1) If the router has a duplicate ZLE message scheduled to be sent, it (1) If the router has a duplicate ZLE message scheduled to be sent,
unschedules its own message so another one will not be sent. it unschedules its own message so another one will not be sent.
(2) If the ZLE contains the router's own address in the Origin field, (2) If the ZLE contains the router's own address in the Origin field,
it signals a leaky scope misconfiguration. it signals a leaky scope misconfiguration.
6.6. Sending ZCMs 6.6. Sending ZCMs
Each ZBR should send a Zone Convexity Message (ZCM) for each scope zone Each ZBR should send a Zone Convexity Message (ZCM) for each scope zone
for which it is a boundary every [ZCM-INTERVAL] seconds, +/- 30% of for which it is a boundary every [ZCM-INTERVAL] seconds, +/- 30% of
[ZCM-INTERVAL] each time to avoid message synchronisation. [ZCM-INTERVAL] each time to avoid message synchronisation.
ZCMs are sent to the [ZCM-RELATIVE-GROUP] in the scoped range itself. ZCMs are sent to the [ZCM-RELATIVE-GROUP] in the scoped range itself.
(For example, if the scope range is 239.1.0.0 to 239.1.0.255, then these (For example, if the scope range is 239.1.0.0 to 239.1.0.255, then these
messages should be sent to 239.1.0.252.) As these are not Locally-Scoped messages should be sent to 239.1.0.252.) As these are not Locally-
packets, they are simply multicast across the scope zone itself, and Scoped packets, they are simply multicast across the scope zone itself,
require no path to be built up, nor any special processing by and require no path to be built up, nor any special processing by
intermediate Local Scope ZBRs. intermediate Local Scope ZBRs.
6.7. Receiving ZCMs 6.7. Receiving ZCMs
When a ZCM is received for a given scope X, on an interface which is When a ZCM is received for a given scope X, on an interface which is
inside the scope, it follows the rules below: inside the scope, it follows the rules below:
Draft MZAP June 1999
(1) The Origin is added to the local list of ZBRs (including itself) (1) The Origin is added to the local list of ZBRs (including itself)
for that scope, and the Zone ID is updated to be the lowest IP for that scope, and the Zone ID is updated to be the lowest IP
address in the list. The new entry is scheduled to be timed out address in the list. The new entry is scheduled to be timed out
after [ZCM-HOLDTIME] if no further messages are received from that after [ZCM-HOLDTIME] if no further messages are received from
ZBR, so that the Zone ID will converge to the lowest address of any that ZBR, so that the Zone ID will converge to the lowest address
active ZBR for the scope. of any active ZBR for the scope.
(2) If a ZBR is listed in ZCMs received, but the next-hop interface (2) If a ZBR is listed in ZCMs received, but the next-hop interface
(according to the multicast RIB) towards that ZBR is outside the (according to the multicast RIB) towards that ZBR is outside the
scope zone, or if no ZCM is received from that ZBR for [ZCM- scope zone, or if no ZCM is received from that ZBR for [ZCM-
HOLDTIME] seconds, as in the example in Figure 3, then signal a HOLDTIME] seconds, as in the example in Figure 4, then signal a
Draft MZAP October 1999
non-convexity problem. non-convexity problem.
(3) For each textual name in the ZCM, see if a name for the same scope (3) For each textual name in the ZCM, see if a name for the same
and language is locally-configured; if so, but the scope names do scope and language is locally-configured; if so, but the scope
not match, signal a scope name conflict to a local administrator. names do not match, signal a scope name conflict to a local
administrator.
6.8. Sending NIMs 6.8. Sending NIMs
Periodically, for each scope zone Y for which it is a boundary, a router Periodically, for each scope zone Y for which it is a boundary, a router
originates a Not-Inside Message (NIM) for each "X not inside" entry it originates a Not-Inside Message (NIM) for each "X not inside" entry it
has created when receiving ZAMs. Like a ZAM, this message is multicast has created when receiving ZAMs. Like a ZAM, this message is multicast
to the address [MZAP-LOCAL-GROUP] from one of its interfaces inside Y. to the address [MZAP-LOCAL-GROUP] from one of its interfaces inside Y.
Each ZBR should send such a Not-Inside Message every [NIM-INTERVAL] Each ZBR should send such a Not-Inside Message every [NIM-INTERVAL]
seconds, +/- 30% of [NIM-INTERVAL] to avoid message synchronization. seconds, +/- 30% of [NIM-INTERVAL] to avoid message synchronization.
6.9. Receiving NIMs 6.9. Receiving NIMs
When a ZBR receives a NIM saying that "X is not inside Y", it is When a ZBR receives a NIM saying that "X is not inside Y", it is
forwarded, unmodified, in a manner similar to ZAMs: forwarded, unmodified, in a manner similar to ZAMs:
(1) If the NIM was received on an interface with a boundary for either (1) If the NIM was received on an interface with a boundary for
X or Y, the NIM is discarded. either X or Y, the NIM is discarded.
(2) Unlike ZAMs, if the NIM was not received on the interface towards (2) Unlike ZAMs, if the NIM was not received on the interface towards
the message origin (according to the Multicast RIB), the NIM is the message origin (according to the Multicast RIB), the NIM is
discarded. discarded.
(3) If a NIM for the same X and Y (where each is identified by its (3) If a NIM for the same X and Y (where each is identified by its
first multicast address) was received in the last [ZAM-DUP-TIME] first multicast address) was received in the last [ZAM-DUP-TIME]
seconds, the NIM is not forwarded. seconds, the NIM is not forwarded.
Draft MZAP June 1999
(4) Otherwise, the NIM is cached for at least [ZAM-DUP-TIME] seconds. (4) Otherwise, the NIM is cached for at least [ZAM-DUP-TIME] seconds.
(5) The ZBR then re-originates the NIM (i.e., with the original UDP (5) The ZBR then re-originates the NIM (i.e., with the original UDP
payload) into each local scope zone in which it has interfaces, payload) into each local scope zone in which it has interfaces,
except that it is not sent back into the local scope zone from except that it is not sent back into the local scope zone from
which the message was received, nor is it sent out any interface which the message was received, nor is it sent out any interface
with a boundary for either X or Y. with a boundary for either X or Y.
Draft MZAP October 1999
7. Constants 7. Constants
[MZAP-PORT]: The well-known UDP port to which all MZAP messages are [MZAP-PORT]: The well-known UDP port to which all MZAP messages are
sent. Value: 2106. sent. Value: 2106.
[MZAP-LOCAL-GROUP]: The well-known group in the Local Scope to which [MZAP-LOCAL-GROUP]: The well-known group in the Local Scope to which
ZAMs are sent. All Multicast Address Allocation servers and Zone ZAMs are sent. All Multicast Address Allocation servers and Zone
Boundary Routers listen to this group. Value: 239.255.255.252 for IPv4; Boundary Routers listen to this group. Value: 239.255.255.252 for IPv4;
FF03:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFC for IPv6. FF03:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFC for IPv6.
skipping to change at page 24, line 4 skipping to change at page 24, line 43
[ZCM-INTERVAL]: The interval at which a Zone Boundary Router originates [ZCM-INTERVAL]: The interval at which a Zone Boundary 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
Draft MZAP June 1999
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 Boundary Router originates [NIM-INTERVAL]: The interval at which a Zone Boundary Router originates
Not-Inside Messages. Default value: 1800 seconds (30 minutes). Not-Inside Messages. Default value: 1800 seconds (30 minutes).
Draft MZAP October 1999
[NIM-HOLDTIME]: The holdtime to include the state within a NIM. This [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 SHOULD be set to at least 3 * [NIM-INTERVAL]. Default value: 5460 (91
minutes) minutes)
8. Security Considerations 8. Security Considerations
While unauthorized reading of MZAP messages is relatively innocuous (so While unauthorized reading of MZAP messages is relatively innocuous (so
encryption is generally not an issue), accepting unauthenticated MZAP encryption is generally not an issue), accepting unauthenticated MZAP
messages can be problematic. Authentication of MZAP messages can be messages can be problematic. Authentication of MZAP messages can be
provided by using the IPsec Authentication Header (AH) [12]. provided by using the IPsec Authentication Header (AH) [12].
skipping to change at page 25, line 4 skipping to change at page 25, line 43
Accepting unauthenticated ZAM messages, however, could cause Accepting unauthenticated ZAM messages, however, could cause
applications to believe that a scope zone exists when it does not. If applications to believe that a scope zone exists when it does not. If
these were believed, then applications may choose to use this non- these were believed, then applications may choose to use this non-
existent administrative scope for their uses. Such applications would existent administrative scope for their uses. Such applications would
be able to communicate successfully, but would be unaware that their be able to communicate successfully, but would be unaware that their
traffic may be traveling further than they expected. As a result, any traffic may be traveling further than they expected. As a result, any
application accepting unauthenticated ZAMs MUST only take scope names as application accepting unauthenticated ZAMs MUST only take scope names as
a guideline, and SHOULD assume that their traffic sent to non-local a guideline, and SHOULD assume that their traffic sent to non-local
scope zones might travel anywhere. The confidentiality of such traffic scope zones might travel anywhere. The confidentiality of such traffic
Draft MZAP June 1999
CANNOT be assumed from the fact that it was sent to a scoped address CANNOT be assumed from the fact that it was sent to a scoped address
that was discovered using MZAP. 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 (MAASs) of names and address ranges of scopes, and accepting Servers (MAASs) of names and address ranges of scopes, and accepting
unauthenticated ZAMs could result in false names being presented to unauthenticated ZAMs could result in false names being presented to
users, and in wrong addresses being allocated to users. To counter users, and in wrong addresses being allocated to users. To counter
this, MAAS's authenticate ZAMs as follows: this, MAAS's authenticate ZAMs as follows:
Draft MZAP October 1999
(1) A ZBR signs all ZAMs it originates (using an AH). (1) A ZBR signs all ZAMs it originates (using an AH).
(2) A ZBR signs a ZAM it relays if and only if it can authenticate the (2) A ZBR signs a ZAM it relays if and only if it can authenticate
previous sender. A ZBR MUST still forward un-authenticated ZAMs the previous sender. A ZBR MUST still forward un-authenticated
(to provide leak detection), but should propagate an authenticated ZAMs (to provide leak detection), but should propagate an
ZAM even if an un-authenticated one was received with the last authenticated ZAM even if an un-authenticated one was received
[ZAM-DUP-TIME] seconds. with the last [ZAM-DUP-TIME] seconds.
(3) A MAAS SHOULD be configured with the public key of the local zone (3) A MAAS SHOULD be configured with the public key of the local zone
in which it resides. A MAAS thus configured SHOULD ignore an in which it resides. A MAAS thus configured SHOULD ignore an
unauthenticated ZAM if an authenticated one for the same scope has unauthenticated ZAM if an authenticated one for the same scope
been received, and MAY ignore all unauthenticated ZAMs. has been received, and MAY ignore all unauthenticated ZAMs.
9. Acknowledgements 9. Acknowledgements
This document is a product of the MBone Deployment Working Group, whose This document is a product of the MBone Deployment Working Group, whose
members provided many helpful comments and suggestions. The Multicast members provided many helpful comments and suggestions, Van Jacobson
Address Allocation Working Group also provided useful feedback regarding provided some of the original ideas that led to this protocol. The
scope names and interactions with applications. Multicast Address Allocation Working Group also provided useful feedback
regarding scope names and interactions with applications.
10. References 10. References
[1] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July [1] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
1998. 2365, July 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", BCP 14, RFC 2119, March 1997.
[3] Handley, M., Thaler, D., and D. Estrin, "The Internet Multicast [3] Thaler, D., Handley, M., and D. Estrin, "The Internet Multicast
Address Allocation Architecture", Internet Draft, Dec 1997. Address Allocation Architecture", Work in Progress, October 1999.
[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.
Draft MZAP June 1999
[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", Work in Progress, 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., and S. Hanna. "Multicast Address Allocation Protocol
handley-aap-01.txt, Internet Draft, July 1998. (AAP)", Work in Progress, October 1999.
Draft MZAP October 1999
[8] Kermode, R. "Scoped Hybrid Automatic Repeat reQuest with Forward [8] Kermode, R. "Scoped Hybrid Automatic Repeat reQuest with Forward
Error Correction (SHARQFEC)", ACM SIGCOMM 98, September 1998, Error Correction (SHARQFEC)", ACM SIGCOMM 98, September 1998,
Vancouver, Canada. Vancouver, Canada.
[9] Patel, B., Shah, M., and S. Hanna. "Multicast Address Dynamic [9] Patel, B., Shah, M., and S. Hanna. "Multicast Address Dynamic
Client Allocation Protocol (MADCAP)", Work in progress, May 1999. Client Allocation Protocol (MADCAP)", Work in progress, May 1999.
[10] J. Postel, "Assigned Numbers", RFC 1700, STD 2, October 1994. [10] J. Postel, "Assigned Numbers", RFC 1700, STD 2, October 1994.
[11] IANA, "Address Family Numbers", http://www.isi.edu/in- [11] IANA, "Address Family Numbers", http://www.isi.edu/in-
notes/iana/assignments/address-family-numbers notes/iana/assignments/address-family-numbers
[12] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, [12] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998. November 1998.
Draft MZAP June 1999
11. Authors' Addresses 11. Authors' Addresses
Mark Handley Mark Handley
AT&T Center for Internet Research at ICSI AT&T Center for Internet Research at ICSI
1947 Center St, Suite 600 1947 Center St, Suite 600
Berkely, CA 94704 Berkely, CA 94704
USA USA
Email: mjh@aciri.org Email: mjh@aciri.org
David Thaler David Thaler
Microsoft Microsoft
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
Email: dthaler@microsoft.com Email: dthaler@microsoft.com
Roger Kermode Roger Kermode
Motorola Australian Research Centre Motorola Australian Research Centre
12 Lord St, 12 Lord St,
Botany, NSW 2109 Botany, NSW 2019
Australia Australia
Email: Roger_Kermode@email.mot.com Email: Roger_Kermode@email.mot.com
12. Full Copyright Statement 12. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
Draft MZAP October 1999
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 implementation 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
Draft MZAP June 1999
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.
Table of Contents Table of Contents
1 Introduction .................................................... 2 1 Introduction .................................................... 2
2 Terminology ..................................................... 4 2 Terminology ..................................................... 4
3 Overview ........................................................ 5 3 Overview ........................................................ 5
3.1 Scope Nesting ................................................. 6 3.1 Scope Nesting ................................................. 6
3.2 Other Messages ................................................ 7 3.2 Other Messages ................................................ 7
3.3 Zone IDs ...................................................... 7 3.3 Zone IDs ...................................................... 7
4 Detecting Router Misconfigurations .............................. 8 4 Detecting Router Misconfigurations .............................. 8
4.1 Detecting non-convex scope zones .............................. 8 4.1 Detecting non-convex scope zones .............................. 8
4.2 Detecting leaky boundaries for non-local scopes ............... 9 4.2 Detecting leaky boundaries for non-local scopes ............... 9
4.3 Detecting a leaky Local Scope zone ............................ 10 4.3 Detecting a leaky Local Scope zone ............................ 10
4.4 Detecting conflicting scope zones ............................. 10 4.4 Detecting conflicting scope zones ............................. 11
5 Packet Formats .................................................. 11 5 Packet Formats .................................................. 11
5.1 Zone Announcement Message ..................................... 14 5.1 Zone Announcement Message ..................................... 14
5.2 Zone Limit Exceeded (ZLE) ..................................... 15 5.2 Zone Limit Exceeded (ZLE) ..................................... 16
5.3 Zone Convexity Message ........................................ 15 5.3 Zone Convexity Message ........................................ 16
5.4 Not-Inside Message ............................................ 16 5.4 Not-Inside Message ............................................ 17
6 Message Processing Rules ........................................ 17 6 Message Processing Rules ........................................ 18
6.1 Internal entities listening to MZAP messages .................. 17 6.1 Internal entities listening to MZAP messages .................. 18
6.2 Sending ZAMs .................................................. 18 6.2 Sending ZAMs .................................................. 19
6.3 Receiving ZAMs ................................................ 18
6.4 Sending ZLEs .................................................. 20 Draft MZAP October 1999
6.5 Receiving ZLEs ................................................ 21
6.6 Sending ZCMs .................................................. 21 6.3 Receiving ZAMs ................................................ 19
6.7 Receiving ZCMs ................................................ 21 6.4 Sending ZLEs .................................................. 21
6.8 Sending NIMs .................................................. 22 6.5 Receiving ZLEs ................................................ 22
6.9 Receiving NIMs ................................................ 22 6.6 Sending ZCMs .................................................. 22
7 Constants ....................................................... 23 6.7 Receiving ZCMs ................................................ 22
8 Security Considerations ......................................... 24 6.8 Sending NIMs .................................................. 23
9 Acknowledgements ................................................ 25 6.9 Receiving NIMs ................................................ 23
10 References ..................................................... 25 7 Constants ....................................................... 24
8 Security Considerations ......................................... 25
9 Acknowledgements ................................................ 26
10 References ..................................................... 26
11 Authors' Addresses ............................................. 27 11 Authors' Addresses ............................................. 27
12 Full Copyright Statement ....................................... 27 12 Full Copyright Statement ....................................... 27
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/