draft-ietf-mboned-addrarch-03.txt | draft-ietf-mboned-addrarch-04.txt | |||
---|---|---|---|---|
Internet Engineering Task Force P. Savola | Internet Engineering Task Force P. Savola | |||
Internet-Draft CSC/FUNET | Internet-Draft CSC/FUNET | |||
Obsoletes: 2776,2908,2909 (if October 18, 2005 | Obsoletes: 2776,2908,2909 (if March 3, 2006 | |||
approved) | approved) | |||
Expires: April 21, 2006 | Intended status: Best Current | |||
Practice | ||||
Expires: September 4, 2006 | ||||
Overview of the Internet Multicast Addressing Architecture | Overview of the Internet Multicast Addressing Architecture | |||
draft-ietf-mboned-addrarch-03.txt | draft-ietf-mboned-addrarch-04.txt | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | 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 | 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. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
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 | |||
skipping to change at page 1, line 35 | skipping to change at page 1, line 37 | |||
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 April 21, 2006. | This Internet-Draft will expire on September 4, 2006. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2005). | Copyright (C) The Internet Society (2006). | |||
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 | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Terminology: Allocation or Assignment . . . . . . . . . . 3 | 1.1. Terminology: Allocation or Assignment . . . . . . . . . . 3 | |||
2. Multicast Address Allocation . . . . . . . . . . . . . . . . . 4 | 2. Multicast Address Allocation . . . . . . . . . . . . . . . . . 4 | |||
2.1. Derived Allocation . . . . . . . . . . . . . . . . . . . . 4 | 2.1. Derived Allocation . . . . . . . . . . . . . . . . . . . . 4 | |||
2.1.1. GLOP Allocation . . . . . . . . . . . . . . . . . . . 4 | 2.1.1. GLOP Allocation . . . . . . . . . . . . . . . . . . . 4 | |||
2.1.2. Unicast-prefix -based Allocation . . . . . . . . . . . 4 | 2.1.2. Unicast-prefix -based Allocation . . . . . . . . . . . 4 | |||
2.2. Scope-relative Allocation . . . . . . . . . . . . . . . . 5 | 2.2. Administratively Scoped 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 . . . . . . . . . . . . . . . . . . . . 7 | 3.1. Derived Assignment . . . . . . . . . . . . . . . . . . . . 7 | |||
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.4.1. Global IANA Assignment . . . . . . . . . . . . . . . . 8 | ||||
3.4.2. Scope-relative IANA Assignment . . . . . . . . . . . . 8 | ||||
3.5. Dynamic Assignments . . . . . . . . . . . . . . . . . . . 8 | 3.5. Dynamic Assignments . . . . . . . . . . . . . . . . . . . 8 | |||
4. Summary and Future Directions . . . . . . . . . . . . . . . . 9 | 4. Summary and Future Directions . . . . . . . . . . . . . . . . 9 | |||
4.1. Prefix Allocation . . . . . . . . . . . . . . . . . . . . 9 | 4.1. Prefix Allocation . . . . . . . . . . . . . . . . . . . . 10 | |||
4.2. Address Assignment . . . . . . . . . . . . . . . . . . . . 10 | 4.2. Address Assignment . . . . . . . . . . . . . . . . . . . . 11 | |||
4.3. Future Actions . . . . . . . . . . . . . . . . . . . . . . 11 | 4.3. Future Actions . . . . . . . . . . . . . . . . . . . . . . 11 | |||
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 | 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 | 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 | |||
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 14 | Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
A.1. Changes since -01 . . . . . . . . . . . . . . . . . . . . 14 | A.1. Changes since -01 . . . . . . . . . . . . . . . . . . . . 15 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 15 | Intellectual Property and Copyright Statements . . . . . . . . . . 17 | |||
1. Introduction | 1. Introduction | |||
Good, up-to-date documentation of IP multicast is close to non- | Good, up-to-date documentation of IP multicast is close to non- | |||
existent. Particularly, this is an issue with multicast address | 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 | |||
multicast and how the addressing works do not get a clear view of the | multicast and how the addressing works do not get a clear view of the | |||
skipping to change at page 4, line 44 | skipping to change at page 4, line 44 | |||
usage issue is that GLOP addresses are not tied to any prefix but to | usage issue is that GLOP addresses are not tied to any prefix but to | |||
routing domains, so they cannot be used or calculated automatically. | routing domains, so they cannot be used or calculated automatically. | |||
2.1.2. Unicast-prefix -based Allocation | 2.1.2. Unicast-prefix -based Allocation | |||
RFC 3306 [RFC3306] describes a mechanism which embeds up to 64 first | 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 | bits of an IPv6 unicast address in the prefix part of the IPv6 | |||
multicast address, leaving at least 32 bits of group-id space | multicast address, leaving at least 32 bits of group-id space | |||
available after the prefix mapping. | available after the prefix mapping. | |||
A similar mapping has been proposed for IPv4 [I-D.ietf-mboned-ipv4- | A similar mapping has been proposed for IPv4 | |||
uni-based-mcast], but it provides a rather low amount of addresses | [I-D.ietf-mboned-ipv4-uni-based-mcast], but it provides a rather low | |||
(e.g., 1 per an IPv4 /24 block). While there exist large networks | amount of addresses (e.g., 1 per an IPv4 /24 block). While there | |||
without an AS number of their own, this has not been seen to add | exist large networks without an AS number of their own, this has not | |||
sufficient value compared to GLOP addressing. | been seen to add sufficient value compared to GLOP addressing. | |||
The IPv6 unicast-prefix-based allocations are an extremely useful way | The IPv6 unicast-prefix-based allocations are an extremely useful way | |||
to allow each network operator, even each subnet, obtain multicast | to allow each network operator, even each subnet, obtain multicast | |||
addresses easily, through an easy computation. Further, as the IPv6 | addresses easily, through an easy computation. Further, as the IPv6 | |||
multicast header also includes the scope value [RFC3513], multicast | multicast header also includes the scope value [RFC3513], multicast | |||
groups of smaller scope can also be used with the same mapping. | groups of smaller scope can also be used with the same mapping. | |||
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 | |||
skipping to change at page 5, line 22 | skipping to change at page 5, line 22 | |||
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 requires an assignment method. | 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. Administratively Scoped 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]. | |||
As IPv6 scope-relative allocations can be handled with unicast- | As IPv6 administratively scoped allocations can be handled with | |||
prefix-based multicast addressing as described in Section 2.1.2, and | unicast-prefix-based multicast addressing as described in | |||
there is no need for separate scope-relative allocations, we'll just | Section 2.1.2, we'll just discuss IPv4 in this section. | |||
discuss IPv4 in this section. | ||||
The IPv4 scope-relative prefix 239.0.0.0/8 is further divided to | The IPv4 administratively scoped prefix 239.0.0.0/8 is further | |||
Local Scope (239.255.0.0/16) and Organization Local Scope | 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 | (239.192.0.0/14); other parts of the administrative scopes are either | |||
reserved for expansion or undefined [RFC2365]. However, RFC 2365 is | reserved for expansion or undefined [RFC2365]. However, RFC 2365 is | |||
ambiguous as to whether it's the enterprises or the IETF who are | ambiguous as to whether it's the enterprises or the IETF who are | |||
allowed to expand the space. | allowed to expand the space. | |||
Topologies which act under a single administration can easily use the | Topologies which act under a single administration can easily use the | |||
scoped multicast addresses for their internal groups. Groups which | scoped multicast addresses for their internal groups. Groups which | |||
need to be shared between multiple routing domains (but not | need to be shared between multiple routing domains (but not | |||
propagated through the Internet) are more problematic and typically | propagated through the Internet) are more problematic and typically | |||
need an assignment of a global multicast address because their scope | need an assignment of a global multicast address because their scope | |||
is undefined. | is undefined. | |||
There is a large number of multicast applications (such as "Norton | 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 | Ghost") which are restricted either to a link or a site, and it is | |||
extremely undesirable to propagate them further (either to the rest | extremely undesirable to propagate them further (either to the rest | |||
of the site, or beyond the site). Typically many such applications | of the site, or beyond the site). Typically many such applications | |||
have been given or have hijacked a static IANA address assignment; | have been given or have hijacked a static IANA address assignment; | |||
this makes it challenging to implement proper propagation limiting -- | this makes it challenging to implement proper propagation limiting -- | |||
which could be easier if such applications could have been assigned | which could be easier if such applications could have been assigned | |||
specific scope-relative addresses instead. This is an area of | specific administratively scoped addresses instead. This is an area | |||
further future work. | of further future work. | |||
There has also been work on a protocol to automatically discover | There has also been work on a protocol to automatically discover | |||
multicast scope zones [RFC2776], but it has never been widely | multicast scope zones [RFC2776], but it has never been widely | |||
implemented or deployed. | implemented or deployed. | |||
2.3. Static IANA Allocation | 2.3. Static IANA Allocation | |||
In some rare cases, some organizations may have been able to obtain | In some rare cases, some organizations may have been able to obtain | |||
static multicast address allocations (of up to 256 addresses) | static multicast address allocations (of up to 256 addresses) | |||
directly from IANA. Typically these have been meant as a block of | directly from IANA. Typically these have been meant as a block of | |||
static assignments to multicast applications, as described in | static assignments to multicast applications, as described in | |||
Section 3.4. In principle, IANA does not allocate multicast address | Section 3.4.1. In principle, IANA does not allocate multicast | |||
blocks to the operators but GLOP or Unicast-prefix-based allocations | address blocks to the operators but GLOP or Unicast-prefix-based | |||
should be used instead. | allocations should be used instead. | |||
2.4. Dynamic Allocation | 2.4. Dynamic Allocation | |||
RFC 2908 [RFC2908] proposed three different layers of multicast | RFC 2908 [RFC2908] proposed three different layers of multicast | |||
address allocation and assignment, where layers 3 (inter-domain | address allocation and assignment, where layers 3 (inter-domain | |||
allocation) and layer 2 (intra-domain allocation) could be applicable | allocation) and layer 2 (intra-domain allocation) could be applicable | |||
here. Multicast Address-Set Claim Protocol (MASC) [RFC2909] is an | here. Multicast Address-Set Claim Protocol (MASC) [RFC2909] is an | |||
example of the former, and Multicast Address Allocation Protocol | example of the former, and Multicast Address Allocation Protocol | |||
(AAP) [I-D.ietf-malloc-aap] (abandoned in 2000 due lack of interest | (AAP) [I-D.ietf-malloc-aap] (abandoned in 2000 due lack of interest | |||
and technical problems) is an example of the latter. | and technical problems) is an example of the latter. | |||
skipping to change at page 7, line 9 | skipping to change at page 7, line 9 | |||
below. | below. | |||
Any IPv6 address assignment method should be aware of the guidelines | Any IPv6 address assignment method should be aware of the guidelines | |||
for the assignment of the group-IDs for IPv6 multicast addresses | for the assignment of the group-IDs for IPv6 multicast addresses | |||
[RFC3307]. | [RFC3307]. | |||
3.1. Derived Assignment | 3.1. Derived Assignment | |||
There are significantly fewer options for derived address assignment | There are significantly fewer options for derived address assignment | |||
compared to derived allocation. Derived multicast assignment has | compared to derived allocation. Derived multicast assignment has | |||
only been specified for IPv6 link-scoped multicast [I-D.ietf-ipv6- | only been specified for IPv6 link-scoped multicast | |||
link-scoped-mcast], where the EUI64 is embedded in the multicast | [I-D.ietf-ipv6-link-scoped-mcast], where the EUI64 is embedded in the | |||
address, providing a node with unique multicast addresses for link- | multicast address, providing a node with unique multicast addresses | |||
local ASM communications. | for link-local ASM communications. | |||
3.2. SSM Assignment inside the Node | 3.2. SSM Assignment inside the Node | |||
While the SSM multicast addresses have only local (to 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 | significance, there is still a minor issue on how to assign the | |||
addresses between the applications running on the same node (or more | addresses between the applications running on the same node (or more | |||
precisely, an IP address). | precisely, an IP address). | |||
This assignment is not considered to be a problem because typically | This assignment is not considered to be a problem because typically | |||
the addresses for the applications are selected manually or | the addresses for the applications are selected manually or | |||
skipping to change at page 7, line 52 | skipping to change at page 7, line 52 | |||
or which cannot or do not want to justify a static IANA assignment. | or which cannot or do not want to justify a static IANA assignment. | |||
The manual assignment works when the number of participants in a | The manual assignment works when the number of participants in a | |||
group is small, as each participant has to be manually configured. | group is small, as each participant has to be manually configured. | |||
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 an assignment for the | |||
for the particular application directly from IANA. Guidelines for | particular application directly from IANA. There are two main forms | |||
IANA are described in [RFC3171][I-D.ietf-mboned-rfc3171bis]. | of IANA assignment: global and scope-relative. Guidelines for IANA | |||
are described in [RFC3171][I-D.ietf-mboned-rfc3171bis]. | ||||
This is seen as lucrative because it's the simplest approach for | 3.4.1. Global IANA Assignment | |||
application developers because they can then hard-code the multicast | ||||
address. Hard-coding requires no lease of the usable multicast | Globally unique address assignment is seen as lucrative because it's | |||
address, and likewise the client applications do not need to perform | the simplest approach for application developers since they can then | |||
any kind of service discovery (but depending on hard-coded | hard-code the multicast address. Hard-coding requires no lease of | |||
addresses). However, there is an architectural scaling problem with | the usable multicast address, and likewise the client applications do | |||
this approach, as it encourages a "land-grab" of the limited | not need to perform any kind of service discovery (but depending on | |||
multicast address space. | 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 | [RFC3138] describes how to handle those GLOP assignments (called | |||
"eGLOP") which use the private-use AS number space (233.252.0.0/14). | "eGLOP") which use the private-use AS number space (233.252.0.0/14). | |||
It was envisioned that IANA would delegate the responsibility of | It was envisioned that IANA would delegate the responsibility of | |||
these to RIRs, which would assign or allocate addresses as best | these to RIRs, which would assign or allocate addresses as best | |||
seemed fit. However, this was never carried out as IANA did not make | seemed fit. However, this was never carried out as IANA did not make | |||
these allocations to RIRs due to procedural reasons. | these allocations to RIRs due to procedural reasons. | |||
In summary, there are applications which have obtained a static IANA | In summary, there are applications which have obtained a global | |||
assignment and while some of which are really needed, some of which | static IANA assignment and while some of which are really needed, | |||
probably should not have been granted. Conversely, there are some | some of which probably should not have been granted. Conversely, | |||
applications that have not obtained a static IANA assignment, yet | there are some applications that have not obtained a static IANA | |||
should have requested an assignment and been granted one. | 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 | 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] as an example. Since then, there has been a | (MADCAP) [RFC2730] as an example. Since then, there has been a | |||
proposal for DHCPv6 assignment [I-D.jdurand-assign-addr-ipv6- | proposal for DHCPv6 assignment | |||
multicast-dhcpv6]. | [I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6]. | |||
It would be rather straightforward to deploy a dynamic assignment | It would be rather straightforward to deploy a dynamic assignment | |||
protocol which would lease group addresses based on a multicast | protocol which would lease group addresses based on a multicast | |||
prefix to the applications wishing to use multicast. For example, | prefix 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]. | |||
An entirely different approach is Session Announcement Protocol (SAP) | An entirely different approach is Session Announcement Protocol (SAP) | |||
skipping to change at page 9, line 39 | skipping to change at page 10, line 14 | |||
4.1. Prefix Allocation | 4.1. Prefix Allocation | |||
Summary of prefix allocation methods for ASM 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.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 | Administratively scoped | 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 | |||
o Only ASM is affected by the assignment/allocation issues (however, | o Only ASM is affected by the assignment/allocation issues (however, | |||
both ASM and SSM have roughly the same address discovery issues). | both ASM and SSM have roughly the same address discovery issues). | |||
o GLOP allocations seem to provide a sufficient IPv4 multicast | o GLOP allocations seem to provide a sufficient IPv4 multicast | |||
allocation mechanism for now, but could be extended in future. | allocation mechanism for now, but could be extended in future. | |||
Scope-relative allocations provide the opportunity for internal | Administratively scoped allocations provide the opportunity for | |||
IPv4 allocations. | internal IPv4 allocations. | |||
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 generally an architecturally | o Static IANA allocations are generally an architecturally | |||
unacceptable approach. | unacceptable approach. | |||
4.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/RIR assignment |LastResort|LastResort| | | 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 | | | 3.5 | Dynamic assignment protocols | Yes | Yes | | |||
+-------+--------------------------------+----------+----------+ | +--------+--------------------------------+----------+----------+ | |||
Figure 2 | Figure 2 | |||
o Manually configured assignment is what's typically done today, and | o Manually configured assignment is what's typically done today, and | |||
works to a sufficient degree in smaller scale. | works to a sufficient degree in smaller scale. | |||
o Static IANA assignment has been done extensively in the past, but | o Global IANA assignment has been done extensively in the past, but | |||
it needs to be tightened down to prevent problems caused by "land- | it needs to be tightened down to prevent problems caused by "land- | |||
grabbing". | 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 | o Dynamic assignment, e.g., MADCAP has been implemented, but there | |||
is no wide deployment, so a solution is there. However, either | is no wide deployment, so a solution is there. However, 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 | |||
sufficient demand for it in the first place when manual and static | sufficient demand for it in the first place when manual and static | |||
IANA assignments are available. Assignments using SAP also exist | IANA assignments are available. Assignments using SAP also exist | |||
but are not common; global SAP assignment is unfeasible with IPv6. | but are not common; global SAP assignment is unfeasible with IPv6. | |||
o Derived assignments are only applicable in a fringe case of link- | o Derived assignments are only applicable in a fringe case of link- | |||
scoped multicast. | scoped multicast. | |||
skipping to change at page 11, line 18 | skipping to change at page 12, line 6 | |||
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. See [I-D.ietf-mboned-addrdisc-problems] for more. | requestors. See [I-D.ietf-mboned-addrdisc-problems] for more. | |||
o IPv6 multicast DAD and/or multicast prefix communication | o IPv6 multicast DAD and/or multicast prefix communication | |||
mechanisms should be analyzed (e.g., | mechanisms should be analyzed (e.g., | |||
[I-D.jdurand-ipv6-multicast-ra]): whether there is demand or not, | [I-D.jdurand-ipv6-multicast-ra]): whether there is demand or not, | |||
and specify if yes. | 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 administratively scoped address space for static allocation | |||
applications which should not be routed over the Internet (such as | for applications which should not be routed over the Internet | |||
backup software, etc. -- so that these wouldn't need to use global | (such as backup software, etc. -- so that these wouldn't need to | |||
addresses which should never leak in any case). | use 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. | |||
5. 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, | |||
Jerome Durand, and John Kristoff also suggested improvements. | Jerome Durand, John Kristoff, and Dave Price also suggested | |||
improvements. | ||||
6. 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. | |||
IANA may be interested in reviewing the accuracy of the statement on | IANA may be interested in reviewing the accuracy of the statement on | |||
eGLOP address assignments in Section 3.4. | eGLOP address assignments in Section 3.4.1. | |||
(RFC-editor: please remove this section at publication.) | (RFC-editor: please remove this section at publication.) | |||
7. 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. | |||
skipping to change at page 13, line 18 | skipping to change at page 14, line 7 | |||
RFC 3956, November 2004. | RFC 3956, November 2004. | |||
8.2. Informative References | 8.2. Informative References | |||
[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-addrdisc-problems] | [I-D.ietf-mboned-addrdisc-problems] | |||
Savola, P., "Lightweight Multicast Address Discovery | Savola, P., "Lightweight Multicast Address Discovery | |||
Problem Space", draft-ietf-mboned-addrdisc-problems-00 | Problem Space", draft-ietf-mboned-addrdisc-problems-01 | |||
(work in progress), March 2005. | (work in progress), November 2005. | |||
[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", draft-ietf-mboned-ipv4-uni-based-mcast-02 | |||
(work in progress), October 2004. | (work in progress), October 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), | draft-ietf-mboned-rfc3171bis-02 (work in progress), | |||
skipping to change at page 13, line 51 | skipping to change at page 14, line 40 | |||
draft-jdurand-ipv6-multicast-ra-00 (work in progress), | draft-jdurand-ipv6-multicast-ra-00 (work in progress), | |||
February 2005. | 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", | [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", | |||
RFC 2131, March 1997. | 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, | [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, | |||
"Service Location Protocol, Version 2", RFC 2608, | "Service Location Protocol, Version 2", RFC 2608, | |||
June 1999. | June 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. | |||
skipping to change at page 15, line 8 | skipping to change at page 15, line 44 | |||
(To be removed prior to publication as an RFC.) | (To be removed prior to publication as an RFC.) | |||
A.1. Changes since -01 | A.1. Changes since -01 | |||
o Mention the mechanisms which haven't been so succesful: eGLOP and | o Mention the mechanisms which haven't been so succesful: eGLOP and | |||
MZAP. | MZAP. | |||
o Remove the appendices on multicast address discovery (a separate | o Remove the appendices on multicast address discovery (a separate | |||
draft now) and IPv4 unicast-prefix-based multicast addressing. | draft now) and IPv4 unicast-prefix-based multicast addressing. | |||
o Add a note on scope-relative address space and the expansion | o Add a note on administraively scoped address space and the | |||
ambiguity. | expansion ambiguity. | |||
o Remove the references to draft-ietf-mboned-ipv6-issues-xx.txt | o Remove the references to draft-ietf-mboned-ipv6-issues-xx.txt | |||
o Minor editorial cleanups. | o Minor editorial cleanups. | |||
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 | |||
Full Copyright Statement | Full Copyright Statement | |||
Copyright (C) The Internet Society (2005). | Copyright (C) The Internet Society (2006). | |||
This document is subject to the rights, licenses and restrictions | This document is subject to the rights, licenses and restrictions | |||
contained in BCP 78, and except as set forth therein, the authors | contained in BCP 78, and except as set forth therein, the authors | |||
retain all their rights. | retain all their rights. | |||
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 | |||
skipping to change at page 16, line 20 | skipping to change at page 17, line 47 | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at | this standard. Please address the information to the IETF at | |||
ietf-ipr@ietf.org. | ietf-ipr@ietf.org. | |||
Acknowledgment | Acknowledgment | |||
Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is provided by the IETF | |||
Internet Society. | Administrative Support Activity (IASA). | |||
End of changes. 38 change blocks. | ||||
75 lines changed or deleted | 103 lines changed or added | |||
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |