doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc6308.txt b/doc/rfc/rfc6308.txt
new file mode 100644
index 0000000..b5c0fb7
--- /dev/null
+++ b/doc/rfc/rfc6308.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         P. Savola
+Request for Comments: 6308                                     CSC/FUNET
+Obsoletes: 2908                                                June 2011
+Category: Informational
+ISSN: 2070-1721
+
+
+       Overview of the Internet Multicast Addressing Architecture
+
+Abstract
+
+   The lack of up-to-date documentation on IP multicast address
+   allocation and assignment procedures has caused a great deal of
+   confusion.  To clarify the situation, this memo describes the
+   allocation and assignment techniques and mechanisms currently (as of
+   this writing) in use.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6308.
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+Savola                        Informational                     [Page 1]
+
+RFC 6308              Multicast Address Allocation             June 2011
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Terminology: Allocation or Assignment ......................3
+   2. Multicast Address Allocation ....................................3
+      2.1. Derived Allocation .........................................3
+           2.1.1. GLOP Allocation .....................................4
+           2.1.2. Unicast-Prefix-Based Allocation .....................4
+      2.2. Administratively Scoped Allocation .........................5
+      2.3. Static IANA Allocation .....................................6
+      2.4. Dynamic Allocation .........................................6
+   3. Multicast Address Assignment ....................................6
+      3.1. Derived Assignment .........................................6
+      3.2. SSM Assignment inside the Node .............................7
+      3.3. Manually Configured Assignment .............................7
+      3.4. Static IANA Assignment .....................................7
+           3.4.1. Global IANA Assignment ..............................7
+           3.4.2. Scope-Relative IANA Assignment ......................8
+      3.5. Dynamic Assignments ........................................8
+   4. Summary and Future Directions ...................................9
+      4.1. Prefix Allocation ..........................................9
+      4.2. Address Assignment ........................................10
+      4.3. Future Actions ............................................11
+   5. Acknowledgements ...............................................11
+   6. IANA Considerations ............................................11
+   7. Security Considerations ........................................11
+   8. References .....................................................12
+      8.1. Normative References ......................................12
+      8.2. Informative References ....................................13
+
+1.  Introduction
+
+   Good, up-to-date documentation of IP multicast is close to
+   non-existent.  Particularly, this is an issue with multicast address
+   allocations (to networks and sites) and assignments (to hosts and
+   applications).  This problem is stressed by the fact that there
+   exists confusing or misleading documentation on the subject
+   [RFC2908].  The consequence is that those who wish to learn about IP
+   multicast and how the addressing works do not get a clear view of the
+   current situation.
+
+   The aim of this document is to provide a brief overview of multicast
+   addressing and allocation techniques.  The term "addressing
+   architecture" refers to the set of addressing mechanisms and methods
+   in an informal manner.
+
+
+
+
+
+
+Savola                        Informational                     [Page 2]
+
+RFC 6308              Multicast Address Allocation             June 2011
+
+
+   It is important to note that Source-Specific Multicast (SSM)
+   [RFC4607] does not have these addressing problems because SSM group
+   addresses have only local significance; hence, this document focuses
+   on the Any Source Multicast (ASM) model.
+
+   This memo obsoletes and re-classifies RFC 2908 to Historic, and
+   re-classifies RFCs 2776 and 2909 to Historic.
+
+1.1.  Terminology: Allocation or Assignment
+
+   Almost all multicast documents and many other RFCs (such as DHCPv4
+   [RFC2131] and DHCPv6 [RFC3315]) have used the terms "address
+   allocation" and "address assignment" interchangeably.  However, the
+   operator and address management communities use these terms for two
+   conceptually different processes.
+
+   In unicast operations, address allocations refer to leasing a large
+   block of addresses from the Internet Assigned Numbers Authority
+   (IANA) to a Regional Internet Registry (RIR), or from an RIR to a
+   Local Internet Registry (LIR), possibly through a National Internet
+   Registry (NIR).  Address assignments, on the other hand, are the
+   leases of smaller address blocks or even single addresses to the end-
+   user sites or end-users themselves.
+
+   Therefore, in this memo, we will separate the two different
+   functions: "allocation" describes how larger blocks of addresses are
+   obtained by the network operators, and "assignment" describes how
+   applications, nodes, or sets of nodes obtain a multicast address for
+   their use.
+
+2.  Multicast Address Allocation
+
+   Multicast address allocation, i.e., how a network operator might be
+   able to obtain a larger block of addresses, can be handled in a
+   number of ways, as described below.
+
+   Note that these are all only pertinent to ASM -- SSM requires no
+   address block allocation because the group address has only local
+   significance (however, we discuss the address assignment inside the
+   node in Section 3.2).
+
+2.1.  Derived Allocation
+
+   Derived allocations take the unicast prefix or some other properties
+   of the network (e.g., an autonomous system (AS) number) to determine
+   unique multicast address allocations.
+
+
+
+
+
+Savola                        Informational                     [Page 3]
+
+RFC 6308              Multicast Address Allocation             June 2011
+
+
+2.1.1.  GLOP Allocation
+
+   GLOP address allocation [RFC3180] inserts the 16-bit public AS number
+   in the middle of the IPv4 multicast prefix 233.0.0.0/8, so that each
+   AS number can get a /24 worth of multicast addresses.  While this is
+   sufficient for multicast testing or small-scale use, it might not be
+   sufficient in all cases for extensive multicast use.
+
+   A minor operational debugging issue with GLOP addresses is that the
+   connection between the AS and the prefix is not apparent from the
+   prefix when the AS number is greater than 255, but has to be
+   calculated (e.g., as described in [RFC3180], AS 5662 maps to
+   233.22.30.0/24).  A usage issue is that GLOP addresses are not tied
+   to any prefix but to routing domains, so they cannot be used or
+   calculated automatically.
+
+   GLOP mapping is not available with 4-byte AS numbers [RFC4893].
+   Unicast-prefix-based allocation or an IANA allocation from "AD-HOC
+   Block III" (the previous so-called "EGLOP" (Extended GLOP) block)
+   could be used instead, as needed.
+
+   The GLOP allocation algorithm has not been defined for IPv6 multicast
+   because the unicast-prefix-based allocation (described below)
+   addresses the same need in a simpler fashion.
+
+2.1.2.  Unicast-Prefix-Based Allocation
+
+   RFC 3306 [RFC3306] describes a mechanism that embeds up to 64 high-
+   order bits of an IPv6 unicast address in the prefix part of the IPv6
+   multicast address, leaving at least 32 bits of group-id space
+   available after the prefix mapping.
+
+   A similar IPv4 mapping is described in [RFC6034], but it provides a
+   limited number of addresses (e.g., 1 per IPv4 /24 block).
+
+   The IPv6 unicast-prefix-based allocations are an extremely useful way
+   to allow each network operator, even each subnet, to obtain multicast
+   addresses easily, through an easy computation.  Further, as the IPv6
+   multicast header also includes the scope value [RFC4291], multicast
+   groups of smaller scope can also be used with the same mapping.
+
+   The IPv6 Embedded Rendezvous Point (RP) technique [RFC3956], used
+   with Protocol Independent Multicast - Sparse Mode (PIM-SM), further
+   leverages the unicast-prefix-based allocations, by embedding the
+   unicast prefix and interface identifier of the PIM-SM RP in the
+   prefix.  This provides all the necessary information needed to the
+   routing systems to run the group in either inter- or intra-domain
+   operation.  A difference from RFC 3306 is, however, that the hosts
+
+
+
+Savola                        Informational                     [Page 4]
+
+RFC 6308              Multicast Address Allocation             June 2011
+
+
+   cannot calculate their "multicast prefix" automatically (as the
+   prefix depends on the decisions of the operator setting up the RP),
+   but instead require an assignment method.
+
+   All the IPv6 unicast-prefix-based allocation techniques provide a
+   sufficient amount of multicast address space for network operators.
+
+2.2.  Administratively Scoped Allocation
+
+   Administratively scoped multicast address allocation [RFC2365] is
+   provided by two different means: under 239.0.0.0/8 in IPv4 or by
+   4-bit encoding in the IPv6 multicast address prefix [RFC4291].
+
+   Since IPv6 administratively scoped allocations can be handled with
+   unicast-prefix-based multicast addressing as described in
+   Section 2.1.2, we'll only discuss IPv4 in this section.
+
+   The IPv4 administratively scoped prefix 239.0.0.0/8 is further
+   divided into Local Scope (239.255.0.0/16) and Organization Local
+   Scope (239.192.0.0/14); other parts of the administrative scopes are
+   either reserved for expansion or undefined [RFC2365].  However,
+   RFC 2365 is ambiguous as to whether the enterprises or the IETF are
+   allowed to expand the space.
+
+   Topologies that act under a single administration can easily use the
+   scoped multicast addresses for their internal groups.  Groups that
+   need to be shared between multiple routing domains (even if not
+   propagated through the Internet) are more problematic and typically
+   need an assignment of a global multicast address because their scope
+   is undefined.
+
+   There are a large number of multicast applications (such as "Norton
+   Ghost") that are restricted either to a link or a site, and it is
+   extremely undesirable to propagate them further (beyond the link or
+   the site).  Typically, many such applications have been given or have
+   hijacked a static IANA address assignment.  Given the fact that
+   assignments to typically locally used applications come from the same
+   range as global applications, implementing proper propagation
+   limiting is challenging.  Filtering would be easier if a separate,
+   identifiable range would be used for such assignments in the future;
+   this is an area of further future work.
+
+   There has also been work on a protocol to automatically discover
+   multicast scope zones [RFC2776], but it has never been widely
+   implemented or deployed.
+
+
+
+
+
+
+Savola                        Informational                     [Page 5]
+
+RFC 6308              Multicast Address Allocation             June 2011
+
+
+2.3.  Static IANA Allocation
+
+   In some rare cases, organizations may have been able to obtain static
+   multicast address allocations (of up to 256 addresses) directly from
+   IANA.  Typically, these have been meant as a block of static
+   assignments to multicast applications, as described in Section 3.4.1.
+   If another means of obtaining addresses is available, that approach
+   is preferable.
+
+   Especially for those operators that only have a 32-bit AS number and
+   need IPv4 addresses, an IANA allocation from "AD-HOC Block III" (the
+   previous so-called "EGLOP" block) is an option [RFC5771].
+
+2.4.  Dynamic Allocation
+
+   RFC 2908 [RFC2908] proposed three different layers of multicast
+   address allocation and assignment, where layer 3 (inter-domain
+   allocation) and layer 2 (intra-domain allocation) could be applicable
+   here.  The Multicast Address-Set Claim Protocol (MASC) [RFC2909] is
+   an example of the former, and the Multicast Address Allocation
+   Protocol (AAP) [MALLOC-AAP] (abandoned in 2000 due to lack of
+   interest and technical problems) is an example of the latter.
+
+   Both of the proposed allocation protocols were quite complex, and
+   have never been deployed or seriously implemented.
+
+   It can be concluded that dynamic multicast address allocation
+   protocols provide no benefit beyond GLOP/unicast-prefix-based
+   mechanisms and have been abandoned.
+
+3.  Multicast Address Assignment
+
+   There are a number of possible ways for an application, node, or set
+   of nodes to learn a multicast address, as described below.
+
+   Any IPv6 address assignment method should be aware of the guidelines
+   for the assignment of group-IDs for IPv6 multicast addresses
+   [RFC3307].
+
+3.1.  Derived Assignment
+
+   There are significantly fewer options for derived address assignment
+   compared to derived allocation.  Derived multicast assignment has
+   only been specified for IPv6 link-scoped multicast [RFC4489], where
+   the EUI64 is embedded in the multicast address, providing a node with
+   unique multicast addresses for link-local ASM communications.
+
+
+
+
+
+Savola                        Informational                     [Page 6]
+
+RFC 6308              Multicast Address Allocation             June 2011
+
+
+3.2.  SSM Assignment inside the Node
+
+   While SSM multicast addresses have only local (to the node)
+   significance, there is still a minor issue on how to assign the
+   addresses between the applications running on the same IP address.
+
+   This assignment is not considered to be a problem, because typically
+   the addresses for these applications are selected manually or
+   statically, but if done using an Application Programming Interface
+   (API), the API could check that the addresses do not conflict prior
+   to assigning one.
+
+3.3.  Manually Configured Assignment
+
+   With manually configured assignment, a network operator who has a
+   multicast address prefix assigns the multicast group addresses to the
+   requesting nodes using a manual process.
+
+   Typically, the user or administrator that wants to use a multicast
+   address for a particular application requests an address from the
+   network operator using phone, email, or similar means, and the
+   network operator provides the user with a multicast address.  Then
+   the user/administrator of the node or application manually configures
+   the application to use the assigned multicast address.
+
+   This is a relatively simple process; it has been sufficient for
+   certain applications that require manual configuration in any case,
+   or that cannot or do not want to justify a static IANA assignment.
+   The manual assignment works when the number of participants in a
+   group is small, as each participant has to be manually configured.
+
+   This is the most commonly used technique when the multicast
+   application does not have a static IANA assignment.
+
+3.4.  Static IANA Assignment
+
+   In contrast to manually configured assignment, as described above,
+   static IANA assignment refers to getting an assignment for the
+   particular application directly from IANA.  There are two main forms
+   of IANA assignment: global and scope-relative.  Guidelines for IANA
+   are described in [RFC5771].
+
+3.4.1.  Global IANA Assignment
+
+   Globally unique address assignment is seen as lucrative because it's
+   the simplest approach for application developers, since they can then
+   hard-code the multicast address.  Hard-coding requires no lease of
+   the usable multicast address, and likewise the client applications do
+
+
+
+Savola                        Informational                     [Page 7]
+
+RFC 6308              Multicast Address Allocation             June 2011
+
+
+   not need to perform any kind of service discovery (but depend on
+   hard-coded addresses).  However, there is an architectural scaling
+   problem with this approach, as it encourages a "land-grab" of the
+   limited multicast address space.
+
+3.4.2.  Scope-Relative IANA Assignment
+
+   IANA also assigns numbers as an integer offset from the highest
+   address in each IPv4 administrative scope, as described in [RFC2365].
+   For example, the SLPv2 discovery scope-relative offset is "2", so the
+   SLPv2 discovery address within IPv4 Local-Scope (239.255.0.0/16) is
+   "239.255.255.253"; within the IPv4 Organization Local-Scope
+   (239.192.0.0/14), it is "239.195.255.253"; and so on.
+
+   Similar scope-relative assignments also exist with IPv6 [RFC2375].
+   As IPv6 multicast addresses have much more flexible scoping, scope-
+   relative assignments are also applicable to global scopes.  The
+   assignment policies are described in [RFC3307].
+
+3.5.  Dynamic Assignments
+
+   Layer 1 as defined in RFC 2908 [RFC2908] described dynamic assignment
+   from Multicast Address Allocation Servers (MAAS) to applications and
+   nodes, with the Multicast Address Dynamic Client Allocation Protocol
+   (MADCAP) [RFC2730] as an example.  Since then, other mechanisms have
+   also been proposed (e.g., DHCPv6 assignment
+   [MCAST-DHCPv6]), but these have not gained traction.
+
+   It would be rather straightforward to deploy a dynamic assignment
+   protocol that would lease group addresses based on a multicast prefix
+   to applications wishing to use multicast.  However, only few have
+   implemented MADCAP (i.e., it is not significantly deployed).  It is
+   not clear if the sparse deployment is due to a lack of need for the
+   protocol.  Moreover, it is not clear how widely, for example, the
+   APIs for communication between the multicast application and the
+   MADCAP client operating at the host have been implemented [RFC2771].
+
+   An entirely different approach is the Session Announcement Protocol
+   (SAP) [RFC2974].  In addition to advertising global multicast
+   sessions, the protocol also has associated ranges of addresses for
+   both IPv4 and IPv6 that can be used by SAP-aware applications to
+   create new groups and new group addresses.  Creating a session (and
+   obtaining an address) is a rather tedious process, which is why it
+   isn't done all that often.  It is also worth noting that the IPv6 SAP
+   address is unroutable in the inter-domain multicast.
+
+
+
+
+
+
+Savola                        Informational                     [Page 8]
+
+RFC 6308              Multicast Address Allocation             June 2011
+
+
+   Conclusions about dynamic assignment protocols are that:
+
+   1.  multicast is not significantly attractive in the first place,
+
+   2.  most applications have a static IANA assignment and thus require
+       no dynamic or manual assignment,
+
+   3.  those applications that cannot be easily satisfied with IANA or
+       manual assignment (i.e., where dynamic assignment would be
+       desirable) are rather marginal, or
+
+   4.  there are other reasons why dynamic assignments are not seen as a
+       useful approach (for example, issues related to service
+       discovery/rendezvous).
+
+   In consequence, more work on rendezvous/service discovery would be
+   needed to make dynamic assignments more useful.
+
+4.  Summary and Future Directions
+
+   This section summarizes the mechanisms and analysis discussed in this
+   memo, and presents some potential future directions.
+
+4.1.  Prefix Allocation
+
+   A summary of prefix allocation methods for ASM is shown in Figure 1.
+
+       +-------+--------------------------------+--------+--------+
+       | Sect. | Prefix allocation method       | IPv4   | IPv6   |
+       +-------+--------------------------------+--------+--------+
+       | 2.1.1 | Derived: GLOP                  |  Yes   | NoNeed*|
+       | 2.1.2 | Derived: Unicast-prefix-based  |   No   |  Yes   |
+       |  2.2  | Administratively scoped        |  Yes   | NoNeed*|
+       |  2.3  | Static IANA allocation         |  Yes** |   No   |
+       |  2.4  | Dynamic allocation protocols   |   No   |   No   |
+       +-------+--------------------------------+--------+--------+
+       *  = the need satisfied by IPv6 unicast-prefix-based allocation
+       ** = mainly using the AD-HOC block III (formerly called "EGLOP")
+
+                                 Figure 1
+
+
+
+
+
+
+
+
+
+
+
+Savola                        Informational                     [Page 9]
+
+RFC 6308              Multicast Address Allocation             June 2011
+
+
+   o  Only ASM is affected by the assignment/allocation issues.
+
+   o  With IPv4, GLOP allocations provide a sufficient IPv4 multicast
+      allocation mechanism for those that have a 16-bit AS number.  IPv4
+      unicast-prefix-based allocation offers some addresses.  IANA is
+      also allocating from the AD-HOC block III (formerly called
+      "EGLOP"), especially with 32-bit AS number holders in mind.
+      Administratively scoped allocations provide the opportunity for
+      internal IPv4 allocations.
+
+   o  With IPv6, unicast-prefix-based addresses and the derivatives
+      provide a good allocation strategy, and this also works for scoped
+      multicast addresses.
+
+   o  Dynamic allocations are too complex and unnecessary a mechanism.
+
+4.2.  Address Assignment
+
+   A summary of address assignment methods is shown in Figure 2.
+
+      +--------+--------------------------------+----------+----------+
+      | Sect.  | Address assignment method      | IPv4     | IPv6     |
+      +--------+--------------------------------+----------+----------+
+      |  3.1   | Derived: link-scope addresses  |  No      |   Yes    |
+      |  3.2   | SSM (inside the node)          |  Yes     |   Yes    |
+      |  3.3   | Manual assignment              |  Yes     |   Yes    |
+      |  3.4.1 | Global IANA/RIR assignment     |LastResort|LastResort|
+      |  3.4.2 | Scope-relative IANA assignment |  Yes     |   Yes    |
+      |  3.5   | Dynamic assignment protocols   |  Yes     |   Yes    |
+      +--------+--------------------------------+----------+----------+
+
+                                 Figure 2
+
+   o  Manually configured assignment is typical today, and works to a
+      sufficient degree in smaller scale.
+
+   o  Global IANA assignment has been done extensively in the past.
+      Scope-relative IANA assignment is acceptable, but the size of the
+      pool is not very high.  Inter-domain routing of IPv6 IANA-assigned
+      prefixes is likely going to be challenging, and as a result that
+      approach is not very appealing.
+
+   o  Dynamic assignment, e.g., MADCAP, has been implemented, but there
+      is no wide deployment.  Therefore, either there are other gaps in
+      the multicast architecture, or there is no sufficient demand for
+      it in the first place when manual and static IANA assignments are
+      available.  Assignments using SAP also exist but are not common;
+      global SAP assignment is infeasible with IPv6.
+
+
+
+Savola                        Informational                    [Page 10]
+
+RFC 6308              Multicast Address Allocation             June 2011
+
+
+   o  Derived assignments are only applicable in a fringe case of link-
+      scoped multicast.
+
+4.3.  Future Actions
+
+   o  Multicast address discovery/"rendezvous" needs to be analyzed at
+      more length, and an adequate solution provided.  See
+      [ADDRDISC-PROB] and [MSA-REQ] for more information.
+
+   o  The IETF should consider whether to specify more ranges of the
+      IPv4 administratively scoped address space for static allocation
+      for applications that should not be routed over the Internet (such
+      as backup software, etc. -- so that these wouldn't need to use
+      global addresses, which should never leak in any case).
+
+   o  The IETF should consider its static IANA allocations policy, e.g.,
+      "locking it down" to a stricter policy (like "IETF Consensus") and
+      looking at developing the discovery/rendezvous functions, if
+      necessary.
+
+5.  Acknowledgements
+
+   Tutoring a couple of multicast-related papers, the latest by Kaarle
+   Ritvanen [RITVANEN], convinced the author that updated multicast
+   address assignment/allocation documentation is needed.
+
+   Multicast address allocations/assignments were discussed at the
+   MBONED WG session at IETF 59 [MBONED-IETF59].
+
+   Dave Thaler, James Lingard, and Beau Williamson provided useful
+   feedback for the preliminary version of this memo.  Myung-Ki Shin,
+   Jerome Durand, John Kristoff, Dave Price, Spencer Dawkins, and Alfred
+   Hoenes also suggested improvements.
+
+6.  IANA Considerations
+
+   IANA considerations in Sections 4.1.1 and 4.1.2 of obsoleted and now
+   Historic [RFC2908] were never implemented in the IANA registry.
+
+7.  Security Considerations
+
+   This memo only describes different approaches to allocating and
+   assigning multicast addresses, and this has no security
+   considerations; the security analysis of the mentioned protocols is
+   out of scope of this memo.
+
+
+
+
+
+
+Savola                        Informational                    [Page 11]
+
+RFC 6308              Multicast Address Allocation             June 2011
+
+
+   Obviously, the dynamic assignment protocols in particular are
+   inherently vulnerable to resource exhaustion attacks, as discussed,
+   e.g., in [RFC2730].
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2365]   Meyer, D., "Administratively Scoped IP Multicast",
+               BCP 23, RFC 2365, July 1998.
+
+   [RFC3180]   Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8",
+               BCP 53, RFC 3180, September 2001.
+
+   [RFC3306]   Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
+               Multicast Addresses", RFC 3306, August 2002.
+
+   [RFC3307]   Haberman, B., "Allocation Guidelines for IPv6 Multicast
+               Addresses", RFC 3307, August 2002.
+
+   [RFC3956]   Savola, P. and B. Haberman, "Embedding the Rendezvous
+               Point (RP) Address in an IPv6 Multicast Address",
+               RFC 3956, November 2004.
+
+   [RFC4291]   Hinden, R. and S. Deering, "IP Version 6 Addressing
+               Architecture", RFC 4291, February 2006.
+
+   [RFC4489]   Park, J-S., Shin, M-K., and H-J. Kim, "A Method for
+               Generating Link-Scoped IPv6 Multicast Addresses",
+               RFC 4489, April 2006.
+
+   [RFC4607]   Holbrook, H. and B. Cain, "Source-Specific Multicast for
+               IP", RFC 4607, August 2006.
+
+   [RFC5771]   Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines
+               for IPv4 Multicast Address Assignments", BCP 51,
+               RFC 5771, March 2010.
+
+   [RFC6034]   Thaler, D., "Unicast-Prefix-Based IPv4 Multicast
+               Addresses", RFC 6034, October 2010.
+
+
+
+
+
+
+
+
+
+
+
+Savola                        Informational                    [Page 12]
+
+RFC 6308              Multicast Address Allocation             June 2011
+
+
+8.2.  Informative References
+
+   [ADDRDISC-PROB]
+               Savola, P., "Lightweight Multicast Address Discovery
+               Problem Space", Work in Progress, March 2006.
+
+   [MALLOC-AAP]
+               Handley, M. and S. Hanna, "Multicast Address Allocation
+               Protocol (AAP)", Work in Progress, June 2000.
+
+   [MBONED-IETF59]
+               "MBONED WG session at IETF59",
+               <http://www.ietf.org/proceedings/04mar/172.htm>.
+
+   [MCAST-DHCPv6]
+               Durand, J., "IPv6 multicast address assignment with
+               DHCPv6", Work in Progress, February 2005.
+
+   [MSA-REQ]   Asaeda, H. and V. Roca, "Requirements for IP Multicast
+               Session Announcement", Work in Progress, March 2010.
+
+   [RFC2131]   Droms, R., "Dynamic Host Configuration Protocol",
+               RFC 2131, March 1997.
+
+   [RFC2375]   Hinden, R. and S. Deering, "IPv6 Multicast Address
+               Assignments", RFC 2375, July 1998.
+
+   [RFC2730]   Hanna, S., Patel, B., and M. Shah, "Multicast Address
+               Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
+               December 1999.
+
+   [RFC2771]   Finlayson, R., "An Abstract API for Multicast Address
+               Allocation", RFC 2771, February 2000.
+
+   [RFC2776]   Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope
+               Zone Announcement Protocol (MZAP)", RFC 2776, February
+               2000.
+
+   [RFC2908]   Thaler, D., Handley, M., and D. Estrin, "The Internet
+               Multicast Address Allocation Architecture", RFC 2908,
+               September 2000.
+
+   [RFC2909]   Radoslavov, P., Estrin, D., Govindan, R., Handley, M.,
+               Kumar, S., and D. Thaler, "The Multicast Address-Set
+               Claim (MASC) Protocol", RFC 2909, September 2000.
+
+   [RFC2974]   Handley, M., Perkins, C., and E. Whelan, "Session
+               Announcement Protocol", RFC 2974, October 2000.
+
+
+
+Savola                        Informational                    [Page 13]
+
+RFC 6308              Multicast Address Allocation             June 2011
+
+
+   [RFC3315]   Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
+               C., and M. Carney, "Dynamic Host Configuration Protocol
+               for IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [RFC4893]   Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
+               Number Space", RFC 4893, May 2007.
+
+   [RITVANEN]  Ritvanen, K., "Multicast Routing and Addressing", HUT
+               Report, Seminar on Internetworking, May 2004,
+               <http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>.
+
+Author's Address
+
+   Pekka Savola
+   CSC - Scientific Computing Ltd.
+   Espoo
+   Finland
+
+   EMail: psavola@funet.fi
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Savola                        Informational                    [Page 14]
+