rfc2908.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   Each of the three layers serves slightly different purposes and as
   such, protocols or mechanisms at each layer may require different
   design tradeoffs.

4.  Scoping

   To allocate dynamic addresses within administrative scopes, a MAAS
   must be able to learn which scopes are in effect, what their address
   ranges and names are, and which addresses or subranges within each
   scope are valid for dynamic allocation by the MAAS.

   The first two tasks, learning the scopes in effect and the address
   range and name(s) of each scope, may be provided by static
   configuration or dynamically learned.  For example, a MAAS may simply
   passively listen to MZAP [9] messages to acquire this information.

   To determine the subrange for dynamic allocation, there are two cases
   for each scope, corresponding to small "indivisible" scopes, and big
   "divisible" scopes.  Note that MZAP identifies which scopes are
   divisible and which are not.

   (1) For small scopes, the allocation domain corresponds to the entire
       topology within the administrative scope.  Hence, all MAASs
       inside the scope may use the entire address range (minus the last



Thaler, et al.               Informational                      [Page 7]

RFC 2908                  MALLOC Architecture             September 2000


       256 addresses reserved as scope-relative addresses), and use the
       Layer 2 mechanism/protocol to coordinate allocations.  For small
       scopes, Prefix Coordinators are not involved.

       Hence, for small scopes, the effective "allocation domain" area
       may be different for different scopes.  Note that a small,
       indivisible scope could be larger or smaller than the Allocation
       Scope used for big scopes (see below).

   (2) For big scopes (including the global scope), the area inside the
       scope may be large enough that simply using a Layer 2
       mechanism/protocol may be inefficient or otherwise undesirable.
       In this case, the scope must span multiple allocation domains,
       and the Layer 3 mechanism/protocol must be used to divvy up the
       scoped address space among the allocation domains.  Hence, a MAAS
       may learn of the scope via MZAP, but must acquire a subrange from
       which to allocate from a Prefix Coordinator.

       For simplicity, the effective "allocation domain" area will be
       the same for all big scopes, being the granularity at which all
       big scopes are divided up.  We define the administrative scope at
       this granularity to be the "Allocation Scope".

4.1.  Allocation Scope

   The Allocation Scope is a new administrative scope, defined in this
   document and to be reserved by IANA with values as noted below.  This
   is the scope that is used by a Layer 2 protocol/mechanism to
   coordinate address allocation for addresses in larger, divisible
   scopes.

   We expect that the Allocation Scope will often coincide with a
   unicast Autonomous System (AS) boundary.

   If an AS is too large, or the network administrator wishes to run
   different intra-domain multicast routing in different parts of an AS,
   that AS can be split by manual setup of an allocation scope boundary
   that is not an AS boundary.  This is done by setting up a multicast
   boundary dividing the unicast AS into two or more multicast
   allocation domains.

   If an AS is too small, and address space is scarce, address space
   fragmentation may occur if the AS is its own allocation domain.
   Here, the AS can instead be treated as part of its provider's
   allocation domain, and use a Layer 2 protocol/mechanism to coordinate
   allocation between its MAAS's (if any) and those of its provider.  An
   AS should probably take this course of action if:




Thaler, et al.               Informational                      [Page 8]

RFC 2908                  MALLOC Architecture             September 2000


   o  it is connected to a single provider,

   o  it does not provide transit for another AS, and

   o  it needs fewer than (say) 256 multicast addresses of larger than
      AS scope allocated on average.

4.1.1.  The IPv4 Allocation Scope -- 239.251.0.0/16

   The address space 239.251.0.0/16 is to be reserved for the Allocation
   Scope.  The ranges 239.248.0.0/16, 239.249.0.0/16 and 239.250.0.0/16
   are to be left unassigned and available for expansion of this space.
   These ranges should be left unassigned until the 239.251.0.0/16 space
   is no longer sufficient.

4.1.2.  The IPv6 Allocation Scope -- SCOP 6

   The IPv6 "scop" value 6 is to be used for the Allocation Scope.

5.  Overview of the Allocation Process

   Once Layer 3 allocation has been performed for large, divisible
   scopes, and each Prefix Coordinator has acquired one or more ranges,
   then those ranges are passed to all MAAS's within the Prefix
   Coordinator's domain via a Layer 2 mechanism/protocol.

   MAAS's within the domain receive these ranges and store them as the
   currently allowable addresses for that domain.  Each range is valid
   for a given lifetime (also acquired via the Layer 3
   mechanism/protocol) and is not revoked before the lifetime has
   expired.  MAAS's also learn of small scopes (e.g., via MZAP) and
   store the ranges associated with them.

   Using the Layer 2 mechanism/protocol, each MAAS ensures that it will
   exclude any addresses which have been or will be allocated by other
   MAAS's within its domain.

   When a client needs a multicast address, it first needs to decide
   what the scope of the intended session should be, and locate a MAAS
   capable of allocating addresses within that scope.

   To pick a scope, the client will either simply choose a well-known
   scope, such as the global scope, or it will enumerate the available
   scopes (e.g., by sending a MADCAP query, or by listening to MZAP
   messages over time) and allow a user to select one.






Thaler, et al.               Informational                      [Page 9]

RFC 2908                  MALLOC Architecture             September 2000


   Locating a MAAS can be done via a variety of methods, including
   manual configuration, using a service location protocol such as SLP
   [12], or via a mechanism provided by a Layer 1 protocol itself.
   MADCAP, for instance, includes such a facility.

   Once the client has chosen a scope and located a MAAS, it then
   requests an address in that scope from the MAAS located.  Along with
   the request it also passes the acceptable range for the lifetimes of
   the allocation it desires.  For example, if the Layer 1 protocol in
   use is MADCAP, the client sends a MADCAP REQUEST message to the MAAS,
   and waits for a NAK message or an ACK message containing the
   allocated information.

   Upon receiving a request from a client, the MAAS then chooses an
   unused address in a range for the specified scope, with a lifetime
   which both satisfies the acceptable range specified by the client,
   and is within the lifetime of the actual range.

   The MAAS uses the Layer 2 mechanism/protocol to ensure that such an
   address does not clash with any addresses allocated by other MAASs.
   For example, if Layer 2 uses manual configuration of non-overlapping
   ranges, then this simply consists of adhering to the range configured
   in the local MAAS.  If, on the other hand, AAP is used at Layer 2 to
   provide less address space fragmentation, the MAAS advertises the
   proposed allocation domain-wide using AAP.  If no clashing AAP claim
   is received within a short time interval, then the address is
   returned to the client via the Layer 1 protocol/mechanism.  If a
   clashing claim is received by the MAAS, then it chooses a different
   address and tries again.  AAP also allows each MAAS to pre-reserve a
   small "pool" of addresses for which it need not wait to detect
   clashes.

   If a domain ever begins to run out of available multicast addresses,
   a Prefix Coordinator in that domain uses the Layer 3
   protocol/mechanism to acquire more space.

6.  Security Considerations

   The architecture described herein does not prevent an application
   from just sending to or joining a multicast address without
   allocating it (just as the same is true for unicast addresses today).
   However, there is no guarantee that data for unallocated addresses
   will be delivered by the network.  That is, routers may drop data for
   unallocated addresses if they have some way of checking whether a
   destination address has been allocated.  For example, if the border
   routers of a domain participate in the Layer 2 protocol/mechanism and
   cache the set of allocated addresses, then data for unallocated




Thaler, et al.               Informational                     [Page 10]

RFC 2908                  MALLOC Architecture             September 2000


   addresses in a range allocated by that domain can be dropped by
   creating multicast forwarding state with an empty outgoing interface
   list and/or pruning back the tree branches for those groups.

   A malicious application may attempt a denial-of-service attack by
   attempting to allocate a large number of addresses, thus attempting
   to exhaust the supply of available addresses.  Other attacks include
   releasing or modifying the allocation of another party.  These
   attacks can be combatted through the use of authentication with
   policy restrictions (such as a maximum number of addresses that can
   be allocated by a single party).

   Hence, protocols/mechanisms that implement layers of this
   architecture should be deployable in a secure fashion.  For example,
   one should support authentication with policy restrictions, and
   should not allow someone unauthorized to release or modify the
   allocation of another party.

7.  Acknowledgments

   Steve Hanna provided valuable feedback on this document.  The members
   of the MALLOC WG and the MBone community provided the motivation for
   this work.

8.  References

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

   [2]  Mark Handley, "Multicast Session Directories and Address
        Allocation", Chapter 6 of PhD Thesis entitled "On Scalable
        Multimedia Conferencing Systems", University of London, 1997.

   [3]  Mark Handley, "An Analysis of Mbone Performance", Chapter 4 of
        PhD Thesis entitled "On Scalable Multimedia Conferencing
        Systems", University of London, 1997.

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

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

   [6]  Estrin, D., Govindan, R., Handley, M., Kumar, S., Radoslavov, P.
        and D. Thaler, "The Multicast Address-Set Claim (MASC)
        Protocol", RFC 2909, September 2000.





Thaler, et al.               Informational                     [Page 11]

RFC 2908                  MALLOC Architecture             September 2000


   [7]  Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
        1112, August 1989.

   [8]  Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
        RFC 1771, March 1995.

   [9]  Handley, M., Thaler, D. and R. Kermode, "Multicast-Scope Zone
        Announcement Protocol (MZAP)", RFC 2776, February 2000.

   [10] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", RFC 2770,
        February 2000.

   [11] Finlayson, R., "Abstract API for Multicast Address Allocation",
        RFC 2771, February 2000.

   [12] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
        Location Protocol, Version 2", RFC 2608, June 1999.

   [13] Mills, D., "Network Time Protocol (Version 3) Specification,
        Implementation and Analysis", RFC 1305, March 1992.

9.  Authors' Addresses

   Dave Thaler
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052-6399

   EMail: [e-mail]


   Mark Handley
   AT&T Center for Internet Research at ICSI
   1947 Center St, Suite 600
   Berkeley, CA 94704

   EMail: [e-mail]


   Deborah Estrin
   Computer Science Dept/ISI
   University of Southern California
   Los Angeles, CA 90089

   EMail: [e-mail]






Thaler, et al.               Informational                     [Page 12]

RFC 2908                  MALLOC Architecture             September 2000


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



















Thaler, et al.               Informational                     [Page 13]