draft-ietf-mboned-addrarch-05.txt | draft-ietf-mboned-addrarch-06.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 October 16, 2006 | Obsoletes: 2908 (if approved) August 3, 2009 | |||
(if approved) | Intended status: Informational | |||
Intended status: Best Current | Expires: February 4, 2010 | |||
Practice | ||||
Expires: April 19, 2007 | ||||
Overview of the Internet Multicast Addressing Architecture | Overview of the Internet Multicast Addressing Architecture | |||
draft-ietf-mboned-addrarch-05.txt | draft-ietf-mboned-addrarch-06.txt | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | This Internet-Draft is submitted to IETF in full conformance with the | |||
applicable patent or other IPR claims of which he or she is aware | provisions of BCP 78 and BCP 79. | |||
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 | 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 Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
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 19, 2007. | This Internet-Draft will expire on February 4, 2010. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2006). | Copyright (c) 2009 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | ||||
This document is subject to BCP 78 and the IETF Trust's Legal | ||||
Provisions Relating to IETF Documents in effect on the date of | ||||
publication of this document (http://trustee.ietf.org/license-info). | ||||
Please review these documents carefully, as they describe your rights | ||||
and restrictions with respect to this document. | ||||
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. Administratively Scoped 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 . . . . . . . . . . . . . . . . . 7 | |||
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 . . . . . . . . . . . . . . . . . . 8 | 3.4. Static IANA Assignment . . . . . . . . . . . . . . . . . . 8 | |||
3.4.1. Global IANA Assignment . . . . . . . . . . . . . . . . 8 | 3.4.1. Global IANA Assignment . . . . . . . . . . . . . . . . 8 | |||
3.4.2. Scope-relative IANA Assignment . . . . . . . . . . . . 8 | 3.4.2. Scope-relative IANA Assignment . . . . . . . . . . . . 8 | |||
3.5. Dynamic Assignments . . . . . . . . . . . . . . . . . . . 9 | 3.5. Dynamic Assignments . . . . . . . . . . . . . . . . . . . 8 | |||
4. Summary and Future Directions . . . . . . . . . . . . . . . . 10 | 4. Summary and Future Directions . . . . . . . . . . . . . . . . 9 | |||
4.1. Prefix Allocation . . . . . . . . . . . . . . . . . . . . 10 | 4.1. Prefix Allocation . . . . . . . . . . . . . . . . . . . . 10 | |||
4.2. Address Assignment . . . . . . . . . . . . . . . . . . . . 11 | 4.2. Address Assignment . . . . . . . . . . . . . . . . . . . . 11 | |||
4.3. Future Actions . . . . . . . . . . . . . . . . . . . . . . 11 | 4.3. Future Actions . . . . . . . . . . . . . . . . . . . . . . 11 | |||
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 | 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 | 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 | |||
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 15 | Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
A.1. Changes between -04 and -05 . . . . . . . . . . . . . . . 15 | A.1. Changes between -05 and -06 . . . . . . . . . . . . . . . 15 | |||
A.2. Changes between -03 and -04 . . . . . . . . . . . . . . . 16 | A.2. Changes between -04 and -05 . . . . . . . . . . . . . . . 15 | |||
A.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 16 | A.3. Changes between -03 and -04 . . . . . . . . . . . . . . . 16 | |||
A.4. Changes between -01 and -02 . . . . . . . . . . . . . . . 16 | A.4. Changes between -02 and -03 . . . . . . . . . . . . . . . 16 | |||
A.5. Changes between -01 and -02 . . . . . . . . . . . . . . . 16 | ||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
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 about IP | [RFC2908]. The consequence is that those who wish to learn about IP | |||
multicast and how the addressing works do not get a clear view of the | multicast and how the addressing works do not get a clear view of the | |||
skipping to change at page 3, line 26 | skipping to change at page 3, line 26 | |||
The aim of this document is to provide a brief overview of multicast | The aim of this document is to provide a brief overview of multicast | |||
addressing and allocation techniques. The term 'addressing | addressing and allocation techniques. The term 'addressing | |||
architecture' refers to the set of addressing mechanisms and methods | architecture' refers to the set of addressing mechanisms and methods | |||
in an informal manner. | in an informal manner. | |||
It is important to note that Source-specific Multicast (SSM) | It is important to note that Source-specific Multicast (SSM) | |||
[RFC4607] does not have these addressing problems because SSM group | [RFC4607] does not have these addressing problems because SSM group | |||
addresses have only local significance; hence, this document focuses | addresses have only local significance; hence, this document focuses | |||
on the Any Source Multicast (ASM) model. | on the Any Source Multicast (ASM) model. | |||
This memo obsoletes RFCs 2776, 2908, and 2909 and re-classifies them | This memo obsoletes and re-classifies to Historic RFC 2908, and re- | |||
Historic. | classifies to Historic RFCs 2776 and 2909. | |||
1.1. Terminology: Allocation or Assignment | 1.1. Terminology: Allocation or Assignment | |||
Almost all multicast documents and many other RFCs (such as DHCPv4 | Almost all multicast documents and many other RFCs (such as DHCPv4 | |||
[RFC2131] and DHCPv6 [RFC3315]) have used the terms address | [RFC2131] and DHCPv6 [RFC3315]) have used the terms address | |||
"allocation" and "assignment" interchangeably. However, the operator | "allocation" and "assignment" interchangeably. However, the operator | |||
and address management communities use these terms for two | and address management communities use these terms for two | |||
conceptually different processes. | conceptually different processes. | |||
In unicast operations, address allocations refer to leasing a large | In unicast operations, address allocations refer to leasing a large | |||
skipping to change at page 4, line 37 | skipping to change at page 4, line 37 | |||
sufficient for multicast testing or small scale use, it might not be | sufficient for multicast testing or small scale use, it might not be | |||
sufficient in all cases for extensive multicast use. | sufficient in all cases for extensive multicast use. | |||
A minor operational debugging issue with GLOP addresses is that the | A minor operational debugging issue with GLOP addresses is that the | |||
connection between the AS and the prefix is not apparent from 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 | 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 | 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 | 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. | |||
GLOP allocation algorithm has not been defined for IPv6 multicast | GLOP mapping is not available with 4-byte AS numbers [RFC4893]. | |||
Unicast-prefix-based Allocation or an IANA allocation from "AD-HOC | ||||
Block III" (the previous so-called "eGLOP" block) could be used | ||||
instead as needed. | ||||
The GLOP allocation algorithm has not been defined for IPv6 multicast | ||||
because the unicast-prefix -based allocation (described below) | because the unicast-prefix -based allocation (described below) | |||
addresses the same need in a simpler fashion. GLOP hasn't been (and | addresses the same need in a simpler fashion. | |||
likely never will be) specified for 4-byte AS numbers | ||||
[I-D.ietf-idr-as4bytes]. | ||||
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 high- | RFC 3306 [RFC3306] describes a mechanism which embeds up to 64 high- | |||
order bits of an IPv6 unicast address in the prefix part of the IPv6 | order bits of an IPv6 unicast address in the prefix part of the IPv6 | |||
multicast address, leaving at least 32 bits of group-id space | 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 | A similar IPv4 mapping is described in | |||
[I-D.ietf-mboned-ipv4-uni-based-mcast], but it provides a rather low | [I-D.ietf-mboned-ipv4-uni-based-mcast], but it provides a limited | |||
amount of addresses (e.g., 1 per an IPv4 /24 block). Although large | number of addresses (e.g., 1 per an IPv4 /24 block). | |||
networks without an AS number do exist, this technique has not been | ||||
seen to add 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, to obtain multicast | to allow each network operator, even each subnet, to 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 [RFC4291], 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 | |||
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 from RFC 3306 is, however, that the hosts | operation. A difference from 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, | prefix depends on the decisions of the operator setting up the RP, | |||
but instead requires an assignment method. | but instead 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 network operators. | |||
operators. | ||||
2.2. Administratively Scoped Allocation | 2.2. Administratively Scoped Allocation | |||
Administratively scoped multicast address allocation [RFC2365] is | Administratively scoped multicast address allocation [RFC2365] is | |||
provided by two different means: under 239.0.0.0/8 in IPv4 or by | 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]. | 4-bit encoding in the IPv6 multicast address prefix [RFC4291]. | |||
Since IPv6 administratively scoped allocations can be handled with | Since IPv6 administratively scoped allocations can be handled with | |||
unicast-prefix-based multicast addressing as described in | unicast-prefix-based multicast addressing as described in | |||
Section 2.1.2, we'll just discuss IPv4 in this section. | Section 2.1.2, we'll only discuss IPv4 in this section. | |||
The IPv4 administratively scoped prefix 239.0.0.0/8 is further | 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 | divided into Local Scope (239.255.0.0/16) and Organization Local | |||
(239.192.0.0/14); other parts of the administrative scopes are either | Scope (239.192.0.0/14); other parts of the administrative scopes are | |||
reserved for expansion or undefined [RFC2365]. However, RFC 2365 is | either reserved for expansion or undefined [RFC2365]. However, RFC | |||
ambiguous as to whether the enterprises or the IETF are allowed to | 2365 is ambiguous as to whether the enterprises or the IETF are | |||
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 (even if not | need to be shared between multiple routing domains (even if 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 (beyond the link or | extremely undesirable to propagate them further (beyond the link or | |||
the site). Typically many such applications have been given or have | the site). Typically many such applications have been given or have | |||
hijacked a static IANA address assignment. The fact that assignments | hijacked a static IANA address assignment. Given the fact that | |||
to typically locally used applications come from the same range as | assignments to typically locally used applications come from the same | |||
global applications, implementing proper propagation limiting is | range as global applications, implementing proper propagation | |||
challenging. Filtering would be easier if such applications would in | limiting is challenging. Filtering would be easier if a separate, | |||
future be assigned specific administratively scoped addresses | identifiable range would be used for such assignments in the future; | |||
instead. This is an area of further future work. | this is an area 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, organizations may have been able to obtain static | |||
static multicast address allocations (of up to 256 addresses) | multicast address allocations (of up to 256 addresses) directly from | |||
directly from IANA. Typically these have been meant as a block of | IANA. Typically these have been meant as a block of static | |||
static assignments to multicast applications, as described in | assignments to multicast applications, as described in Section 3.4.1. | |||
Section 3.4.1. In principle, IANA should not and does not allocate | If another means of obtaining addresses is available that approach is | |||
multicast address blocks to the operators but GLOP or Unicast-prefix- | preferable. | |||
based allocations should be used instead. | ||||
Especially for those operators that only have a 32-bit AS number and | ||||
need IPv4 addresses, an IANA allocation from "AD-HOC Block III" (the | ||||
previous so-called "eGLOP" block) is an option | ||||
[I-D.ietf-mboned-rfc3171bis]. | ||||
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 6 | skipping to change at page 7, line 11 | |||
It can be concluded that dynamic multicast address allocation | It can be concluded that dynamic multicast address allocation | |||
protocols provide no benefit beyond GLOP/unicast-prefix-based | protocols provide no benefit beyond GLOP/unicast-prefix-based | |||
mechanisms and have been abandoned. | mechanisms and have been abandoned. | |||
3. Multicast Address Assignment | 3. Multicast Address Assignment | |||
There are a number of possible ways for an application, node or set | There are a number of possible ways for an application, node or set | |||
of nodes to learn a multicast address as described below. | of nodes to learn a multicast address as described 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 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 [RFC4489], where | only been specified for IPv6 link-scoped multicast [RFC4489], where | |||
the EUI64 is embedded in the multicast address, providing a node with | the EUI64 is embedded in the multicast address, providing a node with | |||
unique multicast addresses for link-local ASM communications. | unique multicast addresses 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 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 IP address. | addresses between the applications running on the same 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 these applications are selected manually or | |||
statically, but if done using an Application Programming Interface | statically, but if done using an Application Programming Interface | |||
(API), the API could check that the addresses do not conflict prior | (API), the API could check that the addresses do not conflict prior | |||
to assigning one. | to assigning one. | |||
3.3. Manually Configured Assignment | 3.3. Manually Configured Assignment | |||
With manually configured assignment, the network operator who has a | With manually configured assignment, a network operator who has a | |||
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 that wants to use a multicast | |||
address for particular application requests an address from the | address for a 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; it has been sufficient for | This is a relatively simple process; it has been sufficient for | |||
certain applications which require manual configuration in any case, | certain applications which require manual configuration in any case, | |||
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 an assignment for the | static IANA assignment refers to getting an assignment for the | |||
particular application directly from IANA. There are two main forms | particular application directly from IANA. There are two main forms | |||
of IANA assignment: global and scope-relative. Guidelines for IANA | of IANA assignment: global and scope-relative. Guidelines for IANA | |||
are described in [RFC3171][I-D.ietf-mboned-rfc3171bis]. | are described in [I-D.ietf-mboned-rfc3171bis]. | |||
3.4.1. Global IANA Assignment | 3.4.1. Global IANA Assignment | |||
Globally unique address assignment is seen as lucrative because it's | Globally unique address assignment is seen as lucrative because it's | |||
the simplest approach for application developers since they can then | the simplest approach for application developers since they can then | |||
hard-code the multicast address. Hard-coding requires no lease of | hard-code the multicast address. Hard-coding requires no lease of | |||
the usable multicast address, and likewise the client applications do | the usable multicast address, and likewise the client applications do | |||
not need to perform any kind of service discovery (but depending on | not need to perform any kind of service discovery (but depending on | |||
hard-coded addresses). However, there is an architectural scaling | hard-coded addresses). However, there is an architectural scaling | |||
problem with this approach, as it encourages a "land-grab" of the | problem with this approach, as it encourages a "land-grab" of the | |||
limited multicast address space. | 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 the assignments were really | ||||
needed, others 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 | 3.4.2. Scope-relative IANA Assignment | |||
IANA also assigns numbers as an integer offset from the highest | IANA also assigns numbers as an integer offset from the highest | |||
address in each IPv4 administrative scope as described in [RFC2365]. | address in each IPv4 administrative scope as described in [RFC2365]. | |||
For example, the SLPv2 discovery scope-relative offset is "2", so | For example, the SLPv2 discovery scope-relative offset is "2", so | |||
SLPv2 discovery address within IPv4 Local-Scope (239.255.0.0/16) is | SLPv2 discovery address within IPv4 Local-Scope (239.255.0.0/16) is | |||
"239.255.255.253", within the IPv4 Organization Local-Scope | "239.255.255.253", within the IPv4 Organization Local-Scope | |||
(239.192.0.0/14) it is "239.195.255.253", and so on. | (239.192.0.0/14) it is "239.195.255.253", and so on. | |||
Similar scope-relative assignments also exist with IPv6 [RFC2375]. | Similar scope-relative assignments also exist with IPv6 [RFC2375]. | |||
As IPv6 multicast addresses have much more flexible scoping, scope- | As IPv6 multicast addresses have much more flexible scoping, scope- | |||
relative assignments are also applicable to global scopes. The | relative assignments are also applicable to global scopes. The | |||
assignment policies are described in [RFC3307]. | 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, other mechanisms have | |||
proposal for DHCPv6 assignment | also been proposed (e.g., DHCPv6 assignment | |||
[I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6]. | [I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6]) but these have not | |||
gained traction. | ||||
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. However, only | prefix to applications wishing to use multicast. However, only few | |||
few have implemented MADCAP, and it hasn't been significantly | have implemented MADCAP, and it hasn't been significantly deployed. | |||
deployed. So, it is not clear if the lack of deployment is due to a | So, it is not clear if the lack of deployment is due to a currently | |||
currently missing need. Moreover, it is not clear how widely for | missing need. Moreover, it is not clear how widely for example the | |||
example the APIs for communication between the multicast application | APIs for communication between the multicast application and the | |||
and the MADCAP client operating at the host have been implemented | MADCAP client operating at the host have been implemented [RFC2771]. | |||
[RFC2771]. | ||||
An entirely different approach is Session Announcement Protocol (SAP) | An entirely different approach is Session Announcement Protocol (SAP) | |||
[RFC2974]. In addition to advertising global multicast sessions, the | [RFC2974]. In addition to advertising global multicast sessions, the | |||
protocol also has associated ranges of addresses for both IPv4 and | protocol also has associated ranges of addresses for both IPv4 and | |||
IPv6 which can be used by SAP-aware applications to create new groups | IPv6 which can be used by SAP-aware applications to create new groups | |||
and new group addresses. Creating a session (and obtaining an | and new group addresses. Creating a session (and obtaining an | |||
address) is a rather tedious process which is why it isn't done all | 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 | that often. It is also worth noting that the IPv6 SAP address is | |||
inter-domain multicast.) | unroutable in the inter-domain multicast. | |||
A conclusion about dynamic assignment protocols is that: | 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. most applications have a static IANA assignment and thus require | 2. most applications have a static IANA assignment and thus require | |||
no dynamic or manual assignment, | no dynamic or manual assignment, | |||
3. those that cannot be easily satisfied with IANA or manual | 3. those that cannot be easily satisfied with IANA or manual | |||
assignment (i.e., where dynamic assignment would be desirable) | assignment (i.e., where dynamic assignment would be desirable) | |||
skipping to change at page 10, line 12 | skipping to change at page 10, line 7 | |||
In consequence, more work on rendezvous/service discovery would be | In consequence, more work on rendezvous/service discovery would be | |||
needed to make dynamic assignments more useful. | needed to make dynamic assignments more useful. | |||
4. Summary and Future Directions | 4. 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. | |||
4.1. Prefix Allocation | 4.1. Prefix Allocation | |||
Summary of prefix allocation methods for ASM is in Figure 1. | A summary of prefix allocation methods for ASM is shown 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 | Yes | | | 2.1.2 | Derived: Unicast-prefix-based | No | Yes | | |||
| 2.2 | Administratively scoped | Yes | NoNeed*| | | 2.2 | Administratively scoped | Yes | NoNeed*| | |||
| 2.3 | Static IANA allocation | No | No | | | 2.3 | Static IANA allocation | Yes** | 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. | |||
** = mainly using the AD-HOC block III (former "eGLOP") | ||||
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. | |||
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 | o With IPv4, GLOP allocations provide a sufficient IPv4 multicast | |||
allocation strategy with IPv6, also for scoped multicast | allocation mechanism for those that have 16-bit AS number. IPv4 | |||
addresses. | unicast-prefix based allocation offers some addresses. IANA is | |||
also allocating from the AD-HOC block III (former "eGLOP") with | ||||
especially 32-bit AS number holders in mind. Administratively | ||||
scoped allocations provide the opportunity for internal IPv4 | ||||
allocations. | ||||
o Dynamic allocations are a too complex and unnecessary mechanism. | o With IPv6, unicast-prefix-based addresses and the derivatives | |||
provide a good allocation strategy and this also works for scoped | ||||
multicast addresses. | ||||
o Static IANA allocations are generally an architecturally | o Dynamic allocations are too complex and unnecessary a mechanism. | |||
unacceptable approach. | ||||
4.2. Address Assignment | 4.2. Address Assignment | |||
Summary of address assignment methods is in Figure 2. | A summary of address assignment methods is shown 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.1 | Global IANA/RIR assignment |LastResort|LastResort| | | 3.4.1 | Global IANA/RIR assignment |LastResort|LastResort| | |||
| 3.4.2 | Scope-relative IANA assignment | Yes | Yes | | | 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 typical today, and works to a | |||
works to a sufficient degree in smaller scale. | sufficient degree in smaller scale. | |||
o Global IANA assignment has been done extensively in the past, but | o Global IANA assignment has been done extensively in the past. | |||
it needs to be tightened down to prevent problems caused by "land- | Scope-relative IANA assignment is acceptable but the size of the | |||
grabbing". Scope-relative IANA assignment is acceptable but the | pool is not very high. Inter-domain routing of IPv6 IANA-assigned | |||
size of the pool is not very high. Inter-domain routing of IPv6 | prefixes is likely going to be challenging and as a result that | |||
IANA-assigned prefixes is likely going to be challenging. | approach is not very appealing. | |||
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, either there are other gaps in the | is no wide deployment. Therefore, either there are other gaps in | |||
multicast architecture or there is no sufficient demand for it in | the multicast architecture or there is no sufficient demand for it | |||
the first place when manual and static IANA assignments are | in the first place when manual and static IANA assignments are | |||
available. Assignments using SAP also exist but are not common; | available. Assignments using SAP also exist but are not common; | |||
global SAP assignment is unfeasible with IPv6. | 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. | |||
4.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. See | |||
needs to be written down to be shown to the IANA static assignment | [I-D.ietf-mboned-addrdisc-problems] and | |||
requestors. See [I-D.ietf-mboned-addrdisc-problems] for more. | [I-D.ietf-mboned-session-announcement-req] 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. | ||||
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 administratively scoped address space for static allocation | IPv4 administratively scoped address space for static allocation | |||
for applications which should not be routed over the Internet | for applications which should not be routed over the Internet | |||
(such as backup software, etc. -- so that these wouldn't need to | (such as backup software, etc. -- so that these wouldn't need to | |||
use global 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 consider its static IANA allocations policy, e.g., | |||
policy, e.g., "locking it down" to a stricter policy (like "IETF | "locking it down" to a stricter policy (like "IETF Consensus") and | |||
Consensus") and looking at developing the discovery/rendezvous | looking at developing the discovery/rendezvous functions, if | |||
functions, if necessary. | necessary. | |||
5. Acknowledgements | 5. Acknowledgements | |||
Tutoring a couple multicast-related papers, the latest by Kaarle | Tutoring a couple of multicast-related papers, the latest by Kaarle | |||
Ritvanen [RITVANEN] convinced the author that updated multicast | Ritvanen [RITVANEN] convinced the author that updated multicast | |||
address assignment/allocation documentation is needed. | address assignment/allocation documentation is needed. | |||
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, John Kristoff, Dave Price, and Spencer Dawkins also | Jerome Durand, John Kristoff, Dave Price, Spencer Dawkins, and Alfred | |||
suggested improvements. | Hoenes 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. | |||
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 | IANA considerations in sections 4.1.1 and 4.1.2 of obsoleted and now | |||
eGLOP address assignments in Section 3.4.1. | Historic [RFC2908] were never implemented in IANA registry. No | |||
update is necessary. | ||||
(RFC-editor: please remove this section at publication.) | (RFC-editor: This section may be removed prior to publication; | |||
alternatively, the second paragraph may be left intact.) | ||||
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. | |||
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]. | |||
8. References | 8. References | |||
8.1. Normative References | 8.1. Normative References | |||
[I-D.ietf-mboned-ipv4-uni-based-mcast] | ||||
Thaler, D., "Unicast-Prefix-based IPv4 Multicast | ||||
Addresses", draft-ietf-mboned-ipv4-uni-based-mcast-06 | ||||
(work in progress), March 2009. | ||||
[I-D.ietf-mboned-rfc3171bis] | ||||
Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for | ||||
IPv4 Multicast Address Assignments", | ||||
draft-ietf-mboned-rfc3171bis-07 (work in progress), | ||||
April 2009. | ||||
[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. | |||
[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", | [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", | |||
BCP 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 | ||||
(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", | Point (RP) Address in an IPv6 Multicast Address", | |||
RFC 3956, November 2004. | RFC 3956, November 2004. | |||
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing | ||||
Architecture", RFC 4291, February 2006. | ||||
[RFC4489] Park, J-S., Shin, M-K., and H-J. Kim, "A Method for | [RFC4489] Park, J-S., Shin, M-K., and H-J. Kim, "A Method for | |||
Generating Link-Scoped IPv6 Multicast Addresses", | Generating Link-Scoped IPv6 Multicast Addresses", | |||
RFC 4489, April 2006. | RFC 4489, April 2006. | |||
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for | [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for | |||
IP", RFC 4607, August 2006. | IP", RFC 4607, August 2006. | |||
8.2. Informative References | 8.2. Informative References | |||
[I-D.ietf-idr-as4bytes] | ||||
Vohra, Q. and E. Chen, "BGP Support for Four-octet AS | ||||
Number Space", draft-ietf-idr-as4bytes-12 (work in | ||||
progress), November 2005. | ||||
[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-02 | Problem Space", draft-ietf-mboned-addrdisc-problems-02 | |||
(work in progress), March 2006. | (work in progress), March 2006. | |||
[I-D.ietf-mboned-ipv4-uni-based-mcast] | [I-D.ietf-mboned-session-announcement-req] | |||
Thaler, D., "Unicast-Prefix-based IPv4 Multicast | Asaeda, H. and V. Roca, "Requirements for IP Multicast | |||
Addresses", draft-ietf-mboned-ipv4-uni-based-mcast-02 | Session Announcement in the Internet", | |||
(work in progress), October 2004. | draft-ietf-mboned-session-announcement-req-01 (work in | |||
progress), March 2009. | ||||
[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] | [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-01 (work | draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01 (work | |||
in progress), February 2005. | 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-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 | [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address | |||
Assignments", RFC 2375, July 1998. | 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 | [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. | |||
[RFC2776] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope | [RFC2776] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope | |||
Zone Announcement Protocol (MZAP)", RFC 2776, | Zone Announcement Protocol (MZAP)", RFC 2776, | |||
February 2000. | February 2000. | |||
skipping to change at page 15, line 23 | skipping to change at page 14, line 50 | |||
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 | [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session | |||
Announcement Protocol", RFC 2974, October 2000. | 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., | [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., | |||
and M. Carney, "Dynamic Host Configuration Protocol for | and M. Carney, "Dynamic Host Configuration Protocol for | |||
IPv6 (DHCPv6)", RFC 3315, July 2003. | IPv6 (DHCPv6)", RFC 3315, July 2003. | |||
[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS | ||||
Number Space", RFC 4893, May 2007. | ||||
[RITVANEN] | [RITVANEN] | |||
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/>. | |||
Appendix A. Changes | Appendix A. Changes | |||
(To be removed prior to publication as an RFC.) | (To be removed prior to publication as an RFC.) | |||
A.1. Changes between -04 and -05 | A.1. Changes between -05 and -06 | |||
o Editorial updates. | ||||
o Obsolete only RFC2908; the rest only move to Historic. | ||||
o Category is Informational instead of BCP (in line with the routing | ||||
architecture. | ||||
o Move 3171bis and v4-uni-based to Normative references in order to | ||||
make sure we don't go forward until they're resolved. | ||||
o Resolve pending issues per IETF75 discussion, in particular major | ||||
changes to eGLOP and IANA policy discussions. | ||||
A.2. Changes between -04 and -05 | ||||
o Editorial updates. These and the following are from Spencer | o Editorial updates. These and the following are from Spencer | |||
Dawkins. | Dawkins. | |||
o New text explictly stating that GLOP for v6 is not needed and GLOP | o New text explicitly stating that GLOP for v6 is not needed and | |||
for 4byte ASNs isn't (and likely won't be) defined. | GLOP for 4byte ASNs isn't (and likely won't be) defined. | |||
o Expand reasons for filtering difficulties with global IANA | o Expand reasons for filtering difficulties with global IANA | |||
assignments for local apps, and that it would be easier if these | assignments for local apps, and that it would be easier if these | |||
were done from the local pool. | were done from the local pool. | |||
o Explicitly mention dynamic allocations protocols' lack of benefit | o Explicitly mention dynamic allocations protocols' lack of benefit | |||
and abandonment. | and abandonment. | |||
A.2. Changes between -03 and -04 | A.3. Changes between -03 and -04 | |||
o S/scope-relative/administratively scoped/ and expand Static IANA | o S/scope-relative/administratively scoped/ and expand Static IANA | |||
Assignment section to two subsections; mainly from Dave Price. | Assignment section to two subsections; mainly from Dave Price. | |||
o Mention the routing challenges of IPv6 IANA assigned prefixes in | o Mention the routing challenges of IPv6 IANA assigned prefixes in | |||
section 4.2 | section 4.2 | |||
A.3. Changes between -02 and -03 | A.4. Changes between -02 and -03 | |||
o Reword architectural implications of Static IANA and editorial | o Reword architectural implications of Static IANA and editorial | |||
improvements; mainly from John Kristoff. | improvements; mainly from John Kristoff. | |||
A.4. Changes between -01 and -02 | A.5. Changes between -01 and -02 | |||
o Mention the mechanisms which haven't been so succesful: eGLOP and | o Mention the mechanisms which haven't been so successful: 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 administratively scoped address space and the | o Add a note on administratively scoped address space and the | |||
expansion 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 | ||||
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). | ||||
End of changes. 66 change blocks. | ||||
180 lines changed or deleted | 167 lines changed or added | |||
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |