idnits 2.17.00 (12 Aug 2021) /tmp/idnits10081/draft-thaler-zeroconf-multicast-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (4 October 2000) is 7892 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '10' is defined on line 284, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 287, but no explicit reference was found in the text == Outdated reference: draft-ietf-malloc-arch has been published as RFC 2908 == Outdated reference: draft-ietf-malloc-madcap has been published as RFC 2730 == Outdated reference: A later version (-04) exists of draft-ietf-malloc-aap-02 ** Obsolete normative reference: RFC 2462 (ref. '10') (Obsoleted by RFC 4862) Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK Working Group Dave Thaler 3 INTERNET-DRAFT Bernard Aboba 4 Category: Informational Microsoft 5 6 4 October 2000 8 Multicast Address Allocation in Auto-Configured Networks 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working documents as Internet- Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 1. Copyright Notice 30 Copyright (C) The Internet Society (2000). All Rights Reserved. 32 2. Abstract 34 Today, with the rapid rise of home networking, there is an increasing 35 need for auto-configuration mechanisms. This document describes how 36 small networks without a multicast address allocation server may auto- 37 allocate multicast addresses. 39 3. Introduction 41 The Internet Multicast Address Allocation Architecture [1] provides a 42 framework which includes multicast address allocation servers (MAASs) 43 that allocate addresses to hosts. The Multicast Address Dynamic Client 44 Allocation Protocol (MADCAP) [2] has been proposed as the protocol via 45 which hosts and servers communicate. The Multicast Address Allocation 46 Protocol (AAP) [3] has been proposed as the protocol via which servers 47 communicate with each other to prevent allocating the same addresses. 48 However, servers may not be present in all environments. 50 Today, with the rapid rise of home networking, there is an increasing 51 need for auto-configuration mechanisms. This document describes how 52 small networks without a multicast address allocation server may auto- 53 allocate multicast addresses. 55 4. Terminology 57 This document uses the following terms: 59 Configured environment 60 A network area (such as the Internet or an enterprise network) 61 which are managed by one or more administrators or 62 organizations. 64 Zero-configuration environment 65 A network area consisting of devices which have no manual 66 configuration done to them, and are not managed by an 67 administrator or organization. 69 There are two primary zero-configuration scenarios which we distinguish 70 from a configured environment in this document. 72 Isolated: A group of hosts communicate as peers in a zero- configuration 73 environment. In this scenario, there are no address 74 allocation servers, and likely no routers. 76 Edge: In this scenario, we assume there is a router which connects a 77 zero-configuration environment to a configured environment 78 such as the Internet. In this scenario, there are no address 79 allocation servers configured in the zero-configuration area, 80 and there may or may not be servers in the configured 81 environment. 83 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 84 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 85 described in [4]. 87 5. Configuration requirements for small networks 89 In order to enable effective multicast address allocation in small 90 networks, the following requirements need to be met: 92 Allocation 93 A mechanism MUST be provided to allow for hosts to allocate 94 multicast addresses. Ideally, host behavior should be the 95 same in a zero-configuration environment and in a configured 96 environment so that transitions can be done easily. 98 Isolated to Edge transition 99 A mechanism MUST be provided to transition between the 100 Isolated and Edge scenarios. This happens when a router is 101 added to connect an Isolated area to a configured environment, 102 such as when a host in an Isolated environment dials an 103 Internet Service Provider (ISP) and becomes a router. 104 Similarly, the reverse transition occurs if the router goes 105 down. 107 Isolated to Configured transition 108 A mechanism MUST be provided to transition between an Isolated 109 and a Configured environment. This occurs, for example, in a 110 corporate environment when a router comes up or goes down. 111 When a router is down, any hosts on disconnected links may be 112 in an Isolated environment. 114 6. Auto-configuration prescription 116 In this section, we assume that MADCAP and AAP are the protocols in use, 117 since they appear to meet the requirements. 119 6.1. Zero-configuration host behavior 121 As described in [5], a host provides two services to its applications 122 through some API. First, it must allow applications to enumerate the 123 set of available multicast scopes. Second, it must allow applications 124 to request, renew, and release addresses, where the scope must be 125 specified by the application. 127 Note that acquiring the set of enumerated scopes does not necessarily 128 imply that addresses are available in each scope, only that it is legal 129 for an application to request an address in one. 131 6.1.1. Scope enumeration 133 To determine whether a multicast address allocation server is available, 134 a host SHOULD, at startup time, attempt to acquire the list of multicast 135 scopes available by using MADCAP's GETINFO request as described in [2], 136 and done periodically thereafter. This determination MAY instead be 137 delayed until an application wants to enumerate scopes, at the expense 138 of increasing the time needed. 140 If any servers are found, a host should use the set of scopes returned 141 by the servers. In addition, if ranges are defined for allocation of 142 Link-Local, Node-Local, and/or Single-Source addresses, these may be 143 assumed as well (for example, such Link- Local and Node-Local are 144 currently defined in IPv6 [6], and Single-Source is currently defined in 145 IPv4 [7]). 147 If no servers are found, a host can assume that any scopes exist which 148 are well-known with specified ranges. These include the Global scope, 149 the Local scope [6], the Allocation scope [1], and the Single-Source 150 scope. In this situation, a host MAY also begin passively listening to 151 MZAP [8] messages to build up its scope list further. (MZAP sends very 152 low frequency reports of scopes to listeners inside those scopes.) 154 6.1.2. Address Allocation 156 Node-Local and Single-Source addresses can be allocated immediately by 157 any host. The algorithm for choosing an address is implementation- 158 dependent, but the address range to use MUST be the range registered 159 with IANA for the specified scope. 161 Link-Local addresses can be allocated only by hosts which implement at 162 least a minimal subset of AAP consisting of the ACLM and AIU messages 164 For all other addresses, the following procedures apply. 166 If the host has recently tried to obtain the scope list, then the host 167 already knows whether any MAAS's are present. If it has not tried 168 recently, then the host can use MADCAP to discover a server when it 169 wants to allocate an address. 171 If a server is present, the host simply uses MADCAP to allocate 172 addresses. 174 If no server is present, then if the scope associated with the request 175 is "big" (Global, or any scope obtained from MZAP and identified by MZAP 176 as "big"), then no addresses may be allocated; otherwise (if the scope 177 is not "big") then the host MAY allocate addresses by participating in 178 AAP. The host MUST NOT allocate the last 256 addresses in the range as 179 these are reserved for scope- relative addresses [6]. 181 6.2. Zero-configuration router behavior 183 In the Edge scenario, a zero-configuration router exists, with a link 184 which connects to a configured environment. Here, there is likely a 185 well-understood distinction between the local area and the external 186 environment, as well as a potential requirement to be able to scope some 187 data to the local area. Hence, if the router detects that it is an 188 "Edge" router (i.e. a router in an Edge scenario), it should instantiate 189 a Local scope boundary on that link. 191 However, before it can do this, a router must be able to distinguish 192 between whether it is in an Edge scenario, or in a configured 193 environment. This could be done in any implementation- specific manner. 194 For example, the router could assume it is in a zero-configuration 195 environment unless it is specifically configured otherwise. This would 196 appear to be acceptable, since if it is in a configured environment, the 197 router would typically be configured anyway. 199 If the router determines that it is an Edge router, the router SHOULD 200 instantiate a Local scope boundary and become a mini-MAAS with behavior 201 as follows. 203 6.2.1. Scope enumeration 205 To acquire a set of scopes, the router performs the same actions as 206 those described for hosts in Section 5.1.1 above, with MADCAP queries 207 being sent out over the link to the configured environment. 209 When the router receives GETINFO messages from clients in the zero- 210 configuration environment asking for the scope list, it responds as a 211 MADCAP server would, by including the scope list it acquired above. 213 6.2.2. Address Allocation 215 Local scope addresses can be allocated immediately by the router as if 216 it were a MADCAP server. For addresses in all larger scopes, the 217 following procedures apply. 219 If a MADCAP server was found in the configured environment, the router 220 acts as a MADCAP proxy and relays the request to an appropriate server 221 as if it were a client. The response is relayed back to the client as 222 if it were a server. 224 if no MADCAP server was found in the configured environment, the router 225 MAY allocate addresses itself if it implements AAP to coordinate with 226 any other MAASs (such as other Edge routers) reached via the configured 227 environment. 229 7. Transitioning Between Scenarios 231 In an Isolated environment, each host should periodically (either at 232 regular intervals, or only when applications request addresses or scope 233 lists) re-check whether a server is available. This allows simple 234 transition to an Edge or configured environment. 236 Similarly, if the host stops receiving responses from any servers, the 237 behavior specified in Section 5.1 allows it to continue allocating 238 addresses. 240 In an Edge environment, the Edge router should periodically (either at 241 regular intervals, or only when hosts request addresses or scope lists) 242 re-check whether a server is available in the configured environment. 244 Similarly, if the Edge router stops receiving responses from any servers 245 in the configured environment, the behavior specified in Section 5.2 246 allows it to continue allocating addresses. 248 8. References 250 [1] Thaler, D., Handley, M., and D. Estrin, "The Internet Multicast 251 Address Allocation Architecture", Internet Draft, draft-ietf- 252 malloc-arch-05.txt, December 2000. 254 [2] Hanna, S., Patel, B., and M. Shah, "Multicast Address Dynamic 255 Client Allocation Protocol (MADCAP)", Work in progress, draft-ietf- 256 malloc-madcap-07.txt, September 1999. 258 [3] Handley, M. and S. Hanna, "Multicast Address Allocation Protocol 259 (AAP)", Work in progress, draft-ietf-malloc-aap-02.txt, October 260 1999. 262 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 263 Levels", BCP 14, RFC 2119, March 1997. 265 [5] Finlayson, R., "An Abstract API for Multicast Address Allocation", 266 RFC 2771, February 2000. 268 [6] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 269 2365, July 1998. 271 [7] IANA, "Single-source IP Multicast Address Range", 272 http://www.isi.edu/in-notes/iana/assignments/single-source- 273 multicast, October 1998. 275 [8] Handley, M., Thaler, D., and Kermode, R., "Multicast-Scope Zone 276 Announcement Protocol (MZAP)", RFC 2776, February 2000. 278 [9] Information technology - Telecommunications and information 279 exchange between systems - Local and metropolitan area networks - 280 Specific Requirements Part 11: Wireless LAN Medium Access Control 281 (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 282 802.11-1997, 1997. 284 [10] Thomson, S. and Narten, T., "IPv6 Stateless Address 285 Autoconfiguration", RFC 2462, December 1998. 287 [11] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., Lear, 288 E., "Address Allocation for Private Internets", RFC 1918, February, 289 1996. 291 9. Security Considerations 293 In the interest of simplicity, this draft does not prescribe a means of 294 securing the multicast auto-configuration mechanism. Thus it is possible 295 that hosts will allocate conflicting multicast addresses for a period of 296 time, or that non-conforming hosts will attempt to deny service to other 297 hosts by allocating the same multicast addresses. 299 Since MADCAP is used as a mechanism for determining whether to auto- 300 configure, it should be noted that it is likely that hosts in small 301 network scenarios will not attempt to secure their MADCAP traffic. 303 If unsecured, MADCAP is vulnerable to a number of threats, including 304 message modification and attacks by rogue servers and unauthenticated 305 clients. While the procedure described in this document does not 306 preclude implementation of MADCAP security, the extra configuration 307 required to set this up represents an implementation barrier in the home 308 network. As a result, it is likely that most home routers will not 309 support MADCAP authentication, and that those networks will remain 310 vulnerable to attack. 312 These threats are most serious in wireless networks such as 802.11, 313 since attackers on a wired network will require physical access to the 314 home network, while wireless attackers may reside outside the home. In 315 order to provide for privacy equivalent to a wired network, the 802.11 316 specification provides for RC4-based encryption. This is known as the 317 "Wired Equivalency Privacy" (WEP) specification, described in [9]. Where 318 WEP is implemented, an attacker will need to obtain the WEP key prior to 319 gaining access to the home network. 321 10. IANA Considerations 323 This draft does not create any new number spaces for IANA 324 administration. 326 11. Acknowledgments 328 This draft has been enriched by comments from Steve Hanna of Sun 329 Microsystems. 331 12. Authors' Addresses 333 Dave Thaler 334 Microsoft Corporation 335 One Microsoft Way 336 Redmond, WA 98052 338 Phone: +1 (425) 703-8835 339 EMail: dthaler@microsoft.com 341 Bernard Aboba 342 Microsoft Corporation 343 One Microsoft Way 344 Redmond, WA 98052 346 Phone: +1 (425) 936-6605 347 EMail: bernarda@microsoft.com 349 13. Full Copyright Statement 351 Copyright (C) The Internet Society (2000). All Rights Reserved. 352 This document and translations of it may be copied and furnished to 353 others, and derivative works that comment on or otherwise explain it or 354 assist in its implementation may be prepared, copied, published and 355 distributed, in whole or in part, without restriction of any kind, 356 provided that the above copyright notice and this paragraph are included 357 on all such copies and derivative works. However, this document itself 358 may not be modified in any way, such as by removing the copyright notice 359 or references to the Internet Society or other Internet organizations, 360 except as needed for the purpose of developing Internet standards in 361 which case the procedures for copyrights defined in the Internet 362 Standards process must be followed, or as required to translate it into 363 languages other than English. The limited permissions granted above are 364 perpetual and will not be revoked by the Internet Society or its 365 successors or assigns. This document and the information contained 366 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 367 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 368 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 369 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 370 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 372 14. Expiration Date 374 This memo is filed as , and 375 expires May 1, 2001.