draft-ietf-mboned-addrarch-00.txt   draft-ietf-mboned-addrarch-01.txt 
Internet Engineering Task Force P. Savola Internet Engineering Task Force P. Savola
Internet-Draft CSC/FUNET Internet-Draft CSC/FUNET
Obsoletes: 2908,2909 (if approved) November 29, 2004 Obsoletes: 2908,2909 (if approved) February 18, 2005
Expires: May 30, 2005 Expires: August 19, 2005
Overview of the Internet Multicast Addressing Architecture Overview of the Internet Multicast Addressing Architecture
draft-ietf-mboned-addrarch-00.txt draft-ietf-mboned-addrarch-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 30, 2005. This Internet-Draft will expire on August 19, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
The lack of up-to-date documentation on IP multicast address The lack of up-to-date documentation on IP multicast address
allocation and assignment procedures has caused a great deal of allocation and assignment procedures has caused a great deal of
confusion. To clarify the situation, this memo describes the confusion. To clarify the situation, this memo describes the
allocation and assignment techniques and mechanisms currently (as of allocation and assignment techniques and mechanisms currently (as of
this writing) in use. this writing) in use.
Table of Contents Table of Contents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
2.1.2 Unicast-prefix -based Allocation . . . . . . . . . . . 4 2.1.2 Unicast-prefix -based Allocation . . . . . . . . . . . 4
2.2 Scope-relative Allocation . . . . . . . . . . . . . . . . 5 2.2 Scope-relative Allocation . . . . . . . . . . . . . . . . 5
2.3 Static IANA Allocation . . . . . . . . . . . . . . . . . . 6 2.3 Static IANA Allocation . . . . . . . . . . . . . . . . . . 6
2.4 Dynamic Allocation . . . . . . . . . . . . . . . . . . . . 6 2.4 Dynamic Allocation . . . . . . . . . . . . . . . . . . . . 6
3. Multicast Address Assignment . . . . . . . . . . . . . . . . . 6 3. Multicast Address Assignment . . . . . . . . . . . . . . . . . 6
3.1 Derived Assignment . . . . . . . . . . . . . . . . . . . . 6 3.1 Derived Assignment . . . . . . . . . . . . . . . . . . . . 6
3.2 SSM Assignment inside the Node . . . . . . . . . . . . . . 7 3.2 SSM Assignment inside the Node . . . . . . . . . . . . . . 7
3.3 Manually Configured Assignment . . . . . . . . . . . . . . 7 3.3 Manually Configured Assignment . . . . . . . . . . . . . . 7
3.4 Static IANA Assignment . . . . . . . . . . . . . . . . . . 7 3.4 Static IANA Assignment . . . . . . . . . . . . . . . . . . 7
3.5 Dynamic Assignments . . . . . . . . . . . . . . . . . . . 8 3.5 Dynamic Assignments . . . . . . . . . . . . . . . . . . . 8
3.6 Future Developments . . . . . . . . . . . . . . . . . . . 8 4. Summary and Future Directions . . . . . . . . . . . . . . . . 9
4. Multicast Address Discovery . . . . . . . . . . . . . . . . . 9 4.1 Prefix Allocation . . . . . . . . . . . . . . . . . . . . 9
5. Summary and Future Directions . . . . . . . . . . . . . . . . 10 4.2 Address Assignment . . . . . . . . . . . . . . . . . . . . 10
5.1 Prefix Allocation . . . . . . . . . . . . . . . . . . . . 10 4.3 Future Actions . . . . . . . . . . . . . . . . . . . . . . 10
5.2 Address Assignment . . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
5.3 Future Actions . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8.1 Normative References . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.2 Informative References . . . . . . . . . . . . . . . . . . 12
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
9.2 Informative References . . . . . . . . . . . . . . . . . . . 13 A. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 B. Multicast Address Discovery . . . . . . . . . . . . . . . . . 15
A. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . 16
1. Introduction 1. Introduction
Good, up-to-date documentation of IP multicast is close to Good, up-to-date documentation of IP multicast is close to
non-existent. Particularly, this is an issue with multicast address non-existent. Particularly, this is an issue with multicast address
allocations (to networks and sites) and assignments (to hosts and allocations (to networks and sites) and assignments (to hosts and
applications). This problem is stressed by the fact that there applications). This problem is stressed by the fact that there
exists confusing or misleading documentation on the subject exists confusing or misleading documentation on the subject
[RFC2908]. The consequence is that those who wish to learn of IP [RFC2908]. The consequence is that those who wish to learn of IP
skipping to change at page 3, line 52 skipping to change at page 4, line 5
Address assignments, on the other hand, are the leases of smaller Address assignments, on the other hand, are the leases of smaller
address blocks or even single addresses to the end-user sites or address blocks or even single addresses to the end-user sites or
end-users themselves. end-users themselves.
Therefore, in this memo, we will separate the two different Therefore, in this memo, we will separate the two different
functions: "allocation" describes how larger blocks of addresses are functions: "allocation" describes how larger blocks of addresses are
obtained by the network operators, and "assignment" describes how obtained by the network operators, and "assignment" describes how
applications, nodes or sets of nodes obtain a multicast address for applications, nodes or sets of nodes obtain a multicast address for
their use. their use.
[[ NOTE IN DRAFT: is this choice of terminology too confusing? ]]
2. Multicast Address Allocation 2. Multicast Address Allocation
Multicast address allocation, i.e., how a network operator might be Multicast address allocation, i.e., how a network operator might be
able to obtain a larger block of addresses, can be handled in a able to obtain a larger block of addresses, can be handled in a
number of ways as described below. number of ways as described below.
Note that these are all only pertinent to ASM -- SSM requires no Note that these are all only pertinent to ASM -- SSM requires no
address block allocation because the group address has only local address block allocation because the group address has only local
significance (however, the address assignment inside the node is significance (however, the address assignment inside the node is
still an issue discussed in Section 3.2). still an issue discussed in Section 3.2).
skipping to change at page 5, line 17 skipping to change at page 5, line 17
The IPv6 Embedded RP technique [RFC3956], used with Protocol The IPv6 Embedded RP technique [RFC3956], used with Protocol
Independent Multicast - Sparse Mode (PIM-SM), further leverages the Independent Multicast - Sparse Mode (PIM-SM), further leverages the
unicast prefix based allocations, by embedding the unicast prefix and unicast prefix based allocations, by embedding the unicast prefix and
interface identifier of the PIM-SM Rendezvous Point (RP) in the interface identifier of the PIM-SM Rendezvous Point (RP) in the
prefix. This provides all the necessary information needed to the prefix. This provides all the necessary information needed to the
routing systems to run the group in either inter- or intra-domain routing systems to run the group in either inter- or intra-domain
operation. A difference to RFC 3306 is, however, that the hosts operation. A difference to RFC 3306 is, however, that the hosts
cannot calculate their "multicast prefix" automatically, as the cannot calculate their "multicast prefix" automatically, as the
prefix depends on the decisions of the operator setting up the RP but prefix depends on the decisions of the operator setting up the RP but
rather needs to be communicated somehow. rather requires an assignment method.
All the IPv6 unicast-prefix -based allocation techniques provide All the IPv6 unicast-prefix -based allocation techniques provide
sufficient amount of multicast address space for the network sufficient amount of multicast address space for the network
operators. operators.
2.2 Scope-relative Allocation 2.2 Scope-relative Allocation
Administratively scoped multicast [RFC2365] is provided by two Administratively scoped multicast [RFC2365] is provided by two
different means: under 239.0.0.0/8 in IPv4 or by 4-bit encoding in different means: under 239.0.0.0/8 in IPv4 or by 4-bit encoding in
the IPv6 multicast address prefix [RFC3513]. the IPv6 multicast address prefix [RFC3513].
skipping to change at page 7, line 32 skipping to change at page 7, line 32
multicast address prefix assigns the multicast group addresses to the multicast address prefix assigns the multicast group addresses to the
requesting nodes using a manual process. requesting nodes using a manual process.
Typically the user or administrator which wants to use a multicast Typically the user or administrator which wants to use a multicast
address for particular application requests an address from the address for particular application requests an address from the
network operator using phone, email, or similar means, and the network operator using phone, email, or similar means, and the
network operator provides the user with a multicast address. Then network operator provides the user with a multicast address. Then
the user/administrator of the node or application manually configures the user/administrator of the node or application manually configures
the application to use the assigned multicast address. the application to use the assigned multicast address.
This is a relatively simple process in the beginning, but would This is a relatively simple process; it has been sufficient for
become unscalable if the multicast usage would get on a serious rise certain applications which require manual configuration in any case,
(fortunately, we have dynamic assignment, see Section 3.5). Another, or which cannot or do not want to justify a static IANA assignment.
separate issue is to ensure that the users wishing to use that The manual assignment works when the number of participants in a
application are able to locate the configured multicast address group is small, as each participant has to be manually configured.
("rendezvous" or "service discovery"); in this particular case, this
might call for e.g., DNS-based discovery of the multicast address.
This is the most commonly used technique when the multicast This is the most commonly used technique when the multicast
application does not have a static IANA assignment. application does not have a static IANA assignment.
3.4 Static IANA Assignment 3.4 Static IANA Assignment
In contrast to manually configured assignment, as described above, In contrast to manually configured assignment, as described above,
static IANA assignment refers to getting a globally unique assignment static IANA assignment refers to getting a globally unique assignment
for the particular application directly from IANA. Guidelines for for the particular application directly from IANA. Guidelines for
IANA are described in [I-D.ietf-mboned-rfc3171bis]. IANA are described in [I-D.ietf-mboned-rfc3171bis].
skipping to change at page 8, line 20 skipping to change at page 8, line 18
In summary, there are applications which have obtained a static IANA In summary, there are applications which have obtained a static IANA
assignment, some of which are really needed, and some of which assignment, some of which are really needed, and some of which
probably should not have been granted. probably should not have been granted.
3.5 Dynamic Assignments 3.5 Dynamic Assignments
The layer 1 of RFC 2908 [RFC2908] described dynamic assignment from The layer 1 of RFC 2908 [RFC2908] described dynamic assignment from
Multicast Address Allocation Servers (MAAS) to applications and Multicast Address Allocation Servers (MAAS) to applications and
nodes, with Multicast Address Dynamic Client Allocation Protocol nodes, with Multicast Address Dynamic Client Allocation Protocol
(MADCAP) [RFC2730] and a proposal for DHCPv6 assignments (MADCAP) [RFC2730] as examples. Since then, there has been a
[I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6] as examples. proposal for DHCPv6 assignment
[I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6].
Based on a multicast prefix, it would be rather straightforward to Based on a multicast prefix, it would be rather straightforward to
deploy a dynamic assignment protocol which would lease group deploy a dynamic assignment protocol which would lease group
addresses to the applications wishing to use multicast. For example, addresses to the applications wishing to use multicast. For example,
only few have implemented MADCAP, and it's not significantly only few have implemented MADCAP, and it's not significantly
deployed. Moreover, it is not clear how widely for example the APIs deployed. Moreover, it is not clear how widely for example the APIs
for communication between the multicast application and the MADCAP for communication between the multicast application and the MADCAP
client operating at the host have been implemented [RFC2771]. client operating at the host have been implemented [RFC2771].
Based on that, a conclusion is that multicast is that either: 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. It is a rather tedious process to create a
session (and obtain an address) this way 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, 1. multicast is not significantly attractive in the first place,
2. manually configured assignments are sufficient for now, or 2. very many applications have a static IANA assignment and thus
require no dynamic or manual assignment,
3. that there are other gaps why dynamic assignments are not seen as 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 a useful approach (for example, issues related to service
discovery/rendezvous). discovery/rendezvous).
In consequence, more work on rendezvous/service discovery will be In consequence, more work on rendezvous/service discovery will be
needed to make dynamic assignment more useful. needed to make dynamic assignment more useful.
3.6 Future Developments 4. Summary and Future Directions
IPv6 could offer an alternative to dynamic assignments due to its
larger address space: if a multicast prefix (e.g., about 2^32 bits
worth of group-id's) is allocated to a subnet, it would be sufficient
to ensure that multiple applications running on that subnet do not
try to use the same address (selected e.g., using a random process).
This could call for a Duplicate Address Detection process, and/or a
way for the RPs to inform the hosts about the prefix that could be
used on each subnet (assuming Embedded-RP would be used).
4. Multicast Address Discovery
[[ NOTE IN DRAFT: it is not clear whether this section belongs in
this document at all; it is somewhat related, but could bear a more
extensive discussion elsewhere. It should likely go in a separate
document (if there was one discussing these problems!), or in an
appendix. Feedback is appreciated. ]]
As was noted in Section 3, multicast address discovery (i.e., service
discovery or "rendezvous") is a problem with multicast address
assignment. In particular, an acceptable mechanism (mechanisms such
as Service Location Protocol (SLP) [RFC2608] seem to have been
considered too complex) seems to be missing which the hosts wishing
to participate in a group could use to find the address of that group
[MBONED-IETF59].
It is worth noting that as long as not deploying an address
assignment and service discovery protocols/mechanisms means that one
can get a static address assignment from IANA, there is little
interest from the application developers to actually do anything
except try to get the assignment from IANA. Conclusion: if we want
to use non-IANA processes, the assignments must be either forbidden
completely, or made sufficiently difficult that it's easier for the
application developers to take another route if a feasible mechanism
is available.
There are two issues in the service discovery:
1. The session initiator being able to publish the session somehow,
and
2. The session participants finding out about the session (rather
than creating their own).
When manually configured or static IANA assignments are used, 1)
should be relatively straightforward (if something needs to be
manually configured or statically assigned, putting it e.g., in DNS
should not be a problem). However, this is still more complex for
dynamic or derived assignments because it implies that the host or
the application has the right to make that publication on its own,
rather than through a manual process by an administrator.
2) is always a challenge, but could leverage for example DNS (e.g.,
by relying on using SRV records with the DNS search path, as
described in [I-D.iab-dns-choices] and
[I-D.palet-v6ops-tun-auto-disc]).
5. Summary and Future Directions
This section summarizes the mechanisms and analysis discussed in this This section summarizes the mechanisms and analysis discussed in this
memo, and presents some potential future directions. memo, and presents some potential future directions.
5.1 Prefix Allocation 4.1 Prefix Allocation
Summary of prefix allocation methods is in Figure 1. Summary of prefix allocation methods for ASM is in Figure 1.
+-------+--------------------------------+--------+--------+ +-------+--------------------------------+--------+--------+
| Sect. | Prefix allocation method | IPv4 | IPv6 | | Sect. | Prefix allocation method | IPv4 | IPv6 |
+-------+--------------------------------+--------+--------+ +-------+--------------------------------+--------+--------+
| 2 | SSM | NoNeed | NoNeed |
| 2.1.1 | Derived: GLOP | Yes | NoNeed*| | 2.1.1 | Derived: GLOP | Yes | NoNeed*|
| 2.1.2 | Derived: Unicast-prefix -based |No -yet | Yes | | 2.1.2 | Derived: Unicast-prefix -based |No -yet | Yes |
| 2.2 | Separate Scope-relative | Yes | NoNeed*| | 2.2 | Separate Scope-relative | Yes | NoNeed*|
| 2.3 | Static IANA allocation | No | No | | 2.3 | Static IANA allocation | No | No |
| 2.4 | Dynamic allocation protocols | No | No | | 2.4 | Dynamic allocation protocols | No | No |
+-------+--------------------------------+--------+--------+ +-------+--------------------------------+--------+--------+
* = the need satisfied by IPv6 unicast-prefix -based allocation. * = the need satisfied by IPv6 unicast-prefix -based allocation.
Figure 1 Figure 1
skipping to change at page 11, line 5 skipping to change at page 10, line 5
o Unicast-prefix -based addresses and the derivatives provide good o Unicast-prefix -based addresses and the derivatives provide good
allocation strategy with IPv6, also for scoped multicast allocation strategy with IPv6, also for scoped multicast
addresses. addresses.
o Dynamic allocations are a too complex and unnecessary mechanism. o Dynamic allocations are a too complex and unnecessary mechanism.
o Static IANA allocations are an architecturally unacceptable o Static IANA allocations are an architecturally unacceptable
approach. approach.
5.2 Address Assignment 4.2 Address Assignment
Summary of address assignment methods is in Figure 2. Summary of address assignment methods is in Figure 2.
+-------+--------------------------------+----------+----------+ +-------+--------------------------------+----------+----------+
| Sect. | Address assignment method | IPv4 | IPv6 | | Sect. | Address assignment method | IPv4 | IPv6 |
+-------+--------------------------------+----------+----------+ +-------+--------------------------------+----------+----------+
| 3.1 | Derived: link-scope addresses | No | Yes | | 3.1 | Derived: link-scope addresses | No | Yes |
| 3.2 | SSM (inside the node) | Yes | Yes | | 3.2 | SSM (inside the node) | Yes | Yes |
| 3.3 | Manual assignment | Yes | Yes | | 3.3 | Manual assignment | Yes | Yes |
| 3.4 | Static IANA assignment |LastResort|LastResort| | 3.4 | Static IANA assignment |LastResort|LastResort|
skipping to change at page 11, line 33 skipping to change at page 10, line 33
o Static IANA assignment has been done extensively in the past, but o Static IANA assignment has been done extensively in the past, but
it needs to be tightened down to prevent problems caused by it needs to be tightened down to prevent problems caused by
"land-grabbing". "land-grabbing".
o Dynamic assignment, e.g., using MADCAP have been implemented, but o Dynamic assignment, e.g., using MADCAP have been implemented, but
there is no wide deployment, so a solution is there -- but either there is no wide deployment, so a solution is there -- but either
there are other gaps in the multicast architecture or there is no there are other gaps in the multicast architecture or there is no
need for it in the first place, when manual configuration is need for it in the first place, when manual configuration is
possible, and static IANA assignments are still there. possible, and static IANA assignments are still there.
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 o Derived assignments are only applicable in a fringe case of
link-scoped multicast. link-scoped multicast.
5.3 Future Actions 4.3 Future Actions
o Multicast address discovery/"rendezvous" needs to be analyzed at o Multicast address discovery/"rendezvous" needs to be analyzed at
more length, and an adequate solution provided; the result also more length, and an adequate solution provided; the result also
needs to be written down to be shown to the IANA static assignment needs to be written down to be shown to the IANA static assignment
requestors. requestors. See [I-D.savola-mboned-address-discovery-problems]
and Appendix B for more.
o IPv6 multicast DAD and/or multicast prefix communication o IPv6 multicast DAD and/or multicast prefix communication
mechanisms should be analyzed: whether there is demand or not, and mechanisms should be analyzed (e.g.,
specify if so. [I-D.jdurand-ipv6-multicast-ra]): whether there is demand or not,
and specify if yes.
o The IETF should consider whether to specify more ranges of the o The IETF should consider whether to specify more ranges of the
IPv4 scope-relative address space for static allocation for IPv4 scope-relative address space for static allocation for
applications which should not be routed over the Internet (such as applications which should not be routed over the Internet (such as
backup software, etc. -- so that these wouldn't need to use backup software, etc. -- so that these wouldn't need to use
global addresses which should never leak in any case). global addresses which should never leak in any case).
o The IETF should seriously consider its static IANA allocations o The IETF should seriously consider its static IANA allocations
policy, e.g., "locking it down" to a stricter policy (like "IETF policy, e.g., "locking it down" to a stricter policy (like "IETF
Consensus") and looking at developing the discovery/rendezvous Consensus") and looking at developing the discovery/rendezvous
functions, if necessary. functions, if necessary.
6. Acknowledgements 5. Acknowledgements
Tutoring a couple multicast-related papers, the latest by Kaarle Tutoring a couple multicast-related papers, the latest by Kaarle
Ritvanen [RITVANEN] convinced the author that the up-to-date Ritvanen [RITVANEN] convinced the author that the up-to-date
multicast address assignment/allocation documentation is necessary. multicast address assignment/allocation documentation is necessary.
Multicast address allocations/assignments were discussed at the Multicast address allocations/assignments were discussed at the
MBONED WG session at IETF59 [MBONED-IETF59]. MBONED WG session at IETF59 [MBONED-IETF59].
Dave Thaler, James Lingard, and Beau Williamson provided useful Dave Thaler, James Lingard, and Beau Williamson provided useful
feedback for the preliminary version of this memo. Myung-Ki Shin feedback for the preliminary version of this memo. Myung-Ki Shin and
also suggested improvements. Jerome Durand also suggested improvements.
7. IANA Considerations 6. IANA Considerations
This memo includes no request to IANA, but as the allocation and This memo includes no request to IANA, but as the allocation and
assignment of multicast addresses are related to IANA functions, it assignment of multicast addresses are related to IANA functions, it
wouldn't hurt if the IANA reviewed this entire memo. wouldn't hurt if the IANA reviewed this entire memo.
IANA considerations in sections 4.1.1 and 4.1.2 of [RFC2908] still IANA considerations in sections 4.1.1 and 4.1.2 of [RFC2908] still
apply to the administratively scoped prefixes. apply to the administratively scoped prefixes.
(RFC-editor: please remove this section at publication.) (RFC-editor: please remove this section at publication.)
8. Security Considerations 7. Security Considerations
This memo only describes different approaches to allocating and This memo only describes different approaches to allocating and
assigning multicast addresses, and this has no security assigning multicast addresses, and this has no security
considerations; the security analysis of the mentioned protocols is considerations; the security analysis of the mentioned protocols is
out of scope of this memo. out of scope of this memo.
Obviously, especially the dynamic assignment protocols are inherently Obviously, especially the dynamic assignment protocols are inherently
vulnerable to resource exhaustion attacks, as discussed e.g., in vulnerable to resource exhaustion attacks, as discussed e.g., in
[RFC2730]. [RFC2730].
9. References 8. References
9.1 Normative References 8.1 Normative References
[I-D.ietf-ipv6-link-scoped-mcast] [I-D.ietf-ipv6-link-scoped-mcast]
Park, J., Shin, M. and H. Kim, "Link Scoped IPv6 Multicast Park, J., "Link Scoped IPv6 Multicast Addresses",
Addresses", draft-ietf-ipv6-link-scoped-mcast-06 (work in Internet-Draft draft-ietf-ipv6-link-scoped-mcast-08,
progress), October 2004. December 2004.
[I-D.ietf-mboned-rfc3171bis] [I-D.ietf-mboned-rfc3171bis]
Albanna, Z., Almeroth, K., Cotton, M. and D. Meyer, "IANA Albanna, Z., Almeroth, K., Cotton, M. and D. Meyer, "IANA
Guidelines for IPv4 Multicast Address Assignments", Guidelines for IPv4 Multicast Address Assignments",
draft-ietf-mboned-rfc3171bis-02 (work in progress), March Internet-Draft draft-ietf-mboned-rfc3171bis-02, March
2004. 2004.
[I-D.ietf-ssm-arch] [I-D.ietf-ssm-arch]
Holbrook, H. and B. Cain, "Source-Specific Multicast for Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", draft-ietf-ssm-arch-06 (work in progress), September IP", Internet-Draft draft-ietf-ssm-arch-06, September
2004. 2004.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, July 1998. RFC 2365, July 1998.
[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8",
53, RFC 3180, September 2001. BCP 53, RFC 3180, September 2001.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002. Multicast Addresses", RFC 3306, August 2002.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002. Addresses", RFC 3307, August 2002.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003. (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", RFC Point (RP) Address in an IPv6 Multicast Address",
3956, November 2004. RFC 3956, November 2004.
9.2 Informative References 8.2 Informative References
[I-D.iab-dns-choices] [I-D.iab-dns-choices]
Faltstrom, P. and R. Austein, "Design Choices When Faltstrom, P. and R. Austein, "Design Choices When
Expanding DNS", draft-iab-dns-choices-00 (work in Expanding DNS", Internet-Draft draft-iab-dns-choices-00,
progress), October 2004. October 2004.
[I-D.ietf-malloc-aap] [I-D.ietf-malloc-aap]
Handley, M. and S. Hanna, "Multicast Address Allocation Handley, M. and S. Hanna, "Multicast Address Allocation
Protocol (AAP)", June 2000. Protocol (AAP)", June 2000.
[I-D.ietf-mboned-ipv4-uni-based-mcast] [I-D.ietf-mboned-ipv4-uni-based-mcast]
Thaler, D., "Unicast-Prefix-based IPv4 Multicast Thaler, D., "Unicast-Prefix-based IPv4 Multicast
Addresses", draft-ietf-mboned-ipv4-uni-based-mcast-02 Addresses",
(work in progress), October 2004. Internet-Draft draft-ietf-mboned-ipv4-uni-based-mcast-02,
October 2004.
[I-D.ietf-mboned-ipv6-multicast-issues] [I-D.ietf-mboned-ipv6-multicast-issues]
Savola, P., "IPv6 Multicast Deployment Issues", Savola, P., "IPv6 Multicast Deployment Issues",
draft-ietf-mboned-ipv6-multicast-issues-01 (work in Internet-Draft draft-ietf-mboned-ipv6-multicast-issues-01,
progress), September 2004. September 2004.
[I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6] [I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6]
Durand, J., "IPv6 multicast address assignment with Durand, J., "IPv6 multicast address assignment with
DHCPv6", DHCPv6",
draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 (work , June 2004.
in progress), June 2004.
[I-D.jdurand-ipv6-multicast-ra]
Durand, J. and P. Savola, "Route Advertisement Option for
IPv6 Multicast Prefixes",
Internet-Draft draft-jdurand-ipv6-multicast-ra-00,
February 2005.
[I-D.palet-v6ops-tun-auto-disc] [I-D.palet-v6ops-tun-auto-disc]
Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point
Discovery Mechanisms", draft-palet-v6ops-tun-auto-disc-02 Discovery Mechanisms",
(work in progress), October 2004. Internet-Draft draft-palet-v6ops-tun-auto-disc-03, January
2005.
[I-D.savola-mboned-address-discovery-problems]
Savola, P., "Lightweight Multicast Address Discovery
Problem Space",
, February 2005.
[MBONED-IETF59] [MBONED-IETF59]
"MBONED WG session at IETF59", "MBONED WG session at IETF59",
<http://www.ietf.org/proceedings/04mar/172.htm>. <http://www.ietf.org/proceedings/04mar/172.htm>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
2131, March 1997. RFC 2131, March 1997.
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day,
"Service Location Protocol, Version 2", RFC 2608, June "Service Location Protocol, Version 2", RFC 2608, June
1999. 1999.
[RFC2730] Hanna, S., Patel, B. and M. Shah, "Multicast Address [RFC2730] Hanna, S., Patel, B. and M. Shah, "Multicast Address
Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
December 1999. December 1999.
[RFC2771] Finlayson, R., "An Abstract API for Multicast Address [RFC2771] Finlayson, R., "An Abstract API for Multicast Address
Allocation", RFC 2771, February 2000. Allocation", RFC 2771, February 2000.
[RFC2908] Thaler, D., Handley, M. and D. Estrin, "The Internet [RFC2908] Thaler, D., Handley, M. and D. Estrin, "The Internet
Multicast Address Allocation Architecture", RFC 2908, Multicast Address Allocation Architecture", RFC 2908,
September 2000. September 2000.
[RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M., [RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M.,
Kumar, S. and D. Thaler, "The Multicast Address-Set Claim Kumar, S. and D. Thaler, "The Multicast Address-Set Claim
(MASC) Protocol", RFC 2909, September 2000. (MASC) Protocol", RFC 2909, September 2000.
[RFC2974] Handley, M., Perkins, C. and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
M. Carney, "Dynamic Host Configuration Protocol for IPv6 M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[RITVANEN] [RITVANEN]
Ritvanen, K., "Multicast Routing and Addressing", HUT Ritvanen, K., "Multicast Routing and Addressing", HUT
Report, Seminar on Internetworking, May 2004, Report, Seminar on Internetworking, May 2004,
<http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>. <http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>.
Author's Address Author's Address
Pekka Savola Pekka Savola
CSC - Scientific Computing Ltd. CSC - Scientific Computing Ltd.
Espoo Espoo
Finland Finland
EMail: psavola@funet.fi Email: psavola@funet.fi
Appendix A. Open Issues Appendix A. Open Issues
(This section will be removed or merged with the rest before (This section will be removed or merged with the rest before
publication..) publication..)
o Is the case for IPv4 Unicast-Prefix Base Multicast addressing o Is the case for IPv4 Unicast-Prefix Base Multicast addressing
sufficiently strong, or could those organizations just get an AS sufficiently strong, or could those organizations just get an AS
number themselves if they really wanted to do multicast? number themselves if they really wanted to do multicast?
o Should one merge the routing architecture document's contents here Appendix B. Multicast Address Discovery
as well?
[[ NOTE IN DRAFT: the intent of this section has been mostly
superceded by [I-D.savola-mboned-address-discovery-problems] and
therefore it is put in the appendix, with pending removal in the
future.
As was noted in Section 3, multicast address discovery (i.e., service
discovery or "rendezvous") is a problem with multicast address
assignment. In particular, an acceptable mechanism (mechanisms such
as Service Location Protocol (SLP) [RFC2608] seem to have been
considered too complex) seems to be missing which the hosts wishing
to participate in a group could use to find the address of that group
[MBONED-IETF59].
It is worth noting that as long as not deploying an address
assignment and service discovery protocols/mechanisms means that one
can get a static address assignment from IANA, there is little
interest from the application developers to actually do anything
except try to get the assignment from IANA. Conclusion: if we want
to use non-IANA processes, the assignments must be either forbidden
completely, or made sufficiently difficult that it's easier for the
application developers to take another route if a feasible mechanism
is available.
There are two issues in the service discovery:
1. The session initiator being able to publish the session somehow,
and
2. The session participants finding out about the session (rather
than creating their own).
When manually configured or static IANA assignments are used, 1)
should be relatively straightforward (if something needs to be
manually configured or statically assigned, putting it e.g., in DNS
should not be a problem). However, this is still more complex for
dynamic or derived assignments because it implies that the host or
the application has the right to make that publication on its own,
rather than through a manual process by an administrator.
2) is always a challenge, but could leverage for example DNS (e.g.,
by relying on using SRV records with the DNS search path, as
described in [I-D.iab-dns-choices] and
[I-D.palet-v6ops-tun-auto-disc]).
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 16, line 41 skipping to change at page 16, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/