idnits 2.17.1 draft-ietf-mboned-addrdisc-problems-01.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 459. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 (November 19, 2005) is 6732 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-03 ** Downref: Normative reference to an Informational draft: draft-ietf-mboned-addrarch (ref. 'I-D.ietf-mboned-addrarch') -- Obsolete informational reference (is this intentional?): RFC 3138 (Obsoleted by RFC 5771) Summary: 4 errors (**), 0 flaws (~~), 3 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 Expires: May 23, 2006 November 19, 2005 6 Lightweight Multicast Address Discovery Problem Space 7 draft-ietf-mboned-addrdisc-problems-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on May 23, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 Typically applications developers have requested static IANA 41 assignments for their applications, even if the applications would 42 typically be only used within a site, between consenting sites, or 43 would not eventually even use multicast at all. This memo describes 44 this problem space, and summarizes a number of proposed approaches to 45 mitigating these problems. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Mitigation Techniques . . . . . . . . . . . . . . . . . . . . 5 52 3.1. Locally Scoped Address Assignment by a Registry . . . . . 5 53 3.2. Single Administration Address Discovery with Server 54 Configuration . . . . . . . . . . . . . . . . . . . . . . 6 55 3.3. Zero-configuration Single Administration Address 56 Discovery . . . . . . . . . . . . . . . . . . . . . . . . 7 57 3.4. Global Multiple Administration Address Discovery . . . . . 7 58 4. DNS As a Means of Indirection . . . . . . . . . . . . . . . . 8 59 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 64 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 Intellectual Property and Copyright Statements . . . . . . . . . . 10 68 1. Introduction 70 There are a lot of different challenges relating to the discovery and 71 use of an appropriate multicast address as described below. This 72 document only addresses the second one. 74 a. Getting a list of all the available (public) sessions which one 75 could join (and possibly send) to, similar to a "TV guide". That 76 is, having to know everything before you can decide if you're 77 interested in something or not; this is out of scope for this 78 memo. 80 b. Discovering the multicast address used by a particular 81 application for particular purpose, within or crossing a scope. 82 I.e., you know what you're looking for, but don't know if the 83 session has been created already and what its address would be. 85 c. The different sources (unicast addresses) participating in a 86 session. For ASM, there is no need for such discovery. For SSM, 87 this is expected to happen out-of-band or following separate 88 requirements [I-D.lehtonen-mboned-dynssm-req]. 90 Many applications have been written which leverage or could leverage 91 multicast routing infrastructures, in one or more of the following 92 scopes: (We'll get back to these later.) 94 1. link-local scope, 96 2. [geographical] site scope, 98 3. organization-local scope, 100 4. global scope, used between consenting sites/enterprises, also 101 including cases like "inside a country", or 103 5. a truly global scope. 105 Multicast-leveraging applications are often designed in such a manner 106 that each multicast group has a "server", "session creator" or some 107 other node(s) (or persons operating the nodes) which are in some way 108 in control of the application. 110 Both the "server" and "client end" of an application are currently 111 typically provisioned with the group address using static IANA 112 assignment [I-D.ietf-mboned-addrarch]. Only rarely these apps are 113 manually configured e.g. with locally scoped addresses even in cases 114 where using local addresses would be feasible. 116 It would be highly desirable (as described in Section 2) that the 117 applications could easily use more dynamic, and more scoping-friedly 118 mechanisms for discovering the appropriate addresses to use. 120 All of these issues are only relevant to Any Source Multicast (ASM), 121 as SSM requires this information is known a priori. 123 2. Problem Statement 125 The current IANA static assignment to applications is a problem for 126 multiple reasons: 128 1. This messes up the multicast scoping plans which the site may 129 have. Each application's global address must be individually 130 scoped and filtered in all the routers and in their access lists. 131 Scoping should be easier. 133 2. Static IANA assignments are required for each application; a 134 permanent global assignment for each potentially multicast-using 135 application depletes the resource quickly. 137 3. This has issues with IPv6, because such IPv6 addresses can not be 138 scalably routed in inter-domain routing; in intra-domain, this 139 requires manual configuration or running BSR (for ff01::/16 or 140 ff02::/16 or the like) 142 4. "Intended for local only use" applications typically leak through 143 to the IPv4 MSDP because there is no clear logic which ones 144 should be global and which ones are local. 146 There are at least four different proposed ways to mitigate this, 147 from the least to most extensive: 149 a. Smaller-than-global single-administration address assignment by a 150 registry (from 239/8 or elsewhere). 152 b. Smaller-than-global single-administration discovery, with the 153 expectation that a locally scoped address is manually configured 154 on the "server end". 156 c. Smaller-than-global single-administration discovery with complete 157 zero-configuration. 159 d. Global (but restricted) multi-administration discovery with some 160 amount of manual configuration. 162 We'll outline each proposed mitigation technique briefly below. 164 NOTE: David Meyer's experience from being the designated expert for 165 IANA assignments is that almost all of the requested multicast 166 addresses have been such that the requestors would not have been 167 satisfied if their application would only be restricted to operate 168 within a site. 170 If people agree on this, the first three mitigation techniques won't 171 have significant impact, because the application developers won't 172 implement the discovery in any case. They will _still_ want to get 173 the globally scoped addresses from IANA, instead of implementing the 174 "service discovery inside an organization" -shim. 176 3. Mitigation Techniques 178 The generic goals from the application/deployment perspective are: 180 o Not depending on any uncommon external infrastructure besides the 181 application itself (e.g., a MADCAP [RFC2730] server), so that the 182 application can be deployed where MADCAP server is not present. 183 I.e., this should be sufficiently lightweight to be coded in the 184 application or be used by a simple application shim library. 186 o The application should "just work" from perspective of "client 187 end" without any configuration. "Server end" may or may not 188 require configuration of an address. 190 o The presence of applications should be easily filterable at least 191 at the edges of the network. 193 o Preferably it should also be easy to segment the use of 194 application into the smallest possible scopes within the network, 195 to avoid undue state and confusion in the network. 197 o We'll look at using DNS as an additional component in Section 4. 199 3.1. Locally Scoped Address Assignment by a Registry 201 If we ignore requirements for different levels of scoping, the 202 simplest approach would be to make globally unique assignments within 203 a well known local scoped address block. Group address assignments 204 could be made by IANA (or some other registry) to applications on a 205 first come first serve basis, much like what is done for port numbers 206 used in protocols such as SCTP, TCP and UDP. This well defined range 207 could then be scoped at the public Internet boundaries to ensure 208 private usage remains private. 210 Theoretically, reserved space within the administratively scoped 211 address range (239/8) defined by RFC 2365 [RFC2365] that could be 212 used for such a purpose. This address range should even be scoped at 213 public Internet boundaries already. However, many organizations are 214 already making use of the entire administratively scoped range. For 215 better or worse, we feel that it is now too late to reclaim the 216 reserved address space within the administratively scoped range for 217 the problem case described here even if it were to be appropriate to 218 do so. 220 If we consider multiple levels of scoping, using static address 221 assignments may be problematic for sites with the need to separate 222 applications between their local boundaries. If no other scoping 223 mechanism is used, the network would have to create and maintain 224 complex forwarding and filtering rules to ensure group membership for 225 the well defined group address does not leak outside the desired 226 local scope. 228 Even if a well defined local scope address range could be used and 229 additional levels of scoping were not an issue, it is not clear that 230 multicast application developers would accept a local scoped address 231 over a globally routable one. Given the choice of a local scoped 232 assignment and a global one, what incentive is there for an 233 application developer to choose a locally scoped one if there is even 234 a faint chance of global usage? 236 IANA is not the only option for such a registry; for example, 237 Regional Internet Registries could perform assignments if there was 238 demand, as described by the "eGLOP" proposal [RFC3138]. No registry 239 has yet taken up the offer though, and doing so would be useful only 240 if IANA ceased making assignments itself. 242 An additional, fundamental question with static address assiginment 243 in the IPv4 multicast address space (224/4) is, how big of an address 244 range should be reserved? Existing multicast applications in use 245 have been written to use an address block as large as a /8. Any 246 allocation on this order is clearly diminishing the limited pool of 247 already limited IPv4 multicast addresses. 249 3.2. Single Administration Address Discovery with Server Configuration 251 The second mitigation technique would be to specify and implement a 252 mechanism, requiring no infrastructure in the network, where the 253 "server end" would be manually configured with appropriately selected 254 locally-scoped addresses which the clients would use to discover the 255 group address. 257 The client ends should discover the smallest possible scope where the 258 application is supported. 260 A few notes on this method: 262 o One could characterize a potential solution as an easily 263 implementable server shim at "server end" listening to a set well- 264 known locally-scoped multicast addresses (e.g., SAP scope-relative 265 addresses), which would respond to queries by "client end". 267 o How can the servers demultiplex "queries" sent to these addresses? 268 Are these messages in SAP format or something simpler? The query 269 must have an identifier (e.g., done by hashing a name?) which the 270 server uses to know the client is interested in the server's 271 multicast transmission. 273 o How should the servers communicate back to the clients? By 274 replying with unicast (issues after bootup with lots of nodes) or 275 do the clients also join the address (DoS potential, a very 276 crowded group which all the servers at least need to subscribe 277 to)? 279 Again, this does not solve the root problem; why would an application 280 designer implement this mechanism when he/she wants to support global 281 scoping as well? IANA assignment will be requested in any case. 283 3.3. Zero-configuration Single Administration Address Discovery 285 A slightly more extensive problem is the same as above, but assuming 286 that the application must be completely zero-configurable. That is, 287 it must work without having to manually configure anything on the 288 server end. 290 This could be achieved e.g., by adding to the above a SAP-like 291 address segments from which the addresses could be dynamically 292 reserved. This might not sit well on the organization's local 293 scoping plans, however. 295 However, it is worth considering whether this is really needed. For 296 link-local scope, this may be desirable as such requires no set-up of 297 multicast routing. But for larger scopes, is this really useful? If 298 there is no administrator to configure the address, likely there is 299 no multicast infrastructure in the first place, or desire to run the 300 application in multicast mode! 302 Again, this does not solve the root problem. 304 3.4. Global Multiple Administration Address Discovery 306 Most applications are such that they _can_ be run over site/ 307 organization boundaries (even if they typically would not be), so the 308 application developers will want to support the most extensive scope. 309 There is no common local scope (even between organization-local and 310 global) which could cover these disjoint global interconnections, so 311 the applications must use global scope addresses. 313 To get away from static IANA assignments, there should be a 314 lightweight multicast address discovery function which could be used 315 e.g., in the embedded devices to discover the appropriate multicast 316 address they should use. 318 Obviously, the result could also be that the application should be 319 restricted to a local scope, and use local scope addresses, but wider 320 discovery should also be supported. 322 This approach has a number of challenges, however. It's difficult to 323 visualize how multiple administrative domains could perform discovery 324 in a desired manner automatically -- we have to assume that the sites 325 might not want to tell about all of their local sessions to all the 326 other sites (i.e., you may want to allow site A to discover session 327 1, and site B to discover session 2, but not mix these). In other 328 words, there will likely need to be some manual control of what gets 329 seen to the outside and what not. This makes the mechanism more 330 complicated, and requires more network operator management. 332 Further attributes and requirements for this kind of approach remain 333 to be figured out. 335 4. DNS As a Means of Indirection 337 DNS could be leveraged as an additional configuration mechanism with 338 varying usefulness in any of the preceding approaches. The relevant 339 information could be stored in the DNS in mainly two different ways: 341 1. Using local information (e.g., DNS search path, reverse IP 342 addresses, etc.); these have been analyzed in Section 3.2 of 343 [I-D.palet-v6ops-tun-auto-disc], or 345 2. By global information, for example having IANA assign an 346 application-specific DNS entry (e.g., "_dogfight.apps.mcast.net") 347 instead of an address. The sites could either use a default 348 value (which might point to e.g., scoped address space) or make 349 their DNS servers authoritative for that zone and insert their 350 own addresses. 352 Both assume the ability to (e.g., manually) insert records in the 353 local DNS and perform DNS lookups. The former additionally assumes 354 the capability to discover where to find the local information. If 355 these assumptions are acceptable, DNS could be used as an additional 356 mechanism at least with the first two classes of mitigation 357 techniques. 359 5. Acknowledgements 361 This memo grew out of the discussions in MBONED WG, where the 362 participants were, among others, Beau Williamson, Albert Manfredi, 363 Marshall Eubanks, John Kristoff, David Meyer, Stig Venaas, Rami 364 Lehtonen, and Leonard Giuliano. 366 6. IANA Considerations 368 This memo includes no request to IANA. 370 [[Note to the RFC-Editor: this section should be removed prior to 371 publication.]] 373 7. Security Considerations 375 As section Section 3.4 describes, the organizations will not want to 376 expose all their sessions, or even knowledge that the organization is 377 using a particular application, to the outside. The confidentiality 378 needs must be considered when designing a solution to solve one of 379 the problems in this problem space. 381 8. References 383 8.1. Normative References 385 [I-D.ietf-mboned-addrarch] 386 Savola, P., "Overview of the Internet Multicast Addressing 387 Architecture", draft-ietf-mboned-addrarch-03 (work in 388 progress), October 2005. 390 8.2. Informative References 392 [I-D.lehtonen-mboned-dynssm-req] 393 Lehtonen, R., "Requirements for discovery of dynamic SSM 394 sources", draft-lehtonen-mboned-dynssm-req-00 (work in 395 progress), February 2005. 397 [I-D.palet-v6ops-tun-auto-disc] 398 Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point 399 Discovery Mechanisms", draft-palet-v6ops-tun-auto-disc-03 400 (work in progress), January 2005. 402 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 403 RFC 2365, July 1998. 405 [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address 406 Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, 407 December 1999. 409 [RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, 410 June 2001. 412 Author's Address 414 Pekka Savola 415 CSC/FUNET 416 Espoo 417 Finland 419 Email: psavola@funet.fi 421 Full Copyright Statement 423 Copyright (C) The Internet Society (2005). 425 This document is subject to the rights, licenses and restrictions 426 contained in BCP 78, and except as set forth therein, the authors 427 retain all their rights. 429 This document and the information contained herein are provided on an 430 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 431 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 432 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 433 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 434 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 435 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 437 Intellectual Property 439 The IETF takes no position regarding the validity or scope of any 440 Intellectual Property Rights or other rights that might be claimed to 441 pertain to the implementation or use of the technology described in 442 this document or the extent to which any license under such rights 443 might or might not be available; nor does it represent that it has 444 made any independent effort to identify any such rights. Information 445 on the procedures with respect to rights in RFC documents can be 446 found in BCP 78 and BCP 79. 448 Copies of IPR disclosures made to the IETF Secretariat and any 449 assurances of licenses to be made available, or the result of an 450 attempt made to obtain a general license or permission for the use of 451 such proprietary rights by implementers or users of this 452 specification can be obtained from the IETF on-line IPR repository at 453 http://www.ietf.org/ipr. 455 The IETF invites any interested party to bring to its attention any 456 copyrights, patents or patent applications, or other proprietary 457 rights that may cover technology that may be required to implement 458 this standard. Please address the information to the IETF at 459 ietf-ipr@ietf.org. 461 Acknowledgment 463 Funding for the RFC Editor function is currently provided by the 464 Internet Society.