--- 1/draft-ietf-mboned-addrarch-01.txt 2006-02-04 17:27:30.000000000 +0100 +++ 2/draft-ietf-mboned-addrarch-02.txt 2006-02-04 17:27:30.000000000 +0100 @@ -1,147 +1,144 @@ Internet Engineering Task Force P. Savola Internet-Draft CSC/FUNET -Obsoletes: 2908,2909 (if approved) February 18, 2005 -Expires: August 19, 2005 +Obsoletes: 2776,2908,2909 (if August 8, 2005 +approved) +Expires: February 9, 2006 Overview of the Internet Multicast Addressing Architecture - draft-ietf-mboned-addrarch-01.txt + draft-ietf-mboned-addrarch-02.txt Status of this Memo - This document is an Internet-Draft and is subject to all provisions - of Section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. + other groups may also distribute working documents as Internet- + Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on August 19, 2005. + This Internet-Draft will expire on February 9, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The lack of up-to-date documentation on IP multicast address allocation and assignment procedures has caused a great deal of confusion. To clarify the situation, this memo describes the allocation and assignment techniques and mechanisms currently (as of this writing) in use. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology: Allocation or Assignment . . . . . . . . . . 3 - 2. Multicast Address Allocation . . . . . . . . . . . . . . . . . 4 + 2. Multicast Address Allocation . . . . . . . . . . . . . . . . . 3 2.1 Derived Allocation . . . . . . . . . . . . . . . . . . . . 4 2.1.1 GLOP Allocation . . . . . . . . . . . . . . . . . . . 4 2.1.2 Unicast-prefix -based Allocation . . . . . . . . . . . 4 2.2 Scope-relative Allocation . . . . . . . . . . . . . . . . 5 2.3 Static IANA Allocation . . . . . . . . . . . . . . . . . . 6 2.4 Dynamic Allocation . . . . . . . . . . . . . . . . . . . . 6 3. Multicast Address Assignment . . . . . . . . . . . . . . . . . 6 3.1 Derived Assignment . . . . . . . . . . . . . . . . . . . . 6 3.2 SSM Assignment inside the Node . . . . . . . . . . . . . . 7 3.3 Manually Configured Assignment . . . . . . . . . . . . . . 7 3.4 Static IANA Assignment . . . . . . . . . . . . . . . . . . 7 3.5 Dynamic Assignments . . . . . . . . . . . . . . . . . . . 8 4. Summary and Future Directions . . . . . . . . . . . . . . . . 9 4.1 Prefix Allocation . . . . . . . . . . . . . . . . . . . . 9 4.2 Address Assignment . . . . . . . . . . . . . . . . . . . . 10 4.3 Future Actions . . . . . . . . . . . . . . . . . . . . . . 10 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1 Normative References . . . . . . . . . . . . . . . . . . . 12 - 8.2 Informative References . . . . . . . . . . . . . . . . . . 12 + 8.2 Informative References . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 - A. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14 - B. Multicast Address Discovery . . . . . . . . . . . . . . . . . 15 + A. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + A.1 Changes since -01 . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 16 1. Introduction - Good, up-to-date documentation of IP multicast is close to - non-existent. Particularly, this is an issue with multicast address + Good, up-to-date documentation of IP multicast is close to non- + existent. Particularly, this is an issue with multicast address allocations (to networks and sites) and assignments (to hosts and applications). This problem is stressed by the fact that there exists confusing or misleading documentation on the subject [RFC2908]. The consequence is that those who wish to learn of IP multicast and how the addressing works do not get a clear view of the current situation. The aim of this document is to provide a brief overview of multicast addressing and allocation techniques. The term 'addressing architecture' refers to the set of addressing mechanisms and methods in an informal manner. It is important to note that Source-specific Multicast (SSM) [I-D.ietf-ssm-arch] does not have these addressing problems; hence, - this document focuses on Any Source Multicast (ASM) model. The - applicability of SSM has been briefly discussed in - [I-D.ietf-mboned-ipv6-multicast-issues]. + this document focuses on Any Source Multicast (ASM) model. - This memo obsoletes RFC 2908 and RFC 2909 and re-classifies them + This memo obsoletes RFCs 2776, 2908, and 2909 and re-classifies them Historic. 1.1 Terminology: Allocation or Assignment Almost all multicast documents and many other RFCs (such as DHCPv4 [RFC2131] and DHCPv6 [RFC3315]) have used the terms address "allocation" and "assignment" interchangeably. However, the operator and address management communities use these for two conceptually different processes. In unicast operations, address allocations refer to leasing a large block of addresses from Internet Assigned Numbers Authority (IANA) to - a Regional Internet Registry (RIR), from RIR to a Local Internet + a Regional Internet Registry (RIR) or from RIR to a Local Internet Registry (LIR) possibly through a National Internet Registry (NIR). Address assignments, on the other hand, are the leases of smaller - address blocks or even single addresses to the end-user sites or - end-users themselves. + address blocks or even single addresses to the end-user sites or end- + users themselves. Therefore, in this memo, we will separate the two different functions: "allocation" describes how larger blocks of addresses are obtained by the network operators, and "assignment" describes how applications, nodes or sets of nodes obtain a multicast address for their use. 2. Multicast Address Allocation Multicast address allocation, i.e., how a network operator might be able to obtain a larger block of addresses, can be handled in a number of ways as described below. Note that these are all only pertinent to ASM -- SSM requires no address block allocation because the group address has only local - significance (however, the address assignment inside the node is - still an issue discussed in Section 3.2). + significance (however, we discuss the address assignment inside the + node in Section 3.2). 2.1 Derived Allocation Derived allocations take the unicast prefix or some other properties of the network to determine unique multicast address allocations. 2.1.1 GLOP Allocation GLOP address allocation [RFC3180] inserts the 16-bit public Autonomous System (AS) number in the middle of the IPv4 multicast @@ -157,25 +154,25 @@ tied to any prefix but to routing domains, so they cannot be used or calculated automatically. 2.1.2 Unicast-prefix -based Allocation RFC 3306 [RFC3306] describes a mechanism which embeds up to 64 first bits of an IPv6 unicast address in the prefix part of the IPv6 multicast address, leaving at least 32 bits of group-id space available after the prefix mapping. - A similar mapping has been proposed for IPv4 - [I-D.ietf-mboned-ipv4-uni-based-mcast], but it provides a rather low - amount of addresses (e.g., 1 per an IPv4 /24 block). While there - exist large networks without an AS number of their own, this has not - been seen to add sufficient value compared to GLOP addressing. + A similar mapping has been proposed for IPv4 [I-D.ietf-mboned-ipv4- + uni-based-mcast], but it provides a rather low amount of addresses + (e.g., 1 per an IPv4 /24 block). While there exist large networks + without an AS number of their own, this has not been seen to add + sufficient value compared to GLOP addressing. The IPv6 unicast-prefix -based allocations are an extremely useful way to allow each network operator, even each subnet, obtain multicast addresses easily, through an easy computation. Further, as the IPv6 multicast header also includes the scope value [RFC3513], multicast groups of smaller scope can also be used with the same mapping. The IPv6 Embedded RP technique [RFC3956], used with Protocol Independent Multicast - Sparse Mode (PIM-SM), further leverages the @@ -199,101 +196,108 @@ the IPv6 multicast address prefix [RFC3513]. As IPv6 scope-relative allocations can be handled with unicast-prefix -based multicast addressing as described in Section 2.1.2, and there is no need for separate scope-relative allocations, we'll just discuss IPv4 in this section. The IPv4 scope-relative prefix 239.0.0.0/8 is further divided to Local Scope (239.255.0.0/16) and Organization Local Scope (239.192.0.0/14); other parts of the administrative scopes are either - reserved for expansion or undefined [RFC2365]. + reserved for expansion or undefined [RFC2365]. However, RFC 2365 is + ambiguous as to whether it's the enterprises or the IETF who are + allowed to expand the space. Topologies which act under a single administration can easily use the scoped multicast addresses for their internal groups. Groups which need to be shared between multiple routing domains (but not propagated through Internet) are more problematic and typically need an assignment of a global multicast address because their scope is undefined. There is a large number of multicast applications (such as "Norton Ghost") which are restricted either to a link or a site, but it is extremely undesirable to propagate them further (either to the rest of the site, or beyond the site). Typically many such applications have been given a static IANA address assignment; this makes it challenging to implement proper propagation limiting -- which could be easier if such applications could have been assigned specific scope-relative addresses instead. This is an area of further future - work -- it might be able to mitigate this issue if there was more - coordination inside the scope-relative allocation block. + work. + + There has also been work on protocol to automatically discover + multicast scope zones [RFC2776], but it has never been seriously + implemented or deployed. 2.3 Static IANA Allocation In some rare cases, some organizations may have been able to obtain - static multicast address allocations directly from IANA. Typically - these have been meant as a block of static assignments to multicast - applications, as described in Section 3.4. In principle, IANA does - not allocate multicast address blocks to the operators but GLOP or - Unicast-prefix -based allocations should be used instead. + static multicast address allocations (of up to 256 addresses) + directly from IANA. Typically these have been meant as a block of + static assignments to multicast applications, as described in + Section 3.4. In principle, IANA does not allocate multicast address + blocks to the operators but GLOP or Unicast-prefix -based allocations + should be used instead. 2.4 Dynamic Allocation RFC 2908 [RFC2908] proposed three different layers of multicast address allocation and assignment, where layers 3 (inter-domain allocation) and layer 2 (intra-domain allocation) could be applicable here. Multicast Address-Set Claim Protocol (MASC) [RFC2909] is an example of the former, and Multicast Address Allocation Protocol (AAP) [I-D.ietf-malloc-aap] (abandoned in 2000 due lack of interest and technical problems) is an example of the latter. Both of the proposed allocation protocols were quite complex, and have never been deployed or seriously implemented. It can be concluded that there are no dynamic multicast address - allocation protocols, and other methods such as GLOP or - unicast-prefix -based addressing should be used instead. + allocation protocols, and other methods such as GLOP or unicast- + prefix -based addressing should be used instead. 3. Multicast Address Assignment For multicast address assignment, i.e., how an application learns the address it can use, or a node (or a set of nodes) learns an address it could use for an application, has a number of options as described below. Any IPv6 address assignment method should be aware of the guidelines for the assignment of the group-IDs for IPv6 multicast addresses [RFC3307]. 3.1 Derived Assignment There are significantly fewer options for derived address assignment - compared to derived allocation. Derived multicast assignment is only - being specified for IPv6 link-scoped multicast - [I-D.ietf-ipv6-link-scoped-mcast], where the EUI64 is embedded in the - multicast address, providing a node with unique multicast addresses - for link-local ASM communications. + compared to derived allocation. Derived multicast assignment has + only been specified for IPv6 link-scoped multicast [I-D.ietf-ipv6- + link-scoped-mcast], where the EUI64 is embedded in the multicast + address, providing a node with unique multicast addresses for link- + local ASM communications. 3.2 SSM Assignment inside the Node While the SSM multicast addresses have only local (to the node) significance, there is still a minor issue on how to assign the addresses between the applications running on the same node (or more precisely, an IP address). This assignment is not considered to be a problem because typically the addresses for the applications are selected manually or - statically, but if done using an API, the API could check that the - addresses do not conflict prior to assigning one. + statically, but if done using an Application Programming Interface + (API), the API could check that the addresses do not conflict prior + to assigning one. 3.3 Manually Configured Assignment - With manually configured assignment, the network operator which has a + With manually configured assignment, the network operator who has a multicast address prefix assigns the multicast group addresses to the requesting nodes using a manual process. Typically the user or administrator which wants to use a multicast address for particular application requests an address from the network operator using phone, email, or similar means, and the network operator provides the user with a multicast address. Then the user/administrator of the node or application manually configures the application to use the assigned multicast address. @@ -304,78 +308,86 @@ group is small, as each participant has to be manually configured. This is the most commonly used technique when the multicast application does not have a static IANA assignment. 3.4 Static IANA Assignment In contrast to manually configured assignment, as described above, static IANA assignment refers to getting a globally unique assignment for the particular application directly from IANA. Guidelines for - IANA are described in [I-D.ietf-mboned-rfc3171bis]. + IANA are described in [RFC3171][I-D.ietf-mboned-rfc3171bis]. This is seen as lucrative because it's the simplest approach for application developers because they can then hard-code the multicast - address, requiring no lease of the usable multicast address, and - likewise the client applications do not need to perform any kind of - service discovery (but depending on hard-coded addresses). However, - this is a bad approach architecturally, as we should focus on - enhancing and deploying service discovery and address assignment (as - needed) instead of encouraging a "land-grab" of multicast addresses. + address. Hard-coding requires no lease of the usable multicast + address, and likewise the client applications do not need to perform + any kind of service discovery (but depending on hard-coded + addresses). However, this is a bad approach architecturally, as we + should focus on enhancing and deploying service discovery and address + assignment (as needed) instead of encouraging a "land-grab" of + multicast addresses. + + [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 static IANA assignment, some of which are really needed, and some of which probably should not have been granted. 3.5 Dynamic Assignments The layer 1 of RFC 2908 [RFC2908] described dynamic assignment from Multicast Address Allocation Servers (MAAS) to applications and nodes, with Multicast Address Dynamic Client Allocation Protocol - (MADCAP) [RFC2730] as examples. Since then, there has been a - proposal for DHCPv6 assignment - [I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6]. + (MADCAP) [RFC2730] as an example. Since then, there has been a + proposal for DHCPv6 assignment [I-D.jdurand-assign-addr-ipv6- + multicast-dhcpv6]. - Based on a multicast prefix, it would be rather straightforward to - deploy a dynamic assignment protocol which would lease group - addresses to the applications wishing to use multicast. For example, + It would be rather straightforward to deploy a dynamic assignment + protocol which would lease group addresses based on a multicast + prefix to the applications wishing to use multicast. For example, only few have implemented MADCAP, and it's not significantly deployed. Moreover, it is not clear how widely for example the APIs for communication between the multicast application and the MADCAP client operating at the host have been implemented [RFC2771]. An entirely different approach is Session Announcement Protocol (SAP) [RFC2974]. In addition to advertising global multicast sessions, the protocol also has associated ranges of addresses for both IPv4 and IPv6 which can be used by SAP-aware applications to create new groups - and new group addresses. It is a rather tedious process to create a - session (and obtain an address) this way which is why it isn't done - all that often. (Note that the IPv6 SAP address is unroutable in the + and new group addresses. Creating a session (and obtaining an + address) is a rather tedious process which is why it isn't done all + that often. (Note that the IPv6 SAP address is unroutable in the inter-domain multicast.) A conclusion about dynamic assignment protocols is that: 1. multicast is not significantly attractive in the first place, 2. very many applications have a static IANA assignment and thus require no dynamic or manual assignment, 3. those that cannot be easily satisfied with IANA or manual assignment (i.e., where dynamic assignment would be desirable) are rather marginal, or 4. that there are other gaps why dynamic assignments are not seen as a useful approach (for example, issues related to service discovery/rendezvous). - In consequence, more work on rendezvous/service discovery will be - needed to make dynamic assignment more useful. + In consequence, more work on rendezvous/service discovery would be + needed to make dynamic assignments more useful. 4. Summary and Future Directions This section summarizes the mechanisms and analysis discussed in this memo, and presents some potential future directions. 4.1 Prefix Allocation Summary of prefix allocation methods for ASM is in Figure 1. @@ -412,62 +424,61 @@ 4.2 Address Assignment Summary of address assignment methods is in Figure 2. +-------+--------------------------------+----------+----------+ | Sect. | Address assignment method | IPv4 | IPv6 | +-------+--------------------------------+----------+----------+ | 3.1 | Derived: link-scope addresses | No | Yes | | 3.2 | SSM (inside the node) | Yes | Yes | | 3.3 | Manual assignment | Yes | Yes | - | 3.4 | Static IANA assignment |LastResort|LastResort| + | 3.4 | Static IANA/RIR assignment |LastResort|LastResort| | 3.5 | Dynamic assignment protocols | Yes | Yes | +-------+--------------------------------+----------+----------+ Figure 2 o Manually configured assignment is what's typically done today, and works to a sufficient degree in smaller scale. o Static IANA assignment has been done extensively in the past, but - it needs to be tightened down to prevent problems caused by - "land-grabbing". + it needs to be tightened down to prevent problems caused by "land- + grabbing". o Dynamic assignment, e.g., using MADCAP have been implemented, but - there is no wide deployment, so a solution is there -- but either - there are other gaps in the multicast architecture or there is no - need for it in the first place, when manual configuration is - possible, and static IANA assignments are still there. - Assignments using SAP also exist but are not common; global SAP - assignment is unfeasible with IPv6. + there is no wide deployment, so a solution is there. However, + either there are other gaps in the multicast architecture or there + is no sufficient demand for it in the first place when manual and + static IANA assignments are available. Assignments using SAP also + exist but are not common; global SAP assignment is unfeasible with + IPv6. - o Derived assignments are only applicable in a fringe case of - link-scoped multicast. + o Derived assignments are only applicable in a fringe case of link- + scoped multicast. 4.3 Future Actions o Multicast address discovery/"rendezvous" needs to be analyzed at more length, and an adequate solution provided; the result also needs to be written down to be shown to the IANA static assignment - requestors. See [I-D.savola-mboned-address-discovery-problems] - and Appendix B for more. + requestors. See [I-D.ietf-mboned-addrdisc-problems] for more. o IPv6 multicast DAD and/or multicast prefix communication mechanisms should be analyzed (e.g., [I-D.jdurand-ipv6-multicast-ra]): whether there is demand or not, and specify if yes. o The IETF should consider whether to specify more ranges of the IPv4 scope-relative address space for static allocation for applications which should not be routed over the Internet (such as - backup software, etc. -- so that these wouldn't need to use - global addresses which should never leak in any case). + backup software, etc. -- so that these wouldn't need to use global + addresses which should never leak in any case). o The IETF should seriously consider its static IANA allocations policy, e.g., "locking it down" to a stricter policy (like "IETF Consensus") and looking at developing the discovery/rendezvous functions, if necessary. 5. Acknowledgements Tutoring a couple multicast-related papers, the latest by Kaarle Ritvanen [RITVANEN] convinced the author that the up-to-date @@ -482,217 +493,179 @@ 6. IANA Considerations This memo includes no request to IANA, but as the allocation and assignment of multicast addresses are related to IANA functions, it wouldn't hurt if the IANA reviewed this entire memo. IANA considerations in sections 4.1.1 and 4.1.2 of [RFC2908] still apply to the administratively scoped prefixes. + IANA may be interested in reviewing the accuracy of the statement on + eGLOP address assignments in Section 3.4. + (RFC-editor: please remove this section at publication.) 7. Security Considerations This memo only describes different approaches to allocating and assigning multicast addresses, and this has no security considerations; the security analysis of the mentioned protocols is out of scope of this memo. Obviously, especially the dynamic assignment protocols are inherently vulnerable to resource exhaustion attacks, as discussed e.g., in [RFC2730]. 8. References 8.1 Normative References [I-D.ietf-ipv6-link-scoped-mcast] - Park, J., "Link Scoped IPv6 Multicast Addresses", - Internet-Draft draft-ietf-ipv6-link-scoped-mcast-08, - December 2004. - - [I-D.ietf-mboned-rfc3171bis] - Albanna, Z., Almeroth, K., Cotton, M. and D. Meyer, "IANA - Guidelines for IPv4 Multicast Address Assignments", - Internet-Draft draft-ietf-mboned-rfc3171bis-02, March - 2004. + Park, J., "A Method for Generating Link Scoped IPv6 + Multicast Addresses", draft-ietf-ipv6-link-scoped-mcast-09 + (work in progress), July 2005. [I-D.ietf-ssm-arch] Holbrook, H. and B. Cain, "Source-Specific Multicast for - IP", Internet-Draft draft-ietf-ssm-arch-06, September - 2004. + IP", draft-ietf-ssm-arch-06 (work in progress), + September 2004. [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. + [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, + "IANA Guidelines for IPv4 Multicast Address Assignments", + BCP 51, RFC 3171, August 2001. + [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53, RFC 3180, September 2001. [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002. [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004. 8.2 Informative References - [I-D.iab-dns-choices] - Faltstrom, P. and R. Austein, "Design Choices When - Expanding DNS", Internet-Draft draft-iab-dns-choices-00, - October 2004. - [I-D.ietf-malloc-aap] Handley, M. and S. Hanna, "Multicast Address Allocation Protocol (AAP)", June 2000. + [I-D.ietf-mboned-addrdisc-problems] + Savola, P., "Lightweight Multicast Address Discovery + Problem Space", draft-ietf-mboned-addrdisc-problems-00 + (work in progress), March 2005. + [I-D.ietf-mboned-ipv4-uni-based-mcast] Thaler, D., "Unicast-Prefix-based IPv4 Multicast - Addresses", - Internet-Draft draft-ietf-mboned-ipv4-uni-based-mcast-02, - October 2004. + Addresses", draft-ietf-mboned-ipv4-uni-based-mcast-02 + (work in progress), October 2004. - [I-D.ietf-mboned-ipv6-multicast-issues] - Savola, P., "IPv6 Multicast Deployment Issues", - Internet-Draft draft-ietf-mboned-ipv6-multicast-issues-01, - September 2004. + [I-D.ietf-mboned-rfc3171bis] + Albanna, Z., Almeroth, K., Cotton, M., and D. Meyer, "IANA + Guidelines for IPv4 Multicast Address Assignments", + draft-ietf-mboned-rfc3171bis-02 (work in progress), + March 2004. [I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6] Durand, J., "IPv6 multicast address assignment with DHCPv6", - , June 2004. + draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01 (work + in progress), February 2005. [I-D.jdurand-ipv6-multicast-ra] Durand, J. and P. Savola, "Route Advertisement Option for IPv6 Multicast Prefixes", - Internet-Draft draft-jdurand-ipv6-multicast-ra-00, + draft-jdurand-ipv6-multicast-ra-00 (work in progress), February 2005. - [I-D.palet-v6ops-tun-auto-disc] - Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point - Discovery Mechanisms", - Internet-Draft draft-palet-v6ops-tun-auto-disc-03, January - 2005. - - [I-D.savola-mboned-address-discovery-problems] - Savola, P., "Lightweight Multicast Address Discovery - Problem Space", - , February 2005. - [MBONED-IETF59] "MBONED WG session at IETF59", . [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. - [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, - "Service Location Protocol, Version 2", RFC 2608, June - 1999. + [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, December 1999. [RFC2771] Finlayson, R., "An Abstract API for Multicast Address Allocation", RFC 2771, February 2000. - [RFC2908] Thaler, D., Handley, M. and D. Estrin, "The Internet + [RFC2776] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope + Zone Announcement Protocol (MZAP)", RFC 2776, + February 2000. + + [RFC2908] Thaler, D., Handley, M., and D. Estrin, "The Internet Multicast Address Allocation Architecture", RFC 2908, September 2000. [RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M., - Kumar, S. and D. Thaler, "The Multicast Address-Set Claim + Kumar, S., and D. Thaler, "The Multicast Address-Set Claim (MASC) Protocol", RFC 2909, September 2000. - [RFC2974] Handley, M., Perkins, C. and E. Whelan, "Session + [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. - [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and - M. Carney, "Dynamic Host Configuration Protocol for IPv6 - (DHCPv6)", RFC 3315, July 2003. + [RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, + June 2001. + + [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., + and M. Carney, "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. [RITVANEN] Ritvanen, K., "Multicast Routing and Addressing", HUT Report, Seminar on Internetworking, May 2004, . Author's Address Pekka Savola CSC - Scientific Computing Ltd. Espoo Finland Email: psavola@funet.fi -Appendix A. Open Issues - - (This section will be removed or merged with the rest before - publication..) - - o Is the case for IPv4 Unicast-Prefix Base Multicast addressing - sufficiently strong, or could those organizations just get an AS - number themselves if they really wanted to do multicast? - -Appendix B. Multicast Address Discovery - - [[ NOTE IN DRAFT: the intent of this section has been mostly - superceded by [I-D.savola-mboned-address-discovery-problems] and - therefore it is put in the appendix, with pending removal in the - future. +Appendix A. Changes - As was noted in Section 3, multicast address discovery (i.e., service - discovery or "rendezvous") is a problem with multicast address - assignment. In particular, an acceptable mechanism (mechanisms such - as Service Location Protocol (SLP) [RFC2608] seem to have been - considered too complex) seems to be missing which the hosts wishing - to participate in a group could use to find the address of that group - [MBONED-IETF59]. + (To be removed prior to publication as an RFC.) - It is worth noting that as long as not deploying an address - assignment and service discovery protocols/mechanisms means that one - can get a static address assignment from IANA, there is little - interest from the application developers to actually do anything - except try to get the assignment from IANA. Conclusion: if we want - to use non-IANA processes, the assignments must be either forbidden - completely, or made sufficiently difficult that it's easier for the - application developers to take another route if a feasible mechanism - is available. +A.1 Changes since -01 - There are two issues in the service discovery: + o Mention the mechanisms which haven't been so succesful: eGLOP and + MZAP. - 1. The session initiator being able to publish the session somehow, - and + o Remove the appendices on multicast address discovery (a separate + draft now) and IPv4 unicast-prefix based multicast addressing. - 2. The session participants finding out about the session (rather - than creating their own). + o Add a note on scope-relative address space and the expansion + ambiguity. - When manually configured or static IANA assignments are used, 1) - should be relatively straightforward (if something needs to be - manually configured or statically assigned, putting it e.g., in DNS - should not be a problem). However, this is still more complex for - dynamic or derived assignments because it implies that the host or - the application has the right to make that publication on its own, - rather than through a manual process by an administrator. + o Remove the references to draft-ietf-mboned-ipv6-issues-xx.txt - 2) is always a challenge, but could leverage for example DNS (e.g., - by relying on using SRV records with the DNS search path, as - described in [I-D.iab-dns-choices] and - [I-D.palet-v6ops-tun-auto-disc]). + o Minor editorial cleanups. Intellectual Property Statement 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