idnits 2.17.1 draft-ietf-mboned-addrdisc-problems-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 390. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 380. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 22, 2005) is 6968 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-ietf-mboned-addrarch-01 ** Downref: Normative reference to an Informational draft: draft-ietf-mboned-addrarch (ref. 'I-D.ietf-mboned-addrarch') Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONE Deployment P. Savola 3 Internet-Draft CSC/FUNET 4 Expires: September 23, 2005 March 22, 2005 6 Lightweight Multicast Address Discovery Problem Space 7 draft-ietf-mboned-addrdisc-problems-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 23, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 Typically applications developers have requested static IANA 43 assignments for the applications, even if the applications would 44 typically be only used within a site, between consenting sites, or 45 would not eventually even use multicast at all. This memo describes 46 this problem space, and summarizes a number of proposed approaches to 47 mitigating these problems. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Mitigation Techniques . . . . . . . . . . . . . . . . . . . . 5 54 3.1 Locally Scoped Address Assignment by IANA . . . . . . . . 5 55 3.2 Single Administration Address Discovery with Server 56 Configuration . . . . . . . . . . . . . . . . . . . . . . 6 57 3.3 Zero-configuration Single Administration Address 58 Discovery . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.4 Global Multiple Administration Address Discovery . . . . . 7 60 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7.1 Normative References . . . . . . . . . . . . . . . . . . . 8 65 7.2 Informative References . . . . . . . . . . . . . . . . . . 8 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 67 Intellectual Property and Copyright Statements . . . . . . . . 10 69 1. Introduction 71 There are a lot of different challenges relating to the discovery and 72 use of an appropriate multicast address, see below. This document 73 only addresses the second one. 75 a. Getting a list of all the available (public) sessions which one 76 could join (and possibly send) to, similar to a "TV guide". That 77 is, having to know everything before you can decide if you're 78 interested in something or not; this is out of scope for this 79 memo. 81 b. Discovering the multicast address used by a particular 82 application for particular purpose, within or crossing a scope. 83 I.e., you know what you're looking for, but don't know if the 84 session has been created already and what its address would be. 86 c. The different sources (unicast addresses) participating in a 87 session. For ASM, there is no need for such discovery. For SSM, 88 this is expected to happen out-of-band or following separate 89 requirements [I-D.lehtonen-mboned-dynssm-req]. 91 Many applications have been written which leverage or could leverage 92 multicast routing infrastructures, in one or more of the following 93 scopes: (We'll get back to these later.) 95 1. link-local scope, 97 2. [geographical] site scope, 99 3. organization-local scope, 101 4. global scope, used between consenting sites/enterprises, also 102 including cases like "inside a country", or 104 5. a truly global scope. 106 Multicast-leveraging applications are often designed such that each 107 multicast group has a "server", "session creator" or some other 108 node(s) (or persons operating the nodes) which are in some way in 109 control of the application. 111 Both the "server" and "client end" of an application are currently 112 typically provisioned with the group address using static IANA 113 assignment [I-D.ietf-mboned-addrarch]. Only rarely these apps are 114 manually configured e.g. with locally scoped addresses, especially 115 the ones with a large number of clients. 117 It would be highly desirable that the applications could easily use 118 more dynamic, and more scoping-friedly mechanisms for discovering the 119 appropriate addresses to use. 121 All of these issues are only relevant to Any Source Multicast (ASM), 122 as SSM requires this information is known a priori. 124 2. Problem Statement 126 The current IANA static assignment for these applications is a 127 problem for multiple reasons: 129 o This messes up the multicast scoping plans which the site may 130 have. Each application's global address must be individually 131 scoped and filtered in all the routers and in their access lists. 132 Scoping should be easier. 134 o Static IANA assignments are required for each application; a 135 permanant global assignment for each application which could use 136 multicast depletes the resource quickly. 138 o This has issues with IPv6, because such IPv6 addresses can not be 139 scalably routed in inter-domain routing; in intra-domain, this 140 requires manual configuration or running BSR (for ff01::/16 or 141 ff02::/16 or the like) 143 o "Intended for local only use" applications typically leak through 144 to the IPv4 MSDP because there is no clear logic which ones should 145 be global and which ones are local. 147 There are at least four different proposed ways to mitigate this, 148 from the least to most extensive: 150 a. Smaller-than-global single-administration address assignment by 151 IANA (from 239/8 or elsewhere). 153 b. Smaller-than-global single-administration discovery, with the 154 expectation that a locally scoped address is manually configured 155 on the "server end". 157 c. Smaller-than-global single-administration discovery with complete 158 zero-configuration. 160 d. Global (but restricted) multi-administration discovery with some 161 amount of manual configuration. 163 We'll outline each proposed mitigation technique briefly below. 165 NOTE: David Meyer's experience from being the designated expert for 166 IANA assignments is that almost all of the requested multicast 167 addresses have been such that the requestors would not have been 168 satisfied if their application would only be restricted to operate 169 within a site. 171 If people agree on this, the first three mitigation techniques won't 172 have significant impact, because the application developers won't 173 implement the discovery in any case. They will _still_ want to get 174 the globally scoped addresses from IANA, instead of implementing the 175 "service discovery inside an organization" -shim. 177 3. Mitigation Techniques 179 The generic goals from the application/deployment perspective are: 181 o Not depending on any uncommon external infrastructure besides the 182 application itself (e.g., a MADCAP [RFC2730] server), so that the 183 application can be deployed where MADCAP server is not present. 184 I.e., this should be sufficiently lightweight to be coded in the 185 application or be used by a simple application shim library. 187 o The application should "just work" from perspective of "client 188 end" without any configuration. "Server end" may or may not 189 require configuration of an address. 191 o The presence of applications should be easily filterable at least 192 at the edges of the network. 194 o Preferably it should also be easy to segment the use of 195 application into the smallest possible scopes within the network, 196 to avoid undue state and confusion in the network. 198 3.1 Locally Scoped Address Assignment by IANA 200 If we ignore the first problem about local scoping, the easiest 201 mitigation technique might be having IANA assign locally scoped 202 addresses on FCFS basis (like UDP/TCP port numbers). This could be 203 done inside or outside of 239/8. 205 This way the local applications could easily get a local assignment 206 which could be easily filtered by site administrators at site 207 borders. 209 This is slightly inflexible as the application developers could only 210 tell whether the application's scope is link-local (there are very 211 few of these), global, or something in between. "Expanding ring 212 search" inside the site-local scopes would not be possible. 214 NOTE, based on DaveM's experience, it is not clear why the 215 application designers would accept a local range instead of a global 216 assignment, even if the application would primarily be used within a 217 local scope. 219 3.2 Single Administration Address Discovery with Server Configuration 221 The second mitigation technique would be to specify and implement a 222 mechanism, requiring no infrastructure in the network, where the 223 "server end" would be manually configured with appropriately selected 224 locally-scoped addresses which the clients would use to discover the 225 group address. 227 The client ends should discover the smallest possible scope where the 228 application is supported. 230 A few notes on this method: 232 o One could characterize a potential solution as an easily 233 implementable server shim at "server end" listening to a set 234 well-known locally-scoped multicast addresses, which would respond 235 to queries by "client end". 237 o How can the servers demultiplex "queries" sent to these addresses? 238 Are these messages in SAP format or something simpler? The query 239 must have an identifier (e.g., done by hashing a name?) which the 240 server uses to know the client is interested in the server's 241 multicast transmission. 243 o How should the servers communicate back to the clients? By 244 replying with unicast (issues after bootup with lots of nodes) or 245 do the clients also join the address (DoS potential, a very 246 crowded group which all the servers at least need to subscribe 247 to)? 249 Again, this does not solve the root problem; why would an application 250 designer implement this mechanism when he/she wants to support global 251 scoping as well? IANA assignment will be requested in any case. 253 3.3 Zero-configuration Single Administration Address Discovery 255 A slightly more extensive problem is the same as above, but assuming 256 that the application must be completely zero-configurable. That is, 257 it must work without having to manually configure anything on the 258 server end. 260 This could be achieved e.g., by adding to the above a SAP-like 261 address segments from which the addresses could be dynamically 262 reserved. This might not sit well on the organization's local 263 scoping plans, however. 265 However, it is worth considering whether this is really needed. For 266 link-local scope, this may be desirable as such requires no set-up of 267 multicast routing. But for larger scopes, is this really useful? If 268 there is no administrator to configure the address, likely there is 269 no multicast infrastructure in the first place, or desire to run the 270 application in multicast mode! 272 Again, this does not solve the root problem. 274 3.4 Global Multiple Administration Address Discovery 276 Most applications are such that they _can_ be run over 277 site/organization boundaries (even if they typically would not be), 278 so the application developers will want to support the most extensive 279 scope. There is no common local scope (even between 280 organization-local and global) which could cover these disjoint 281 global interconnections, so the applications must use global scope 282 addresses. 284 To get away from static IANA assignments, there should be a 285 lightweight multicast address discovery function which could be used 286 e.g., in the embedded devices to discover the appropriate multicast 287 address they should use. 289 Obviously, the result could also be that the application should be 290 restricted to a local scope, and use local scope addresses, but wider 291 discovery should also be supported. 293 This approach has a number of challenges, however. It's difficult to 294 visualize how multiple administrative domains could perform discovery 295 in a desired manner automatically -- we have to assume that the sites 296 might not want to tell about all of their local sessions to all the 297 other sites (i.e., you may want to allow site A to discover session 298 1, and site B to discover session 2, but not mix these). In other 299 words, there will likely need to be some manual control of what gets 300 seen to the outside and what not. This makes the mechanism more 301 complicated, and requires more network operator management. 303 Further attributes and requirements for this kind of approach remain 304 to be figured out. 306 4. Acknowledgements 308 This memo grew out of the discussions in MBONED WG, where the 309 participants were, among others, Beau Williamson, Albert Manfredi, 310 Marshall Eubanks, John Kristoff, David Meyer, Stig Venaas, Rami 311 Lehtonen, and Leonard Giuliano. 313 5. IANA Considerations 315 This memo includes no request to IANA. 317 [[Note to the RFC-Editor: this section should be removed prior to 318 publication.]] 320 6. Security Considerations 322 As section Section 3.4 describes, the organizations will not want to 323 expose all their sessions, or even knowledge that the organization is 324 using a particular application, to the outside. The confidentiality 325 needs must be considered. 327 7. References 329 7.1 Normative References 331 [I-D.ietf-mboned-addrarch] 332 Savola, P., "Overview of the Internet Multicast Addressing 333 Architecture", 334 Internet-Draft draft-ietf-mboned-addrarch-01, February 335 2005. 337 7.2 Informative References 339 [I-D.lehtonen-mboned-dynssm-req] 340 Lehtonen, R., "Requirements for discovery of dynamic SSM 341 sources", 342 Internet-Draft draft-lehtonen-mboned-dynssm-req-00, 343 February 2005. 345 [RFC2730] Hanna, S., Patel, B. and M. Shah, "Multicast Address 346 Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, 347 December 1999. 349 Author's Address 351 Pekka Savola 352 CSC/FUNET 353 Espoo 354 Finland 356 Email: psavola@funet.fi 358 Intellectual Property Statement 360 The IETF takes no position regarding the validity or scope of any 361 Intellectual Property Rights or other rights that might be claimed to 362 pertain to the implementation or use of the technology described in 363 this document or the extent to which any license under such rights 364 might or might not be available; nor does it represent that it has 365 made any independent effort to identify any such rights. Information 366 on the procedures with respect to rights in RFC documents can be 367 found in BCP 78 and BCP 79. 369 Copies of IPR disclosures made to the IETF Secretariat and any 370 assurances of licenses to be made available, or the result of an 371 attempt made to obtain a general license or permission for the use of 372 such proprietary rights by implementers or users of this 373 specification can be obtained from the IETF on-line IPR repository at 374 http://www.ietf.org/ipr. 376 The IETF invites any interested party to bring to its attention any 377 copyrights, patents or patent applications, or other proprietary 378 rights that may cover technology that may be required to implement 379 this standard. Please address the information to the IETF at 380 ietf-ipr@ietf.org. 382 Disclaimer of Validity 384 This document and the information contained herein are provided on an 385 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 386 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 387 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 388 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 389 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 390 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 392 Copyright Statement 394 Copyright (C) The Internet Society (2005). This document is subject 395 to the rights, licenses and restrictions contained in BCP 78, and 396 except as set forth therein, the authors retain all their rights. 398 Acknowledgment 400 Funding for the RFC Editor function is currently provided by the 401 Internet Society.