summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6308.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6308.txt')
-rw-r--r--doc/rfc/rfc6308.txt787
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]
+