idnits 2.17.1 draft-ietf-dhc-mdhcp-03.txt: -(349): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(427): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 11) being 96 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 5. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 186: '... The DHCP server MUST provide TTL valu...' RFC 2119 keyword, line 190: '... DHCP server MUST NOT allocate the s...' RFC 2119 keyword, line 221: '...ment. The client MUST obtain an IP add...' RFC 2119 keyword, line 222: '...st address. Therefore, B flag MUST not...' RFC 2119 keyword, line 239: '... MBZ: MUST BE ZERO (reserve...' (20 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 464 has weird spacing: '... client assi...' == Line 468 has weird spacing: '...rom the reac...' == Line 478 has weird spacing: '...options may c...' == Line 527 has weird spacing: '...fferent a d...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A new flag (M) is defined to differentiate the MDHCP messages from DHCP messages. All the messages (DHCPDISCOVER, DHCPOFFER etc.) use M flag defined below to indicate multicast address negotiations. The second bit of the flag field (bit 1) defines M (multicast) flag. The M bit must be set for all the message exchanges pertinent to the multicast address assignment. The client MUST obtain an IP address prior to requesting a multicast address. Therefore, B flag MUST not be set when M flag is set. -- 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 20, 1997) is 9647 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) -- Missing reference section? '1' on line 726 looks like a reference -- Missing reference section? '3' on line 736 looks like a reference -- Missing reference section? '5' on line 744 looks like a reference -- Missing reference section? '2' on line 730 looks like a reference -- Missing reference section? 'Table 1' on line 446 looks like a reference -- Missing reference section? 'Table 2' on line 446 looks like a reference -- Missing reference section? '4' on line 740 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration working group Baiju V. Patel, 3 Internet Draft Intel Corp, 4 Munil Shah 5 Microsoft Corp. 6 November 20, 1997 8 Multicast address allocation extensions to the 10 Dynamic Host Configuration Protocol 12 14 Status of this Memo 16 This document is an Internet Draft. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its Areas, 18 and its Working Groups. Note that other groups may also distribute 19 working documents as Internet Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months. Internet Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet 24 Drafts as reference material or to cite them other than as a 25 "working draft" or "work in progress". 27 To learn the current status of any Internet-Draft, please check the 28 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 29 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 30 munnari.oz.au. 32 A revised version of this draft document will be submitted to the 33 RFC editor as a Proposed Standard for the Internet Community. 34 Discussion and suggestions for improvement are requested. This 35 document will expire before February 1998. Distribution of this 36 draft is unlimited. 38 Abstract 40 The Dynamic Host Configuration Protocol (DHCP) provides a framework 41 for passing configuration information to hosts on a TCP/IP network. 42 The multicast extensions to DHCP add additional capability of 43 dynamic allocation of the multicast addresses and additional 44 configuration options. 46 1. Introduction 48 The multicast extensions to DHCP (MDHCP) provide configuration 49 parameters to the multicast applications. MDHCP is built on a 50 client-server model, where designated DHCP server allocates 51 multicast addresses and delivers parameters associated with the 52 address to dynamically configured hosts. Throughout the remainder 53 MDHCP 11/20/97 55 of this document, the term "server" refers to a host providing 56 multicast address(es) and parameters through DHCP, and the term 57 "client" refers to a host requesting multicast address(es) and 58 parameters from a DHCP server. MDHCP server is used at times, to 59 indicate a DHCP server capable of handling MDHCP extensions to the 60 DHCP protocol and the MDHCP client is used to indicate the MDHCP 61 capable DHCP client. MDHCP is not a separate protocol, but is 62 simply an extension to the DHCP protocol. 64 Like DHCP, MDHCP should be a mechanism rather than a policy. MDHCP 65 must allow local system administrators control over configuration 66 parameters where desired; e.g., local system administrators should 67 be able to enforce local policies concerning allocation and access 68 to local resources where desired. 70 The MDHCP client is not required to obtain IP address from a DHCP 71 server in order to use MDHCP protocol. 73 The design goals specified in the DHCP RFC also apply to MDHCP. 75 1.1. Requirements 77 Throughout this document, the words that are used to define the 78 significance of particular requirements are capitalized. These 79 words are: 81 o "MUST" 83 This word or the adjective "REQUIRED" means that the 84 item is an absolute requirement of this specification. 86 o "MUST NOT" 88 This phrase means that the item is an absolute prohibition 89 of this specification. 91 o "SHOULD" 93 This word or the adjective "RECOMMENDED" means that there 94 may exist valid reasons in particular circumstances to 95 ignore this item, but the full implications should be 96 understood and the case carefully weighed before choosing a 97 different course. 99 o "SHOULD NOT" 101 This phrase means that there may exist valid reasons in 102 particular circumstances when the listed behavior is 103 acceptable or even useful, but the full implications should 104 MDHCP 11/20/97 106 be understood and the case carefully weighed before 107 implementing any behavior described with this label. 109 o "MAY" 111 This word or the adjective "OPTIONAL" means that this item 112 is truly optional. One vendor may choose to include the 113 item because a particular marketplace requires it or because 114 it enhances the product, for example; another vendor may 115 omit the same item. 117 1.2. Terminology 119 This document uses the following terms[1]: 121 o "DHCP client" 123 A DHCP client is an Internet host that obtains configuration 124 parameters (e.g., network address) using DHCP protocol 126 o "DHCP server" 128 A DHCP server is an Internet host that provides 129 configuration parameters to DHCP clients. 131 o "MDHCP client" 133 A MDHCP client is a DHCP client that supports MDHCP 134 extensions. 136 o "MDHCP server" 138 A MDHCP server is a DHCP server that supports MDHCP 139 extensions. 141 1.3. Motivation and protocol requirements. 143 For multicast applications to be ubiquitous, there is a need to 144 standardize on a protocol to allocate multicast addresses to an 145 application. Following are the set of requirements on such a 146 protocol. 148 Conflict Free Allocation: When two applications obtain a multicast 149 address (using a common multicast address allocation protocol), both 150 applications may be allocated identical addresses only if it can be 151 guaranteed that no hosts will receive multicasts using same address 152 from both the applications on the same network interface provided 153 that the multicast scoping is implemented correctly. 155 MDHCP 11/20/97 157 Quick response: The application should not have to wait for a long 158 time before it able to determine if it can use a multicast address. 159 The response time should primarily be a function of network and 160 system delays only and should not be in the order of several 161 minutes. 163 Low network load: The multicast address allocation protocol is a 164 control protocol. Therefore, it should impose minimal load on the 165 network. Specifically, the address allocation protocol should not 166 overload a modem line when used by a dial-in user. 168 Work with power managed systems: System may be in on, off or low 169 power state between the address allocation and usage period. 171 Multicast address scopes: The protocol must be able to allocate both 172 the administratively scoped and global addresses. 174 Efficient use of address space: The multicast address space is 175 smaller then IP address space. Moreover, a host or application may 176 require multiple addresses. Therefore, efficient use of address 177 space is a design goal of multicast address allocation protocol. 179 1.4. MHDCP Protocol Summary 181 From the protocol standpoint, MDHCP is an extension of the DHCP. As 182 in normal DHCP protocol, a MDHCP client requests multicast 183 address(es) from the MDHCP server for a specified multicast scope. 184 The MDHCP servers assigns multicast address(es) to the hosts to be 185 used within the requested scope, and valid over a specific period. 186 The DHCP server MUST provide TTL value of the address. The client, 187 when using the assigned address should not use the TTL value larger 188 than the one provided. The lease period is defined by the duration 189 of the lease and the time at which the lease becomes effective. The 190 DHCP server MUST NOT allocate the same address to different clients 191 with overlapping lease period and scope. The protocol also allows 192 client to request more than one address at a time. 194 Before requesting a multicast address, a client needs to obtain the 195 list of multicast scopes available on the MDHCP server. The 196 multicast scope-list is one of the MDHCP configuration parameters. 197 The scope list may be obtained through the DHCP option described in 198 [3], or may be obtained by some other means. Similarly, the MDHCP 199 server address (multicast) may also be obtained by the option 200 described in [3] or can be configured on the client. 202 The MDHCP server is not required to be co-located with a DHCP 203 server. Therefore, in a typical deployment, there may be fewer MDHCP 204 servers then the DHCP servers. 206 The MDHCP protocol uses M flag and a set of options defined below. 208 MDHCP 11/20/97 210 2. MDHCP messages and options. 212 The following options and flags are used by MDHCP extensions. 214 2.1. M flag 216 A new flag (M) is defined to differentiate the MDHCP messages from 217 DHCP messages. All the messages (DHCPDISCOVER, DHCPOFFER etc.) use 218 M flag defined below to indicate multicast address negotiations. The 219 second bit of the flag field (bit 1) defines M (multicast) flag. 220 The M bit must be set for all the message exchanges pertinent to the 221 multicast address assignment. The client MUST obtain an IP address 222 prior to requesting a multicast address. Therefore, B flag MUST not 223 be set when M flag is set. 225 1 1 1 1 1 1 227 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 |B|M| MBZ | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 B: BROADCAST flag 237 M: Multicast address request flag. 239 MBZ: MUST BE ZERO (reserved for future use) 241 2.2. Multicast Scope Option 243 This option is used by the client to indicate the multicast scope 244 for the requested multicast address(es). It is also used to indicate 245 the scope of the assigned address by the DHCP server. If this option 246 is not specified, the DHCP server MAY allocate an address from a 247 DEFAULT scope or reject the request. 249 Code Len Scope Id 251 +-----+-----+-----+-----+-----+-----+ 253 | 101 | 4 | i1 | i2 | i3 | i4 | 255 +-----+-----+-----+-----+-----+-----+ 257 The client may obtain the scope list through the option described in 258 [3] or using some other means. The scope id is the numeric 259 representation of the scope as described in [3]. The 'code' for this 260 option is 101 and the length is 4. 262 MDHCP 11/20/97 264 2.3. Start time Option 266 The start time is used in a client request (DHCPDISCOVER or 267 DHCPREQUEST) to allow the client to request the starting time for 268 the use of the assigned address. This option allows client to 269 request a multicast address for use at a future time. 271 Code Len Time 273 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 275 | 102 | 8 | t1 | t2 | t3 | t4 | t5 | t6 | t7 | t8 | 277 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 279 The time value is the decimal representation of Network Time 280 Protocol (NTP) time values in seconds [5]. 282 The 'code' for this option is 102 and the length is 8. 284 If IP Address Lease Time option specifies [2] the duration of the 285 lease beginning at Start Time option value. 287 2.4. Multicast TTL Option 289 This option specifies the TTL value to be used with the multicast 290 address. The TTL is specified as an octet with a value between 1 291 and 255. The implied value of this option is 255 when not included. 293 Code Len Multicast TTL 295 +-----+-----+-----+ 297 | 103 | 1 | n | 299 +-----+-----+-----+ 301 The 'code' for this option is 103 and the length is 1. 303 2.5. Number of Addresses Requested Option 305 This option specifies the number of addresses requested by the 306 client. The client MAY obtain more than one address either by 307 repeating the protocol for every address or by requesting all the 308 addresses at the same time via this option. The server MAY use this 309 option to indicate to the client the number of addresses it has 310 allocated to the client. When the client is requesting only one 311 address, this option need not be included. 313 Code Len Number of Addresses 315 +-----+-----+-----+-----+ 317 | 104 | 2 | n | 319 +-----+-----+-----+-----+ 321 The 'code' for this option is 104 and the length is 2. 323 MDHCP 11/20/97 325 2.6. Client Port Option 327 In order to facilitate implementations outside the operating system 328 kernel, and to allow two separate client implementations: one for 329 DHCP and one for MDHCP, if this option is specified, the MDHCP server 330 MUST use the source port number used in the DHCPDISCOVER, 331 DHCPREQUEST, DHCPINFORM, and DHCPRESEASE as the destination port 332 number in the response messages. 334 Code Len Port 336 +-----+-----+-----+ 338 | 105 | 1 | n | 340 +-----+-----+-----+ 342 The 'code' for this option is 105 and the length is 1. 344 2.7. List of Address Ranges Allocated 346 This option is used by the server to provide the list of all the 347 address ranges allocated to the client when client requests more than 348 one addresses. When a client requests only one address, the server 349 uses the �yiaddr� field specify the allocated address. When a client 350 requests more than one address, additional address ranges are listed 351 via this option. 353 Code Len Address Range List 355 +-----+-----+-----+-----+-...-+-----+ 357 | 105 | n | L1 | L2 | | Ln | 359 +-----+-----+-----+-----+-----+-----+ 361 Where the Address Range List is of the follwing format. 363 StartAddress1 BlockSize1 StartAddress2 BlockSize2 ... 365 +---+---+---+---+---+---+---+---+---+---+---+---+--...--+ 367 |S11|S12|S13|S14|B11|B12|S21|S22|S23|S24|B21|B22| | 369 +---+---+---+---+---+---+---+---+---+---+---+---+-------+ 371 The 'code' for this option is TBD and the minimum length is 6. 373 3. MDHP protocol 375 The client first needs to know the group multicast address of the 376 MDHCP servers, and the multicast scope list. This address and the 377 scope list may be obtained by requesting the options specified in 378 [3] from DHCP servers via DHCPINFORM or from other repository of 379 network configurations. 381 At this point, client has two ways of obtaining the multicast 382 address(es) from the server. 384 MDHCP 11/20/97 386 In the first method [see Figure 1], the client is requesting 387 address(es) from any of the MDHCP servers configured to hand out 388 addresses from a given scope. The client selects a scope and sends 389 out a DHCPDISCOVER 390 message to the multicast address of the MDHCP servers. The server 391 responds by sending DHCPOFFER message directly to the client. The 392 client then sends DHCPREQUEST messages to the multicast address. 393 of the MDHCP servers. The selected server responds by sending 394 DHCPACK message directly to the client as in normal DHCP protocol. 395 The multicast DHCPDICOVER and DHCPREQUEST messages are received by 396 only the multicast capable DHCP servers, and therefore, there is no 397 conflict between the MDHCP and DHCP messages. Further, the messages 398 for renewing and releasing lease are sent directly to the MDHCP 399 servers only, and therefore, there is conflict between DHCP and 400 MDHCP message interpretation by a non-MDHCP capable server. The 401 fields and options that are different from the normal DHCP message 402 exchange are summarized in Table 1 to 3. For details on rest of the 403 fields, please refer DHCP RFC [1]. 405 The client can later renew or release the multicast address by using 406 DHCPREQUEST and DHCPRELEASE message exchanges as defined in the DHCP 407 RFC [1]. 409 At any time, if the MDHCP server is unable to satisfy the 410 DHCPREQUEST message (e.g., the requested address has been 411 allocated), the server MUST respond with a DHCPNAK message. 413 Note that all the messages in this exchange have their M flag set 414 and B flag not set. 416 In the second method [see Figure 2] the client is requesting 417 address(es) directly from a specific MDHCP server. When a client 418 knows the IP address of the MDHCP server from which it can obtain a 419 multicast address(es) from a give scope, it MAY skip the discover 420 phase ( i.e. DHCPDISCOVER and DHCPOFFER message exchange ) and 421 directly start with unicasting DHCPREQUEST message to the server. If 422 this fails, the client SHOULD revert back to the first method. 424 The MDHCP client may need to be deployed on the client machines 425 where DHCP client implementation is not capable of filtering out the 426 MDHCP messages. In that case, the MDHCP client MUST use a port 427 number different from �DHCP client port(68)�. The MDHCP client MUST 428 specify this port in the DHCPDISCOVER and DHCPREQUEST messages via 429 �Client Port Option�. 431 The MDHCP Client MUST provide client identifier option when sending 432 messages for multicast address assignment. The client generates a 433 unique key and uses that as a client identifier in the DHCPDISCOVER 434 message. The client identifier is the key to distinguish the client 435 request and to avoid duplicate address allocation. 437 Each client may be running several different multicast enabled 438 applications, and each application may require separate multicast 439 address(es). Client MUST use separate unique client identifier when 440 MDHCP 11/20/97 442 requesting separate multicast address(es) for each request. A client 443 implementation may choose to use hardware address, application 444 instance and time of request to generate unique client identifiers. 446 The following tables [Table 1, Table 2] describes the fields and 447 options that are relavent to MDHCP protocol but are different from 448 the normal DHCP protocol [1] 450 Field DHCPOFFER DHCPACK DHCPNAK 452 ----- --------- ------- ------- 454 'flags' Set 'M' Bit. set 'M' Bit set 'M' bit 456 BROADCAST bit 0 BROADCAST bit 0 BROADCAST bit 0 458 'ciaddr' 'ciaddr' from 'ciaddr' from 0 460 DHCPDISCOVER or 0 DHCPREQUEST or 0 462 'yiaddr' Multicast address Multicast address 464 assigned to client assigned to client 466 'siaddr' Server's IP address Server's IP address 0 468 reachable from the reachable from the 470 client. client. 472 'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from 474 client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST 476 message message message 478 'file' may contain options may contain options (unused) 480 'options' options options 482 Option DHCPOFFER DHCPACK DHCPNAK 484 ------ --------- ------- ------- 486 IP address lease time MUST MUST MUST NOT 488 Lease Start Time MUST MUST MUST NOT 490 Server identifier MUST MUST MUST 492 Multicast Scope MUST MUST MUST NOT 494 Table 1: Fields and options that are different in 495 multicast DHCP server messages. 497 MDHCP 11/20/97 499 Field DHCPDISCOVER DHCPREQUEST DHCPRELEASE 501 ----- ------------ ----------- ----------- 503 'flags' Set 'M' Bit. set 'M' Bit set 'M' bit 505 BROADCAST bit 0 BROADCAST bit 0 BROADCAST bit 0 507 'ciaddr' 0 or client's 0 or client's 0 509 network addr network addr 511 'chaddr' ignored ignored ignored 513 'options' options options (unused) 515 Option DHCPDISCOVER DHCPREQUEST DHCPRELEASE 517 ------ ------------ ----------- ----------- 519 Start time MAY MAY MUST NOT 521 Client identifier MUST MUST MAY 523 Multicast Scope SHOULD SHOULD MAY 525 Client Port MUST(if using MUST (if using MUST NOT 527 a different a different 529 port) port) 531 Table 2: Fields and options that are different in 532 multicast DHCP client messages 533 MDHCP 11/20/97 535 Server Client Server 537 (not selected) (selected) 539 v v v 541 | | | 543 | Obtain IP address | 545 | | | 547 |Begin multicast address request| 549 | | | 551 | _____________/|\_____________ | 553 |/ DHCPDISCOVER | DHCPDISCOVER \| 555 | | | 557 Determines | Determines 559 address(es) | address(es) 561 | | | 563 |\ | ____________/| 565 | \_________ | /DHCPOFFER | 567 | DHCPOFFER\ |/ | 569 | \ | | 571 | Collects replies | 573 | \| | 575 | Selects Address(es) | 577 | | | 579 | _____________/|\_____________ | 581 |/ DHCPREQUEST | DHCPREQUEST \| 583 | | | 585 | | Commits address(es) 587 | | | 589 | | _____________/| 591 | |/ DHCPACK | 593 | | | 595 | assignment complete | 597 | | | 599 . . . 601 | | | 603 | Graceful release | 605 | | | 607 | |\_____________ | 609 | | DHCPRELEASE \| 611 | | | 613 | | Discards lease 615 | | | 617 v v v 619 Figure 1: Timeline diagram of messages exchanged between MDHCP 620 client and servers using group multicast address for MDHCP 621 capable servers. 623 MDHCP 11/20/97 625 Client Server 627 v v 629 | | 631 |\_____________ | 633 | DHCPREQUEST \| 635 | | 637 | Commits address(es) 639 | | 641 | _____________/| 643 |/ DHCPACK | 645 | | 647 | assignment complete 649 | | 651 . . 653 | | 655 Graceful release | 657 | | 659 |\_____________ | 661 | DHCPRELEASE \| 663 | | 665 | Discards lease 667 | | 669 v v v 671 Figure 2: Timeline diagram of messages exchanged between MDHCP 672 client and servers when MDHCP server has already been 673 selected 675 4. MDHCP Protocol properties 677 Conflict free address allocation: In the intranet case, each MDHCP 678 server MAY be allocated part of the administratively scoped address 679 space. As long as the address space managed by MDHCP servers is 680 non-overlapping for a given administrative scope, the protocol 681 will allocate conflict free addresses. MDHCP protocol does not 682 directly address the mechanisms for determining address allocation 683 outside Intranet. However, we propose to use MDHCP as a front end 684 to any future address allocation protocol for the Internet. The DHCP 685 protocol will preserve conflict free address allocation property of 686 the internet multicast address allocation protocol. 688 Small response time: The response time for MDHCP protocol is 689 strictly based on the network propagation delay and the load on the 690 MDHCP server. 692 The MDHCP protocol does not require a client system to be on all the 693 time. Thus, it poses no additional requirements on power managed 694 systems. 696 MDHCP 11/20/97 698 Multicast address scopes: The administratively scoped multicast 699 address may be directly allocated by MDHCP server. However, it is 700 envisioned that the MDHCP protocol will be indirectly used for 701 Internet wide Multicast addresses allocation. In such deployment, 702 the MDHCP server will act as a front-end to future Internet 703 multicast address allocation protocols. 705 Efficient use of address space: The multicast address space may be 706 statically partitioned between MDHCP servers to provide sufficient 707 reliability and load management on servers. However, the multicast 708 based address request will be able to obtain addresses from any of 709 the available servers. 711 5. Security Considerations 713 This document does not explicitly address security considerations to 714 avoid redundant effort with the work in progress in DHC working 715 group of IETF on securing DHCP. 717 6. Acknowledgements 719 The authors would like to thank Rajeev Byrisetty, Steve Deering, 720 Peter Ford, Mark Handley, Van Jacobson, David Oran, Thomas Pfenning, 721 Dave Thayler, Ramesh Vyaghrapuri and the participants of IETF for 722 their assistance with this protocol. 724 7. References 726 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC1541, 728 October 1993. 730 [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor 732 Extensions", RFC 1533, Lachman Technology, Inc., Bucknell 734 University, October 1993. 736 [3] Patel, B., and Shah, M., ``Multicast address allocation 738 extensions options'' 740 [4] Meyer, D., ``Administratively scoped IP Multicast'', Internet 742 draft, 744 [5] D. Mills, ``Network Time Protocol version 2 specification and 746 implementation'', 748 8. Author's Address 750 Baiju V. Patel 751 Intel Corp. 752 2111 NE 25th Ave. 753 Hillsboro, OR 97124 754 MDHCP 11/20/97 756 Phone: 503 264 2422 757 EMail: baiju@mailbox.jf.intel.com 759 Munil Shah 760 Microsoft Corporation 761 One Microsoft Way 762 Redmond, WA 98052 764 Phone:425 703 3924 765 Email:munils@microsoft.com 767 This document will expire on April, 1998