rfc2776.txt

<VC++网络游戏建摸与实现>源代码

   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.