idnits 2.17.1 draft-ietf-mboned-addrdisc-problems-02.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 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 437. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 448. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 455. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 461. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 3, 2006) is 6629 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-mboned-addrarch-03 -- Obsolete informational reference (is this intentional?): RFC 3138 (Obsoleted by RFC 5771) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 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 Intended status: Informational March 3, 2006 5 Expires: September 4, 2006 7 Lightweight Multicast Address Discovery Problem Space 8 draft-ietf-mboned-addrdisc-problems-02.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 4, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 Typically applications developers have requested static IANA 42 assignments for their applications, even if the applications would 43 typically be only used within a site, between consenting sites, or 44 would not eventually even use multicast at all. This memo describes 45 this problem space, and summarizes a number of proposed approaches to 46 mitigating these problems. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Mitigation Techniques . . . . . . . . . . . . . . . . . . . . 5 53 3.1. Locally Scoped Address Assignment by a Registry . . . . . 5 54 3.2. Single Administration Address Discovery with Server 55 Configuration . . . . . . . . . . . . . . . . . . . . . . 6 56 3.3. Zero-configuration Single Administration Address 57 Discovery . . . . . . . . . . . . . . . . . . . . . . . . 7 58 3.4. Global Multiple Administration Address Discovery . . . . . 8 59 4. DNS As a Means of Indirection . . . . . . . . . . . . . . . . 8 60 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 65 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 Intellectual Property and Copyright Statements . . . . . . . . . . 11 69 1. Introduction 71 There are a lot of different challenges relating to the discovery and 72 use of an appropriate multicast address as described below. This 73 document 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 in such a manner 107 that each multicast group has a "server", "session creator" or some 108 other node(s) (or persons operating the nodes) which are in some way 109 in 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 even in cases 115 where using local addresses would be feasible. 117 It would be highly desirable (as described in Section 2) that the 118 applications could easily use more dynamic, and more scoping-friedly 119 mechanisms for discovering the 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 to applications is a problem for 127 multiple reasons: 129 1. 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 2. Static IANA assignments are required for each application; a 135 permanent global assignment for each potentially multicast-using 136 application depletes the resource quickly. 138 3. 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 4. "Intended for local only use" applications typically leak through 144 to the IPv4 MSDP because there is no clear logic which ones 145 should 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 a 151 registry (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 o We'll look at using DNS as an additional component in Section 4. 200 3.1. Locally Scoped Address Assignment by a Registry 202 If we ignore requirements for different levels of scoping, the 203 simplest approach would be to make globally unique assignments within 204 a well known local scoped address block. Group address assignments 205 could be made by IANA (or some other registry) to applications on a 206 first come first serve basis, much like what is done for port numbers 207 used in protocols such as SCTP, TCP and UDP. This well defined range 208 could then be scoped at the public Internet boundaries to ensure 209 private usage remains private. 211 Theoretically, reserved space within the administratively scoped 212 address range (239/8) defined by RFC 2365 [RFC2365] that could be 213 used for such a purpose. This address range should even be scoped at 214 public Internet boundaries already. However, many organizations are 215 already making use of the entire administratively scoped range. For 216 better or worse, we feel that it is now too late to reclaim the 217 reserved address space within the administratively scoped range for 218 the problem case described here even if it were to be appropriate to 219 do so. 221 If we consider multiple levels of scoping, using static address 222 assignments may be problematic for sites with the need to separate 223 applications between their local boundaries. If no other scoping 224 mechanism is used, the network would have to create and maintain 225 complex forwarding and filtering rules to ensure group membership for 226 the well defined group address does not leak outside the desired 227 local scope. 229 Even if a well defined local scope address range could be used and 230 additional levels of scoping were not an issue, it is not clear that 231 multicast application developers would accept a local scoped address 232 over a globally routable one. Given the choice of a local scoped 233 assignment and a global one, what incentive is there for an 234 application developer to choose a locally scoped one if there is even 235 a faint chance of global usage? 237 IANA is not the only option for such a registry; for example, 238 Regional Internet Registries could perform assignments if there was 239 demand, as described by the "eGLOP" proposal [RFC3138]. No registry 240 has yet taken up the offer though, and doing so would be useful only 241 if IANA ceased making assignments itself. 243 An additional, fundamental question with static address assiginment 244 in the IPv4 multicast address space (224/4) is, how big of an address 245 range should be reserved? Existing multicast applications in use 246 have been written to use an address block as large as a /8. Any 247 allocation on this order is clearly diminishing the limited pool of 248 already limited IPv4 multicast addresses. 250 3.2. Single Administration Address Discovery with Server Configuration 252 The second mitigation technique would be to specify and implement a 253 mechanism, requiring no infrastructure in the network, where the 254 "server end" would be manually configured with appropriately selected 255 locally-scoped addresses which the clients would use to discover the 256 group address. 258 The client ends should discover the smallest possible scope where the 259 application is supported. 261 A few notes on this method: 263 o One could characterize a potential solution as an easily 264 implementable server shim at "server end" listening to a set well- 265 known locally-scoped multicast addresses (e.g., a scope-relative 266 address at each local scope), which would respond to queries by 267 "client end". 269 o How can the servers demultiplex "queries" sent to these addresses? 270 Are these messages in SAP format or something simpler? The query 271 must have an identifier (e.g., done by hashing a name?) which the 272 server uses to know the client is interested in the server's 273 multicast transmission. 275 o How should the servers communicate back to the clients? By 276 replying with unicast (issues after bootup with lots of nodes) or 277 do the clients also join the address (DoS potential, a very 278 crowded group which all the servers at least need to subscribe 279 to)? 281 Again, this does not solve the root problem; why would an application 282 designer implement this mechanism when he/she wants to support global 283 scoping as well? IANA assignment will be requested in any case. 285 3.3. Zero-configuration Single Administration Address Discovery 287 A slightly more extensive problem is the same as above, but assuming 288 that the application must be completely zero-configurable. That is, 289 it must work without having to manually configure anything on the 290 server end. 292 This could be achieved e.g., by adding to the above a SAP-like 293 address blocks from which the addresses could be dynamically 294 reserved. This might not sit well on the organization's local 295 scoping plans, however. 297 However, it is worth considering whether this is really needed. For 298 link-local scope, this may be desirable as such requires no set-up of 299 multicast routing. But for larger scopes, is this really useful? If 300 there is no administrator to configure the address, likely there is 301 no multicast infrastructure in the first place, or desire to run the 302 application in multicast mode! 304 Again, this does not solve the root problem. 306 3.4. Global Multiple Administration Address Discovery 308 Most applications are such that they _can_ be run over site/ 309 organization boundaries (even if they typically would not be), so the 310 application developers will want to support the most extensive scope. 311 There is no common local scope (even between organization-local and 312 global) which could cover these disjoint global interconnections, so 313 the applications must use global scope addresses. 315 To get away from static IANA assignments, there should be a 316 lightweight multicast address discovery function which could be used 317 e.g., in the embedded devices to discover the appropriate multicast 318 address they should use. 320 Obviously, the result could also be that the application should be 321 restricted to a local scope, and use local scope addresses, but wider 322 discovery should also be supported. 324 This approach has a number of challenges, however. It's difficult to 325 visualize how multiple administrative domains could perform discovery 326 in a desired manner automatically -- we have to assume that the sites 327 might not want to tell about all of their local sessions to all the 328 other sites (i.e., you may want to allow site A to discover session 329 1, and site B to discover session 2, but not mix these). In other 330 words, there will likely need to be some manual control of what gets 331 seen to the outside and what not. This makes the mechanism more 332 complicated, and requires more network operator management. 334 Further attributes and requirements for this kind of approach remain 335 to be figured out. 337 4. DNS As a Means of Indirection 339 DNS could be leveraged as an additional configuration mechanism with 340 varying usefulness in any of the preceding approaches. The relevant 341 information could be stored in the DNS in mainly two different ways: 343 1. Using local information (e.g., DNS search path, reverse IP 344 addresses, etc.); these have been analyzed in Section 3.2 of 345 [I-D.palet-v6ops-tun-auto-disc], or 347 2. By global information, for example having IANA assign an 348 application-specific DNS entry (e.g., "_dogfight.apps.mcast.net") 349 instead of an address. The sites could either use a default 350 value (which might point to e.g., scoped address space) or make 351 their DNS servers authoritative for that zone and insert their 352 own addresses. 354 Both assume the ability to (e.g., manually) insert records in the 355 local DNS and perform DNS lookups. The former additionally assumes 356 the capability to discover where to find the local information. If 357 these assumptions are acceptable, DNS could be used as an additional 358 mechanism at least with the first two classes of mitigation 359 techniques. 361 5. Acknowledgements 363 This memo grew out of the discussions in MBONED WG, where the 364 participants were, among others, Beau Williamson, Albert Manfredi, 365 Marshall Eubanks, John Kristoff, David Meyer, Stig Venaas, Rami 366 Lehtonen, and Leonard Giuliano. 368 6. IANA Considerations 370 This memo includes no request to IANA. 372 [[Note to the RFC-Editor: this section should be removed prior to 373 publication.]] 375 7. Security Considerations 377 As section Section 3.4 describes, the organizations will not want to 378 expose all their sessions, or even knowledge that the organization is 379 using a particular application, to the outside. The confidentiality 380 needs must be considered when designing a solution to solve one of 381 the problems in this problem space. 383 8. References 385 8.1. Normative References 387 [I-D.ietf-mboned-addrarch] 388 Savola, P., "Overview of the Internet Multicast Addressing 389 Architecture", draft-ietf-mboned-addrarch-03 (work in 390 progress), October 2005. 392 8.2. Informative References 394 [I-D.lehtonen-mboned-dynssm-req] 395 Lehtonen, R., "Requirements for discovery of dynamic SSM 396 sources", draft-lehtonen-mboned-dynssm-req-00 (work in 397 progress), February 2005. 399 [I-D.palet-v6ops-tun-auto-disc] 400 Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point 401 Discovery Mechanisms", draft-palet-v6ops-tun-auto-disc-03 402 (work in progress), January 2005. 404 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 405 RFC 2365, July 1998. 407 [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address 408 Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, 409 December 1999. 411 [RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, 412 June 2001. 414 Author's Address 416 Pekka Savola 417 CSC/FUNET 418 Espoo 419 Finland 421 Email: psavola@funet.fi 423 Full Copyright Statement 425 Copyright (C) The Internet Society (2006). 427 This document is subject to the rights, licenses and restrictions 428 contained in BCP 78, and except as set forth therein, the authors 429 retain all their rights. 431 This document and the information contained herein are provided on an 432 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 433 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 434 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 435 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 436 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 437 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 439 Intellectual Property 441 The IETF takes no position regarding the validity or scope of any 442 Intellectual Property Rights or other rights that might be claimed to 443 pertain to the implementation or use of the technology described in 444 this document or the extent to which any license under such rights 445 might or might not be available; nor does it represent that it has 446 made any independent effort to identify any such rights. Information 447 on the procedures with respect to rights in RFC documents can be 448 found in BCP 78 and BCP 79. 450 Copies of IPR disclosures made to the IETF Secretariat and any 451 assurances of licenses to be made available, or the result of an 452 attempt made to obtain a general license or permission for the use of 453 such proprietary rights by implementers or users of this 454 specification can be obtained from the IETF on-line IPR repository at 455 http://www.ietf.org/ipr. 457 The IETF invites any interested party to bring to its attention any 458 copyrights, patents or patent applications, or other proprietary 459 rights that may cover technology that may be required to implement 460 this standard. Please address the information to the IETF at 461 ietf-ipr@ietf.org. 463 Acknowledgment 465 Funding for the RFC Editor function is provided by the IETF 466 Administrative Support Activity (IASA).