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

Versions: 00 01 02 03

   Dynamic Host Configuration working group            Baiju V. Patel,
   Internet Draft                                      Intel Corp,
                                                       Munil Shah
                                                       Microsoft Corp.
   September 16, 1997
  
  
  
             Multicast address allocation extensions to the
                  Dynamic Host Configuration Protocol
                     <draft-ietf-dhc-mdhcp-02.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 server allocate
   multicast addresses and deliver parameters associated with the                                MDHCP                    09/16/97
  
  
   address to dynamically configured hosts.  Throughout the remainder
   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
   simply extensions 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/97
  
  
        This 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 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 host using DHCP to obtain
        configuration parameters such as a network address.
  
      o "DHCP server"
  
        A DHCP server is an Internet host that returns 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/97
  
  
        A 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 to the
   applications. 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 applications are 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 existing and future 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: The application should not have to wait for a
   long time before it can be sure that it can use a multicast
   address. The response time should be 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. It should be designed to impose minimal load on
   the network. In particular, it should not require periodic
   broadcast/multicast messages from every application. Specifically,                                MDHCP                    09/16/97
  
  
   the 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 system
   may suspend or turn off for some time. The system may come back to
   full power just before the application starts multicasting
   traffic.
  
   Multicast address scopes: The protocol must be able to
  
   allocate both the administratively scoped addresses and global
   addresses.
  
   Efficient use of address space: The multicast address space is
   smaller then IP address space. Moreover, a host or application may
   require multiple address. Therefore, efficient use of address space
   is a design goad of multicast address allocation protocol.
  
  
  
  1.4.  MHDCP Protocol Summary
  
   From the client's point of view, MDHCP is an extension of the DHCP
   mechanisms. The MDHCP servers assigns multicast addresses to the
   hosts to be used within a specific scope, and valid for 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 for a specific lease
   period. The MDHCP 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. The DHCP server MUST provide a TTL
   value. The multicast packets using the assigned address MUST NOT
   use a TTL value larger then 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 same addresses to
  
   different clients with overlapping lease period.  The multicast
   scope list is one of the DHCP configuration parameters.
  
   The scope list may be obtained through the DHCP option described in
   [3], or may be obtained with some other means. Similarly, the MDHCP
   server address (unicast or multicast) may also be obtained by the
   option described in [3] or by some other means.                                MDHCP                    09/16/97
  
  
  
   The MDHCP protocol uses M flag and a set of options defined below.
  
  
  
   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 multicast address. 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 3 4 5
  
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                | code          | length=4      |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                | Scope id                      |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                | Scope id                      |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  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 is 101.
  
  
  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
  
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                | code          | length=4      |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                | 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 is 102.
  
   If IP Address Lease Time option specifies the duration of the lease
   beginning at Start Time option value.                                MDHCP                    09/16/97
  
  
  2.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.
  
                                     1 1 1 1 1 1
                 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
                | code          | length=1      |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                | TTL           |
                +-+-+-+-+-+-+-+-+
  
   The 'code' for this option is 103.
  
  
  
  2.5.  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.
  
                 0 1 2 3 4 5 6 7
                +-+-+-+-+-+-+-+-+
                | code          |
                +-+-+-+-+-+-+-+-+
  
  
   The 'code' for this option is 105.
  
  
  
   3.   MDHP protocol
  
  
   The client needs to obtain the IP address of the MDHCP server (this
   may be a unicast or a multicast address for MDHCP group), and the
   multicast scope list. This list may be obtained as part of the
   normal DHCP protocol using the options specified in [3] or by some
   other means.
  
   The client selects one of multicast scopes and requests multicast
   address(es) from the MDHCP servers.  The fields and options that
  
   are different from the normal DHCP message exchange are summarized
   in Table 1 to 3.  details on rest of the parameters, please                                MDHCP                    09/16/97
  
  
   consult DHCP RFC [1].  The multicast addresses are renewed or
   released using the DHCP exchanges for network addresses as defined
   in the DHCP RFC [1].
  
  
   Note that all the messages in this exchange have their M flag set
   and B flag not set.
  
   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.
  
  
   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
   requesting separate multicast address(es) for each application.
  
   A client implementation may choose to use hardware address, hardware
  
   type and application instance number to generate unique client
   identifier.                                MDHCP                    09/16/97
  
  
  
  
  
  
  Field      DHCPOFFER            DHCPACK             DHCPNAK
  -----      ---------            -------             -------
  'ciaddr'   'ciaddr' from        'ciaddr' from       0
             DHCPDISCOVER or 0    DHCPREQUEST or 0
  'yiaddr'   Starting address of  Starting address of 0
             the multicast block  the multicast block
             assigned 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 NOT
  Server identifier         MUST         MUST               MUST
  Multicast TTL             MUST         MUST               MUST NOT
  
  Multicast Block size      MAY          MAY                MUST NOT
  Cookie                    MUST         MAY                MUST NOT
  
           Table 1:  Fields and options that are different in
                        multicast DHCP server messages.                                MDHCP                    09/16/97
  
  
  
  
     Field      DHCPDISCOVER      DHCPREQUEST           DHCPDECLINE,
  
                                                        DHCPRELEASE
     -----      ------------      -----------           -----------
     'flags'    Set 'M' Bit.      set 'M' Bit           set 'M' bit
                BROADCAST bit 0   BROADCAST bit 0       BROADCAST bit 0
     'ciaddr'   client's network  client's network      0
                addr reachable    addr reachable
                from the server   from the server
     'chaddr'   may contain       may contain           may contain
  
                hardware address  hardware address     hardware address
     'options'  options           options               (unused)
  
     Option                     DHCPDISCOVER  DHCPREQUEST  DHCPDECLINE,
                                                            DHCPRELEASE
     ------                     ------------  -----------   -----------
     Requested IP address       MAY           MUST (in      MUST
  
                                              SELECTING or (DHCPDECLINE),
                                              INIT-REBOOT)  MUST NOT
                                              MUST NOT (in  (DHCPRELEASE)
                                              BOUND or
                                              RENEWING)
     Start time                 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 by
   a non-MDHCP capable server.
  
  
   A summary of fields of MDHCP in messages that are different from
   the corresponding DHCP [1] messages are specified in Tables 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 group multicast
   address of the MDHCP capable servers. In that case, the client
   SHOULD first try to use the unicast address, and if unsuccessful,
   SHOULD try the group multicast address for MDHCP servers.                                MDHCP                    09/16/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
     Figure 2: Timeline diagram of messages exchanged between MDHCP
               client and servers when allocating multicast
               address(es) using group multicast address for MDHCP
               capable servers.                                MDHCP                    09/16/97
  
  
   5.   MDHCP Protocol properties
  
  
   Conflict free address allocation: In the intranet case, each MDHCP
   server is 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. The MDHCP 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.
  
   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.   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.   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.   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.   Author's Address
  
   Baiju V. Patel
   Intel Corp.
  
   2111 NE 25th Ave.
   Hillsboro, OR 97124
  
   Phone: 503 264 2422
   EMail: baiju@mailbox.jf.intel.com
  
   Munil Shah
  
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052
  
   Phone:206 703 3924
   Email:munils@microsoft.com
  
   This document will expire on Sept, 1997                                MDHCP                    09/16/97
  

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