One document matched: draft-ietf-mboned-addrarch-04.txt
Differences from draft-ietf-mboned-addrarch-03.txt
Internet Engineering Task Force P. Savola
Internet-Draft CSC/FUNET
Obsoletes: 2776,2908,2909 (if March 3, 2006
approved)
Intended status: Best Current
Practice
Expires: September 4, 2006
Overview of the Internet Multicast Addressing Architecture
draft-ietf-mboned-addrarch-04.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 4, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
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.
Savola Expires September 4, 2006 [Page 1]
Internet-Draft Multicast Address Allocation March 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology: Allocation or Assignment . . . . . . . . . . 3
2. Multicast Address Allocation . . . . . . . . . . . . . . . . . 4
2.1. Derived Allocation . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . 8
3.4.2. Scope-relative IANA Assignment . . . . . . . . . . . . 8
3.5. Dynamic Assignments . . . . . . . . . . . . . . . . . . . 8
4. Summary and Future Directions . . . . . . . . . . . . . . . . 9
4.1. Prefix Allocation . . . . . . . . . . . . . . . . . . . . 10
4.2. Address Assignment . . . . . . . . . . . . . . . . . . . . 11
4.3. Future Actions . . . . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 15
A.1. Changes since -01 . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Savola Expires September 4, 2006 [Page 2]
Internet-Draft Multicast Address Allocation March 2006
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 of 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.
It is important to note that Source-specific Multicast (SSM)
[I-D.ietf-ssm-arch] does not have these addressing problems; hence,
this document focuses on the Any Source Multicast (ASM) model.
This memo obsoletes RFCs 2776, 2908, and 2909 and re-classifies them
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 "assignment" interchangeably. However, the operator
and address management communities use these for two conceptually
different processes.
In unicast operations, address allocations refer to leasing a large
block of addresses from Internet Assigned Numbers Authority (IANA) to
a Regional Internet Registry (RIR) or from 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.
Savola Expires September 4, 2006 [Page 3]
Internet-Draft Multicast Address Allocation March 2006
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 to determine unique multicast address allocations.
2.1.1. GLOP Allocation
GLOP address allocation [RFC3180] inserts the 16-bit public
Autonomous System (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., from [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.
2.1.2. Unicast-prefix -based Allocation
RFC 3306 [RFC3306] describes a mechanism which embeds up to 64 first
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 mapping has been proposed for IPv4
[I-D.ietf-mboned-ipv4-uni-based-mcast], but it provides a rather low
amount of addresses (e.g., 1 per an IPv4 /24 block). While there
exist large networks without an AS number of their own, this has not
been seen to add sufficient value compared to GLOP addressing.
The IPv6 unicast-prefix-based allocations are an extremely useful way
to allow each network operator, even each subnet, obtain multicast
addresses easily, through an easy computation. Further, as the IPv6
Savola Expires September 4, 2006 [Page 4]
Internet-Draft Multicast Address Allocation March 2006
multicast header also includes the scope value [RFC3513], multicast
groups of smaller scope can also be used with the same mapping.
The IPv6 Embedded 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 Rendezvous Point (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 to RFC 3306 is, however, that the hosts
cannot calculate their "multicast prefix" automatically, as the
prefix depends on the decisions of the operator setting up the RP but
rather requires an assignment method.
All the IPv6 unicast-prefix-based allocation techniques provide
sufficient amount of multicast address space for the network
operators.
2.2. Administratively Scoped Allocation
Administratively scoped multicast [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 [RFC3513].
As IPv6 administratively scoped allocations can be handled with
unicast-prefix-based multicast addressing as described in
Section 2.1.2, we'll just discuss IPv4 in this section.
The IPv4 administratively scoped prefix 239.0.0.0/8 is further
divided to 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 it's the enterprises or the IETF who are
allowed to expand the space.
Topologies which act under a single administration can easily use the
scoped multicast addresses for their internal groups. Groups which
need to be shared between multiple routing domains (but not
propagated through the Internet) are more problematic and typically
need an assignment of a global multicast address because their scope
is undefined.
There is a large number of multicast applications (such as "Norton
Ghost") which are restricted either to a link or a site, and it is
extremely undesirable to propagate them further (either to the rest
of the site, or beyond the site). Typically many such applications
have been given or have hijacked a static IANA address assignment;
this makes it challenging to implement proper propagation limiting --
Savola Expires September 4, 2006 [Page 5]
Internet-Draft Multicast Address Allocation March 2006
which could be easier if such applications could have been assigned
specific administratively scoped addresses instead. 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.
2.3. Static IANA Allocation
In some rare cases, some 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. In principle, IANA does not allocate multicast
address blocks to the operators but GLOP or Unicast-prefix-based
allocations should be used instead.
2.4. Dynamic Allocation
RFC 2908 [RFC2908] proposed three different layers of multicast
address allocation and assignment, where layers 3 (inter-domain
allocation) and layer 2 (intra-domain allocation) could be applicable
here. Multicast Address-Set Claim Protocol (MASC) [RFC2909] is an
example of the former, and Multicast Address Allocation Protocol
(AAP) [I-D.ietf-malloc-aap] (abandoned in 2000 due 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 there are no dynamic multicast address
allocation protocols, and other methods such as GLOP or unicast-
prefix-based addressing should be used instead.
3. Multicast Address Assignment
For multicast address assignment, i.e., how an application learns the
address it can use, or a node (or a set of nodes) learns an address
it could use for an application, has a number of options as described
below.
Any IPv6 address assignment method should be aware of the guidelines
for the assignment of the group-IDs for IPv6 multicast addresses
[RFC3307].
Savola Expires September 4, 2006 [Page 6]
Internet-Draft Multicast Address Allocation March 2006
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
[I-D.ietf-ipv6-link-scoped-mcast], where the EUI64 is embedded in the
multicast address, providing a node with unique multicast addresses
for link-local ASM communications.
3.2. SSM Assignment inside the Node
While the 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 node (or more
precisely, an IP address).
This assignment is not considered to be a problem because typically
the addresses for the 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, the 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 which wants to use a multicast
address for 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 which require manual configuration in any case,
or which 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
Savola Expires September 4, 2006 [Page 7]
Internet-Draft Multicast Address Allocation March 2006
particular application directly from IANA. There are two main forms
of IANA assignment: global and scope-relative. Guidelines for IANA
are described in [RFC3171][I-D.ietf-mboned-rfc3171bis].
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
not need to perform any kind of service discovery (but depending 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.
[RFC3138] describes how to handle those GLOP assignments (called
"eGLOP") which use the private-use AS number space (233.252.0.0/14).
It was envisioned that IANA would delegate the responsibility of
these to RIRs, which would assign or allocate addresses as best
seemed fit. However, this was never carried out as IANA did not make
these allocations to RIRs due to procedural reasons.
In summary, there are applications which have obtained a global
static IANA assignment and while some of which are really needed,
some of which probably should not have been granted. Conversely,
there are some applications that have not obtained a static IANA
assignment, yet should have requested an assignment and been granted
one.
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
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
The layer 1 of RFC 2908 [RFC2908] described dynamic assignment from
Multicast Address Allocation Servers (MAAS) to applications and
nodes, with Multicast Address Dynamic Client Allocation Protocol
Savola Expires September 4, 2006 [Page 8]
Internet-Draft Multicast Address Allocation March 2006
(MADCAP) [RFC2730] as an example. Since then, there has been a
proposal for DHCPv6 assignment
[I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6].
It would be rather straightforward to deploy a dynamic assignment
protocol which would lease group addresses based on a multicast
prefix to the applications wishing to use multicast. For example,
only few have implemented MADCAP, and it's not significantly
deployed. 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 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 which 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. (Note that the IPv6 SAP address is unroutable in the
inter-domain multicast.)
A conclusion about dynamic assignment protocols is that:
1. multicast is not significantly attractive in the first place,
2. very many applications have a static IANA assignment and thus
require no dynamic or manual assignment,
3. those that cannot be easily satisfied with IANA or manual
assignment (i.e., where dynamic assignment would be desirable)
are rather marginal, or
4. that there are other gaps 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.
Savola Expires September 4, 2006 [Page 9]
Internet-Draft Multicast Address Allocation March 2006
4.1. Prefix Allocation
Summary of prefix allocation methods for ASM is in Figure 1.
+-------+--------------------------------+--------+--------+
| Sect. | Prefix allocation method | IPv4 | IPv6 |
+-------+--------------------------------+--------+--------+
| 2.1.1 | Derived: GLOP | Yes | NoNeed*|
| 2.1.2 | Derived: Unicast-prefix-based |No -yet | Yes |
| 2.2 | Administratively scoped | Yes | NoNeed*|
| 2.3 | Static IANA allocation | No | No |
| 2.4 | Dynamic allocation protocols | No | No |
+-------+--------------------------------+--------+--------+
* = the need satisfied by IPv6 unicast-prefix-based allocation.
Figure 1
o Only ASM is affected by the assignment/allocation issues (however,
both ASM and SSM have roughly the same address discovery issues).
o GLOP allocations seem to provide a sufficient IPv4 multicast
allocation mechanism for now, but could be extended in future.
Administratively scoped allocations provide the opportunity for
internal IPv4 allocations.
o Unicast-prefix-based addresses and the derivatives provide good
allocation strategy with IPv6, also for scoped multicast
addresses.
o Dynamic allocations are a too complex and unnecessary mechanism.
o Static IANA allocations are generally an architecturally
unacceptable approach.
Savola Expires September 4, 2006 [Page 10]
Internet-Draft Multicast Address Allocation March 2006
4.2. Address Assignment
Summary of address assignment methods is 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 what's typically done today, and
works to a sufficient degree in smaller scale.
o Global IANA assignment has been done extensively in the past, but
it needs to be tightened down to prevent problems caused by "land-
grabbing". 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.
o Dynamic assignment, e.g., MADCAP has been implemented, but there
is no wide deployment, so a solution is there. However, 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 unfeasible with IPv6.
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; the result also
needs to be written down to be shown to the IANA static assignment
requestors. See [I-D.ietf-mboned-addrdisc-problems] for more.
o IPv6 multicast DAD and/or multicast prefix communication
mechanisms should be analyzed (e.g.,
[I-D.jdurand-ipv6-multicast-ra]): whether there is demand or not,
and specify if yes.
Savola Expires September 4, 2006 [Page 11]
Internet-Draft Multicast Address Allocation March 2006
o The IETF should consider whether to specify more ranges of the
IPv4 administratively scoped address space for static allocation
for applications which 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 seriously 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 multicast-related papers, the latest by Kaarle
Ritvanen [RITVANEN] convinced the author that the up-to-date
multicast address assignment/allocation documentation is necessary.
Multicast address allocations/assignments were discussed at the
MBONED WG session at IETF59 [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, and Dave Price also suggested
improvements.
6. IANA Considerations
This memo includes no request to IANA, but as the allocation and
assignment of multicast addresses are related to IANA functions, it
wouldn't hurt if the IANA reviewed this entire memo.
IANA considerations in sections 4.1.1 and 4.1.2 of [RFC2908] still
apply to the administratively scoped prefixes.
IANA may be interested in reviewing the accuracy of the statement on
eGLOP address assignments in Section 3.4.1.
(RFC-editor: please remove this section at publication.)
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 Expires September 4, 2006 [Page 12]
Internet-Draft Multicast Address Allocation March 2006
Obviously, especially the dynamic assignment protocols are inherently
vulnerable to resource exhaustion attacks, as discussed e.g., in
[RFC2730].
8. References
8.1. Normative References
[I-D.ietf-ipv6-link-scoped-mcast]
Park, J., "A Method for Generating Link Scoped IPv6
Multicast Addresses", draft-ietf-ipv6-link-scoped-mcast-09
(work in progress), July 2005.
[I-D.ietf-ssm-arch]
Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", draft-ietf-ssm-arch-07 (work in progress),
October 2005.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, July 1998.
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,
"IANA Guidelines for IPv4 Multicast Address Assignments",
BCP 51, RFC 3171, August 2001.
[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.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, November 2004.
8.2. Informative References
[I-D.ietf-malloc-aap]
Handley, M. and S. Hanna, "Multicast Address Allocation
Protocol (AAP)", June 2000.
Savola Expires September 4, 2006 [Page 13]
Internet-Draft Multicast Address Allocation March 2006
[I-D.ietf-mboned-addrdisc-problems]
Savola, P., "Lightweight Multicast Address Discovery
Problem Space", draft-ietf-mboned-addrdisc-problems-01
(work in progress), November 2005.
[I-D.ietf-mboned-ipv4-uni-based-mcast]
Thaler, D., "Unicast-Prefix-based IPv4 Multicast
Addresses", draft-ietf-mboned-ipv4-uni-based-mcast-02
(work in progress), October 2004.
[I-D.ietf-mboned-rfc3171bis]
Albanna, Z., Almeroth, K., Cotton, M., and D. Meyer, "IANA
Guidelines for IPv4 Multicast Address Assignments",
draft-ietf-mboned-rfc3171bis-02 (work in progress),
March 2004.
[I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6]
Durand, J., "IPv6 multicast address assignment with
DHCPv6",
draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01 (work
in progress), February 2005.
[I-D.jdurand-ipv6-multicast-ra]
Durand, J. and P. Savola, "Route Advertisement Option for
IPv6 Multicast Prefixes",
draft-jdurand-ipv6-multicast-ra-00 (work in progress),
February 2005.
[MBONED-IETF59]
"MBONED WG session at IETF59",
<http://www.ietf.org/proceedings/04mar/172.htm>.
[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.
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
"Service Location Protocol, Version 2", RFC 2608,
June 1999.
[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.
Savola Expires September 4, 2006 [Page 14]
Internet-Draft Multicast Address Allocation March 2006
[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.
[RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138,
June 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[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/>.
Appendix A. Changes
(To be removed prior to publication as an RFC.)
A.1. Changes since -01
o Mention the mechanisms which haven't been so succesful: eGLOP and
MZAP.
o Remove the appendices on multicast address discovery (a separate
draft now) and IPv4 unicast-prefix-based multicast addressing.
o Add a note on administraively scoped address space and the
expansion ambiguity.
o Remove the references to draft-ietf-mboned-ipv6-issues-xx.txt
o Minor editorial cleanups.
Savola Expires September 4, 2006 [Page 15]
Internet-Draft Multicast Address Allocation March 2006
Author's Address
Pekka Savola
CSC - Scientific Computing Ltd.
Espoo
Finland
Email: psavola@funet.fi
Savola Expires September 4, 2006 [Page 16]
Internet-Draft Multicast Address Allocation March 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Savola Expires September 4, 2006 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-22 23:34:51 |