Dynamic Host Configuration working group Baiju V. Patel, Internet Draft Intel Corp, Munil Shah Microsoft Corp.September 16,November 20, 1997 Multicast address allocation extensions to the Dynamic Host Configuration Protocol<draft-ietf-dhc-mdhcp-02.txt><draft-ietf-dhc-mdhcp-03.txt> Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire before February 1998. Distribution of this draft is unlimited. Abstract The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. The multicast extensions to DHCP add additional capability of dynamic allocation of the multicast addresses and additional configuration options. 1. Introduction The multicast extensions to DHCP (MDHCP) provide configuration parameters to the multicast applications. MDHCP is built on a client-server model, where designated DHCP serverallocateallocates multicast addresses anddeliverdelivers parameters associated with theMDHCP 09/16/97address to dynamically configured hosts. Throughout the remainder Patel and Shah 1 MDHCP 11/20/97 of this document, the term "server" refers to a host providing multicast address(es) and parameters through DHCP, and the term "client" refers to a host requesting multicast address(es) and parameters from a DHCP server. MDHCP server is used at times, to indicate a DHCP server capable of handling MDHCP extensions to the DHCP protocol and the MDHCP client is used to indicate the MDHCP capable DHCP client. MDHCP is not a separate protocol, but is simplyextensionsan extension to the DHCP protocol.MDHCP supports two mechanisms for multicast address allocation. In "automatic allocation", MDHCP assigns a permanent multicast address to a client. In "dynamic allocation", MDHCP assigns a multicast address to a client for a limited period of time (or until the client explicitly relinquishes the address). In "manual allocation", a client's IP address is assigned by the network administrator, and DHCP is used simply to convey the assigned address to the client. A particular network will use one or more of these mechanisms, depending on the policies of the network administrator.Like DHCP, MDHCP should be a mechanism rather than a policy. MDHCP must allow local system administrators control over configuration parameters where desired; e.g., local system administrators should be able to enforce local policies concerning allocation and access to local resources where desired. The MDHCP client is not required to obtain IP address from a DHCP server in order to use MDHCP protocol. The design goals specified in the DHCP RFC also apply to MDHCP. 1.1. Requirements Throughout this document, the words that are used to define the significance of particular requirements are capitalized. These words are: o "MUST" This word or the adjective "REQUIRED" means that the item is an absolute requirement of this specification. o "MUST NOT"MDHCP 09/16/97This phrase means that the item is an absolute prohibition of this specification. o "SHOULD" This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. o "SHOULD NOT" This phrase means that there may exist valid reasons in particular circumstances when the listed behavior is acceptable or even useful, but the full implications should Patel and Shah 2 MDHCP 11/20/97 be understood and the case carefully weighed before implementing any behavior described with this label. o "MAY" This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. 1.2. Terminology This document uses the following terms[1]: o "DHCP client" A DHCP client is an Internet hostusing DHCP to obtainthat obtains configuration parameterssuch as a(e.g., networkaddress.address) using DHCP protocol o "DHCP server" A DHCP server is an Internet host thatreturnsprovides configuration parameters to DHCP clients. o "MDHCP client" A MDHCP client is a DHCP client that supports MDHCP extensions. o "MDHCP server"MDHCP 09/16/97A MDHCP server is a DHCP server that supports MDHCP extensions.o "BOOTP relay agent" A BOOTP relay agent or relay agent is an Internet host or router that passes DHCP messages between DHCP clients and DHCP servers. DHCP is designed to use the same relay agent behavior as specified in the BOOTP protocol specification. o "binding" A binding is a collection of configuration parameters, including at least an IP address, associated with or "bound to" a DHCP client. Bindings are managed by DHCP servers.1.3. Motivation and protocol requirements. For multicast applications to be ubiquitous, there is a need to standardize on a protocol to allocate multicast addresses tothe applications.an application. Following are the set of requirements on such a protocol. Conflict Free Allocation: When two applications obtain a multicast address (using a common multicast address allocation protocol), both applicationsaremay be allocated identical addresses only if it can be guaranteed that no hosts will receive multicasts using same address from both the applications on the same network interface provided that the multicast scoping is implemented correctly.Session protocol independence: The address allocation protocol should be independent of existingPatel andfuture session control protocol. For example, it must be suitable for applications that use SAP (session announcement protocol) and SIP (session invitation protocol). Small response time:Shah 3 MDHCP 11/20/97 Quick response: The application should not have to wait for a long time before itcan be sure thatable to determine if it can use a multicast address. The response time should primarily be a function of network and system delays only and should not be in the order of several minutes. Low network load: The multicast address allocation protocol is a control protocol.ItTherefore, it shouldbe designed toimpose minimal load on the network.In particular, it should not require periodic broadcast/multicast messages from every application.Specifically,MDHCP 09/16/97the address allocation protocol should not overload a modem line when used by a dial-in user. Work with power managed systems:The protocol should not require the client systems to be on all the time. It is perfectly acceptable that once the multicast address is allocated, the systemSystem maysuspend or turnbe in on, offfor some time. The system may come back to fullor low powerjust beforestate between theapplication starts multicasting traffic.address allocation and usage period. Multicast address scopes: The protocol must be able to allocate both the administratively scopedaddressesand global addresses. Efficient use of address space: The multicast address space is smaller then IP address space. Moreover, a host or application may require multipleaddress.addresses. Therefore, efficient use of address space is a designgoadgoal of multicast address allocation protocol. 1.4. MHDCP Protocol Summary From theclient's point of view,protocol standpoint, MDHCP is an extension of the DHCP. As in normal DHCPmechanisms.protocol, a MDHCP client requests multicast address(es) from the MDHCP server for a specified multicast scope. The MDHCP servers assigns multicastaddressesaddress(es) to the hosts to be used withina specificthe requested scope, and validfor a specific period. A client may request multiple multicast addresses. The client requests a multicast address(es) to be used for a specific multicast scope available to it, and forover a specificleaseperiod. TheMDHCP server would ideally assign the address from the requested scope or may allocate it for a different scope. However, if it allocates the address from a different scope, it will provide this information as an option. TheDHCP server MUST provideaTTLvalue.value of the address. Themulticast packetsclient, when using the assigned addressMUST NOTshould not useathe TTL value largerthenthan the one provided. The lease period is defined by the duration of the lease and the time at which the lease becomes effective.Since the client may want to extend lease at a later time, the DHCP server SHOULD make every attempt at allocating an address which is not currently allocated to any other client.The DHCP server MUST NOT allocate the sameaddressesaddress to different clients with overlapping leaseperiod.period and scope. The protocol also allows client to request more than one address at a time. Before requesting a multicastscopeaddress, a client needs to obtain the list of multicast scopes available on the MDHCP server. The multicast scope-list is one of theDHCPMDHCP configuration parameters. The scope list may be obtained through the DHCP option described in [3], or may be obtainedwithby some other means. Similarly, the MDHCP server address(unicast or multicast)(multicast) may also be obtained by the option described in [3] orby some other means.can be configured on the client. The MDHCP server is not required to be co-located with a DHCP server. Therefore, in a typical deployment, there may be fewer MDHCP09/16/97servers then the DHCP servers. The MDHCP protocol uses M flag and a set of options defined below. Patel and Shah 4 MDHCP 11/20/97 2. MDHCP messages and options. The following options and flags are used by MDHCP extensions. 2.1. M flag A new flag (M) is defined to differentiate the MDHCP messages from DHCP messages. All the messages (DHCPDISCOVER, DHCPOFFER etc.) use M flag(this is a new 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. 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B|M| MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B: BROADCAST flag M: Multicast address request flag. MBZ: MUST BE ZERO (reserved for future use) 2.2. Multicast Scope Option This option is used by the client to indicate the multicast scope for the requested multicastaddress.address(es). It is also used to indicate the scope of the assigned address by the DHCP server. If this option is not specified, the DHCP server MAY allocate an address from a DEFAULT scope or reject the request.MDHCP 09/16/97 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3Code Len Scope Id +-----+-----+-----+-----+-----+-----+ | 101 | 45 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | code | length=4|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i1 |Scope idi2 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i3 |Scope idi4 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-----+-----+-----+-----+-----+-----+ The client may obtain the scope list through the option described in [3] or using some other means. The scope id is the numeric representation of the scope as described in [3]. The 'code' for this option is101.101 and the length is 4. Patel and Shah 5 MDHCP 11/20/97 2.3. Start time Option The start time is used in a client request (DHCPDISCOVER or DHCPREQUEST) to allow the client to request the starting time for the use of the assigned address. This option allows client to request a multicast address for use at a future time.1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | codeCode Len Time +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ |length=4102 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+8 | t1 | t2 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |t3 | t4 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |t5 | t6 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |t7 | t8 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ The time value is the decimal representation of Network Time Protocol (NTP) time values in seconds [5]. The 'code' for this option is102.102 and the length is 8. If IP Address Lease Time option specifies [2] the duration of the lease beginning at Start Time option value.MDHCP 09/16/972.4. Multicast TTL Option This option specifies the TTL value to be used with the multicast address. The TTL is specified as an octet with a value between 1 and 255. The implied value of this option is 255 when not included. Code Len Multicast TTL +-----+-----+-----+ | 103 | 11 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|coden | +-----+-----+-----+ The 'code' for this option is 103 and the length is 1. 2.5. Number of Addresses Requested Option This option specifies the number of addresses requested by the client. The client MAY obtain more than one address either by repeating the protocol for every address or by requesting all the addresses at the same time via this option. The server MAY use this option to indicate to the client the number of addresses it has allocated to the client. When the client is requesting only one address, this option need not be included. Code Len Number of Addresses +-----+-----+-----+-----+ |length=1104 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+2 |TTLn |+-+-+-+-+-+-+-+-++-----+-----+-----+-----+ The 'code' for this option is103. 2.5.104 and the length is 2. Patel and Shah 6 MDHCP 11/20/97 2.6. Client Port Option In order to facilitate implementations outside the operating system kernel, and to allow two separate client implementations: one for DHCP and one for MDHCP, if this option is specified, the MDHCP server MUST use the source port number used in the DHCPDISCOVER, DHCPREQUEST, DHCPINFORM, and DHCPRESEASE as the destination port number in the response messages.0Code Len Port +-----+-----+-----+ | 105 | 12 3 4 5 6 7 +-+-+-+-+-+-+-+-+|coden |+-+-+-+-+-+-+-+-++-----+-----+-----+ The 'code' for this option is105. 3. MDHP protocol The client needs to obtain105 and theIP addresslength is 1. 2.7. List of Address Ranges Allocated This option is used by theMDHCPserver(this may be a unicast or a multicast address for MDHCP group), andto provide themulticast scope list. Thislistmay be obtained as partof all thenormal DHCP protocol usingaddress ranges allocated to theoptions specified inclient when client requests more than one addresses. When a client requests only one address, the server uses the ‘yiaddr’ field specify the allocated address. When a client requests more than one address, additional address ranges are listed via this option. Code Len Address Range List +-----+-----+-----+-----+-...-+-----+ | 105 | n | L1 | L2 | | Ln | +-----+-----+-----+-----+-----+-----+ Where the Address Range List is of the follwing format. StartAddress1 BlockSize1 StartAddress2 BlockSize2 ... +---+---+---+---+---+---+---+---+---+---+---+---+--...--+ |S11|S12|S13|S14|B11|B12|S21|S22|S23|S24|B21|B22| | +---+---+---+---+---+---+---+---+---+---+---+---+-------+ The 'code' for this option is TBD and the minimum length is 6. 3. MDHP protocol The client first needs to know the group multicast address of the MDHCP servers, and the multicast scope list. This address and the scope list may be obtained by requesting the options specified in [3] from DHCP servers via DHCPINFORM orby somefrom othermeans. Therepository of network configurations. At this point, clientselects onehas two ways of obtaining the multicastscopesaddress(es) from the server. Patel andrequests multicastShah 7 MDHCP 11/20/97 In the first method [see Figure 1], the client is requesting address(es) from any of the MDHCPservers.servers configured to hand out addresses from a given scope. Thefieldsclient selects a scope andoptions that are different fromsends out a DHCPDISCOVER message to thenormal DHCPmulticast address of the MDHCP servers. The server responds by sending DHCPOFFER messageexchange are summarized in Table 1directly to3. details on restthe client. The client then sends DHCPREQUEST messages to the multicast address. of theparameters, pleaseMDHCP09/16/97 consultservers. The selected server responds by sending DHCPACK message directly to the client as in normal DHCPRFC [1].protocol. The multicastaddressesDHCPDICOVER and DHCPREQUEST messages arerenewed or released usingreceived by only the multicast capable DHCPexchanges for network addresses as defined inservers, and therefore, there is no conflict between the MDHCP and DHCPRFC [1]. Note that allmessages. Further, the messagesin thisfor renewing and releasing lease are sent directly to the MDHCP servers only, and therefore, there is conflict between DHCP and MDHCP message interpretation by a non-MDHCP capable server. The fields and options that are different from the normal DHCP message exchange are summarized in Table 1 to 3. For details on rest of the fields, please refer DHCP RFC [1]. The client can later renew or release the multicast address by using DHCPREQUEST and DHCPRELEASE message exchanges as defined in the DHCP RFC [1]. At any time, if the MDHCP server is unable to satisfy the DHCPREQUEST message (e.g., the requested address has been allocated), the server MUST respond with a DHCPNAK message. Note that all the messages in this exchange have their M flag set and B flag not set. In the second method [see Figure 2] the client is requesting address(es) directly from a specific MDHCP server. When a client knows the IP address of the MDHCP server from which it can obtain a multicast address(es) from a give scope, it MAY skip the discover phase ( i.e. DHCPDISCOVER and DHCPOFFER message exchange ) and directly start with unicasting DHCPREQUEST message to the server. If this fails, the client SHOULD revert back to the first method. The MDHCP client may need to be deployed on the client machines where DHCP client implementation is not capable of filtering out the MDHCP messages. In that case, the MDHCP client MUST use a port number different from ‘DHCP client port(68)’. The MDHCP client MUST specify this port in the DHCPDISCOVER and DHCPREQUEST messages via ‘Client Port Option’. The MDHCP Client MUST provide client identifier option when sending messages for multicast address assignment. The client generates a unique key and uses that as a client identifier in the DHCPDISCOVER message. The client identifier is the key to distinguish the client request and to avoid duplicate address allocation. Each client may be running several different multicast enabled applications, and each application may require separate multicast address(es). Client MUST use separate unique client identifier when Patel and Shah 8 MDHCP 11/20/97 requesting separate multicast address(es) for eachapplication.request. A client implementation may choose to use hardware address,hardware type andapplication instancenumberand time of request to generate unique clientidentifier. MDHCP 09/16/97 Field DHCPOFFERidentifiers. The following tables [Table 1, Table 2] describes the fields and options that are relavent to MDHCP protocol but are different from the normal DHCP protocol [1] Field DHCPOFFER DHCPACK DHCPNAK ----- --------- ------- ------- 'flags' Set 'M' Bit. set 'M' Bit set 'M' bit BROADCAST bit 0 BROADCAST bit 0 BROADCAST bit 0 'ciaddr' 'ciaddr' from 'ciaddr' from 0 DHCPDISCOVER or 0 DHCPREQUEST or 0 'yiaddr'StartingMulticast addressof StartingMulticast addressof 0 the multicast block the multicast blockassigned to client assigned to client 'siaddr' Server's IP address Server's IP address 0 reachable from the reachable from the client. client. 'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST message message message 'file' may contain options may contain options (unused) 'options' options options Option DHCPOFFER DHCPACK DHCPNAK ------ --------- ------- ------- IP address lease time MUST MUST(DHCPREQUEST)MUST NOTServer identifierLease Start Time MUST MUST MUSTMulticast TTLNOT Server identifier MUST MUST MUSTNOTMulticastBlock size MAY MAYScope MUSTNOT CookieMUSTMAYMUST NOT Table 1: Fields and options that are different in multicast DHCP server messages. Patel and Shah 9 MDHCP09/16/9711/20/97 Field DHCPDISCOVER DHCPREQUESTDHCPDECLINE,DHCPRELEASE ----- ------------ ----------- ----------- 'flags' Set 'M' Bit. set 'M' Bit set 'M' bit BROADCAST bit 0 BROADCAST bit 0 BROADCAST bit 0 'ciaddr' 0 or client'snetwork0 or client'snetwork0 network addrreachablenetwork addrreachable from the server from the server'chaddr'may contain may contain may contain hardware address hardware address hardware addressignored ignored ignored 'options' options options (unused) Option DHCPDISCOVER DHCPREQUESTDHCPDECLINE,DHCPRELEASE ------ ------------ ----------- -----------Requested IP address MAY MUST (in MUST SELECTING or (DHCPDECLINE), INIT-REBOOT) MUST NOT MUST NOT (in (DHCPRELEASE) BOUND or RENEWING)Starttime MAY MAY MUST NOT Client identifier MUST MUST MAY Table 2: Fields and options that are different in multicast DHCP client messages -------------------------------------------------------------------- | |INIT-REBOOT |SELECTING |RENEWING|REBINDING | -------------------------------------------------------------------- |multi/unicast |multicast |multicast if |unicast |multicast | | | |multicast DISCOVER| | | | | |unicast otherwise | | | |server-ip |MUST NOT |MUST |MUST NOT|MUST NOT | |requested-ip |MUST |MUST |MUST NOT|MUST NOT | |ciaddr |IP addr |IP addr |IP addr |IP address| --------------------------------------------------------------------- Table 3: Client messages from different states MDHCP 09/16/97 3.1. DHCPDISCOVER Message. If the unicast address of a MDHCP server is known and it supports the desired multicast scope, the MDHCP client SHOULD send a DHCPDISCOVER address to the MDHCP server. If the MDHCP server fails to allocate address(es) or fails to respond, the DHCP client SHOULD send a multicast DHCPDISCOVER message to the group address (multicast) of the MDHCP server. In both cases, if the client uses non-standard DHCP port number, it MUST specify the client port option. The client MUST also specify its IP address in the ciaddr field so that the MDHCP server and respond to the client request with a unicast message. The B flag must not be set and M flag MUST be set. The client MUST include client identifier option. In addition, the DHCPDISCOVER option SHOULD include the following options: o DHCP Scope, o Start time, o Lease time (duration) If any of these options are not specified, the DHCP server may assume default values. 3.2. DHCPOFFER Message. The DHCP server may respond to a DHCPDISCOVER message with a unicast DHCPOFFER the client. This message MUST includes an available multicast address using ``yiaddr'' field. The MDHCP server SHOULD reserve the offered address. When allocating the address, the server MUST make every effort to ensure that the address is not in use for the lease period. The server MUST include configuration parameters such as DHCP scope, start and lease time, in the DHCPOFFER message, if different from the ones requested. The MDHCP server must specify a cookie value in this message and this cookie MUST be specified in all the subsequent messages exchanged between the MDHCP clients and server pertaining to associated address(es). The MDHCP server MUST use the cookie to identify the addresses instead of the client IP address. 3.3. DHCPREQUEST The client will select a multicast address(es) from a DHCPOFFER MDHCP 09/16/97 response. The client SHOULD send a unicast DHCPREQUEST message indicating the selected multicast address(es) to the MDHCP server, when the DHCPOFFER was in response to a unicast DHCPDISCOVER message, and using a multicast message, when the DHCPOFFER was in response to a multicast address. It MUST include multicast address option field in the response. If the number of address selected are different from the number of offered address, the client MUST also include the multicast block size option. The M flag MUST be set and B flag MUST NOT be set. 3.4. DHCPACK. If the multicast address(es) are still available, the MDHCP server MUST reserve the address and send a DHCPACK message. Any configuration parameters in the DHCPACK message SHOULD NOT conflict with the ones in earlier DHCPOFFER message. The M flag MUST be set and B flag MUST NOT be set. 3.5. DHCPNACK The server MAY choose to mark the multicast address in DHCPOFFER unavailable to the client. In that case it will send DHCPNACK message. The M flag MUST be set and B flag MUST NOT be set. 3.6. Renewing and termination of lease The client may choose to release address(es) before the lease time has expired. The usual DHCP messages are used for this purpose. The M flag MUST be set and B flag MUST not be set. Moreover, the client port option SHOULD be specified, if the client is using a port different from the standard DHCP port. The cookie MUST be specified with RENEW and RELEASE messages. 4. Examples of usage The MDHCP server is not required to be co-located with a DHCP server. Therefore, in a typical deployment, there may be fewer MDHCP servers then the DHCP servers. We consider specific examples of DHCP configurations and the use of MDHCP protocol extensions. 4.1. One MDHCP server MDHCP 09/16/97 There is one MDHCP server which is configured to allocate multicast addresses to a client and there may be many DHCP servers. The DHCP servers should be configured to provide the address of the MDHCP server capable of allocating multicast address to the MDHCP client, and should include a multicast scope list supported by the MDHCP server. The client may obtain the DHCP server address and scope list through DHCP client configuration procedure (and may use DHCPINFORM message). The client then selects a multicast scope from which the multicast address is to be requested and sends out a unicast DHCPDISCOVER address and includes multicast scope, start time, and lease time information using DHCP options. It may also specify multicast block size. The MDHCP server responds with an DHCPOFFER for multicast address and includes a TTL value to be used with this address. The client sends out a DHCPREQUEST message and includes the selected. If the address is still available, the server responds with an DHCPACK message, else responds with a NACK message. Since the DHCP messages are directly send to the MDHCP server, the server is capable of interpreting M flag and therefore, there will be no conflict between the interpretation of DHCP and MDHCP messages. MDHCP 09/16/97 Client Server (selected) v v | | Obtain IP address | | | | | Begin multicast address request| | | | | |\_____________ | | DHCPDISCOVER \| | | | Determines | address(es) | | | ____________/| | /DHCPOFFER | |/ | | | \| | Selects Address(es) | | | |\_____________ | | DHCPREQUEST \| | | | Commits address(es) | | | _____________/| |/ DHCPACK | | | assignment complete | | | . . . . | | Graceful release | | | |\_____________ | | DHCPRELEASE \| | | | Discards lease | | v v Figure 1: Timeline diagram of messages exchanged between MDHCP client and servers when allocating multicast address(es) using unicast messages to a MDHCP capable server. MDHCP 09/16/97 4.2. One or more MDHCP servers If one or more MDHCP servers are available to a MDHCP client for the purpose of assigning multicast addresses, the DHCP scope list option SHOULD specify an administratively scoped group address used by the MDHCP servers to receive DHCPDISCOVER messages. Each scope in the scope list MUST be supported by at least one server listening to the group multicast address used by MDHCP servers. The client SHOULD select a scope and send out a DHCPDISCOVER, DHCPREQUEST messages to the group multicast address. The multicast DHCPREQUEST message is only received by the MDHCP capable DHCP servers, and therefore, there is no conflict between the MDHCP and DHCP messages. Further, the messages for renewing and releasing lease are sent directly to the MDHCP servers only, and therefore, there is conflict between DHCP and MDHCP message interpretation bytime MAY MAY MUST NOT Client identifier MUST MUST MAY Multicast Scope SHOULD SHOULD MAY Client Port MUST(if using MUST (if using MUST NOT anon-MDHCP capable server. A summary of fields of MDHCP in messagesdifferent a different port) port) Table 2: Fields and options that are differentfrom the corresponding DHCP [1] messages are specifiedinTables 1 to 3. In some cases, the client may be aware of the unicast address of an MDHCP capable server, and may also be aware of the groupmulticastaddress of the MDHCP capable servers. In that case, theDHCP clientSHOULD first try to use the unicast address,messages Patel andif unsuccessful, SHOULD try the group multicast address for MDHCP servers.Shah 10 MDHCP09/16/9711/20/97 Server Client Server (not selected) (selected) v v v | | | | Obtain IP address | | | | |Begin multicast address request| | | | | _____________/|\_____________ | |/ DHCPDISCOVER | DHCPDISCOVER \| | | | Determines | Determines address(es) | address(es) | | | |\ | ____________/| | \_________ | /DHCPOFFER | | DHCPOFFER\ |/ | | \ | | | Collects replies | | \| | | Selects Address(es) | | | | | _____________/|\_____________ | |/ DHCPREQUEST | DHCPREQUEST \| | | | | | Commits address(es) | | | | | _____________/| | |/ DHCPACK | | | | | assignment complete | | | | . . . | | | | Graceful release | | | | | |\_____________ | | | DHCPRELEASE \| | | | | | Discards lease | | | v v v Figure2:1: Timeline diagram of messages exchanged between MDHCP client and serverswhen allocating multicast address(es)using group multicast address for MDHCP capable servers. Patel and Shah 11 MDHCP09/16/97 5.11/20/97 Client Server v v | | |\_____________ | | DHCPREQUEST \| | | | Commits address(es) | | | _____________/| |/ DHCPACK | | | | assignment complete | | . . | | Graceful release | | | |\_____________ | | DHCPRELEASE \| | | | Discards lease | | v v v Figure 2: Timeline diagram of messages exchanged between MDHCP client and servers when MDHCP server has already been selected 4. MDHCP Protocol properties Conflict free address allocation: In the intranet case, each MDHCP serverisMAY be allocated part of the administratively scoped address space. As long as the address space managed by MDHCP servers is non-overlapping for a given administrative scope, the protocol will allocate conflict free addresses. MDHCP protocol does not directly address the mechanisms for determining address allocation outside Intranet. However, we propose to use MDHCP as a front end to any future address allocation protocol for the Internet. TheMDHCPDHCP protocol will preserve conflict free address allocation property of the internet multicast address allocation protocol.Session protocol independence: The MDHCP protocol does not dictate use of the address allocated, and does not rely on any session control protocol. Therefore, it will work with SIP or SAP based session control protocol.Small response time: The response time for MDHCP protocol is strictly based on the network propagation delay and the load on the MDHCP server. The MDHCP protocol does not require a client system to be on all the time. Thus, it poses no additional requirements on power managed systems. Patel and Shah 12 MDHCP 11/20/97 Multicast address scopes: The administratively scoped multicast address may be directly allocated by MDHCP server. However, it is envisioned that the MDHCP protocol will be indirectly used for Internet wide Multicast addresses allocation. In such deployment, the MDHCP server will act as a front-end to future Internet multicast address allocation protocols. Efficient use of address space: The multicast address space may be statically partitioned between MDHCP servers to provide sufficient reliability and load management on servers. However, the multicast based address request will be able to obtain addresses from any of the available servers.Alternately, the MDHCP server can be organized hierarchically where a master server allocates blocks of addresses to the child servers (using MDHCP protocol). It is also possible to provide further fault-tolerance using DHCP server-server protocol. MDHCP 09/16/97 6.5. Security Considerations This document does not explicitly address security considerations to avoid redundant effort with the work in progress in DHC working group of IETF on securing DHCP.7.6. Acknowledgements The authors would like to thank Rajeev Byrisetty, Steve Deering, Peter Ford, Mark Handley, Van Jacobson, David Oran, Thomas Pfenning, Dave Thayler, Ramesh Vyaghrapuri and the participants of IETF for their assistance with this protocol.8.7. References [1] Droms, R., "Dynamic Host Configuration Protocol", RFC1541, October 1993. [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 1533, Lachman Technology, Inc., Bucknell University, October 1993. [3] Patel, B., and Shah, M., ``Multicast address allocation extensions options'' <draft-ietf-dhc-multopt-00.txt> [4] Meyer, D., ``Administratively scoped IP Multicast'', Internet draft, <draft-ietf-mboned-admin-ip-space-01.txt> [5] D. Mills, ``Network Time Protocol version 2 specification and implementation'',9.8. Author's Address Baiju V. Patel Intel Corp. 2111 NE 25th Ave. Hillsboro, OR 97124 Patel and Shah 13 MDHCP 11/20/97 Phone: 503 264 2422 EMail: baiju@mailbox.jf.intel.com Munil Shah Microsoft Corporation One Microsoft Way Redmond, WA 98052Phone:206Phone:425 703 3924 Email:munils@microsoft.com This document will expire onSept, 1997 MDHCP 09/16/97April, 1998 Patel and Shah 14