draft-ietf-mboned-addrdisc-problems-01.txt   draft-ietf-mboned-addrdisc-problems-02.txt 
MBONE Deployment P. Savola MBONE Deployment P. Savola
Internet-Draft CSC/FUNET 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 Lightweight Multicast Address Discovery Problem Space
draft-ietf-mboned-addrdisc-problems-01.txt draft-ietf-mboned-addrdisc-problems-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 23, 2006. This Internet-Draft will expire on September 4, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
Typically applications developers have requested static IANA Typically applications developers have requested static IANA
assignments for their applications, even if the applications would assignments for their applications, even if the applications would
typically be only used within a site, between consenting sites, or typically be only used within a site, between consenting sites, or
would not eventually even use multicast at all. This memo describes would not eventually even use multicast at all. This memo describes
this problem space, and summarizes a number of proposed approaches to this problem space, and summarizes a number of proposed approaches to
mitigating these problems. mitigating these problems.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3. Mitigation Techniques . . . . . . . . . . . . . . . . . . . . 5 3. Mitigation Techniques . . . . . . . . . . . . . . . . . . . . 5
3.1. Locally Scoped Address Assignment by a Registry . . . . . 5 3.1. Locally Scoped Address Assignment by a Registry . . . . . 5
3.2. Single Administration Address Discovery with Server 3.2. Single Administration Address Discovery with Server
Configuration . . . . . . . . . . . . . . . . . . . . . . 6 Configuration . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Zero-configuration Single Administration Address 3.3. Zero-configuration Single Administration Address
Discovery . . . . . . . . . . . . . . . . . . . . . . . . 7 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 4. DNS As a Means of Indirection . . . . . . . . . . . . . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11
1. Introduction 1. Introduction
There are a lot of different challenges relating to the discovery and There are a lot of different challenges relating to the discovery and
use of an appropriate multicast address as described below. This use of an appropriate multicast address as described below. This
document only addresses the second one. document only addresses the second one.
a. Getting a list of all the available (public) sessions which 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 could join (and possibly send) to, similar to a "TV guide". That
is, having to know everything before you can decide if you're is, having to know everything before you can decide if you're
skipping to change at page 7, line 9 skipping to change at page 7, line 9
locally-scoped addresses which the clients would use to discover the locally-scoped addresses which the clients would use to discover the
group address. group address.
The client ends should discover the smallest possible scope where the The client ends should discover the smallest possible scope where the
application is supported. application is supported.
A few notes on this method: A few notes on this method:
o One could characterize a potential solution as an easily o One could characterize a potential solution as an easily
implementable server shim at "server end" listening to a set well- implementable server shim at "server end" listening to a set well-
known locally-scoped multicast addresses (e.g., SAP scope-relative known locally-scoped multicast addresses (e.g., a scope-relative
addresses), which would respond to queries by "client end". address at each local scope), which would respond to queries by
"client end".
o How can the servers demultiplex "queries" sent to these addresses? o How can the servers demultiplex "queries" sent to these addresses?
Are these messages in SAP format or something simpler? The query Are these messages in SAP format or something simpler? The query
must have an identifier (e.g., done by hashing a name?) which the 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 server uses to know the client is interested in the server's
multicast transmission. multicast transmission.
o How should the servers communicate back to the clients? By o How should the servers communicate back to the clients? By
replying with unicast (issues after bootup with lots of nodes) or replying with unicast (issues after bootup with lots of nodes) or
do the clients also join the address (DoS potential, a very do the clients also join the address (DoS potential, a very
skipping to change at page 7, line 36 skipping to change at page 7, line 37
scoping as well? IANA assignment will be requested in any case. scoping as well? IANA assignment will be requested in any case.
3.3. Zero-configuration Single Administration Address Discovery 3.3. Zero-configuration Single Administration Address Discovery
A slightly more extensive problem is the same as above, but assuming A slightly more extensive problem is the same as above, but assuming
that the application must be completely zero-configurable. That is, that the application must be completely zero-configurable. That is,
it must work without having to manually configure anything on the it must work without having to manually configure anything on the
server end. server end.
This could be achieved e.g., by adding to the above a SAP-like 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 reserved. This might not sit well on the organization's local
scoping plans, however. scoping plans, however.
However, it is worth considering whether this is really needed. For 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 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 multicast routing. But for larger scopes, is this really useful? If
there is no administrator to configure the address, likely there is there is no administrator to configure the address, likely there is
no multicast infrastructure in the first place, or desire to run the no multicast infrastructure in the first place, or desire to run the
application in multicast mode! application in multicast mode!
skipping to change at page 10, line 28 skipping to change at page 11, line 7
Pekka Savola Pekka Savola
CSC/FUNET CSC/FUNET
Espoo Espoo
Finland Finland
Email: psavola@funet.fi Email: psavola@funet.fi
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
skipping to change at page 11, line 23 skipping to change at page 11, line 47
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 10 change blocks. 
10 lines changed or deleted 12 lines changed or added

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