doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc2908.txt b/doc/rfc/rfc2908.txt
new file mode 100644
index 0000000..4ed3f69
--- /dev/null
+++ b/doc/rfc/rfc2908.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                         D. Thaler
+Request for Comments: 2908                                    Microsoft
+Category: Informational                                      M. Handley
+                                                                  ACIRI
+                                                              D. Estrin
+                                                                    ISI
+                                                         September 2000
+
+
+         The Internet Multicast Address Allocation Architecture
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This document proposes a multicast address allocation architecture
+   (MALLOC) for the Internet.  The architecture is modular with three
+   layers, comprising a host-server mechanism, an intra-domain server-
+   server coordination mechanism, and an inter-domain mechanism.
+
+Table of Contents
+
+   1: Introduction ................................................  2
+   2: Requirements ................................................  2
+   3.1: Address Dynamics ..........................................  4
+   3: Overview of the Architecture ................................  5
+   4: Scoping .....................................................  7
+   4.1: Allocation Scope ..........................................  8
+   4.1.1: The IPv4 Allocation Scope -- 239.251.0.0/16 .............  9
+   4.1.2: The IPv6 Allocation Scope -- SCOP 6 .....................  9
+   5: Overview of the Allocation Process ..........................  9
+   6: Security Considerations ..................................... 10
+   7: Acknowledgments ............................................. 11
+   8: References .................................................. 11
+   9: Authors' Addresses .......................................... 12
+   10: Full Copyright Statement ................................... 13
+
+
+
+
+
+
+
+Thaler, et al.               Informational                      [Page 1]
+
+RFC 2908                  MALLOC Architecture             September 2000
+
+
+1.  Introduction
+
+   This document proposes a multicast address allocation architecture
+   (MALLOC) for the Internet, and is intended to be generic enough to
+   apply to both IPv4 and IPv6 environments.
+
+   As with unicast addresses, the usage of any given multicast address
+   is limited in two dimensions:
+
+   Lifetime:
+      An address has a start time and a (possibly infinite) end time,
+      between which it is valid.
+
+   Scope:
+      An address is valid over a specific area of the network.  For
+      example, it may be globally valid and unique, or it may be a
+      private address which is valid only within a local area.
+
+   This architecture assumes that the primary scoping mechanism in use
+   is administrative scoping, as described in RFC 2365 [1].  While
+   solutions that work for TTL scoping are possible, they introduce
+   significant additional complication for address allocation [2].
+   Moreover, TTL scoping is a poor solution for multicast scope control,
+   and our assumption is that usage of TTL scoping will decline before
+   this architecture is widely used.
+
+2.  Requirements
+
+   From a design point of view, the important properties of multicast
+   allocation mechanisms are robustness, timeliness, low probability of
+   clashing allocations, and good address space utilization in
+   situations where space is scare.  Where this interacts with multicast
+   routing, it is desirable for multicast addresses to be allocated in a
+   manner that aids aggregation of routing state.
+
+   o  Robustness/Availability
+
+      The robustness requirement is that an application requiring the
+      allocation of an address should always be able to obtain one, even
+      in the presence of other network failures.
+
+   o  Timeliness
+
+      From a timeliness point of view, a short delay of up to a few
+      seconds is probably acceptable before the client is given an
+      address with reasonable confidence in its uniqueness.  If the
+      session is defined in advance, the address should be allocated as
+      soon as possible, and should not wait until just before the
+
+
+
+Thaler, et al.               Informational                      [Page 2]
+
+RFC 2908                  MALLOC Architecture             September 2000
+
+
+      session starts.  It is in some cases acceptable to change the
+      multicast addresses used by the session up until the time when the
+      session actually starts, but this should only be done when it
+      averts a significant problem such as an address clash that was
+      discovered after initial session definition.
+
+   o  Low Probability of Clashes
+
+      A multicast address allocation scheme should always be able to
+      allocate an address that can be guaranteed not to clash with that
+      of another session.  A top-down partitioning of the address space
+      would be required to completely guarantee that no clashes would
+      occur.
+
+   o  Address Space Packing in Scarcity Situations
+
+      In situations where address space is scarce, simply partitioning
+      the address space would result in significant fragmentation of the
+      address space.    This is because one would need enough spare
+      space in each address space partition to give a reasonable degree
+      of assurance that addresses could still be allocated for a
+      significant time in the event of a network partition.  In
+      addition, providing backup allocation servers in such a hierarchy,
+      so that fail-over (including partitioning of a server and its
+      backup from each other) does not cause collisions would add
+      further to the address space fragmentation.
+
+      Since guaranteeing no clashes in a robust manner requires
+      partitioning the address space, providing a hard guarantee leads
+      to inefficient address space usage.  Hence, when address space is
+      scarce, it is difficult to achieve constant availability and
+      timeliness, guarantee no clashes, and achieve good address space
+      usage.  As a result, we must prioritize these properties.  We
+      believe that, when address space is scarce, achieving good address
+      space packing and constant availability are more important than
+      guaranteeing that address clashes never occur.  What we aim for in
+      these situations is a very high probability that an address clash
+      does not occur, but we accept that there is a finite probability
+      of this happening.  Should a clash occur (or should an application
+      start using an address it did not allocate, which may also lead to
+      a clash), either the clash can be detected and addresses changed,
+      or hosts receiving additional traffic can prune that traffic using
+      source-specific prunes available in IGMP version 3, and so we do
+      not believe that this is a disastrous situation.
+
+      In summary, tolerating the possibility of clashes is likely to
+      allow allocation of a very high proportion of the address space in
+      the presence of network conditions such as those observed in [3].
+
+
+
+Thaler, et al.               Informational                      [Page 3]
+
+RFC 2908                  MALLOC Architecture             September 2000
+
+
+      We believe that we can get good packing and good availability with
+      good collision avoidance, while we would have to compromise
+      packing and availability significantly to avoid all collisions.
+
+      Finally, in situations where address space is not scarce, such as
+      with IPv6, achieving good address space usage is less important,
+      and hence partitioning may potentially be used to guarantee no
+      collisions among hosts that use this architecture.
+
+2.1.  Address Dynamics
+
+   Multicast addresses may be allocated in any of three ways:
+
+   Static:
+      Statically allocated addresses are allocated by IANA for specific
+      protocols that require well-known addresses to work.  Examples of
+      static addresses are 224.0.1.1 which is used for the Network Time
+      Protocol [13] and 224.2.127.255 which is used for global scope
+      multicast session announcements.  Applications that use multicast
+      for bootstrap purposes should not normally be given their own
+      static multicast address, but should bootstrap themselves using a
+      well-known service location address which can be used to announce
+      the binding between local services and multicast addresses.
+
+      Static addresses typically have a permanent lifetime, and a scope
+      defined by the scope range in which they reside.  As such, a
+      static address is valid everywhere (although the set of receivers
+      may be different depending on location), and may be hard-coded
+      into applications, devices, embedded systems, etc.  Static
+      addresses are also useful for devices which support sending but
+      not receiving multicast IP datagrams (Level 1 conformance as
+      specified in RFC 1112 [7]), or even are incapable of receiving any
+      data at all, such as a wireless broadcasting device.
+
+   Scope-relative:
+      RFC 2365 [1] reserves the highest 256 addresses in every
+      administrative scope range for relative assignments.  Relative
+      assignments are made by IANA and consist of an offset which is
+      valid in every scope.  Relative addresses are reserved for
+      infrastructure protocols which require an address in every scope,
+      and this offset may be hard-coded into applications, devices,
+      embedded systems, etc.  Such devices must have a way (e.g. via
+      MZAP [9] or via MADCAP [4]) to obtain the list of scopes in which
+      they reside.
+
+
+
+
+
+
+
+Thaler, et al.               Informational                      [Page 4]
+
+RFC 2908                  MALLOC Architecture             September 2000
+
+
+      The offsets assigned typically have a permanent lifetime, and are
+      valid in every scope and location.  Hence, the scope-relative
+      address in a given scope range has a lifetime equal to that of the
+      scope range in which it falls.
+
+   Dynamic:
+      For most purposes, the correct way to use multicast is to obtain a
+      dynamic multicast address.  These addresses are provided on demand
+      and have a specific lifetime.  An application should request an
+      address only for as long as it expects to need the address.  Under
+      some circumstances, an address will be granted for a period of
+      time that is less than the time that was requested.  This will
+      occur rarely if the request is for a reasonable amount of time.
+      Applications should be prepared to cope with this when it occurs.
+
+      At any time during the lifetime of an existing address,
+      applications may also request an extension of the lifetime, and
+      such extensions will be granted when possible.  When the address
+      extension is not granted, the application is expected to request a
+      new address to take over from the old address when it expires, and
+      to be able to cope with this situation gracefully.  As with
+      unicast addresses, no guarantee of reachability of an address is
+      provided by the network once the lifetime expires.
+
+      These restrictions on address lifetime are necessary to allow the
+      address allocation architecture to be organized around address
+      usage patterns in a manner that ensures addresses are aggregatable
+      and multicast routing is reasonably close to optimal.  In
+      contrast, statically allocated addresses may be given sub-optimal
+      routing.
+
+3.  Overview of the Architecture
+
+   The architecture is modular so that each layer may be used, upgraded,
+   or replaced independently of the others.  Layering also provides
+   isolation, in that different mechanisms at the same layer can be used
+   by different organizations without adversely impacting other layers.
+
+   There are three layers in this architecture (Figure 1).  Note that
+   these layer numbers are different from the layer numbers in the
+   TCP/IP stack, which describe the path of data packets.
+
+
+
+
+
+
+
+
+
+
+Thaler, et al.               Informational                      [Page 5]
+
+RFC 2908                  MALLOC Architecture             September 2000
+
+
+   +--------------------------+         +------------------------+
+   |                          |         |                        |
+   |       to other peers     |         |   to other peers       |
+   |          ||   //         |         |      ||  //   ||       |
+   |          Prefix          |         |    Prefix     Prefix   |
+   |       Coordinator        |         |Coordinator  Coordinator|
+   +------------||------------+         +-------||----//---------+
+                ||Layer 3                       ||   //
+   +------------||------------------------------||--//-----------+
+   |          Prefix                          Prefix             |
+   |       Coordinator=======================Coordinator         |
+   |             ^                              ^                |
+   |             +----------------+-------------+                |
+   |             |       Layer 2  |             |                |
+   |     MAAS<---/                |             +---> MAAS       |
+   |     ^   ^                    v                    ^         |
+   |     .    .                 MAAS                   .         |
+   |     .     .Layer 1           ^                    .Layer 1  |
+   |     v      v                 .Layer 1             v         |
+   | Client   Client              v                 Client       |
+   |                           Client                            |
+   +-------------------------------------------------------------+
+
+  Figure 1: An Overview of the Multicast Address Allocation Architecture
+
+   Layer 1
+      A protocol or mechanism that a multicast client uses to request a
+      multicast address from a multicast address allocation server
+      (MAAS).  When the server grants an address, it becomes the
+      server's responsibility to ensure that this address is not then
+      reused elsewhere within the address's scope during the lifetime
+      granted.
+
+      Examples of possible protocols or mechanisms at this layer include
+      MADCAP [4], HTTP to access a web page for allocation, and IANA
+      static address assignments.
+
+      An abstract API for applications to use for dynamic allocation,
+      independent of the Layer 1 protocol/mechanism in use, is given in
+      [11].
+
+   Layer 2
+      An intra-domain protocol or mechanism that MAAS's use to
+      coordinate allocations to ensure they do not allocate duplicate
+      addresses.  A MAAS must have stable storage, or some equivalent
+      robustness mechanism, to ensure that uniqueness is preserved
+      across MAAS failures and reboots.
+
+
+
+
+Thaler, et al.               Informational                      [Page 6]
+
+RFC 2908                  MALLOC Architecture             September 2000
+
+
+      MAASs also use the Layer 2 protocol/mechanism to acquire (from
+      "Prefix Coordinators") the ranges of multicast addresses out of
+      which they may allocate addresses.
+
+      In this document we use the term "allocation domain" to mean an
+      administratively scoped multicast-capable region of the network,
+      within which addresses in a specific range may be allocated by a
+      Layer 2 protocol/mechanism.
+
+      Examples of protocols or mechanisms at this layer include AAP [5],
+      and manual configuration of MAAS's.
+
+   Layer 3
+      An inter-domain protocol or mechanism that allocates multicast
+      address ranges (with lifetimes) to Prefix Coordinators.
+      Individual addresses may then be allocated out of these ranges by
+      MAAS's inside allocation domains as described above.
+
+      Examples of protocols or mechanisms at this layer include MASC [6]
+      (in which Prefix Coordinators are typically routers without any
+      stable storage requirement), and static allocations by AS number
+      as described in [10] (in which Prefix Coordinators are typically
+      human administrators).
+
+   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: dthaler@microsoft.com
+
+
+   Mark Handley
+   AT&T Center for Internet Research at ICSI
+   1947 Center St, Suite 600
+   Berkeley, CA 94704
+
+   EMail: mjh@aciri.org
+
+
+   Deborah Estrin
+   Computer Science Dept/ISI
+   University of Southern California
+   Los Angeles, CA 90089
+
+   EMail: estrin@usc.edu
+
+
+
+
+
+
+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]
+