MBoneD Working Group                                       Mark Handley
Internet Engineering Task Force                                     ISI                                    AT&T
INTERNET-DRAFT                                              Dave Thaler
17 February
22 June 1999                                                  Microsoft
Expires August December 1999                                     Roger Kermode
                                                               Motorola

           Multicast-Scope Zone Announcement Protocol (MZAP)
                    <draft-ietf-mboned-mzap-03.txt>
                    <draft-ietf-mboned-mzap-04.txt>

                          Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

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
updated, replaced, or obsoleted by other documents at any time.  It is
inappropriate to use Internet Drafts as reference material or to cite
them other than as a "work in progress".

To view the
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.

Abstract Directories can be accessed at
http://www.ietf.org/shadow.html.Abstract

This document defines a protocol, the Multicast-Scope Zone Announcement
Protocol (MZAP), for discovering the multicast administrative scope
zones that are relevant at a particular location.  MZAP also provides
mechanisms whereby two common misconfigurations of administrative scope
zones can be discovered.

Copyright Notice

Copyright (C) The Internet Society (1999).  All Rights Reserved.

Draft                             MZAP                     February 1998                         June 1999

1.  Introduction

IP Multicast groups can be

The use of global scope, or they can be restricted in
scope using a scoping mechanism.  In this document, we only consider
administrative scoping, administratively-scoped IP multicast, as defined in RFC 2365 [1].  An administrative
scope zone is defined by a set of routers surrounding
[1], allows packets to be addressed to a region specific range of multicast
addresses (e.g., 239.0.0.0 to 239.255.255.255 for IPv4) such that the
network.  These "border routers" are
packets will not cross configured administrative boundaries, and also
allows such addresses to be locally assigned and hence are not pass multicast
traffic destined required
to be unique across administrative boundaries.  This property of logical
naming both allows for address reuse, as well as provides the capability
for infrastructure services such as address allocation, session
advertisement, and service location to use well-known addresses which
are guaranteed to have local significance within every organization.

The range of administratively-scoped addresses can be subdivided by
administrators so that multiple levels of administrative boundaries can
be simultaneously supported.  As a result, a "multicast scope" is
defined as a particular range of multicast addresses to which has been given some
topological meaning.

To support such usage, a router at an administrative boundary is
configured with one or
from links leaving more per-interface filters, or "multicast scope
boundaries".  Having such a boundary on an interface means that it will
not forward packets matching a configured range of multicast addresses
in either direction on the interface.

A specific area of the network topology which is within a boundary for a
given scope is known as a "multicast scope zone".  Since the same ranges
can be reused within disjoint areas of the network, there may be many
"multicast scope zone. zones" for any given multicast scope.  A scope zone may
have zero or more textual names (in different languages) for the scope,
for human convenience.  For example, if the range 239.192/14 were
assigned to span an entire corporate network, it might be given
(internally) the name "BigCo Private Scope".

Administrative scope zones may be of any size, and a particular host may
be within many administrative scope zones (for different scopes, i.e.,
for non-overlapping ranges of addresses) of various sizes. The only sizes, as long as
scope zones a host can assume that it is within intersect topologically do not intersect in address
range.

Applications and services are interested in various aspects of the global zone, and
scopes within which they reside:

o    Applications which present users with a
"Local Scope".  A Local Scope is defined as being the smallest
administrative choice of which scope zone encompassing a host, and the border is
configured for addresses in the range 239.255.0.0
     which to 239.255.255.255
inclusive.  RFC 2365 specifies:
   "239.255.0.0/16 operate (e.g., when creating a new session, whether it is defined

Draft                             MZAP                         June 1999

     to be confined to a corporate intranet, or whether it should go out
     over the IPv4 Local Scope.  The Local
   Scope is public Internet) are interested in the minimal enclosing scope, and hence is not further
   divisible. Although textual names which
     have significance to users.

o    Services which use "relative" multicast addresses (as defined in
     [1]) in every scope are interested in the exact extent range of addresses used
     by each scope, so that they can apply a Local Scope is site
   dependent, locally scoped regions must obey certain topological
   constraints. In particular, a Local Scope must not span any other
   scope boundary. Further, a Local Scope must be completely contained
   within or equal constant offset and compute
     which address to any larger use in each scope. In

o    Address allocators are interested in the event that scope regions
   overlap address range, and whether
     they are allowed to allocate addresses within the entire range or
     not.

o    Some applications and services may also be interested in area, the area
     nesting relationships among scopes.  For example, knowledge of overlap must the
     nesting relationships can be used to perform "expanding-scope"
     searches in its own Local Scope.
   This implies that any scope boundary is also a boundary for similar, but better behaved, manner to the Local
   Scope."
as well as:
   "administrative scopes that intersect topologically should not
   intersect 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 address range." localizing multicast repair
     traffic [8].

Two problems barriers currently make administrative scoping difficult to deploy
and use:

o  Applications have no way to dynamically discover information on
   scopes that are relevant to them.  This makes it difficult to use: use
   administrative scope zones, and hence reduces the incentive to deploy
   them.

o  Misconfiguration is easy.  It is difficult to detect scope zones that
   have been configured so as to not be convex (the shortest path
   between two nodes within the zone passes outside the zone), or to
   leak (one or more border boundary routers were not configured correctly), or
   to intersect in both area and address range.

o  Applications have no way to discover the scope zones that

These two barriers are
   relevant to them.  This makes it difficult to use administrative
   scope zones, and hence reduces the incentive to deploy them.

Draft                             MZAP                     February 1998

 This addressed by this document.  In particular, this
document defines the Multicast Scope Zone Announcement Protocol (MZAP)
which will provide applications with information about the allows an entity to learn what scope zones they are within, it is within.
Typically servers will cache the information learned from MZAP and also can
then provide this information to applications in a timely fashion upon
request using other means, e.g., via MADCAP [9].  MZAP also provides
diagnostic information to detect the boundary routers themselves that enables
misconfigured scope zones.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are zones to be interpreted as described detected.

Draft                             MZAP                         June 1999

2.  Terminology

The "Local Scope" is defined in RFC 2119 [2].

Constants used by this protocol are shown as [NAME-OF-CONSTANT], 2365 [1] and
summarized in section 5.

2.  Overview

A multicast represents the smallest
administrative scope Zone Border Router (ZBR) is a router that larger than link-local, and the associated address
range is
configured defined as 239.255.0.0 to be a zone border on one or more of its interfaces.  Any
interface that 239.255.255.255 inclusive (for IPv4,
FF03::/16 for IPv6).  RFC 2365 specifies:
   "239.255.0.0/16 is configured defined to be a border for any administrative scope
zone MUST also the IPv4 Local Scope.  The Local
   Scope is the minimal enclosing scope, and hence is not further
   divisible. Although the exact extent of a Local Scope is site
   dependent, locally scoped regions must obey certain topological
   constraints. In particular, a Local Scope must not span any other
   scope boundary. Further, a Local Scope must be completely contained
   within or equal to any larger scope. In the event that scope regions
   overlap in area, the area of overlap must be in its own Local Scope.
   This implies that any scope boundary is also a boundary for the Local
   Scope."

A multicast scope Zone Boundary Router (ZBR) is a router that is
configured with a boundary for a particular multicast scope on one or
more of its interfaces. Any interface that is configured with a boundary
for any administrative scope zone MUST also have a border boundary for the
Local Scope zone, as defined in [1].

Routers described above.

Such routers SHOULD be configured so that the router itself is within
the scope zone.  This is should shown in figure Figure 1(a), where router A is inside
the scope zone and has the border boundary configuration.  It is possible for the
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
and have the border configuration, but this is NOT RECOMMENDED.

      ............                     ................
     .            .   +B+-->          .                *B+-->
    .              . /               .                / .
   .                *               .                +   .
   .          <---+A*---+C+->       .          <---+A+---*C+->
   .              + .               .              +     .
   .             /  .               .             /      .
    . zone X  <--  .                 . zone X  <--      .
     ..............                   ..................

    A,B,C - routers    * - border boundary interface    + - interface

  (a) Correct zone border boundary         (b) Incorrect zone border boundary

         Figure 1: Administrative scope zone border boundary placement

It is possible for the first router outside the scope zone to be
configured with the boundary, as illustrated in Figure 1(b) where

Draft                             MZAP                         June 1999

routers B and C are outside the zone and have the boundary
configuration, whereas A does not, but this is NOT RECOMMENDED.  This
rule does not apply for Local Scope borders, boundaries, but applies for all
other administrative scope border boundary routers.

Draft                             MZAP                     February 1998

When a ZBR is configured correctly, it can deduce

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
zone.  The combination of this IP address and the first multicast
address in the scope range serve to uniquely identify the scope zone.
Each ZBR listens for messages from other ZBRs for the same boundary, and
can determine the Zone ID based on the source addresses seen.  The Zone
ID may change over time as ZBRs come up and down.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].

Constants used by this protocol are shown as [NAME-OF-CONSTANT], and
summarized in section 7.

3.  Overview

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
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.

Such a ZBR should then send sends periodic Zone Announcement Messages (ZAMs) for the
each zone for which it is configured as a border from one of its
interfaces that go boundary into that scope zone. zone,
containing information on the scope zone's address range, Zone ID, and
textual names.  These messages are multicast to the well-known address
[MZAP-LOCAL-GROUP] in the Local Scope.

Each ZBR also listens for messages from other ZBRs for the same border.
The ZBR with the lowest interface IP address Scope, and are relayed across Local
Scope boundaries into all Local Scope zones within the scope zone from those
ZBRs forming the zone border becomes the zone-id router for the zone.
The combination of this IP address and the first multicast address in
the scoped range serve
referred to uniquely identify by the scope zone.

When a ZBR receives a ZAM for some scope zone:

o  If the ZAM was received on an interface with a boundary for the given
   scope, the ZAM is not forwarded.  For example, router D message, as shown in figure 2
   will not forward the ZAM.

o  If the ZAM was received on an interface which is NOT a Figure 2.

Draft                             MZAP                         June 1999

    ###########################
    # Zone1      =      Zone2 #    ##### = large scope zone boundary
    *E-----+--->A*-----+-x    #
    #      |     =     v      #    ===== = Local Scope
   boundary, and the last Local Zone ID Address in the boundaries
    #      |     ======*===*==#
    #      |     =     B   F  #    ----> = path list is 0,
   the ZBR fills in the Local Zone ID Address of the local zone from
   which the ZAM was received.

o  If a ZAM for the same scope (as identified originated by the origin Zone ID and
   first multicast address) was received in the last [ZAM-DUP-TIME]
   seconds, the E
   G*<-----+--->C*->   |   ^  #
    #      v     =   <-+---+  #    ABCDE = ZBRs
    #      D     =      Zone3 #
    #######*###################        * = boundary interface

                     Figure 2: ZAM is not forwarded.  For example, when router C Flooding Example

Any entity can thus listen on a single well-known group address and
learn about all scopes in
   figure 2 receives the ZAM via B, it will not be forwarded, since which it
   has just forwarded resides.

3.1.  Scope Nesting

MZAP also provides the ZAM from E.

o  Otherwise, ability to discover the ZAM nesting relationships
between scope zones. Two zones are nested if one is cached for at least [ZAM-DUP-TIME] seconds.

o  If the Zone ID comprised of a
subset of the Local Scope zone routers in which the ZBR resides is
   not already other, as shown in the ZAM's path list, then the ZAM is immediately re-
   originated within the Local Scope zone.  It adds its own address Figure 3.

   +-----------+       +-----------+      +-------------+
   | Zone 1    |       | Zone 3    |      | Zone 5      |
   |   +------+|       |    +------+      |    .........|..
   |   |Zone 2||       |    |Zone 4|      |    : Zone 6 | :
   |   +--A---+|       |    C      |      |    D        | :
   +-----------+       +----+--B---+      +--------E----+ :
                                               :..........:

 (a) "Contained"    (b) "Common Border"  (c) "Overlap"
      Zone 2 nests       Zone 4 nests         Zones 5 and
   the zone-id of the Local Scope zone into which the message is being
   forwarded to the ZAM path list before doing so. 6
      inside Zone 1      inside Zone 3        do not nest

                    Figure 3: Zone nesting examples

A ZBR receiving a ZAM
   with a non-null path list MUST NOT forward that ZAM back into a Local
   Scope cannot independently determine whether one zone that is contained in the path list. nested inside
another.  However, it can determine that one zone does NOT nest inside
another.  For example, in figure 2, router F, which did not get the ZAM via 4:

o  ZBR A due to packet
   loss, will not forward the ZAM pass ZAMs for zone 1 but will prevent ZAMs from B back into Zone 2 since the path
   list has { (E,1), (A,2), (B,3) } and hence Zone zone 2 already appears.

Draft                             MZAP                     February 1998

o  In addition, the
   from leaving zone 2. When ZBR re-originates the ZAM out each interface with A first receives a
   Local Scope boundary (except that ZAM for zone 1, it is not sent back out the
   interface over which

Draft                             MZAP                         June 1999

   then knows that zone 1 does not nest within zone 2, but it was received, nor 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 when it sent into any local
   scope receives a ZAM for zone whose ID 3,
   since it is known a ZBR for zone 4 but not zone 3.

o  ZBR D only acts as ZBR zone 6 and appears in the path list).  In each
   such not 5, hence ZBR D can deduce that
   zone 5 does not nest inside zone 6 upon hearing a ZAM re-originated, the for zone 5.
   Similarly, ZBR adds its own IP address to the path
   list, as well E only acts as the Zone ID Address of the Local Scope Zone into
   which the 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
   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.  This is being sent, or 0 if the ID is unknown. (For example,
   if done by
sending Not-Inside Messages (NIMs) which express the other end of fact that a point-to-point link also has zone X
is not inside a boundary on zone Y.  Such messages are sent to the
   interface, then the link has no Local Scope Zone ID.)

    ###########################
    # Zone1      =      Zone2 #    ##### = large scope zone border
    *E-----+--->A*-----+-x    #
    #      |     =     v      #    ===== = Local Scope boundaries
    #      |     ======*===*==#
    #      |     =     B   F  #    ----> = path of ZAM originated well-known
[MZAP-LOCAL-GROUP] and are thus seen by E
    #      +--->C*->   |   ^  #
    #      v     =   <-+---+  #    ABCDE = ZBRs
    #      D     =      Zone3 #
    #######*###################        * = border interface

                     Figure 2: ZAM Flooding Example

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
packet should be dropped. Zones Traveled Limit is set when the packet is
first sent, and defaults same entities listening to 32, but
ZAM messages (e.g., MADCAP servers).  Such entities can be set to a lower value if a
network administrator knows then determine
the expected size nesting relationship between two scopes based on a sustained absence
of any evidence to the zone.

Additional messages called contrary.

3.2.  Other Messages

Two other message types, Zone Convexity Messages (ZCMs) SHOULD also be and Zone Limit
Exceeded (ZLE) messages, are used only by routers, and enable them to
compare their configurations for consistency and detect
misconfigurations.  These messages are sent to MZAP's relative address
within the [ZCM-RELATIVE-GROUP] in the scoped scope range itself.  As these
are not locally scoped packets, they are simply multicast across associated with the scope zone itself, and require no path to be built up, nor any special
processing which they
refer, and hence are typically not seen by Local Scope zone ZBRs.  These entities other than routers.
Their use in detecting specific misconfiguration scenarios will be
covered in the next section.

Packet formats for all messages are used to detect
non-convex administrative scope zones, as illustrated described in figure 3, where Section 5.

3.3.  Zone IDs

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
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

Draft                             MZAP                         June 1999

sent in the future (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 (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 out if no further messages are received from that
ZBR, such that the Zone ID will converge to the lowest address of any
active ZBR for the scope.

4.  Detecting Router Misconfigurations

In this section, we cover how to detect various error conditions. If any
error is detected, the router should attempt to alert a network
administrator to the nature of the misconfiguration. The means to do
this lies outside the scope of MZAP.

4.1.  Detecting non-convex scope zones

Zone Convexity Messages (ZCMs) are used by routers to detect non-convex
administrative scope zones, which are one possible misconfiguration.
Non-convex scope zones can cause problems for applications since a
receiver may never see administratively-scoped packets from a sender
within the same scope zone, since packets travelling between them may be
dropped at the boundary.

In the example illustrated in Figure 4, the path between B and D goes
outside the scope (through A and E). Here Here, Router B and Router C originates ZCMs, send
ZCMs within a given scope zone for which they each reporting have a boundary, with
each other's
presence. reporting the other boundary routers of the zone from which they
have heard.  In Figure 4, Router D cannot see Router B's messages, but
can see C's report of B, and so can conclude the zone is not convex.

Draft                             MZAP                     February 1998

    #####*####========
    #    B   #       =         ##### = non-convex scope boundary
    #    |->A*       =
    #    |   #       =         ===== = other scope boundaries
    #    |   ####*####
    #    |       E   #         ----> = path of B's ZAM ZCM
    #    v          D*
    #    C           #             * = border boundary interface
    #####*############

                   Figure 3: 4: Non-convexity detection

2.1.  Nesting

Draft                             MZAP also provides                         June 1999

Non-convex scope zones can be detected via two methods:

(1)  If a ZBR is listed in ZCMs received, but the ability next-hop interface
     (according to discover the nesting relationships
between scope zones. Two zones are nested if one multicast RIB) towards that ZBR is comprised of a
subset of outside the routers
     scope zone, or

(2)  If a ZBR is listed in the other, ZCMs received, but no ZCM is received from
     that ZBR for [ZCM-HOLDTIME] seconds, as shown illustrated 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 3.

Zone 4 nests         Zones 5 Convexity Messages MAY also be sent and 6
      inside Zone 1      inside Zone 3        do received by correctly
configured ordinary hosts within a scope region, which may be a useful
diagnostic facility that does not nest

                    Figure 4: Zone nesting examples

Nested require privileged access.

4.2.  Detecting leaky boundaries for non-local scopes provide the ability

A "leaky" boundary is one which logically has a "hole" due to perform "expanding-scope" searches
in some
router not having a similar, but better behaved, manner boundary applied on an interface where one ought to
exist.  Hence, the well-known expanding
ring search where boundary does not completely surround a piece of the TTL of a query is steadily increased until a
replier can be found.  Studies have also shown that nested scopes
network, resulting in scoped data leaking outside.

Leaky scope boundaries can be
useful in localizing multicast repair traffic [8].

A ZBR cannot independently determine whether one zone is nested detected via two methods:

(1)  If it receives ZAMs originating inside
another.  However, they can determine the scope boundary on an
     interface that one points outside the zone does NOT nest inside
another.  For example, boundary.  Such a ZAM
     message must have escaped the zone through a leak, and flooded back
     around behind the boundary.  This is illustrated in figure 4:

Draft                             MZAP                     February 1998

o  ZBR Figure 5.
         =============#####*########
         = Zone1      #    A will pass Zone2 #       C   = misconfigured router
         =      +---->*E   v       #
         =      |     #    B       #     ##### = leaky scope boundary
         =======*=====#====*=======#
         =      D     #    |       #     ===== = other scope boundaries
         =      ^-----*C<--+       #
         = Zone4      #      Zone3 #     ----> = path of ZAMs
         =============##############

                            Figure 5: ZAM Leaking

(2)  If a Zone Length Exceeded (ZLE) message is received.  The ZAM
     packet also contains a Zones Traveled Limit.  If the number of
     Local Scope zones traversed becomes equal to the Zones Traveled
     Limit, a ZLE message is generated (the suppression mechanism for zone 1
     preventing implosion is described later in the Processing Rules

Draft                             MZAP                         June 1999

     section).  ZLEs detect leaks where packets do not return to another
     part of the same scope zone, but will prevent ZAMs from zone 2 instead reach other Local Scope
     zones far away from leaving zone 2. the ZAM originator.

In either case, the misconfigured router will be either the message
origin, or one of the routers in the 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 path list which is nested inside included in
the other. However, message received (or perhaps a router on the path between two such
ZBRs which ought to have been a ZBR C can determine that
   zone 3 does not nest inside itself).

4.3.  Detecting a leaky Local Scope zone 4 since it

A local scope is leaky if 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, router has an administrative scope boundary
on some interface, but does not that have a zone does nest inside another, means Local Scope boundary on that
nesting must be determined
interface as specified in a distributed fashion.

When a ZBR receives RFC 2365.  This can be detected via the
following method:

o  If a ZAM for a given scope X for which it is NOT received by a border, it
creates ZBR which is 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 boundary
   for that scope, it compares the ZBR knows that X does not
nest inside any scope for which it is a border.  If Origin's Scope Zone ID in the entry's timer
expires (because no more ZAMs for X are heard ZAM
   with its own Zone ID for [ZAM-HOLDTIME]), the
entry given scope.  If the two do not match,
   this is deleted.

Periodically, at an interval evidence 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 misconfiguration.  Since a border.  Like temporary mismatch
   may result immediately after a ZAM, this message recent change in the reachability of
   the lowest-addressed ZBR, misconfiguration should be assumed only if
   the mismatch is multicast persistent.

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
group within the address [MZAP-LOCAL-GROUP] from range identified by the ZAM. The router at
fault will be the one of its interfaces in Y.

When reporting that a boundary was reached.

4.4.  Detecting conflicting scope zones

Conflicting address ranges can be detected via the following method:

o  If a ZBR receives a NIM saying that "X is ZAM for a given scope, and the included start and
   end addresses overlap with, but are not inside Y", it is
forwarded, unmodified, in identical to, the start and
   end addresses of a manner similar to ZAMs: locally-configured scope.

Conflicting scope names can be detected via the following method:

o  If the NIM was received on an interface a ZBR is configured with a boundary textual name for either X a given scope and
   language, and it receives a ZAM 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 ZCM with a name for the same X scope
   and Y (where each is identified by its first
   multicast address) was received in the last [ZAM-DUP-TIME] seconds, language, but the NIM is scope names do not forwarded. match.

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                         June 1999

Detecting either type of conflict above indicates that it is not sent back into either the local scope zone from which
router or the router originating the message was received, nor is it misconfigured.
Configuration tools SHOULD strip white space from the beginning and end
of each name to avoid accidental misconfiguration.

5.  Packet Formats

All MZAP messages are sent out any interface over UDP, with a boundary for either X destination port of [MZAP-
PORT] and an IPv4 TTL or Y.

3.  Usage

In this section, we summarize how to inform internal entities IPv6 Hop Limit of scopes
in which they reside, as well as how to detect various error conditions.
If any error is detected, the router should attempt 255.

When sending an MZAP message referring to alert a network
administrator to the nature of the misconfiguration.  The means to do
this lies outside the given scope of MZAP.

3.1.  Zone IDs

When zone, a border router first starts up, it uses its lowest IP ZBR MUST
use a source address which it considers to be inside a given will have significance everywhere within the
scope zone as to which the Zone ID for that
zone, and schedules the ZCM and ZAM messages to message refers.  For example, link-local
addresses MUST NOT be sent in the future
(it does not send them immediately).  When a ZAM or ZCM is received for
the given scope, used.

The common MZAP message header (which follows the sender UDP header), is added to the local list of ZBRs
(including itself) for that scope, and the shown
below:
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Version    |B|    PTYPE    |Address Family |   NameCount   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Message Origin                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Zone ID is updated to be the
lowest IP address Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Zone Start Address                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Zone End Address                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded Zone Name-1 (variable length)                         |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |     . . .                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  . . .        | Encoded Zone Name-N (variable length)         |
+-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |     Padding (if needed)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version:
   The version defined in this document is version 0.

"Big" scope bit (B):
   If clear, indicates that the list.  Entries addresses in the list are eventually timed
out if no further messages scoped range are received from that ZBR, such not

Draft                             MZAP                         June 1999

   subdividable, and that the
Zone ID will converge to the lowest address of any active ZBR for the
scope.

3.2.  Informing internal entities of scopes

Any host or application allocators may join utilize the [MZAP-LOCAL-GROUP] to listen for
Zone Announcement Messages to build up a list of the scope zones that
are relevant locally, and for Not-Inside Messages if it wishes to learn
nesting information.  However, listening for to such messages is entire
   range.  If set, address allocators should not use the
recommended method for regular applications to discover this
information.  These applications will normally query a local Multicast
Address Allocation Server [3], which entire range,
   but should learn an appropriate sub-range via another mechanism
   (e.g., AAP [7]).

Packet Type (PTYPE):
   The packet types defined in turn listens to this document are:
      0: Zone Announcement Messages and Message (ZAM)
      1: Zone Limit Exceeded (ZLE)
      2: Zone Convexity Message (ZCM)
      3: Not-Inside Messages to maintain scope
information.

Draft                             MZAP                     February 1998

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" Message (NIM)

Address Family:
   The IANA-assigned address family number [10,11] identifying the
   address family for at
     least [NIM-HOLDTIME] seconds.

3.3.  Detecting non-convex scope zones

Non-convex scope zones can be detected via two methods:

(1)  If a ZBR is listed all addresses in ZCMs received, but the next-hop interface
     (according to packet.  The families defined
   for IP are:
       1: IPv4
       2: IPv6

Name Count:
   The number of encoded zone name blocks in this packet.  The count may
   be zero.

Zone Start Address: 32 bits (IPv4) or 128 bits (IPv6)
   This gives the multicast RIB) towards that ZBR is outside start address for the scope zone, or

(2)  If a ZBR zone boundary.  For
   example, if the zone is listed in ZCMs received, but no ZCM is received from
     that ZBR a boundary for [ZCM-HOLDTIME] seconds, as illustrated in figure 3. 239.1.0.0 to 239.1.0.255, then
   Zone Convexity Messages MAY also be sent and received by correctly
configured ordinary hosts within a scope region, which may be a useful
diagnostic facility that does not require privileged access.

3.4.  Detecting leaky boundaries Start Address is 239.1.0.0.

Zone End Address: 32 bits (IPv4) or 128 bits (IPv6)
   This gives the ending address for non-local scopes

Leaky scope boundaries can be detected via two methods:

(1)  If it receives ZAMs originating inside the scope zone boundary.  For
   example, if the zone is a boundary on an for 239.1.0.0 to 239.1.0.255, then
   Zone End Address is 239.1.0.255.

Message Origin: 32 bits (IPv4) or 128 bits (IPv6)
   This gives the IP address of the interface that points outside originated the zone boundary.  Such
   message.

Zone ID Address: 32 bits (IPv4) or 128 bits (IPv6)
   This gives the lowest IP address of a ZAM
     message must have escaped boundary router that has been
   observed in the zone through a leak, originating the message.  Together with Zone
   Start Address and flooded back
     around behind Zone End Address, it forms a unique ID for the boundary.  This
   zone.  Note that this ID is illustrated usually different from the ID of the
   Local Scope zone in Figure 5.
         =============#####*########
         = Zone1      #    A Zone2 #       C   = misconfigured router
         =      +---->*E   v       #
         =      |     #    B       #     ##### = leaky scope boundary
         =======*=====#====*=======#
         =      D     # which the origin resides.

Encoded Zone Name:

Draft                             MZAP                         June 1999

   +--------------------+
   |D| Reserved (7 bits)|
   +--------------------+
   |       #     ===== = LangLen (1 byte)   |
   +--------------------+-----------+
   | Language Tag (variable size)   |
   +--------------------+-----------+
   | NameLen (1 byte)   |
   +--------------------+-----------+
   | 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:
   If set, indicates a preference that the name in the following
   language should be used if no name is available in a desired
   language.

Language tag length (LangLen): 1 byte
   The length, in bytes, of the language tag.

Language Tag: (variable size)
   The language tag, such as "en-US", indicating the language of the
   zone name.  Language tags are described in [6].

Name Len:
   The length, in bytes, of the Zone Name field.  The length MUST NOT be
   zero.

Zone Name: multiple of 8 bits
   The Zone Name is an ISO 10646 character string in UTF-8 encoding [4]
   indicating the name given to the scope boundaries
         =      ^-----*C<--+       #
         = Zone4      #      Zone3 #     ----> = path zone (eg: ``ISI-West Site'').
   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 ZAMs
         =============##############

                            Figure 5:
   each name before encoding, to avoid accidental conflicts.

Padding (if needed):
   The end of the MZAP header is padded with null bytes until it is 4-
   byte aligned.

Draft                             MZAP                         June 1999

5.1.  Zone Announcement Message

A Zone Announcement Message has PTYPE=0, and is periodically sent by a
ZBR for each scope for which it is a boundary, EXCEPT:

o    the Local Scope

o    the Link-local scope

The format of a Zone Announcement Message is shown below:
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      ZT       |     ZTL       |           Hold Time           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Local Zone ID Address 0                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Router Address 1                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Local Zone ID Address 1                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Router Address N                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Local Zone ID Address N                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields are defined as follows:
Zones Traveled (ZT): 8 bits
   This gives the number of Local Zone IDs contained in this message
   path.

Zones Traveled Limit (ZTL): 8 bits
   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
   limit exists.

Hold Time:
   The time, in seconds, after which the receiver may assume the scope
   no longer exists, if no subsequent ZAM Leaking

Draft                             MZAP                     February 1998

(2)  If a ZLE message is received.

In either case, the misconfigured router will  This should be either the message
origin,
   set to [ZAM-HOLDTIME].

Draft                             MZAP                         June 1999

Zone Path: multiple of 64 bits (IPv4) or one 256 bits (IPv6)
   The zone path is a list of Local Zone ID Addresses (the Zone ID
   Address of a local zone) through which the routers in ZAM has passed, and IP
   addresses of the path list included router that forwarded the packet.  The origin router
   fills in the message
received.

3.5.  Detecting "Local Zone ID Address 0" field when sending the ZAM.
   Every Local Scope router that forwards the ZAM across a leaky Local Scope zone

A
   boundary MUST add the Local Zone ID Address of the local scope zone that
   the packet of the zone into which the message is leaky if a router has an administrative scope boundary
on some interface, but does not have being forwarded, and
   its own IP address to the end of this list, and increment ZT
   accordingly.  The zone path is empty which the ZAM is first sent.

5.2.  Zone Limit Exceeded (ZLE)

The format of a ZLE is shown below:
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      ZT       |     ZTL       |         Hold Time             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Local Zone ID Address 0                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Router Address 1                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Local Zone ID Address 1                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Router Address N                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Local Scope boundary on that
interface as specified in RFC 2365.  This can be detected via Zone ID Address N                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

All fields are copied from the
following method:

o  If a ZAM for a given scope ZAM, except PTYPE which is received set to one.

5.3.  Zone Convexity Message

A Zone Announcement Message has PTYPE=2, and is periodically sent by a
ZBR for each scope for which it is a border for boundary (except the Link-local
scope).  Note that scope, it compares ZCM's ARE sent in the Origin's Scope Local Scope.

Draft                             MZAP                         June 1999

Unlike Zone ID in Announcement Messages which are sent to the ZAM with
   its own [MZAP-LOCAL-
GROUP], Zone ID for Convexity Messages are sent to the given scope.  If [ZCM-RELATIVE-GROUP] in
the two do not match, this
   is evidence scope zone itself.  The format of a misconfiguration.  Since a temporary mismatch may
   result immediately after a recent change in ZCM is shown below:
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            MZAP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ZNUM      |  unused       |           Hold Time           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          ZBR Address 1                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          ZBR Address N                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields are as follows:
Number of ZBR addresses (ZNUM): 8 bits
   This field gives the reachability number of ZBR Addresses contained in this
   message.

Hold Time:
   The time, in seconds, after which the
   lowest-addressed ZBR, misconfiguration receiver may assume the sender
   is no longer reachable, if no subsequent ZCM is received.  This
   should be assumed only if set to [ZCM-HOLDTIME].

ZBR Address: 32 bits (IPv4) or 128 bits (IPv6)
   These fields give the
   mismatch is persistent.

The exact location addresses of the problem can be found by doing an mtrace [5] other ZBRs from which the router detecting the problem, back to the ZAM origin, for any
group within the address range identified by the ZAM. The router at
fault will be the one reporting that a boundary was reached.

3.6.  Detecting conflicting scope zones

Conflicting address ranges can be detected via the following method:

o  If a
   Message Origin ZBR receives a ZAM for a given scope, and the included start and
   end addresses overlap with, has received ZCMs but are whose hold time has not identical to, the start and
   end
   expired.  The router should include all such addresses of a locally-configured scope.

Conflicting scope names can be detected via which fit in
   the following method:

o  If a ZBR is configured with a non-empty scope name for a given scope,
   and packet, preferring those which it receives a ZAM with a non-empty scope name for the same scope,
   and the scope names has not included recently if
   all do not match.

Detecting either type of conflict above indicates that either the local
router or router originating the message is misconfigured.
Configuration tools SHOULD strip white space from the beginning fit.

5.4.  Not-Inside Message

A Not-Inside Message (NIM) has PTYPE=3, and end

Draft                             MZAP                     February 1998

of each name to avoid accidental misconfiguration.

3.7.  Packet Formats

All MZAP messages are is periodically sent over UDP, with by a destination port of [MZAP-
PORT].
ZBR which knows that a scope X does not nest within another scope Y ("X
not inside Y"):

The common MZAP message header (which follows the UDP header), format of a Not-Inside Message is shown below:

Draft                             MZAP                         June 1999

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Version    |B|    PTYPE    |Address Family |   NameCount   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Message Origin                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Zone ID Address                        |
                            MZAP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Not-Inside Zone Start Address                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Zone End Address                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded Zone Name-1 (variable length)                         |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |     . . .                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  . . .        | Encoded Zone Name-N (variable length)         |
+-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |     Padding (if needed)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version:

The version defined in this document is version 0.

"Big" scope bit (B):
   If clear, indicates that the addresses in the scoped range fields are not
   subdividable, and that address allocators may utilize the entire
   range.  If set, address allocators should not use the entire range,
   but should learn an appropriate sub-range via another mechanism
   (e.g., AAP [7]).

Draft as follows:
MZAP                     February 1998

Packet Type (PTYPE):
   The packet types defined in this document are:
      0: Zone Announcement Message (ZAM)
      1: Zone Limit Exceeded (ZLE)
      2: Zone Convexity Message (ZCM)
      3: Not-Inside Message (NIM)

Address Family:
   The IANA-assigned address family number Header:
   Header fields identifying the address
   family for all addresses in the packet.  The families defined for IP
   are:
       1: IPv4
       2: IPv6

Name Count:
   The number of encoded zone name blocks in this packet.  The count may
   be zero.

Zone Start Address: 32 bits (IPv4) or 128 bits (IPv6)
   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 X.  The Name Count may be 0.

Not-Inside Zone Start
   Address is 239.1.0.0.

Zone End Address: 32 bits (IPv4) or 128 bits (IPv6)
   This gives the ending 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 End Address is 239.1.0.255. Y.

6.  Message Origin: 32 bits (IPv4) Processing Rules

6.1.  Internal entities listening to MZAP messages

Any host or 128 bits (IPv6)
   This gives the IP address of the interface that originated application may join the
   message. [MZAP-LOCAL-GROUP] to listen for
Zone ID Address: 32 bits (IPv4) or 128 bits (IPv6)
   This gives the lowest IP address of Announcement Messages to build up a boundary router that has been
   observed in the zone originating list of the message.  Together with Zone
   Start Address scope zones that
are relevant locally, and Zone End Address, it forms a unique ID for the
   zone.  Note that this ID Not-Inside Messages if it wishes to learn
nesting information.  However, listening to such messages is NOT the ID of not the Local Scope zone in
recommended method for regular applications to discover this
information.  These applications will normally query a local Multicast
Address Allocation Server (MAAS) [3], which the origin resides.

Draft                             MZAP                     February 1998

Encoded Zone Name:
   +--------------------+
   |D| Reserved (7 bits)|
   +--------------------+
   | LangLen (1 byte)   |
   +--------------------+-----------+
   | Language Tag (variable size)   |
   +--------------------+-----------+
   | NameLen (1 byte)   |
   +--------------------+-----------+
   | in turn listens to 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:
   If set, indicates
Announcement Messages and Not-Inside Messages to maintain scope
information, and can be queried by clients via MADCAP messages.

An entity (including a preference MAAS) lacking any such information can only
assume that it is within the name in Global Scope, and the following
   language should be used if no name is available Local Scope, both of
which have well-known address ranges defined in [1].

An internal entity (e.g., an MAAS) receiving a desired
   language.

Language tag length (LangLen): 1 byte
   The length, in bytes, of ZAM will parse the language tag.

Language Tag: (variable size)
   The language tag,
information that is relevant to it, such as "en-US", indicating the language of address range, and the
   zone name.  Language tags are described in [6].

Name Len:
   The length, in bytes,
names.  An address allocator receiving such information MUST also use
the "B" bit to determine whether it can add the address range to the set
of ranges from which it may allocate addresses (specifically, it may add
them only if the bit is zero).  Even if the bit is zero, an MAAS SHOULD
still store the range information so that clients who use relative-
addresses can still obtain the ranges by requesting them from the MAAS.

An internal entity (e.g., an MAAS) may assume that X nests within Y if:

Draft                             MZAP                         June 1999

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.

6.2.  Sending ZAMs

Each ZBR should send a Zone Name field. Announcement Message for each scope zone for
which it is a boundary every [ZAM-INTERVAL] seconds, +/- 30% of [ZAM-
INTERVAL] each time to avoid message synchronisation.

The length MUST NOT be
   zero.

Zone Name: multiple ZAM packet also contains a Zones Traveled Limit (ZTL).  If the
number of 8 bits
   The Local Zone Name is an ISO 10646 character string IDs in UTF-8 encoding [4]
   indicating the name given ZAM path becomes equal to the scope zone (eg: ``ISI-West Site'').
   It should be relatively short and MUST be less than 256 bytes in
   length. White space SHOULD Zones
Traveled Limit, the packet will be stripped from dropped.  The ZTL field is set when
the beginning packet is first sent, and end of
   each name before encoding, to avoid accidental conflicts.  All the
   border routers defaults to the same region SHOULD 32, but can be configured set to give the
   same Zone Name, or a zero length string MAY be given.  A zero length
   string is taken to mean that another router is lower
value if a network administrator knows the expected to be
   configured with size of the zone.

6.3.  Receiving ZAMs

When a ZBR receives a ZAM for some scope zone name.  Having ALL X, it uses the ZBRs following
rules.

If the local ZBR does NOT have any configuration for a scope zone
   announce zero length names should be considered an error.

Padding (if needed):
   The X:

(1)  Check to see if the included start and end of addresses overlap with,
     but are not identical to, the MZAP header is padded with null bytes until it is 4-

Draft                             MZAP                     February 1998

   byte aligned.

Draft                             MZAP                     February 1998

3.7.1.  Zone Announcement Message

A Zone Announcement Message has PTYPE=0, start and is periodically sent by end addresses of any
     locally-configured scope Y, and if so, signal an address range
     conflict to a local administrator.

(2)  Create a local "X not inside" state entry, if such an entry does
     not already exist.  The ZBR then restarts the entry's timer at
     [ZAM-HOLDTIME].  Existence of this state indicates that the ZBR for each
     knows that X does not nest inside any scope for which it is a border, EXCEPT:

o
     boundary.  If the Global Scope

o entry's timer expires (because no more ZAMs for X
     are heard for [ZAM-HOLDTIME]), the Local Scope

o entry is deleted.

If the Link-local local ZBR does have configuration for scope

The format of X:

(1)  If the ZAM originated from OUTSIDE the scope (i.e., received over a Zone Announcement Message is shown below:
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     boundary interface for scope X):

Draft                             MZAP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      ZT       |     ZTL       |           Hold Time           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Local                         June 1999

     a)
        If the Scope Zone ID Address 0                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Router Address 1                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Local in the ZAM matches the ZBR's own Scope Zone ID Address 1                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Router Address N                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Local
        ID, then signal a leaky scope misconfiguration.

     b)
        Drop the ZAM (perform no further processing below).  For
        example, router G in Figure 2 will not forward the ZAM. This
        rule is primarily a safety measure, since the placement of G in
        Figure 2 is not a recommended configuration, as discussed
        earlier.

(2)  If the ZAM originated from INSIDE the scope:

     a)
        Add the Origin to the local list of ZBRs (including the local
        ZBR) for scope X, and update the Zone ID Address N                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Authentication Block (optional)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields are defined as follows:
Zones Traveled (ZT): 8 bits
   This gives is to be the lowest IP
        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 number of Local Zone IDs contained in this message
   path.

Zones Traveled Limit (ZTL): 8 bits
   This gives ID will converge to the limit on number lowest
        address of local zones that any active ZBR for the packet can
   traverse before it MUST be dropped.  A value of 0 indicates that no
   limit exists.

Draft                             MZAP                     February 1998

Hold Time:
   The time, scope.

     b)
        If the Origin's Scope Zone ID in seconds, after which the receiver may assume ZAM does not match the
        Scope Zone ID kept by the local ZBR, and this mismatch continues
        to occur, then signal a possible leaky scope
   no longer exists, warning.

     c)
        For each textual name in the ZAM, see if no subsequent ZAM a name for the same
        scope and language is received.  This should be
   set locally-configured; if so, but the scope
        names do not match, signal a scope name conflict to [ZAM-HOLDTIME].

Zone Path: multiple of 64 bits (IPv4) or 256 bits (IPv6)
   The zone path a local
        administrator.

     d)
        If the ZAM was received on an interface which is NOT a list of Local
        Scope boundary, and the last Local Zone ID Addresses (the Address in the path
        list is 0, the ZBR fills in the Local Zone ID Address of a the
        local zone) through zone from which the ZAM has passed, was received.

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]
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
receives the ZAM via B, it will not be forwarded, since it has just
forwarded the ZAM from E.

Draft                             MZAP                         June 1999

The Zones Travelled count in the message is then incremented, and IP
   addresses of if the router that forwarded
updated count is equal to or greater than the packet.  The origin router
   fills ZTL field, schedule a ZLE
to be sent as described in the "Local next subsection and perform no further
processing below.

If the Zone ID Address 0" field when sending of the ZAM.
   Every Local Scope router that forwards zone in which the ZBR resides is not
already in the ZAM's path list, then the ZAM across a is immediately re-
originated within the Local Scope
   boundary MUST add zone.  It adds its own address and the Local
Zone ID Address of the local zone that
   the packet of the Local Scope zone into which the message is being forwarded, and
   its own IP address
forwarded to the end of this list, and increment ZT
   accordingly.  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
Scope zone that is contained in the path list.  For example, in Figure
2, router F, which did not get the ZAM via A due to packet loss, will
not forward the ZAM from B back into Zone 2 since the path list has {
(E,1), (A,2), (B,3) } and hence Zone 2 already appears.

In addition, the ZBR re-originates the ZAM out each interface with a
Local Scope boundary (except that it is empty not sent back out the 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 such ZAM is first sent.

Authentication Block:
   If present, this provides information which can be used re-
originated, the ZBR adds its own IP address to
   authenticate the sender path list, as well as
the Zone ID Address of the Local Scope Zone into which the ZAM (i.e. Router Address N, if ZT is
   non-zero, being
sent, or Message Origin, 0 if ZT the ID is zero).  (TBD: any reason not to
   re-use SAP's "Authentication Header" here?)

3.7.2. unknown. (For example, if the other end of a
point-to-point link also has a boundary on the interface, then the link
has no Local Scope Zone Limit Exceeded (ZLE) ID.)

6.4.  Sending ZLEs

This packet is sent by a local-zone border boundary router that would have
exceeded the Zone Traveled Limit if it had forwarded a ZAM packet. To
avoid ZLE implosion, ZLEs are multicast with a random delay and
suppressed by other ZLEs.  It is only scheduled if at least [ZLE-MIN-
INTERVAL] seconds have elapsed since it previously sent a ZLE to any
destination.  To schedule a ZLE, the router sets a random delay timer
within the interval [ZLE-SUPPRESSION-INTERVAL], and listens to the
[MZAP-RELATIVE-GROUP] within the included scope for other ZLEs.  If any
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
to the [MZAP-RELATIVE-GROUP] within the indicated scope.

The method used to choose a random delay (T) is as follows:
  Choose a random value X from the uniform random interval [0:1]
  Let C = 256
  Set T = [ZLE-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C)

Draft                             MZAP                         June 1999

This method equation results in an exponential random distribution which
ensures that close to one ZBR will respond.

The format  Using a purely uniform
distribution would begin to exhibit scaling problems as the number of
ZBRs rose.  Since ZLEs are only suppressed if a duplicate ZLE arrives
before the time chosen, two routers choosing delays which differ by an
amount less than the propagation delay between them will both send
messages, consuming excess bandwidth.  Hence it is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      ZT       |     ZTL       |              unused           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Local Zone ID Address 0                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Router Address 1                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Local Zone ID Address 1                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Router Address N                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Local desirable to minimize
the number of routers choosing a delay close to the lowest delay chosen,
and an exponential distribution is suitable for this purpose.

A router SHOULD NOT send more than one Zone ID Address N                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

All fields are copied from Limit Exceeded message every
[ZLE-MIN-INTERVAL] regardless of destination.

6.5.  Receiving ZLEs

When a router receives a ZLE, it performs the following actions:

(1)  If the ZAM, except PTYPE which is set to one.

A router receiving has a duplicate ZLE messages SHOULD log them and attempt message scheduled to alert be sent, it
     unschedules its own message so another one will not be sent.

(2)  If the
network administrator that ZLE contains the router's own address in the Origin field,
     it signals a leaky scope zone is misconfigured.

3.7.3. misconfiguration.

6.6.  Sending ZCMs

Each ZBR should send a Zone Convexity Message

A Zone Announcement Message has PTYPE=2, and is periodically sent by a
ZBR (ZCM) for each scope zone
for which it is a border, EXCEPT:

o    the Global Scope

o    the Link-local scope
(Note that ZCM's ARE sent in the Local Scope.)

Unlike Zone Announcement Messages which are sent boundary every [ZCM-INTERVAL] seconds, +/- 30% of
[ZCM-INTERVAL] each time to the [MZAP-LOCAL-
GROUP], Zone Convexity Messages avoid message synchronisation.

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
messages should be sent to 239.1.0.252.) As these are not Locally-Scoped
packets, they are simply multicast across the scope zone itself.  The format of itself, and
require no path to be built up, nor any special processing by
intermediate Local Scope ZBRs.

6.7.  Receiving ZCMs

When a ZCM 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ZNUM      |  unused       |           Hold Time           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          ZBR Address 1                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          ZBR Address N                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ received for a given scope X, on an interface which is
inside the scope, it follows the rules below:

Draft                             MZAP                         June 1999

(1)  The fields 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
     address in the list.  The new entry is scheduled to be timed out
     after [ZCM-HOLDTIME] if no further messages are as follows:
Number received from that
     ZBR, so that the Zone ID will converge to the lowest address of any
     active ZBR addresses (ZNUM): 8 bits
   This field gives for the number of scope.

(2)  If a ZBR Addresses contained in this
   message.

Hold Time:
   The time, is listed in seconds, after which ZCMs received, but the receiver may assume next-hop interface
     (according to the sender multicast RIB) towards that ZBR is no longer reachable, outside the
     scope zone, or if no subsequent ZCM is received.  This
   should be set to [ZCM-HOLDTIME]. received from that ZBR Address: 32 bits (IPv4) or 128 bits (IPv6)
   These fields give for [ZCM-
     HOLDTIME] seconds, as in the addresses of example in Figure 3, then signal a
     non-convexity problem.

(3)  For each textual name in the other ZBRs from which ZCM, see if a name for the
   Message Origin ZBR has received ZCMs same scope
     and language is locally-configured; if so, but whose hold time has the scope names do
     not
   expired.  The match, signal a scope name conflict to a local administrator.

6.8.  Sending NIMs

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
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.

Each ZBR should include all send such addresses which fit in
   the packet, preferring those which it has not included recently if
   all do not fit.

3.7.4.  Not-Inside Message

A a Not-Inside Message (NIM) has PTYPE=3, and is periodically sent by every [NIM-INTERVAL]
seconds, +/- 30% of [NIM-INTERVAL] to avoid message synchronization.

6.9.  Receiving NIMs

When a ZBR which knows that receives a scope X does not nest within another scope Y ("X NIM saying that "X is not inside Y"):

The format of a Not Inside Message Y", it 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
forwarded, unmodified, in a manner similar to ZAMs:

(1)  If the scope X.  The Name Count may be 0.

Not-Inside Zone Start Address: 32 bits (IPv4) NIM was received on an interface with a boundary for either
     X or 128 bits (IPv6)
   This gives Y, the start address for NIM is discarded.

(2)  Unlike ZAMs, if the scope Y.

Authentication Block:
   If present, this provides information which can be used NIM was not received on the interface towards
     the message origin (according to
   authenticate the sender of Multicast RIB), the NIM is
     discarded.

(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]
     seconds, the NIM is not forwarded.

Draft                             MZAP                         June 1999

(4)  Otherwise, the NIM is cached for at least [ZAM-DUP-TIME] seconds.

(5)  The ZBR then re-originates the NIM (i.e. Message Origin in (i.e., with the MZAP
   Header).

4.  Message Timing

Each ZBR should send a Zone Announcement Message for original UDP
     payload) into each local scope zone for in which it is a boundary every [ZAM-INTERVAL] seconds, +/- 30% of [ZAM-
INTERVAL] each time to avoid message synchronisation.

Each ZBR should send a Zone Convexity Message for each scope zone for
which has interfaces,
     except that it is a boundary every [ZCM-INTERVAL] seconds, +/- 30% of [ZCM-
INTERVAL] each time to avoid message synchronisation.

A router SHOULD NOT send more than one Zone Limit Exceeded message every
[ZLE-MIN-INTERVAL] regardless of destination.

Each ZBR should send a Zone State Session Message for each not sent back into the local scope zone
for from
     which it the message was received, nor is it sent out any interface
     with a boundary every [ZNSM-INTERVAL] seconds, +/- 30% of
[ZNSM- INTERVAL] each time to avoid message synchronization.

5. for either X or Y.

7.  Constants

[MZAP-PORT]:  The well-known UDP port to which all MZAP messages are
sent.  Value: TBD by IANA.

Draft                             MZAP                     February 1998 2106.

[MZAP-LOCAL-GROUP]:  The well-known group in the Local Scope to which
ZAMs are sent.  All Multicast Address Allocation servers and Zone Border
Boundary Routers listen to this group.  Value: TBD by IANA. 239.255.255.252 for IPv4;
FF03:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFC for IPv6.

[ZCM-RELATIVE-GROUP]:  The relative group in each scope zone, to which
ZCMs are sent.  A Zone Border Boundary Router listens to the relative group in
each scope for which it is a border. boundary.  Value: TBD by IANA. (last IP address in scope
range) - 3.  For example, in the Local Scope, the relative group is the
same as the [MZAP-LOCAL-GROUP] address.

[ZAM-INTERVAL]:  The interval at which a Zone Border Boundary Router originates
Zone Announcement Messages.  Default value: 600 seconds (10 minutes).

[ZAM-HOLDTIME]:  The holdtime to include in a ZAM.  This SHOULD be set
to at least 3 * [ZAM-INTERVAL].  Default value: 1860 seconds (31
minutes).

[ZAM-DUP-TIME]:  The time interval after forwarding a ZAM, during which
ZAMs for the same scope will not be forwarded.  Default value: 30
seconds.

[ZCM-INTERVAL]:  The interval at which a Zone Border Boundary Router originates
Zone Convexity Messages.  Default value: 600 seconds (10 minutes).

[ZCM-HOLDTIME]:  The holdtime to include in a ZCM.  This SHOULD be set
to at least 3 * [ZCM-INTERVAL].  Default value: 1860 seconds (31
minutes).

[ZLE-SUPPRESSION-INTERVAL]:  The interval over which to choose a random
delay before sending a ZLE message.  Default value: 300 seconds (5

Draft                             MZAP                         June 1999

minutes).

[ZLE-MIN-INTERVAL]:  The minimum interval between sending ZLE messages,
regardless of destination.  Default value: 300 seconds (5 minutes).

[NIM-INTERVAL]: The interval at which a Zone Border Boundary Router originates
Zone Not Inside
Not-Inside Messages.  Default value is value: 1800 seconds (30 minutes) 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.

8.  Security Considerations

While unauthorized reading of MZAP does not include authentication in its messages.  Thus it messages is open
to misbehaving hosts sending spoof ZAMs, ZCMs, or NIMs.

Draft relatively innocuous (so
encryption is generally not an issue), accepting unauthenticated MZAP
messages can be problematic.  Authentication of MZAP                     February 1998 messages can be
provided by using the IPsec Authentication Header (AH) [12].

In the case of ZCMs, these spoof messages ZCMs and ZLEs, an attacker can cause false logging of
convexity and leakage problems.  It is likely that is would be purely an
annoyance, and not cause any significant problem.

In the case of ZAMs, spoof  (Such messages can also cause false logging of
configuration problems.  This is also considered to could
be authenticated, but since they may be sent within large scopes, the
receiver may not be able to authenticate a significant
problem. non-malicious sender.)

ZAMs and NIMs, on the other hand, are sent within the Local Scope, where
assuming a security relationship between senders and receivers is more
practical.

In the case of NIMs, spoof accepting unauthenticated 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

Accepting unauthenticated ZAM messages, however, could cause
applications to believe that a scope zone exists when it does not.  If
these were believed, then applications may choose to use this non-existent non-
existent administrative scope
zone for their uses.  Such applications would
be able to communicate successfully, but would be unaware that their
traffic may be traveling further than they expected.  As a result, applications any
application accepting unauthenticated ZAMs MUST only take scope names as
a guideline, and SHOULD assume that their traffic sent to non-local
scope zones might travel anywhere.  The confidentiality of such traffic

Draft                             MZAP                         June 1999

CANNOT be assumed from the fact that it was sent to a scoped address
that was discovered using MZAP.

In addition, ZAMs are used to inform Multicast Address Allocation
Servers (MAASs) of names and address ranges of scopes, and spoofed accepting
unauthenticated ZAMs would could result in false names being presented to
users, and in wrong addresses being allocated to users.  To counter
this, MAAS's authenticate ZAMs may be authenticated as follows:

(1)  A ZBR signs all ZAMs it originates. originates (using an AH).

(2)  A ZBR signs a ZAM it forwards relays if and only if it can authenticate the
     previous sender.  A ZBR MUST still forward un-authenticated ZAMs
     (to provide leak detection), but should propagate an authenticated
     ZAM even if an un-authenticated one was received with the last
     [ZAM-DUP-TIME] seconds.

(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
     unauthenticated ZAM if an authenticated one for the same scope has
     been received, and MAY ignore all unauthenticated ZAMs.

Draft                             MZAP                     February 1998

7.

9.  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.

10.  References

[1]  Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July
     1998.

[2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", RFC 2119, March 1997.

[3]  Handley, M., Thaler, D., and D. Estrin, "The Internet Multicast
     Address Allocation Architecture", Internet Draft, Dec 1997.

[4]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
     2279, January 1998.

Draft                             MZAP                         June 1999

[5]  Fenner, W., and S. Casner, "A ''traceroute'' facility for IP
     Multicast", draft-ietf-idmr-traceroute-ipm-02.txt, Internet Draft,
     November 1997.

[6]  Alvestrand, H., "Tags for the Identification of Languages", RFC
     1766, March 1995.

[7]  Handley, M., "Multicast Address Allocation Protocol (AAP)", draft-
     handley-aap-01.txt, Internet Draft, July 1998.

[8]  Kermode, R. "Scoped Hybrid Automatic Repeat reQuest with Forward
     Error Correction (SHARQFEC)", ACM SIGCOMM 98, September 1998,
     Vancouver, Canada.

8.  Acknowledgements

This document is a product of the MBone Deployment Working Group, whose
members provided many helpful comments

[9]  Patel, B., Shah, M., and suggestions.  The Multicast S. Hanna.  "Multicast Address Dynamic
     Client Allocation Working Group also provided useful feedback regarding
scope names Protocol (MADCAP)", Work in progress, May 1999.

[10] J. Postel, "Assigned Numbers", RFC 1700, STD 2, October 1994.

[11] IANA, "Address Family Numbers", http://www.isi.edu/in-
     notes/iana/assignments/address-family-numbers

[12] Kent, S., and interactions with applications.

9. R. Atkinson, "IP Authentication Header", RFC 2402,
     November 1998.

Draft                             MZAP                         June 1999

11.  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.

12.  Full Copyright Statement

Copyright (C) The Internet Society (1998). (1999).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works.  However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS
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
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE."

Draft                             MZAP                     February 1998 PURPOSE.

Table of Contents

1 Introduction ....................................................    2
2 Terminology .....................................................    4
3 Overview ........................................................    3
2.1    5
3.1 Scope Nesting ....................................................... .................................................    6
3 Usage ...........................................................    8
3.1
3.2 Other Messages ................................................    7
3.3 Zone IDs ......................................................    7
4 Detecting Router Misconfigurations ..............................    8
3.2 Informing internal entities of scopes .........................    8
3.3
4.1 Detecting non-convex scope zones ..............................    9
3.4    8
4.2 Detecting leaky boundaries for non-local scopes ...............    9
3.5
4.3 Detecting a leaky Local Scope zone ............................   10
3.6
4.4 Detecting conflicting scope zones .............................   10
3.7
5 Packet Formats ................................................ ..................................................   11
3.7.1
5.1 Zone Announcement Message ...................................   15
3.7.2 .....................................   14
5.2 Zone Limit Exceeded (ZLE) ...................................   16
3.7.3 .....................................   15
5.3 Zone Convexity Message ......................................   17
3.7.4 ........................................   15
5.4 Not-Inside Message ..........................................   18
4 ............................................   16
6 Message Timing Processing Rules ........................................   17
6.1 Internal entities listening to MZAP messages ..................   17
6.2 Sending ZAMs ..................................................   19
5   18
6.3 Receiving ZAMs ................................................   18
6.4 Sending ZLEs ..................................................   20
6.5 Receiving ZLEs ................................................   21
6.6 Sending ZCMs ..................................................   21
6.7 Receiving ZCMs ................................................   21
6.8 Sending NIMs ..................................................   22
6.9 Receiving NIMs ................................................   22
7 Constants .......................................................   19
6   23
8 Security Considerations .........................................   20
7 References ......................................................   22
8   24
9 Acknowledgements ................................................   22
9   25
10 References .....................................................   25
11 Authors' Addresses ..............................................   22
10 .............................................   27
12 Full Copyright Statement .......................................   23   27