--- 1/draft-ietf-mboned-addrdisc-problems-01.txt 2006-03-07 05:12:46.000000000 +0100 +++ 2/draft-ietf-mboned-addrdisc-problems-02.txt 2006-03-07 05:12:46.000000000 +0100 @@ -1,17 +1,18 @@ MBONE Deployment P. Savola Internet-Draft CSC/FUNET -Expires: May 23, 2006 November 19, 2005 +Intended status: Informational March 3, 2006 +Expires: September 4, 2006 Lightweight Multicast Address Discovery Problem Space - draft-ietf-mboned-addrdisc-problems-01.txt + draft-ietf-mboned-addrdisc-problems-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -22,55 +23,55 @@ 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 May 23, 2006. + This Internet-Draft will expire on September 4, 2006. Copyright Notice - Copyright (C) The Internet Society (2005). + Copyright (C) The Internet Society (2006). Abstract Typically applications developers have requested static IANA assignments for their applications, even if the applications would typically be only used within a site, between consenting sites, or would not eventually even use multicast at all. This memo describes this problem space, and summarizes a number of proposed approaches to mitigating these problems. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Mitigation Techniques . . . . . . . . . . . . . . . . . . . . 5 3.1. Locally Scoped Address Assignment by a Registry . . . . . 5 3.2. Single Administration Address Discovery with Server Configuration . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Zero-configuration Single Administration Address Discovery . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.4. Global Multiple Administration Address Discovery . . . . . 7 + 3.4. Global Multiple Administration Address Discovery . . . . . 8 4. DNS As a Means of Indirection . . . . . . . . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 - Intellectual Property and Copyright Statements . . . . . . . . . . 10 + Intellectual Property and Copyright Statements . . . . . . . . . . 11 1. Introduction There are a lot of different challenges relating to the discovery and use of an appropriate multicast address as described below. This document only addresses the second one. a. Getting a list of all the available (public) sessions which one could join (and possibly send) to, similar to a "TV guide". That is, having to know everything before you can decide if you're @@ -254,22 +255,23 @@ locally-scoped addresses which the clients would use to discover the group address. The client ends should discover the smallest possible scope where the application is supported. A few notes on this method: o One could characterize a potential solution as an easily implementable server shim at "server end" listening to a set well- - known locally-scoped multicast addresses (e.g., SAP scope-relative - addresses), which would respond to queries by "client end". + known locally-scoped multicast addresses (e.g., a scope-relative + address at each local scope), which would respond to queries by + "client end". o How can the servers demultiplex "queries" sent to these addresses? Are these messages in SAP format or something simpler? The query must have an identifier (e.g., done by hashing a name?) which the server uses to know the client is interested in the server's multicast transmission. o How should the servers communicate back to the clients? By replying with unicast (issues after bootup with lots of nodes) or do the clients also join the address (DoS potential, a very @@ -281,21 +283,21 @@ scoping as well? IANA assignment will be requested in any case. 3.3. Zero-configuration Single Administration Address Discovery A slightly more extensive problem is the same as above, but assuming that the application must be completely zero-configurable. That is, it must work without having to manually configure anything on the server end. This could be achieved e.g., by adding to the above a SAP-like - address segments from which the addresses could be dynamically + address blocks from which the addresses could be dynamically reserved. This might not sit well on the organization's local scoping plans, however. However, it is worth considering whether this is really needed. For link-local scope, this may be desirable as such requires no set-up of multicast routing. But for larger scopes, is this really useful? If there is no administrator to configure the address, likely there is no multicast infrastructure in the first place, or desire to run the application in multicast mode! @@ -413,21 +415,21 @@ Pekka Savola CSC/FUNET Espoo Finland Email: psavola@funet.fi Full Copyright Statement - Copyright (C) The Internet Society (2005). + Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions 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 @@ -453,12 +455,12 @@ 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 currently provided by the - Internet Society. + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA).