[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01

MALLOC working group                        Baiju V. Patel, Intel Corp.
Internet Draft                              Munil Shah, Microsoft Corp.
August 1998                    Stephen R. Hanna, Sun Microsystems, Inc.
Expires: February 1999                   draft-ietf-malloc-mdhcp-00.txt

               Multicast address allocation based on the
                  Dynamic Host Configuration Protocol

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 1999. Distribution of this draft is unlimited.

Abstract

   This document defines a protocol, MDHCP, that allows hosts to request
   multicast addresses from multicast address allocation servers. MDHCP
   is similar to DHCP, but not dependent on it.

1. Introduction

   Multicast address allocation based on the Dynamic Host Configuration
   Protocol (MDHCP) is a protocol similar to DHCP ([1], [2]) that allows
   hosts to request multicast address allocation services from multicast
   address allocation servers. This protocol is part of the Multicast
   Address Allocation Architecture defined in [5]. However, it may be
   used separately from the rest of that architecture as appropriate.






Patel, Shah, and Hanna                                          [Page 1]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


1.1. Protocol Overview

   MDHCP is built on a client-server model, where hosts request address
   allocation services from address allocation servers. See Appendix A
   for examples of typical protocol exchanges.

1.2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and"OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

   Throughout the rest of this document, the words "server" or "MDHCP
   server" refer to a host providing multicast address allocation
   services via MDHCP. The words "client" or "MDHCP client" refer to a
   host requesting multicast address allocation services via MDHCP.

1.3. Motivation and Protocol Requirements

   For multicast applications to be deployed everywhere, there is a need
   to define a protocol that any host may use to allocate multicast
   addresses. Here are the requirements for such a protocol.

   Quick response: The host should be able to allocate a multicast
   address and begin to use it promptly.

   Low network load: Hosts that are not allocating or deallocating
   multicast addresses at the present time should not need to send or
   receive any network traffic.

   Support for intermittently connected or power managed systems: Hosts
   should be able to be disconnected from the network, powered off, or
   otherwise inaccessible except during the brief period during which
   they are allocating a multicast address.

   Multicast address scopes: The protocol must be able to allocate both
   the administratively scoped and globally scoped multicast addresses.

   Efficient use of address space: The multicast address space is fairly
   small. The protocol should make efficient use of this scarce
   resource.

   Authentication: Because multicast addresses are scarce, it is
   important to protect against hoarding of these addresses. One way to
   do this is by authenticating clients.

   Policy neutral: Allocation policies (such as who can allocate
   addresses) should not be dictated by the protocol.



Patel, Shah, and Hanna                                          [Page 2]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


1.4. Relationship with DHCP

   In order to allow code reuse, MDHCP is based on a subset of DHCP.
   However, it has been carefully designed to ensure that there are no
   dependencies or interactions between the two protocols. MDHCP may be
   deployed without concern for impacts on existing DHCP servers or
   clients.

   As stated above, MDHCP is based on a subset of DHCP. The message
   format and behavior of the protocols are similar, but there are
   differences. This specification has been designed to stand on its
   own, independent of the DHCP specifications. Implementers of MDHCP do
   not need to read the DHCP specifications, although they may find them
   useful.

   Where there are conflicts between the MDHCP and DHCP specifications
   (and there are several), the MDHCP specifications apply to MDHCP and
   the DHCP specifications apply to DHCP. Remember, the protocols are
   similar but independent.

2. Protocol Description

   The MDHCP protocol is a client-server protocol. In general, the
   client unicasts or multicasts a message to one or more servers, which
   optionally respond with messages unicast to the client.

   Messages are always sent via UDP. A reserved port number dedicated
   for MDHCP is used on the server (to be assigned by IANA). Any port
   number may be used on client machines. When an MDHCP server sends a
   message to an MDHCP client, it MUST use a destination port number
   that matches the source port number provided by the client in the
   message that caused the server to send its message.

   Like DHCP, MDHCP is a mechanism rather than a policy. MDHCP allows
   local system administrators to exercise control over configuration
   parameters where desired. For example, MDHCP servers may be
   configured to limit the number of multicast addresses allocated to a
   single client. Properly enforcing such a limit requires cryptographic
   security, which will be addressed in a supplementary document.

   All MDHCP messages have the same format. This format is identical to
   that of a DHCP message. However, many of the fields are unused. Each
   message includes a message type and a type-length-value encoded
   options field.

   The next few sections describe the MDHCP message format and message
   types. A full list of MDHCP options is provided in section 3.




Patel, Shah, and Hanna                                          [Page 3]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


2.1. Message Format

   The format of an MDHCP message is identical to that of a DHCP
   message. However, many of the fields are unused.

   Figure 1 gives the format of an MDHCP message and Table 1 describes
   each of the fields in the MDHCP message. The numbers in parentheses
   indicate the size of each field in octets. The names for the fields
   given in the figure will be used throughout this document to refer to
   the fields in MDHCP messages.

   Any message whose UDP data is too short to hold this format (at least
   232 bytes) MUST be ignored.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     op (1)    |   htype (1)   |   hlen (1)    |   hops (1)    |
   +---------------+---------------+---------------+---------------+
   |                            xid (4)                            |
   +-------------------------------+-------------------------------+
   |           secs (2)            |           flags (2)           |
   +-------------------------------+-------------------------------+
   |                          ciaddr  (4)                          |
   +---------------------------------------------------------------+
   |                          yiaddr  (4)                          |
   +---------------------------------------------------------------+
   |                          siaddr  (4)                          |
   +---------------------------------------------------------------+
   |                          giaddr  (4)                          |
   +---------------------------------------------------------------+
   |                                                               |
   |                          chaddr  (16)                         |
   |                                                               |
   |                                                               |
   +---------------------------------------------------------------+
   |                                                               |
   |                          sname   (64)                         |
   +---------------------------------------------------------------+
   |                                                               |
   |                          file    (128)                        |
   +---------------------------------------------------------------+
   |                                                               |
   |                          options (variable)                   |
   +---------------------------------------------------------------+

                 Figure 1:  Format of an MDHCP message



Patel, Shah, and Hanna                                          [Page 4]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


   FIELD      OCTETS       DESCRIPTION
   -----      ------       -----------

   op            1  Message op code / message type.
                    1 = BOOTREQUEST, 2 = BOOTREPLY
   htype         1  Should be zero. Ignored.
   hlen          1  Should be zero. Ignored.
   hops          1  Must be zero.
   xid           4  Transaction ID, a random number chosen by the
                    client, used by the client and server to associate
                    messages and responses between a client and a
                    server.
   secs          2  Must be zero.
   flags         2  Must be 64 (decimal).
   ciaddr        4  Must be zero.
   yiaddr        4  First allocated multicast address (must be zero for
                    Messages from clients).
   siaddr        4  Must be zero.
   giaddr        4  Must be zero.
   chaddr       16  Must be zero.
   sname        64  First octet must be zero, rest ignored.
   file        128  First octet must be zero, rest ignored.
   options     var  Optional parameters field.  See section 3
                    for a list of defined options.

           Table 1:  Description of fields in an MDHCP message

2.1.1. MDHCP Message Fields

   All multi-octet quantities are in network byte-order.

   The op field of each MDHCP message sent from a client to a server
   MUST contain BOOTREQUEST (1). BOOTREPLY MUST be used in the op field
   of each MDHCP message sent from a server to a client.

   The htype and hlen fields SHOULD be zero. They SHOULD be ignored by
   MDHCP clients and servers.

   The hops, secs, ciaddr, siaddr, giaddr, and chaddr fields MUST have
   the value zero (0). Messages containing any other value MUST be
   ignored.

   The flags field MUST have the value sixty-four decimal (64). Messages
   containing any other value MUST be ignored.

   The yiaddr field MUST be set to zero (0) by MDHCP clients. Servers
   use this field for returning the first allocated Multicast address,
   as described in section 2.5.



Patel, Shah, and Hanna                                          [Page 5]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


   The sname and file fields are not used. The first octet of these
   fields MUST be zero and the rest MUST be ignored.

2.1.2. The options field

   The first four octets of the 'options' field of an MDHCP message MUST
   have the (decimal) values 99, 130, 83 and 99, respectively. This
   sequence is known as the "magic cookie".

   The remainder of the 'options' field consists of a list of tagged
   parameters that are called "options". Options may be fixed length or
   variable length. All options begin with a tag (or 'code') octet,
   which uniquely identifies the option. Fixed-length options without
   data consist of only a tag octet. Only options 0 and 255 are fixed
   length. All other options are variable-length with a length octet
   following the tag octet. The value of the length octet does not
   include the two octets specifying the tag and length. The length
   octet is followed by "length" octets of data. In the case of some
   variable-length options, the length field is a constant but must
   still be specified. Any options defined subsequent to this document
   MUST contain a length octet even if the length is fixed or zero.

   The option field MUST contain the magic cookie defined above,
   followed by any number of options that are not an end option, and
   ending with an end option (code 255) followed by any number of pad
   options (code 0). Any message whose options field does not conform to
   this syntax MUST be ignored.

   Anyone sending an MDHCP message SHOULD include only options listed in
   section 3, but MAY include other MDHCP options that are defined in
   the future. Anyone receiving an MDHCP message MUST ignore
   unrecognized options. A new MDHCP option may be defined by defining a
   new DHCP option using the process defined in [2] and specifying in
   the Internet Draft or RFC documenting the option that this option
   should be considered an MDHCP option as well. Alternatively, this
   document may be revised or supplemented.

2.2. Message Types

   The "MDHCP message type" option MUST be included in every MDHCP
   message.  This option defines the "type" of the MDHCP message.

   Throughout this document, MDHCP messages that include an 'MDHCP
   message type' option will be referred to by the type of the message;
   e.g., an MDHCP message with 'MDHCP message type' option type 1 will
   be referred to as an "MDHCPDISCOVER" message.

   Here are descriptions of the message types a client may send and the



Patel, Shah, and Hanna                                          [Page 6]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


   way a server should respond. Table 2, which appears at the end of
   this section, summarizes which options are allowed with each message
   type.

2.2.1. MDHCPDISCOVER

   The MDHCPDISCOVER message is used by a MDHCP client that wants to
   discover MDHCP servers that can probably satisfy a request. MDHCP
   clients MAY employ other methods to find MDHCP servers, such as
   caching an IP address that worked in the past or obtaining a DNS name
   or IP address from DHCP or prior configuration. Using the
   MDHCPDISCOVER message has the particular advantage that it allows
   clients to automatically move to another server if one fails.

   The MDHCP client begins by sending a multicast MDHCPDISCOVER message
   to an MDHCP server multicast address. Any servers that wish to assist
   the client respond by sending a unicast MDHCPOFFER message to the
   client. If a server can process the request with a shorter lease time
   or later start time than the client requested, it MAY send an
   MDHCPOFFER message with the lease time that it can offer.

   After a suitable delay, the client selects the server it wants to use
   and moves into the request phase. The time over which the client
   collects messages and the mechanism used to select one MDHCPOFFER are
   implementation dependent. If no MDHCPOFFER messages are received
   after an appropriate delay, the client SHOULD resend its
   MDHCPDISCOVER message.

   For more details about the MDHCP Server Multicast Address, see
   section 2.9.

2.2.2. MDHCPREQUEST

   The MDHCPREQUEST message is used by an MDHCP client that wants to
   allocate or extend the lease of a multicast address.

   The MDHCP client sends out an MDHCPREQUEST message. If this request
   was previously sent as an MDHCPDISCOVER message, the MDHCPREQUEST
   message SHOULD be multicast to the MDHCP server multicast address so
   that all MDHCP servers know which server was selected. Otherwise, the
   MDHCPREQUEST message SHOULD be unicast to the MDHCP server that the
   client wants to use.

   If the selected server can process the request successfully, it
   SHOULD unicast an MDHCPACK message to the client. Otherwise, it
   SHOULD unicast an MDHCPNAK to the client. If a server can process the
   request with a shorter lease time or later start time than the client
   requested, it MAY send an MDHCPACK message with the lease time that



Patel, Shah, and Hanna                                          [Page 7]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


   it can offer.

   If the server responds with an MDHCPNAK or fails to respond within a
   reasonable (implementation-dependent) delay, the client MAY try to
   find another server by sending an MDHCPDISCOVER request with another
   xid.

2.2.3 MDHCPRELEASE

   If a client wants to deallocate a multicast address before its lease
   expires, the client unicasts an MDHCPRELEASE message to the server
   from which it allocated the address. The server does not respond to
   this message.

2.2.2. MDHCPINFORM

   The MDHCPINFORM message is used by an MDHCP client that wants to
   acquire configuration parameters.

   The MDHCP client sends out an MDHCPINFORM message. The message may be
   unicast to a particular MDHCP server or multicast to the MDHCP server
   multicast address.

   If a server receives an MDHCPINFORM message and it can process the
   request successfully, it SHOULD unicast an MDHCPACK message to the
   client. The MDHCPACK message SHOULD include the Multicast Scope List
   option and MAY include the Current Time option. Otherwise, it SHOULD
   ignore the MDHCPINFORM message.

   If no MDHCPACK messages are received after an appropriate delay, the
   client may resend its MDHCPINFORM message to the MDHCP server
   multicast address.

2.2.4. Options Allowed

   Table 2 summarizes which options are allowed with each message type.

   Option                  MDHCPOFFER     MDHCPACK       MDHCPNAK
   ------                  ----------     --------       --------
   Requested IP Address    MUST NOT       MUST NOT       MUST NOT
   IP address lease time   MUST           MUST           MUST NOT
   MDHCP Message Type      MUST           MUST           MUST
   Server Identifier       MUST           MAY            MAY
   Client identifier       MUST           MUST           MUST
   Multicast Scope         MUST           MUST           MUST NOT
   Start Time              MAY            MAY            MUST NOT
   Multicast TTL           MAY            MAY            MUST NOT
   Number of Addresses



Patel, Shah, and Hanna                                          [Page 8]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


     Requested             MAY            MAY            MUST NOT
   Multicast Scope List    MAY            MAY            MUST NOT
   List of Address Ranges
     Allocated             MAY            MAY            MUST NOT
   Current Time            MAY            MAY            MUST NOT

   Option                  MDHCPDISCOVER  MDHCPREQUEST   MDHCPRELEASE
   ------                  ------------   -----------    -----------
   Requested IP Address    MAY            MAY            MUST
   IP address lease time   MAY            MAY            MUST NOT
   MDHCP Message Type      MUST           MUST           MUST
   Server Identifier       MUST NOT       MUST (if       MUST NOT
                                            multicast)
   Client identifier       MUST           MUST           MUST
   Multicast Scope         SHOULD         SHOULD         MUST NOT
   Start Time              MAY            MAY            MUST NOT
   Multicast TTL           MUST NOT       MUST NOT       MUST NOT
   Number of Addresses
     Requested             MAY            MAY            MAY
   Multicast Scope List    MAY            MAY            MUST NOT
   List of Address Ranges
     Allocated             MAY            MAY            MAY
   Current Time            MAY            MAY            MUST NOT

   Option                  MDHCPINFORM
   ------                  ------------
   Requested IP Address    MUST NOT
   IP address lease time   MUST NOT
   MDHCP Message Type      MUST
   Server Identifier       MUST NOT
   Client identifier       MUST
   Multicast Scope         MUST NOT
   Start time              MUST NOT
   Multicast TTL           MUST NOT
   Number of Addresses
     Requested             MUST NOT
   Multicast Scope List    MUST NOT
   List of Address Ranges
     Allocated             MUST NOT
   Current Time            MUST NOT


             Table 2:  Options allowed in MDHCP messages

2.3. Retransmission

   MDHCP clients are responsible for all message retransmission. The
   client MUST adopt a retransmission strategy that incorporates a



Patel, Shah, and Hanna                                          [Page 9]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


   randomized exponential backoff algorithm to determine the delay
   between retransmissions.  The delay between retransmissions SHOULD be
   chosen to allow sufficient time for replies from the server to be
   delivered based on the characteristics of the internetwork between
   the client and the server. For example, in a 10Mb/sec Ethernet
   internetwork, the delay before the first retransmission SHOULD be 4
   seconds randomized by the value of a uniform random number chosen
   from the range -1 to +1. Clients with clocks that provide resolution
   granularity of less than one second may choose a non-integer
   randomization value. The delay before the next retransmission SHOULD
   be 8 seconds randomized by the value of a uniform number chosen from
   the range -1 to +1. The retransmission delay SHOULD be doubled with
   subsequent retransmissions up to a maximum of 64 seconds. The client
   MAY provide an indication of retransmission attempts to the user as
   an indication of the progress of the process. The client MAY halt
   retransmission at any point.

2.4. Associating Client and Server Messages

   Messages between clients and servers are associated with one another
   using the client identifier option and xid field. Each client MUST
   choose a client identifier that is unique within a multicast address
   allocation domain. For each transaction initiated by a client, the
   client MUST generate an xid value that is unique for that client
   identifier and likely to be unique across all client identifiers. For
   instance, a client might start with a random xid and increment from
   there. The client identifier option and xid field MUST be included in
   each message sent by the client or the server.

   The client MUST check the client identifier option and xid field in
   each incoming message to ensure that they match its client identifier
   and an outstanding transaction. If not, the message MUST be
   discarded. The server MUST check the client identifier option and xid
   field in each incoming message to establish the proper context for
   the message. If the message is inappropriate for its context, it
   SHOULD be discarded.

   A transaction can be an attempt to allocate a multicast address
   (consisting of MDHCPDISCOVER, MDHCPOFFER, MDHCPREQUEST, MDHCPACK, and
   MDHCPNAK messages), an attempt to extend a lease (consisting of
   MDHCPREQUEST, MDHCPACK, and MDHCPNAK messages), an attempt to release
   a previously allocated multicast address (consisting of a single
   MDHCPRELEASE message), or an attempt to acquire configuration
   parameters (consisting of MDHCPINFORM and MDHCPACK messages).

2.5. Allocating Multiple Addresses

   An MDHCP client may request the allocation of more than one multicast



Patel, Shah, and Hanna                                         [Page 10]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


   address in a single request by including the Number of Addresses
   Requested option in the MDHCPDISCOVER and MDHCPREQUEST messages. An
   MDHCP server may include this option in an MDHCPOFFER or MDHCPACK
   message to indicate its willingness to supply more than one address.
   Finally, an MDHCP client may include this option in an MDHCPRELEASE
   message to release a set of addresses or in an MDHCPREQUEST message
   to renewing a lease for a set of addresses.

   When the Number of Addresses Requested option is included in an
   MDHCPOFFER or MDHCPACK message, it MUST be accompanied by a List of
   Address Ranges Allocated option listing the address ranges offered or
   allocated. This is in addition to the normal requirement that the
   yiaddr field be set to the first multicast address allocated.

   When the Number of Addresses Requested option is included in an
   MDHCPREQUEST message for the purposes of renewing a lease for a set
   of addresses or in an MDHCPRELEASE message, it MUST be accompanied by
   a List of Address Ranges Allocated option listing the address ranges
   affected. This is in addition to the normal requirement that the
   Requested IP Address option be used to specify the first multicast
   address allocated.

2.6. Multicast Scopes

   RFC 2365 [3] provides for dividing the multicast address space into a
   number of administratively scopes. Routers should be configured so
   that each scope corresponds to a particular partition of the network
   into disjoint regions. Messages sent to a multicast address that
   falls within a certain administrative scope should only be delivered
   to hosts that have joined that multicast group *and* fall within the
   same region as the sender. For instance, packets sent to an address
   in the organization-local scope should only be delivered to hosts
   that have joined that group and fall within the same organization as
   the sender.

   Different sets of scopes may be in effect at different places in the
   network and at different times. Before attempting to allocate an
   address from an administrative scope (other than global or link-
   level scope, which are always in effect), an MDHCP client SHOULD
   determine that the scope is in effect at its location at this time.
   Several techniques that an MDHCP client may use to determine the set
   of administrative scopes in effect (the scope list) are: manual
   configuration, configuration via DHCP or MDHCP (using the Multicast
   Scope List option), or listening to MZAP messages [6].

   When an MDHCP client requests an address, it SHOULD specify the
   administrative scope from which the address should be allocated. This
   scope is indicated with the Multicast Scope option. If no scope is



Patel, Shah, and Hanna                                         [Page 11]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


   specified, the server MAY allocate an address from some default scope
   or refuse to allocate an address. In any case, the server MUST
   include the Multicast Scope option in all MDHCPOFFER and MDHCPACK
   messages.

2.7. Multicast TTL

   Another way to limit propagation of multicast messages is by setting
   the TTL field before sending them. This technique has several
   disadvantages in comparison to administratively scoped multicast
   addresses, but it is currently in widespread usage.

   An MDHCP client MAY request a multicast address for use with a
   specific TTL by including a Multicast TTL option in an MDHCPDISCOVER
   or MDHCPREQUEST message. The server SHOULD respond to this option by
   returning only addresses which support the specified TTL (or
   greater).  If the client does not include this option, the server
   MUST assume that 255 is indicated.

   When sending an MDHCPOFFER or MDHCPACK message with a multicast
   address in it, an MDHCP server MUST indicate the maximum TTL that may
   be used with the address by including a Multicast TTL option. This is
   known as the "maximum TTL" associated with that address.

   When using a multicast address allocated with MDHCP, all hosts SHOULD
   NOT set the TTL field to a number larger than the maximum TTL
   associated with that address.

2.8. Locating MDHCP Servers

   There are several ways for an MDHCP client to locate an MDHCP server.
   For instance, the client may obtain a DNS name or IP address from
   DHCP or manual configuration.

   One particularly convenient technique is for the client to send an
   MDHCPDISCOVER message to an MDHCP Server Multicast Address and wait
   for MDHCPOFFER responses. This technique is described in more detail
   in the next section.

2.9. MDHCP Server Multicast Address

   Each multicast scope has an associated MDHCP Server Multicast
   Address. This address has been reserved by the IANA as the address
   with a relative offset of -1 from the last address of a multicast
   scope.

   An MDHCP client looking for servers that can provide multicast
   allocation services MAY send an MDHCPDISCOVER message to an MDHCP



Patel, Shah, and Hanna                                         [Page 12]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


   Server Multicast Address. Any MDHCP servers listening to this address
   SHOULD respond with a unicast MDHCPOFFER message to the client if
   they wish to offer a response. Clients may also send MDHCPINFORM
   messages in the same manner, with servers responding with MDHCPACK
   messages if they can supply the requested information.

   If a client receives no response to a message sent to an MDHCP Server
   Multicast Address (after retransmission), it MAY send the message to
   a larger scope and repeat this process as necessary. However, the
   client MUST NOT send an MDHCP message to the MDHCP Server Multicast
   Address associated with the global scope.

   The MDHCP Server Multicast Address used by a client for its initial
   message MAY be established by configuration (manually or via DHCP).
   If a client has no such configuration, it SHOULD start with the MDHCP
   Server Multicast Address associated with the smallest scope of which
   it is aware. If a client does not know what the scope list is, it
   should assume that it is IPv4 Local Scope and Global Scope.

   This technique allows MDHCP servers to provide services for scopes in
   which they do not reside. However, such servers MUST make special
   efforts to ensure that their services meet clients' needs for largely
   conflict-free allocation. In particular, AAP traffic does not extend
   outside of the scope that is being managed so coordinating with other
   servers may be difficult. Also, establishing which scope the client
   is in may be difficult. If an MDHCP server is not prepared to provide
   services for scopes in which it does not reside, it SHOULD ignore
   requests whose scope does not match (or is enclosed by) the scope of
   the MDHCP Server Multicast Address on which the request was received.

2.10. Clock Skew

   The Current Time option is used to detect and handle clock skew
   between MDHCP clients and servers. This option SHOULD be included in
   any MDHCP message that includes an absolute time (such as the Start
   Time option). It MAY be included in any MDHCPDISCOVER, MDHCPOFFER,
   MDHCPREQUEST, or MDHCPACK message.

   Clock skew is a situation where two systems have clocks that are not
   synchronized. MDHCP servers SHOULD expect and tolerate a small amount
   of clock skew with their clients (up to an hour) by ensuring that
   multicast addresses are allocated for an extra hour on either side of
   the lease given to the client. However, large amounts of clock skew
   require special handling.

   The Current Time option contains the sender's opinion of the current
   time in UTC at or about the time the message was assembled. Because
   of delays in transmission and processing, this value will rarely



Patel, Shah, and Hanna                                         [Page 13]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


   match the receiver's opinion of the current time at the time the
   option is processed by the receiver.

   If an MDHCP server detects clock skew, it MAY ignore the client or it
   MAY attempt to correct for the clock skew (for instance, by adjusting
   any absolute times in packets sent to or from the client in question
   by the calculated offset). The server MAY log a message.

2.11. Using MDHCP Without Administrative Scoping

   MDHCP can be used in an environment that does not have administrative
   scoping enabled. In such an environment, TTL scoping SHOULD be used.
   The Multicast Scope List option MAY be used to distribute information
   about TTL scopes that are enforced with TTL thresholds. MDHCP clients
   MAY include the Multicast TTL option in MDHCPDISCOVER or MDHCPREQUEST
   packets. MDHCP servers MUST include the Multicast TTL option in
   MDHCPOFFER and MDHCPACK packets when the TTL to be used is less than
   255.

   Multicast MDHCPDISCOVER, MDHCPREQUEST, and MDHCPINFORM packets must
   be carefully managed in a TTL scoped environment to avoid flooding
   them around the world. MDHCP clients MAY be configured (manually or
   via DHCP) with an MDHCP Server Multicast Address and appropriate TTL.
   Alternatively, the MDHCP Server Multicast Address associated with the
   IPv4 Local Scope may be blocked so that packets sent to it are not
   sent outside a certain boundary. In this case, MDHCP clients need not
   be configured manually or via DHCP, since their default behavior in
   choosing an MDHCP Server Multicast Address without configuration is
   to choose the MDHCP Server Multicast Address associated with the IPv4
   Local Scope.

3. MDHCP Options

   The following options are defined for use in MDHCP messages. The
   options are listed in numerical order.

3.1. Pad Option

   The pad option can be used to cause subsequent fields to align on
   word boundaries.

   The code for the pad option is 0, and its length is 1 octet.

    Code
   +-----+
   |  0  |
   +-----+




Patel, Shah, and Hanna                                         [Page 14]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


3.2. Requested IP Address

   This option is used in a client request (MDHCPDISCOVER or
   MDHCPREQUEST) to allow the client to request that a particular
   multicast address be assigned.

   The code for this option is 50, and its length is 4.

    Code   Len          Address
   +-----+-----+-----+-----+-----+-----+
   |  50 |  4  |  a1 |  a2 |  a3 |  a4 |
   +-----+-----+-----+-----+-----+-----+

3.3. IP Address Lease Time

   This option is used in a client request (MDHCPDISCOVER or
   MDHCPREQUEST) to allow the client to request a lease time for the
   multicast address. In a server reply (MDHCPOFFER), an MDHCP server
   uses this option to specify the lease time it is willing to offer.

   The time is in units of seconds, and is specified as a 32-bit
   unsigned integer.

   The code for this option is 51, and its length is 4.

    Code   Len         Lease Time
   +-----+-----+-----+-----+-----+-----+
   |  51 |  4  |  t1 |  t2 |  t3 |  t4 |
   +-----+-----+-----+-----+-----+-----+

3.4. MDHCP Message Type

   This option is used to convey the type of the MDHCP message.  The
   code for this option is 53, and its length is 1.  Legal values for
   this option are:

           Value   Message Type
           -----   ------------
             1     MDHCPDISCOVER
             2     MDHCPOFFER
             3     MDHCPREQUEST
             4     reserved
             5     MDHCPACK
             6     MDHCPNAK
             7     MDHCPRELEASE
             8     MDHCPINFORM





Patel, Shah, and Hanna                                         [Page 15]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


    Code   Len  Type
   +-----+-----+-----+
   |  53 |  1  | 1-8 |
   +-----+-----+-----+

3.5. Server Identifier

   This option is used in MDHCPOFFER and MDHCPREQUEST messages, and may
   optionally be included in the MDHCPACK and MDHCPNAK messages. MDHCP
   servers include this option in the MDHCPOFFER in order to allow the
   client to distinguish between lease offers. MDHCP clients use the
   contents of the 'server identifier' field as the destination address
   for any MDHCP messages unicast to the MDHCP server. MDHCP clients
   also indicate which of several lease offers is being accepted by
   including this option in an MDHCPREQUEST message.

   The identifier is the IP address of the selected server.

   The code for this option is 54, and its length is 4.

    Code  Len            Address
   +-----+-----+-----+-----+-----+-----+
   |  54 |  4  |  a1 |  a2 |  a3 |  a4 |
   +-----+-----+-----+-----+-----+-----+

3.6. Client Identifier

   This option is used by MDHCP clients to specify their unique
   identifier. MDHCP servers use this value to index their database of
   address bindings.  This value is expected to be unique for all
   clients in an administrative domain.

   Identifiers SHOULD be treated as opaque objects by MDHCP servers.

   The client identifier MAY consist of type-value pairs similar to the
   of a hardware type and hardware address. In this case the type field
   SHOULD be one of the ARP hardware types defined in STD2 [8].  A
   hardware type of 0 (zero) should be used when the value field
   contains an identifier other than a hardware address (e.g. a fully
   qualified domain name).

   For correct identification of clients, each client's client-
   identifier MUST be unique among the client-identifiers used on the
   subnet to which the client is attached.  Vendors and system
   administrators are responsible for choosing client-identifiers that
   meet this requirement for uniqueness.

   The code for this option is 61, and its minimum length is 2.



Patel, Shah, and Hanna                                         [Page 16]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


    Code  Len   Type  Client-Identifier
   +-----+-----+-----+-----+-----+---
   |  61 |  n  |  t1 |  i1 |  i2 | ...
   +-----+-----+-----+-----+-----+---

3.7. Multicast Scope

   The multicast scope option is used by the client to indicate the
   multicast scope for the requested multicast address. It is also used
   to indicate the scope of the assigned address by the MDHCP server. If
   this option is not specified, the MDHCP server MAY allocate an
   address from a default scope or reject the request.

            Code  Len      Scope ID
           +-----+-----+-----+-----+-----+-----+
           | 101 | 4   | i1  | i2  | i3  | i4  |
           +-----+-----+-----+-----+-----+-----+

   The client may obtain the scope list through the Multicast Scope List
   option or using some other means. The scope id is the first multicast
   address in the scope.

   The code for this option is 101 and the length is 4.

3.8. Start Time

   The Start Time option is used in a client request (MDHCPDISCOVER or
   MDHCPREQUEST) to allow the client to request the starting time for
   the use of the assigned address. This option allows a client to
   request a multicast address for use at a future time.

            Code  Len      Time
           +-----+-----+-----+-----+-----+-----+
           | 102 | 4   | t1  | t2  | t3  | t4  |
           +-----+-----+-----+-----+-----+-----+

   The time value is an unsigned 32 bit integer in network byte order
   giving the number of seconds since 00:00 UTC, 1st January 1970. This
   is consistent with the time format used in AAP [9] and can be
   converted to an NTP timestamp by adding decimal 2208988800. This time
   format will not wrap until the year 2106.

   If the Start Time option is present, the IP Address Lease Time option
   specifies the duration of the lease beginning at the Start Time
   option value.

   If the Start Time option is present, the Current Time option MUST
   also be present, as described in section 2.10.



Patel, Shah, and Hanna                                         [Page 17]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


   The code for this option is 102 and the length is 4.

3.9. Multicast TTL

   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 | 1   | n   |
           +-----+-----+-----+

   The code for this option is 103 and the length is 1.

3.10. Number of Addresses Requested

   This option specifies the minimum and desired number of addresses
   requested by the client. These values are unsigned 16 bit integers
   stored in network byte order. The minimum MUST be less than or equal
   to the desired number. If a packet is received where this is not the
   case, the desired value MUST be used for both.

   The client MAY obtain more than one address either by repeating the
   protocol for every address or by requesting several addresses at the
   same time via this option. When the client is requesting only one
   address, this option SHOULD not be included. An MDHCP server
   receiving an MDHCPDISCOVER or MDHCPREQUEST packet including this
   option MUST include between minimum and desired number of addresses
   in any MDHCPOFFER or MDHCPACK response.

   The server MAY use this option to indicate to the client the number
   of addresses it has allocated to the client. In this case, the
   minimum and desired values MUST be equal.

            Code  Len    Minimum     Desired
           +-----+-----+-----+-----+-----+-----+
           | 104 | 4   | min       | desired   |
           +-----+-----+-----+-----+-----+-----+

   The code for this option is 104 and the length is 4.

3.11. Multicast Scope List

   The format of the multicast scope list option is:






Patel, Shah, and Hanna                                         [Page 18]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


         Code  Len   Count  List
        +-----+-----+-----+-----+-...-+-----+
        | 107 | n   | m   | L1  |     | Lm  |
        +-----+-----+-----+-----+-...-+-----+

   The scope list is a list of m tuples, where each tuple is of the
   form,

        Scope ID ( 4 Bytes )    Last Address (4 Bytes )
       +-----+-----+-----+-----+-----+-----+-----+-----+
       | ID1 | ID2 | ID3 | ID4 | E1  | E2  | E3  | E4  |
       +-----+-----+-----+-----+-----+-----+-----+-----+

        TTL   Desc  Scope Description
               Len
       +-----+-----+-----+-...-+-----+
       | T   | n   | d1  |     | dn  |
       +-----+-----+-----+-...-+-----+

   where scope ID is the first multicast address in the scope, Last
   Address is the last multicast address in the scope, TTL is the
   multicast TTL value for the multicast addresses of the scope, Scope
   Description is a UTF-8 [10] string describing the scope, and Desc Len
   is the length of the scope description in octets. The scope IDs of
   entries in the list SHOULD be unique and the scopes SHOULD be listed
   from smallest to largest.

   The code for this option is 107.

   Example:

   There are two scopes supported by the multicast address allocation
   server: Inside abcd.com with addresses 239.192.0.0-239.195.255.255,
   and world with addresses 224.0.1.0-238.255.255.255. Then this option
   will be given as:

         Code  Len   Count
        +-----+-----+-----+...
        | 107 | 41  | 2   |
        +-----+-----+-----+...

           Scope ID     Last Address    TTL Len Desc
       +---+---+---+---+---+---+---+---+---+---+--+--+-...-+--+--+
       |239|192| 0 | 0 |239|195|255|255|10 |15 | Inside abcd.com |
       +---+---+---+---+---+---+---+---+---+---+--+--+-...-+--+--+
       |224| 0 | 1 | 0 |238|255|255|255|16 |5  | world           |
       +---+---+---+---+---+---+---+---+---+---+--+--+-...-+--+--+




Patel, Shah, and Hanna                                         [Page 19]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


3.12. List of Address Ranges Allocated

   This option is used by the server to provide the list of all the
   address ranges allocated to the client when the client requests more
   than one address. When a client requests only one address, the server
   uses the 'yiaddr' field to specify the allocated address. When a
   client requests more than one address, additional address ranges are
   listed via this option.

   This option is also used by the client when requesting a lease
   extension for more than one address or releasing more than one
   address.

            Code  Len     Address Range List
           +-----+-----+-----+-----+-...-+-----+
           | TBD | n   | L1  | L2  |     | Ln  |
           +-----+-----+-----+-----+-----+-----+
            where the Address Range List is of the following 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.13. Current Time

   The current time may be used to express what the sender thinks the
   current time is. This option may be used to detect clock skew and
   MUST be used if the Start Time option is used, as described in
   section 2.10.

            Code  Len      Time
           +-----+-----+-----+-----+-----+-----+
           | TBD | 4   | t1  | t2  | t3  | t4  |
           +-----+-----+-----+-----+-----+-----+

   The time value is an unsigned 32 bit integer in network byte order
   giving the number of seconds since 00:00 UTC, 1st January 1970. This
   is consistent with the time format used in AAP [9] and can be
   converted to an NTP [4] timestamp by adding decimal 2208988800. This
   time format will not wrap until the year 2106.

   The code for this option is TBD and the length is 4.

3.14. End Option




Patel, Shah, and Hanna                                         [Page 20]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


   The end option marks the end of valid information in the vendor
   field. Subsequent octets should be filled with pad options.

   The code for this option is 255, and the length is 1.

    Code
   +-----+
   | 255 |
   +-----+

4. Open Issues and Action Items

   Do we want to support MDHCP servers that provide services for scopes
   that they are not in? The current spec attempts to do so.

   How should an MDHCP client determine which MDHCP Server Multicast
   Addresses to send requests to and how should an MDHCP server
   determine which MDHCP Server Multicast Addresses to listen to? The
   current spec describes one technique, but others may be more
   appropriate.

   How should an MDHCP server deal with clock skew? The current spec
   describes one technique, but others may be more appropriate.

   Is it possible to figure out which scopes are larger or smaller than
   others, based on MZAP messages? If so, it would be nice to say the
   Multicast Scope List SHOULD be ordered from smallest to largest. If
   not, it will be hard for clients to decide on an ordered list of
   MDHCP Server Multicast Addresses to send to and hard for a server to
   determine whether a request came from an MDHCP Server Multicast
   Address associated with a scope larger than that of the request.

   Decide how to deal with language issues. We should probably have a
   way for the client to specify which language it would prefer to
   receive and a way for the server to specify which language it is
   sending. This applies to scope descriptions and would allow the
   client to say "Give me scope descriptions in German, please", for
   instance. If draft-whistler-plane14-00.txt goes through, we can use
   that. Or we can use RFC 1766 language tags. See RFC 2277 for more
   info.

   Get DHCP option codes assigned to the Current Time and List of
   Address Ranges Allocated options. Also, give back the option codes
   assigned to the Client Port option and change the name of the old
   Multicast Block option to Number of Addresses Requested.

   Reserve a UDP port number for MDHCP.




Patel, Shah, and Hanna                                         [Page 21]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


   Should we add a section describing the possible operations in more
   detail? This might allow us to remove some text from the section
   describing message types, while providing more specific descriptions
   for how each of the messages are intended to be used and under what
   circumstances different options are required.

5. Security Considerations

   There are several security risks associated with multicast address
   allocation.

   First, multicast addresses are a scarce commodity. Therefore, it may
   be desirable or necessary to provide access controls on allocation
   services. Enforcing such controls requires client authentication with
   replay prevention.

   Second, there are many possibilities for denial of service.
   Allocating excessive numbers of addresses may be addressed by
   providing access controls as described above. Deallocating or
   modifying other clients' addresses may be handled in a similar way.
   Installing a false server can be addressed by requiring clients to
   authenticate servers.

   Third, information about who has allocated what may disclose
   confidential information and may be useful in other attacks such as
   sending extra data to your enemies' multicast groups. Providing
   confidentiality via encryption addresses those problems somewhat,
   although traffic analysis is still possible.

   There are already efforts underway in the DHC Working Group that
   should be helpful with these problems. The authors are monitoring
   this work and hope to apply the solutions developed there in this
   context.

6. Acknowledgments

   The authors would like to thank Rajeev Byrisetty, Steve Deering,
   Peter Ford, Mark Handley, Van Jacobson, David Oran, Thomas Pfenning,
   Dave Thaler, Ramesh Vyaghrapuri and the participants of the IETF for
   their assistance with this protocol.

   Much of the text in this document is based on or copied from [1] and
   [2]. The authors of this document would like to express their
   gratitude to the authors of these previous works. Any errors in this
   document are solely the fault of the authors of this document.

7. References




Patel, Shah, and Hanna                                         [Page 22]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


   [1]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
        March 1997.

   [2]  Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
        Extensions", RFC 2132, March 1997.

   [3]  Meyer, D., "Administratively Scoped IP Multicast", RFC 2365,
        July 1998.

   [4]  Mills, D., "Network Time Protocol (Version 3) Specification,
        Implementation and Analysis", RFC 1305, March 1992.

   [5]  Handley, M., D. Thaler, and D. Estrin, "The Internet Multicast
        Address Allocation Architecture", Internet Draft, draft-handley-
        malloc-arch-00.txt, December 1997.

   [6]  Handley, M., "Multicast-Scope Zone Announcement Protocol
        (MZAP)", Internet Draft, draft-ietf-mboned-mzap-00.txt, December
        1997.

   [7]  Croft, W., and J. Gilmore, "Bootstrap Protocol", RFC 951,
        Stanford University and Sun Microsystems, September 1985.

   [8]  Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
        1700, USC/Information Sciences Institute, July 1992.

   [9]  Handley, M., "Multicast Address Allocation Protocol (AAP)",
        Internet Draft, draft-handley-aap-00.txt, December 1997.

   [10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
        2279, January 1998.

8. Authors' Addresses

      Baiju V. Patel
      Intel Corp.
      2111 NE 25th Ave.
      Hillsboro, OR 97124

      Phone: 503 264 2422
      EMail: baiju.v.patel@intel.com

      Munil Shah
      Microsoft Corporation
      One Microsoft Way
      Redmond, WA 98052

      Phone: 425 703 3924



Patel, Shah, and Hanna                                         [Page 23]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


      Email: munils@microsoft.com

      Stephen R. Hanna
      Sun Microsystems, Inc.
      2 Elizabeth Drive, M/S UCHL03-205
      Chelmsford, MA 01824

      Phone: +1.978.442.0166
      Email: steve.hanna@sun.com

APPENDIX A: Examples

   This appendix includes several examples of typical MDHCP protocol
   exchanges.

1. Unicast Address Allocation

   In this example, an MDHCP client wants to allocate a multicast
   address from the global scope for use during the next two hours. It
   knows (through prior configuration or communication) the scopes that
   are in effect at its location and the unicast address of an MDHCP
   server that provides allocation services for the global scope.

   The client begins by unicasting an MDHCPREQUEST packet to the server.
   This packet includes the IP Address Lease Time, MDHCP Message Type,
   Client Identifier, and Multicast Scope options.

   The server responds with an MDHCPACK packet containing the requested
   address. The address is stored in the yiaddr field. This packet
   includes the IP Address Lease Time, MDHCP Message Type, Client
   Identifier, and Multicast Scope options.

   At this time, the client is said to have a two hour "lease" on the
   multicast address, indicating that (with high likelihood) this
   address will not be allocated to any other clients in the same scope
   for use during this period. The client may then proceed to distribute
   the address to others and conduct a multicast session on the address.

   If the client had not received a response from the server, it would
   probably have retransmitted its MDHCPREQUEST packet for a while. If
   it still received no response, it could try another server or move to
   multicast discovery with the MDHCPDISCOVER message.

   The following figure illustrates this exchange.







Patel, Shah, and Hanna                                         [Page 24]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


                   Client          Server
                     v               v
                     |               |
                     |\_____________ |
                     | MDHCPREQUEST \|
                     |               |
                     |        Commits address
                     |               |
                     | _____________/|
                     |/ MDHCPACK     |
                     |               |
                     |               |
                     v               v

        Figure 2: Timeline diagram of messages exchanged
                  in Unicast Address Allocation example

2. Lease Extension

   This is a continuation of the previous example. The client has
   already allocated a multicast address from the global scope for use
   during the next two hours. Half way through this two hour period, it
   decides that it wants to extend its lease for another hour.

   The client unicasts an MDHCPREQUEST packet to the server from which
   it allocated the address. This packet includes the Requested IP
   Address, IP Address Lease Time, MDHCP Message Type, and Client
   Identifier options. The time included in the IP Address Lease Time is
   two hours, since the client wants the lease to expire two hours from
   the current time.

   The server responds with an MDHCPACK packet indicating that the lease
   extension has been granted. The address is stored in the yiaddr
   field. This packet includes the IP Address Lease Time, MDHCP Message
   Type, Client Identifier, and Multicast Scope options.

   If the server did not want to grant the requested lease extension, it
   would have responded with an MDHCPACK packet with the remaining lease
   time indicated in the IP Address Lease Time option. It would *not*
   send an MDHCPNAK packet, since that would cancel the lease
   immediately.

   The following figure illustrates this exchange.








Patel, Shah, and Hanna                                         [Page 25]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


                   Client          Server
                     v               v
                     |               |
                     |\_____________ |
                     | MDHCPREQUEST \|
                     |               |
                     |        Extends lease
                     |               |
                     | _____________/|
                     |/ MDHCPACK     |
                     |               |
                     |               |
                     v               v

        Figure 3: Timeline diagram of messages exchanged
                  in Lease Extension example

3. Address Release

   This is a continuation of the previous example. The client has
   already allocated a multicast address and extended its lease for
   another two hours. Half an hour later, the client finishes its use of
   the multicast address and wants to release it so it can be reused.

   The client unicasts an MDHCPRELEASE packet to the server from which
   it allocated the address. This packet includes the Requested IP
   Address, MDHCP Message Type, and Client Identifier options. When the
   server receives this packet, it cancels the client's lease on the
   address.

   Since the server does not acknowledge the MDHCPRELEASE packet, there
   is no provision for the client retransmitting it. However, this is
   not very harmful. If an MDHCPRELEASE packet is lost, the server will
   keep the multicast address reserved for the client's use until the
   end of its lease. At that point, the address will once again be
   available for use by others.

   The following figure illustrates this exchange.













Patel, Shah, and Hanna                                         [Page 26]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


                   Client          Server
                     v               v
                     |               |
                     |\_____________ |
                     | MDHCPRELEASE \|
                     |               |
                     |        Cancels lease
                     |               |
                     v               v

        Figure 4: Timeline diagram of messages exchanged
                  in Address Release example

4. Multicast Discovery and Address Allocation

   Let's revisit the first example, but say that the MDHCP client did
   not know the unicast address of the MDHCP server that it wanted to
   use.

   The client begins by multicasting an MDHCPDISCOVER packet to an MDHCP
   Server Multicast Address. This packet includes the IP Address Lease
   Time, MDHCP Message Type, Client Identifier, and Multicast Scope
   options.

   Any servers that receive the MDHCPDISCOVER packet and can satisfy
   this request temporarily reserve an address for the client and
   unicast an MDHCPOFFER packet to the client. These packets contain the
   IP Address Lease Time, MDHCP Message Type, Server Identifier, Client
   Identifier, and Multicast Scope options. The reserved address is also
   stored in the yiaddr field.

   After a suitable delay, the client multicasts an MDHCPREQUEST packet
   to the MDHCP Server Multicast Address. This packet contains all of
   the options included in the MDHCPDISCOVER packet, but also includes
   the Server Identifier option, indicating which server it has selected
   for the request.

   The server whose Server Identifier matches the one specified by the
   client responds with an MDHCPACK packet containing the same
   information as the MDHCPOFFER packet. All the other servers that had
   sent MDHCPOFFER packets stop reserving an address for the client and
   forget about the whole exchange.

   The client now has a two hour "lease" on the multicast address, just
   like it did in the first example.

   If the client had not received a response from the server, it would
   have retransmitted its MDHCPREQUEST packet for a while. If it still



Patel, Shah, and Hanna                                         [Page 27]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


   received no response, it could try another server or return to
   multicast discovery with a new MDHCPDISCOVER message.

   The following figure illustrates this exchange.

                   Server          Client          Server
               (not selected)                    (selected)
                     v               v               v
                     |               |               |
                     |Begin multicast address request|
                     |               |               |
                     | _____________/|\_____________ |
                     |/MDHCPDISCOVER | MDHCPDISCOVER\|
                     |               |               |
                 Reserves            |           Reserves
                 Address             |           Address
                     |               |               |
                     |\              |  ____________/|
                     | \_________    | /MDHCPOFFER   |
                     | MDHCPOFFER\   |/              |
                     |            \  |               |
                     |       Collects replies        |
                     |              \|               |
                     |     Selects Address           |
                     |               |               |
                     | _____________/|\_____________ |
                     |/ MDHCPREQUEST | MDHCPREQUEST \|
                     |               |               |
                     |               |     Commits address
                     |               |               |
                     |               | _____________/|
                     |               |/ MDHCPACK     |
                     |               |               |
                     | assignment complete           |
                     |               |               |
                     v               v               v

        Figure 5: Timeline diagram of messages exchanged
                  in Multicast Discovery and Address Allocation example

APPENDIX B: Change Log

   CHANGES FROM draft-ietf-dhc-mdhcp-03.txt

   Many changes to make this document no longer dependent on the DHCP
   spec. This should make the document easier to read and understand.

   Removed MDHCPDECLINE.



Patel, Shah, and Hanna                                         [Page 28]


Internet Draft       draft-ietf-malloc-mdhcp-00.txt          August 1998


   Added Current Time option to deal with clock skew.

   Scopes are now identified by the first multicast address in the scope
   instead of using a scope ID.

   Changed Total Addresses Requested option to Number of Addresses
   Requested. Changed this option to have minimum and desired fields.

   Clarified that servers MAY send MDHCPOFFER or MDHCPACK messages with
   shorter lifetimes or later start times than those requested by the
   client. This is consistent with DHCP and provides a simple way to
   achieve the minimum/maximum lifetime functionality described in the
   malloc abstract API.






































Patel, Shah, and Hanna                                         [Page 29]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/