    Network Working Group                                         M. Handley
    Request for Comments: 2776                                         ACIRI
    Category: Standards Track                                      D. Thaler
                                                                   Microsoft
                                                                  R. Kermode
                                                                    Motorola
                                                               February 2000

               Multicast-Scope Zone Announcement Protocol (MZAP)

    Status of this Memo

       This document specifies an Internet standards track protocol for the
       Internet community, and requests discussion and suggestions for
       improvements.  Please refer to the current edition of the "Internet
       Official Protocol Standards" (STD 1) for the standardization state
       and status of this protocol.  Distribution of this memo is unlimited.

    Copyright Notice

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

    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 common
       misconfigurations of administrative scope zones can be discovered.

    Table of Contents

       1 Introduction ................................................  2
       2 Terminology .................................................  4
       3 Overview ....................................................  5
       3.1 Scope Nesting .............................................  6
       3.2 Other Messages ............................................  7
       3.3 Zone IDs ..................................................  7
       4 Detecting Router Misconfigurations ..........................  8
       4.1 Detecting non-convex scope zones ..........................  8
       4.2 Detecting leaky boundaries for non-local scopes ...........  9
       4.3 Detecting a leaky Local Scope zone ........................ 10
       4.4 Detecting conflicting scope zones ......................... 10
       5 Packet Formats .............................................. 11
       5.1 Zone Announcement Message ................................. 14
       5.2 Zone Limit Exceeded (ZLE) ................................. 15
       5.3 Zone Convexity Message .................................... 15

    Handley, et al.             Standards Track                     [Page 1]

    RFC 2776                          MZAP                     February 2000

       5.4 Not-Inside Message ........................................ 16
       6 Message Processing Rules .................................... 17
       6.1 Internal entities listening to MZAP messages .............. 17
       6.2 Sending ZAMs .............................................. 18
       6.3 Receiving ZAMs ............................................ 18
       6.4 Sending ZLEs .............................................. 20
       6.5 Receiving ZLEs ............................................ 20
       6.6 Sending ZCMs .............................................. 21
       6.7 Receiving ZCMs ............................................ 21
       6.8 Sending NIMs .............................................. 21
       6.9 Receiving NIMs ............................................ 22
       7 Constants ................................................... 22
       8 Security Considerations ..................................... 23
       9 Acknowledgements ............................................ 24
       10 References ................................................. 25
       11 Authors' Addresses ......................................... 26
       12 Full Copyright Statement ................................... 27

    1.  Introduction

       The use of administratively-scoped IP multicast, as defined in RFC
       2365 [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 packets will not cross configured administrative
       boundaries, and also allows such addresses to be locally assigned and
       hence are not 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 addresses which has been given some
       topological meaning.

       To support such usage, a router at an administrative boundary is
       configured with one or 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 zones" for any given multicast scope.  A

    Handley, et al.             Standards Track                     [Page 2]

    RFC 2776                          MZAP                     February 2000

       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, as
       long as scope zones that intersect topologically do not intersect in
       address range.

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

       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
          to be confined to a corporate intranet, or whether it should go
          out over the public Internet) are interested in the 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 range of addresses used
          by each scope, so that they can apply a constant offset and
          compute which address to use in each scope.

       o  Address allocators are interested in the 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 the
          nesting relationships among scopes.  For example, knowledge of the
          nesting relationships can be used to perform "expanding-scope"
          searches in a similar, but better behaved, manner to the well-
          known expanding ring search where the TTL of a query is steadily
          increased until a replier can be found.  Studies have also shown
          that nested scopes can be useful in localizing multicast repair
          traffic [8].

       Two 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
          administrative scope zones, and hence reduces the incentive to
          deploy them.

    Handley, et al.             Standards Track                     [Page 3]

    RFC 2776                          MZAP                     February 2000

       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 boundary routers were not configured
          correctly), or to intersect in both area and address range.

       These two barriers are addressed by this document.  In particular,
       this document defines the Multicast Scope Zone Announcement Protocol
       (MZAP) which allows an entity to learn what scope zones it is within.
       Typically servers will cache the information learned from MZAP and
       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 the boundary routers themselves
       that enables misconfigured scope zones to be detected.

    2.  Terminology

       The "Local Scope" is defined in RFC 2365 [1] and represents the
       smallest 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, FF03::/16 for IPv6).  RFC 2365 specifies:

          "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
          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 boundary
       for the Local Scope zone, as described above.

       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 and has the boundary configuration.

    Handley, et al.             Standards Track                     [Page 4]

    RFC 2776                          MZAP                     February 2000

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

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

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

              Figure 1: Administrative scope zone 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
       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 boundaries, but applies for all
       other boundary routers.

       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.

       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, containing information on the scope zone's address range, Zone
       ID, and textual names.  These messages are multicast to the well-

    Handley, et al.             Standards Track                     [Page 5]

    RFC 2776                          MZAP                     February 2000

       known address [MZAP-LOCAL-GROUP] in the Local Scope, and are relayed
       across Local Scope boundaries into all Local Scope zones within the
       scope zone referred to by the ZAM message, as shown in Figure 2.

        ###########################
        # Zone1      =      Zone2 #    ##### = large scope zone boundary
        *E-----+--->A*-----+-x    #
        #      |     =     v      #    ===== = Local Scope boundaries
        #      |     ======*===*==#
        #      |     =     B   F  #    ----> = path of ZAM originated by E
       G*<-----+--->C*->   |   ^  #
        #      v     =   <-+---+  #    ABCDE = ZBRs
        #      D     =      Zone3 #
        #######*###################        * = boundary interface

                       Figure 2: ZAM Flooding Example

       Any entity can thus listen on a single well-known group address and
       learn about all scopes in which it resides.

    3.1.  Scope Nesting

       MZAP also provides the ability to discover the nesting relationships
       between scope zones.  Two zones are nested if one is comprised of a
       subset of the routers in the other, as shown in Figure 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 6
            inside Zone 1      inside Zone 3        do not nest

                       Figure 3: Zone nesting examples

       A ZBR cannot independently determine whether one zone is nested
       inside another.  However, it can determine that one zone does NOT
       nest inside another.  For example, in Figure 3:

       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 then knows that zone 1 does not nest within zone 2, but it
          cannot, however, determine whether zone 2 nests within zone 1.

    Handley, et al.             Standards Track                     [Page 6]

    RFC 2776                          MZAP                     February 2000

       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 receives
          a ZAM for 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 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 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 done by
       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
       [MZAP-LOCAL-GROUP] and are thus seen by the same entities listening
       to ZAM messages (e.g., MADCAP servers).  Such entities can then
       determine the nesting relationship between two scopes based on a
       sustained absence of any evidence to the contrary.

    3.2.  Other Messages

       Two other message types, Zone Convexity Messages (ZCMs) 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 scope range associated with the scope zone to
       which they refer, and hence are typically not seen by entities other
       than routers.  Their use in detecting specific misconfiguration
       scenarios will be covered in the next section.

       Packet formats for all messages are described in 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 sent in the future (it does not send them
       immediately).  When a 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.

    Handley, et al.             Standards Track                     [Page 7]

    RFC 2776                          MZAP                     February 2000

       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

       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, Router B and Router C
       send 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 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.

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

                    Figure 4: Non-convexity detection

    Handley, et al.             Standards Track                     [Page 8]

    RFC 2776                          MZAP                     February 2000

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

       (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
           scope zone,

       (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 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
       configured ordinary hosts within a scope region, which may be a
       useful diagnostic facility that does not require privileged access.

    4.2.  Detecting leaky boundaries for non-local scopes

       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 exist.  Hence, the boundary does not completely surround a piece
       of the network, resulting in scoped data leaking outside.

       Leaky scope boundaries can be detected via two methods:

       (1) If it receives ZAMs originating inside the scope boundary on an
           interface that points outside the zone 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
           5.

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

                            Figure 5: ZAM Leaking

    Handley, et al.             Standards Track                     [Page 9]

    RFC 2776                          MZAP                     February 2000

       (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
           preventing implosion is described later in the Processing Rules
           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
       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 ZBRs which ought to have been a ZBR itself).

    4.3.  Detecting a leaky Local Scope zone

       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 interface as specified in RFC 2365.  This can be detected via
       the following method:

       o  If a ZAM for a given scope is received by a ZBR which is a
          boundary 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, this is evidence of a misconfiguration.  Since a
          temporary mismatch may result immediately after a recent change in
          the reachability of the lowest-addressed ZBR, misconfiguration
          should be assumed only if the mismatch is 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 range identified by the ZAM.  The router
       at fault will be the one 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 ZAM for a given scope, and the included start
          and end addresses overlap with, but are not identical to, the
          start and end addresses of a locally-configured scope.

       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
          language, and it receives a ZAM or ZCM with a name for the same
          scope and language, but the scope names do not match.

    Handley, et al.             Standards Track                    [Page 10]

    RFC 2776                          MZAP                     February 2000

       Detecting either type of conflict above indicates that either the
       local router or the router originating the message is 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 over UDP, with a destination port of
       [MZAP-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 use a source address which will have significance everywhere
       within the scope zone to which the message refers.  For example,
       link-local addresses MUST NOT be used.

       The common MZAP message header (which follows the UDP header), 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Version    |B|    PTYPE    |Address Family |   NameCount   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Message Origin                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Zone ID 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.

    Handley, et al.             Standards Track                    [Page 11]

    RFC 2776                          MZAP                     February 2000

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

       Packet Type (PTYPE):
          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 [10,11] 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 boundary.  For
          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 End Address: 32 bits (IPv4) or 128 bits (IPv6)
          This gives the ending 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 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 originated the
          message.

       Zone ID Address: 32 bits (IPv4) or 128 bits (IPv6)
          This gives the lowest IP address of a boundary router that has
          been observed in the zone originating the message.  Together with
          Zone 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 Local Scope zone in which the origin resides.

    Handley, et al.             Standards Track                    [Page 12]

    RFC 2776                          MZAP                     February 2000

       Encoded Zone Name:
          +--------------------+
          |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 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 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.

    Handley, et al.             Standards Track                    [Page 13]

    RFC 2776                          MZAP                     February 2000

    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 should assume the
          scope no longer exists, if no subsequent ZAM is received.  This
          should be set to [ZAM-HOLDTIME].

    Handley, et al.             Standards Track                    [Page 14]

    RFC 2776                          MZAP                     February 2000

       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
          Address of a local zone) through which the ZAM has passed, and IP
          addresses of the router that forwarded the packet.  The origin
          router 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 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 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 Zone ID Address N                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       All fields are copied from the ZAM, except PTYPE which is 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 boundary (except the Link-
       local scope).  Note that ZCM's ARE sent in the Local Scope.

       Unlike Zone Announcement Messages which are sent to the [MZAP-LOCAL-
       GROUP], Zone Convexity Messages are sent to the [ZCM-RELATIVE-GROUP]
       in the scope zone itself.  The format of a ZCM is shown below:

    Handley, et al.             Standards Track                    [Page 15]

    RFC 2776                          MZAP                     February 2000

        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 number of ZBR Addresses contained in this
          message.

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

       ZBR Address: 32 bits (IPv4) or 128 bits (IPv6)
          These fields give the addresses of the other ZBRs from which the
          Message Origin ZBR has received ZCMs but whose hold time has not
          expired.  The router should include all such addresses which fit
          in the packet, preferring those which it has not included recently
          if all do not fit.

    5.4.  Not-Inside Message

       A Not-Inside Message (NIM) has PTYPE=3, and is periodically sent by a
       ZBR which knows that a scope X does not nest within another scope Y
       ("X not inside Y"):

       The format of a Not-Inside Message is shown below:

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

    Handley, et al.             Standards Track                    [Page 16]

    RFC 2776                          MZAP                     February 2000

       The fields are as follows:

       MZAP Header:  Header fields identifying the scope X.  The Name Count
          may be 0.

       Not-Inside Zone Start Address: 32 bits (IPv4) or 128 bits (IPv6) This
          gives the start address for the scope Y.

    6.  Message Processing Rules

    6.1.  Internal entities listening to MZAP messages

       Any host or application may join 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 to such messages is
       not the recommended method for regular applications to discover this
       information.  These applications will normally query a local
       Multicast Address Allocation Server (MAAS) [3], which in turn listens
       to Zone Announcement Messages and Not-Inside Messages to maintain
       scope information, and can be queried by clients via MADCAP messages.

       An entity (including a MAAS) lacking any such information can only
       assume that it is within the Global Scope, and the Local Scope, both
       of which have well-known address ranges defined in [1].

       An internal entity (e.g., an MAAS) receiving a ZAM will parse the
       information that is relevant to it, such as the address range, and
       the 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) should assume that X nests within
       Y if:

       a) it first heard ZAMs for both X and Y at least [NIM-HOLDTIME]
          seconds ago, AND

       b) it has not heard a NIM indicating that "X not inside Y" for at
          least [NIM-HOLDTIME] seconds.

    Handley, et al.             Standards Track                    [Page 17]

    RFC 2776                          MZAP                     February 2000

    6.2.  Sending ZAMs

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

       The ZAM packet also contains a Zones Traveled Limit (ZTL).  If the
       number of Local Zone IDs in the ZAM path becomes equal to the Zones
       Traveled Limit, the packet will be dropped.  The ZTL field is set
       when the packet is first sent, and defaults to 32, but can be set to
       a lower value if a network administrator knows the expected size of
       the zone.

    6.3.  Receiving ZAMs

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

       If the local ZBR does NOT have any configuration for scope X:

       (1) Check to see if the included start and end addresses overlap
           with, but are not identical to, the start and 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
           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 are heard for [ZAM-HOLDTIME]), the entry is deleted.

       If the local ZBR does have configuration for scope X:

       (1) If the ZAM originated from OUTSIDE the scope (i.e., received over
           a boundary interface for scope X):

          a) If the Scope Zone ID in the ZAM matches the ZBR's own Scope
             Zone 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.

    Handley, et al.             Standards Track                    [Page 18]

    RFC 2776                          MZAP                     February 2000

       2) If the ZAM originated from INSIDE the scope:

          a) If the next-hop interface (according to the multicast RIB)
             towards the Origin is outside the scope zone, then signal a
             non- convexity problem.

          b) 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 to occur, then signal a possible leaky scope warning.

          c) 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
             names do not match, signal a scope name conflict to a local
             administrator.

          d) 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
             list is 0, the ZBR fills in the Local Zone ID Address of the
             local zone from which the ZAM 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.

       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 to be sent as described in the next subsection and perform no
       further processing below.

       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-
       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
       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 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 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 re-originated, the ZBR adds its own IP address to the path

    Handley, et al.             Standards Track                    [Page 19]

    RFC 2776                          MZAP                     February 2000

       list, as well as the Zone ID Address of the Local Scope Zone into
       which the ZAM is being sent, or 0 if the ID is unknown.  (For
       example, if the other end of a point-to-point link also has a
       boundary on the interface, then the link has no Local Scope Zone ID.)

    6.4.  Sending ZLEs

       This packet is sent by a local-zone 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)

       This equation results in an exponential random distribution which
       ensures that close to one ZBR will respond.  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 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 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 router has a duplicate ZLE message scheduled to 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,
           it signals a leaky scope misconfiguration.

    Handley, et al.             Standards Track                    [Page 20]

    RFC 2776                          MZAP                     February 2000

    6.6.  Sending ZCMs

       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 [ZCM-INTERVAL] each time to 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, 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 received for a given scope X, on an interface which is
       inside the scope, it follows the rules below:

       (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
           address in the list.  The new entry is scheduled to be timed out
           after [ZCM-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.

       (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
           scope zone, or if no ZCM is received from that ZBR for [ZCM-
           HOLDTIME] seconds, as in the example in Figure 4, then signal a
           non-convexity problem.

       (3) For each textual name in the ZCM, see if a name for the same
           scope and language is locally-configured; if so, but the scope
           names do not 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 send such a Not-Inside Message every [NIM-INTERVAL]
       seconds, +/- 30% of [NIM-INTERVAL] to avoid message synchronization.

    Handley, et al.             Standards Track                    [Page 21]

    RFC 2776                          MZAP                     February 2000

    6.9.  Receiving NIMs

       When a ZBR receives a NIM saying that "X is not inside Y", it is
       forwarded, unmodified, in a manner similar to ZAMs:

       (1) If the NIM was received on an interface with a boundary for
           either X or Y, the NIM is discarded.

       (2) Unlike ZAMs, if the NIM was not received on the interface towards
           the message origin (according to the 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.

       (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
           payload) into each local scope zone in which it has interfaces,
           except that it is not sent back into the local scope zone from
           which the message was received, nor is it sent out any interface
           with a boundary for either X or Y.

    7.  Constants

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

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

       [ZCM-RELATIVE-GROUP]:  The relative group in each scope zone, to
       which ZCMs are sent.  A Zone Boundary Router listens to the relative
       group in each scope for which it is a boundary.  Value: (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 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).

    Handley, et al.             Standards Track                    [Page 22]

    RFC 2776                          MZAP                     February 2000

       [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 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 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 Boundary Router
       originates Not-Inside Messages.  Default value: 1800 seconds (30
       minutes).

       [NIM-HOLDTIME]:   The holdtime to include the state within a NIM.
       This SHOULD be set to at least 3 * [NIM-INTERVAL]. Default value:
       5460 (91 minutes)

    8.  Security Considerations

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

       In the case of 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.  (Such messages
       could be authenticated, but since they may be sent within large
       scopes, the receiver may not be able to authenticate a 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.

    Handley, et al.             Standards Track                    [Page 23]

    RFC 2776                          MZAP                     February 2000

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

       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 administrative scope 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, 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 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 accepting
       unauthenticated ZAMs could result in false names being presented to
       users, and in wrong addresses being allocated to users.  To counter
       this, MAAS's authenticate ZAMs as follows:

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

    9.  Acknowledgements

       This document is a product of the MBone Deployment Working Group,
       whose members provided many helpful comments and suggestions, Van
       Jacobson provided some of the original ideas that led to this
       protocol.  The Multicast Address Allocation Working Group also
       provided useful feedback regarding scope names and interactions with
       applications.

    Handley, et al.             Standards Track                    [Page 24]

    RFC 2776                          MZAP                     February 2000

    10.  References

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

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

       [3]  Thaler, D., Handley, M. and D. Estrin, "The Internet Multicast
            Address Allocation Architecture", Work in Progress.

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

       [5]  Fenner, W. and S. Casner, "A `traceroute' facility for IP
            Multicast", Work in Progress.

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

       [7]  Handley, M. and S. Hanna.  "Multicast Address Allocation
            Protocol (AAP)", Work in Progress.

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

       [9]  Hanna, S., Patel, B., and M. Shah.  "Multicast Address Dynamic
            Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.

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

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

       [12] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
            November 1998.

    Handley, et al.             Standards Track                    [Page 25]

    RFC 2776                          MZAP                     February 2000

    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

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

       EMail: Roger.Kermode@motorola.com

    Handley, et al.             Standards Track                    [Page 26]

    RFC 2776                          MZAP                     February 2000

    12.  Full Copyright Statement

       Copyright (C) The Internet Society (2000).  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 Standards process must be
       followed, or as required to translate it into 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 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.

    Acknowledgement

       Funding for the RFC Editor function is currently provided by the
       Internet Society.

    Handley, et al.             Standards Track                    [Page 27]