[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 RFC 2776

Internet Engineering Task Force                                MboneD WG
Internet Draft                                                M. Handley
draft-ietf-mboned-mzap-00.txt                                        ISI
December 15, 1997
Expires: June 1998


           Multicast-Scope Zone Announcement Protocol (MZAP)

STATUS OF THIS MEMO

   This document is an Internet-Draft. 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 draft documents 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 ``work in progress''.

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this document is unlimited.


                                 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.

1 Status

   This is a strawman proposal. It has not been subject to any peer
   review or implementation.

2 Introduction

   IP Multicast groups can be global scope, or they can be restricted in



M. Handley                                                    [Page 1]


Internet Draft                    MZAP                 December 15, 1997


   scope using a scoping mechanism. In this document, we only consider
   administrative scoping, as defined in [1]. An administrative scope
   zone is defined by a set of border routers to a region of the
   network. These border routers are configured to not pass multicast
   traffic destined for a particular range of multicast addresses to or
   from links leaving the scope zone.

   Administrative scope zones may be of any size, and a particular host
   may be within many administrative scope zones. The only zones a host
   can assume that it is within are the global zone, and local scope
   Local scope is defined as being the smallest administrative scope
   zone encompassing a host, and the border is configured for addresses
   in the range 239.255.0.0 to 239.255.255.255 inclusive. [1] 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.

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

        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 routers was not
         configured correctly).

        o Applications have no way to discover the scope zones that are
         relevant to them. This makes it difficult to use admin scope
         zones, and hence reduced the incentive to deploy them.

   This document defines the Multicast Scope Zone Announcement Protocol
   (MZAP) which will provide applications with information about the
   scope zones they are within, and also provide diagnostic information
   to detect misconfigured scope zones.

3 Specification

   A multicast scope Zone Border Router (ZBR) is a router that is
   configured to be a zone border on one or more of its interfaces. Any
   interface that is configured to be a border for any admin scope zone
   MUST also be a border for the local scope zone, as defined in [1].




M. Handley                                                    [Page 2]


Internet Draft                    MZAP                 December 15, 1997


   Routers SHOULD be configured so as the router itself is within the
   scope zone. This is should in figure 1A, where router 1 is inside the
   scope zone and has the border configuration. It is possible for the
   first router outside the scope zone to be configured with the border,
   as illustrated in figure 1B where routers 2 and 3 are outside the
   zone and have the border configuration, but this is NOT RECOMMENDED.

         ............                     ................
        .            .   +O+-->          .                *O+-->
       .              . /  2            .                /. 2
      .              1 *               .              1 +  .
      .          <---+O*---+O+->       .          <---+O+---*O+->
      .              + .     3         .              +     . 3
      .             /  .               .             /      .
       . zone X  <--  .                 . zone X  <--      .
        ..............                   ..................

       O - router       * - border interface      + - interface

     A. Correct zone border           B. Incorrect zone border



   Figure 1: Correct admin scope zone border placement


   This rule does not apply for local scope borders, but applies for all
   other admin scope border routers.

   When a ZBR router 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 router should then send periodic Zone Announcement
   Messages (ZAMs) for the zone for which it is configured as a border
   from each of its interfaces that go into that scope zone. These
   messages are multicast to the address 239.255.255.254, which is a
   locally scoped address.

   Each ZBR router should also listen for ZAM messages from other ZBRs
   for the same border. The ZBR router with the lowest interface IP
   address within the zone from those ZBRs forming the zone border
   becomes the zone-id router for the zone. The combination of this IP
   address and the base address of the scoping range server to uniquely
   identify the scope zone.




M. Handley                                                    [Page 3]


Internet Draft                    MZAP                 December 15, 1997


   Every local scope ZBR that receives any ZAM for a scope zone other
   than local scope SHOULD then forward the ZAM out of all the other
   interfaces that are in different local scope zones except ones that
   form a border for the zone described in the ZAM. It adds the zone-id
   of the local scope zone that the message came from to the ZAM path
   list before doing so. A local scope 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. This process is illustrated in
   figure 2.

   in

   Figure 2: ZAM Message Flooding



   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 to 32, but can be set to a
   lower value if a network administrator knows the expected size of the
   zone.

   Addition messages called Zone Convexity Messages (ZCM) SHOULD also be
   sent to the second highest address in the scope zone range itself
   (For example, if the scope zone border is for 239.1.0.0 to
   239.1.0.255, then these messages should be sent to 239.1.0.254.) As
   these are not locally scoped packets, they are simply multicast
   across the scope zone itself, and require no path to be built up, or
   forwarding by local scope zone ZBRs. These messages are used to
   detect non-convex admin scope zones, as illustrated in figure 3. Here
   Router B and Router C originates ZCM messages, each reporting each
   other's presence. Router D cannot see Router B's messages, but sees
   Router C's report of Router B, and so concludes the zone is not
   convex.

   in

   Figure 3: ZAM Message Flooding



3.1 Packet Formats


   Zone Announcement Message (IPv4)

   The format of a Zone Announcement Message is shown in figure 4.



M. Handley                                                    [Page 4]


Internet Draft                    MZAP                 December 15, 1997



    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | V=0 |R| PTYPE |      ZT       |     ZTL       | IP  |  MLEN   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Zone Base Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Message Origin                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Zone ID Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Local Zone ID Address 0                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Router Address 0                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                .....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Local Zone ID Address N                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Router Address N                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Zone Name                           |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 4: Zone Announcement Message Format



   The fields are defined as follows:

   Version (V): 3 bits The version defined in this document is version
        0.

   Respond (R): 1 bit When set to 1, this bit indicates that a router
        MAY generate a Zone Limit Exceeded message in response to this
        ZAM message. When set to zero, a router MUST NOT generate a Zone
        Limit Exceeded message in response to this message.

   Packet Type (PTYPE): 4 bits A Zone Announcement Message has PTYPE=0.

   Zone 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



M. Handley                                                    [Page 5]


Internet Draft                    MZAP                 December 15, 1997


        dropped.

   IP Protocol Version (IP): 3 bits This indicates the format of the
        following packet. The following values are defined:

   0: IPv4

   1: IPv6

   Mask length (MLEN): 5 bits This gives the mask length which together
        with the zone base address defines the range of addresses that
        form the border to this zone.  For example, if the zone is a
        border for 239.1.0.0 to 239.1.0.255, then MLEN has the value 24.
        A value of zero means all the bits are included in the mask, and
        the zone is a border for a single address.

   Zone Base Address: 32 bits This gives the base 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 Base Address is 239.1.0.0.

   Message Origin: 32 bits This gives the IP address of the interface
        that originated the ZAM message.

   Zone ID Address: 32 bits This gives the lowest IP address that has
        been observed in the zone sending ZAM messages. Together with
        Zone Base Address and MLEN it forms a unique ID for the zone.

   Zone Path: multiple of 64 bits The zone path is a list of 32 bit
        Local Zone ID Addresses (the Zone ID Address of a local zone)
        through which the ZAM message has passed, and 32 bit IP
        addresses of the router that forwarded the packet. 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 was received from and its own IP address to the end of
        this list, and increments ZT accordingly.  The zone path is
        empty which the ZAM message is first sent.

   Zone Name: multiple of 8 bits The Zone Name is an ISO 10646 character
        string in UTF-8 encoding indicating the name given to the scope
        zone (eg: "ISI-West Site"). It should be relatively short and
        MUST be less that 256 bytes in length. All the border routers to
        the same region SHOULD be configured 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 expected to be configured
        with the zone name.  Having ALL the ZBR routers for a scope zone
        announce zero length names should be considered an error.

3.1.1 Zone Limit Exceeded (ZLE)



M. Handley                                                    [Page 6]


Internet Draft                    MZAP                 December 15, 1997


   This packet is sent by a local-zone border router that would have
   exceeded the Zone Traveled Limit if it had forwarded a ZAM packet. It
   is only sent if the "Respond" bit in the ZAM packet is set, and it is
   unicast to the Message Origin given in the ZAM packet.

   The format is the same as a ZAM message, and is shown in figure 5:


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  V=0  | PTYPE |      ZT       |     ZTL       | IP  |  MLEN   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Zone Base Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Message Origin                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Zone ID Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Local Zone ID Address 0                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                .....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Local Zone ID Address N                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Zone Name                           |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Figure 5: Zone Announcement Message Format



   All fields are copied from the ZAM message, except PTYPE which is set
   to one.

   A router receiving ZLE messages SHOULD log them and attempt to alert
   the network administrator that the scope zone is misconfigured.


   Zone Convexity Message

   Unlike Zone Announcement Messages which are sent to the locally
   scoped address 239.255.255.254, Zone Convexity Messages are sent to
   the second highest address in the scope zone itself. The format of a



M. Handley                                                    [Page 7]


Internet Draft                    MZAP                 December 15, 1997


   ZCM is shown in figure 6 and is similar to a ZAM, expect PTYPE take
   the value two.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  V=0  | PTYPE |     ZNUM      |    unused     | IP  |  MLEN   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Zone Base Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Message Origin                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Zone ID Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          ZBR Address 0                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                .....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          ZBR Address N                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Zone Name                           |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Figure 6: Zone Convexity Message Format



   The fields are as follows:

   Number of ZBR addresses (ZNUM): 8 bits This field gives the number of
        ZBR Addresses contained in this message.

   ZBR Address (32 bits) These fields give the addresses of ALL the
        other ZBR routers that the Message Origin ZBR has received ZCM
        messages from during the time that it has taken the Message
        Origin ZBR to send ten ZCM messages.

4 Using Zone Announcement Messages

   Any host or application may listen to Zone Announcement Messages to
   build up a list of the scope zones that are relevant locally.
   However, listening to Zone Announcement Messages is not the
   recommended method for regular applications to discover this



M. Handley                                                    [Page 8]


Internet Draft                    MZAP                 December 15, 1997


   information. These applications will normally query a local Multicast
   Address Allocation Server[2], which in turn will listen to Zone
   Announcement Messages.

   A ZBR can discover misconfiguration of scope boundaries in one of
   several ways:

        o It receives ZLE messages indicating that the scope zone is
         leaking.

        o It receives ZAM messages 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 7.

        o Other ZBR routers in the scope zone are announcing that they
         are seeing a different set of routers than our router observes
         from arriving ZCM messages. If this is a persistent condition,
         it indicates that the scope zone is probably not convex, as
         illustrated in figure 3.

   in

   Figure 7: ZAM Message Leaking



   All these conditions should be considered errors and the router
   should attempt to alert the network administrator to the nature of
   the misconfiguration.

   Zone Convexity Messages can 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.

5 Message Timing

   Each ZBR router 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.

   Each ZBR router should send a Zone Convexity Message for each scope
   zone for which 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.



M. Handley                                                    [Page 9]


Internet Draft                    MZAP                 December 15, 1997


   Default values are:

   ZAM-INTERVAL 300 seconds.

   ZCM-INTERVAL 300 seconds.

   ZLE-MIN-INTERVAL 300 seconds.

6 Security Considerations

   MZAP does not include authentication in its messages. Thus it is open
   to misbehaving hosts sending spoof ZAM or ZCM messages.

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

   In the case of ZAM messages, spoof messages can also cause false
   logging of configuration problems. This is also considered to not be
   a significant problem.

   Spoof zone announcements however might 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 admin 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 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.

7 Bibliography

   [1]  D. Meyer, "Administratively Scoped IP Multicast", Internet
   Draft, draft-ietf-mboned-admin-ip-space-04.txt [2]  M. Handley, D.
   Thaler, D. Estrin, "The Internet Multicast Address Allocation
   Architecture", Internet Draft, Dec 1997.













M. Handley                                                   [Page 10]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/