[Search] [txt|pdfized|bibtex] [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.
   November 20, 1997
             Multicast address allocation extensions to 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
   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.
   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 allocates
   multicast addresses and delivers parameters associated with the
   address to dynamically configured hosts.  Throughout the remainder
   Patel and Shah                                                    1
                                MDHCP                    11/20/97
   of this document, the term "server" refers to a host providing
   multicast address(es) and parameters through DHCP, and the term
   "client" refers to a host requesting multicast address(es) and
   parameters from a DHCP server. MDHCP server is used at times, to
   indicate a DHCP server capable of handling MDHCP extensions to the
   DHCP protocol and the MDHCP client is used to indicate the MDHCP
   capable DHCP client. MDHCP is not a separate protocol, but is
   simply an extension to the DHCP protocol.
   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"
           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
    Patel and Shah                                               2
                                MDHCP                    11/20/97
           be understood and the case carefully weighed before
           implementing any behavior described with this label.
         o "MAY"
           This word or the adjective "OPTIONAL" means that this item
           is truly optional.  One vendor may choose to include the
           item because a particular marketplace requires it or because
           it enhances the product, for example; another vendor may
           omit the same item.
  1.2. Terminology
      This document uses the following terms[1]:
         o "DHCP client"
           A DHCP client is an Internet host that obtains configuration
           parameters (e.g.,  network address) using DHCP protocol
         o "DHCP server"
           A DHCP server is an Internet host that provides
           configuration parameters to DHCP clients.
         o "MDHCP client"
           A MDHCP client is a DHCP client that supports MDHCP
         o "MDHCP server"
           A MDHCP server is a DHCP server that supports MDHCP
  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 an
  application. Following are the set of requirements on such a
  Conflict Free Allocation: When two applications obtain a multicast
  address (using a common multicast address allocation protocol), both
  applications may be allocated identical addresses only if it can be
  guaranteed that no hosts will receive multicasts using same address
  from both the applications on the same network interface provided
  that the multicast scoping is implemented correctly.
    Patel and Shah                                               3
                                MDHCP                    11/20/97
   Quick response: The application should not have to wait for a long
   time before it able to determine if it can use a multicast address.
   The response time should primarily be a function of network and
   system delays only and should not be in the order of several
   Low network load: The multicast address allocation protocol is a
   control protocol. Therefore, it should impose minimal load on the
   network. Specifically, the address allocation protocol should not
   overload a modem line when used by a dial-in user.
   Work with power managed systems: System may be in on, off or low
   power state between the address allocation and usage period.
   Multicast address scopes: The protocol must be able to allocate both
   the administratively scoped 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 addresses. Therefore, efficient use of address
   space is a design goal of multicast address allocation protocol.
  1.4. MHDCP Protocol Summary
   From the protocol standpoint, MDHCP is an extension of the DHCP. As
   in normal DHCP protocol, a MDHCP client requests multicast
   address(es) from the MDHCP server for a specified multicast scope.
   The MDHCP servers assigns multicast address(es) to the hosts to be
   used within the requested scope, and valid over a specific period.
   The DHCP server MUST provide TTL value of the address. The client,
   when using the assigned address should not use the TTL value larger
   than the one provided.  The lease period is defined by the duration
   of the lease and the time at which the lease becomes effective. The
   DHCP server MUST NOT allocate the same address to different clients
   with overlapping lease period and scope. The protocol also allows
   client to request more than one address at a time.
   Before requesting a multicast address, a client needs to obtain the
   list of multicast scopes available on the MDHCP server. The
   multicast scope-list is one of the MDHCP configuration parameters.
   The scope list may be obtained through the DHCP option described in
   [3], or may be obtained by some other means. Similarly, the MDHCP
   server address (multicast) may also be obtained by the option
   described in [3] or can be configured on the client.
   The MDHCP server is not required to be co-located with a DHCP
   server. Therefore, in a typical deployment, there may be fewer MDHCP
   servers then the DHCP servers.
   The MDHCP protocol uses M flag and a set of options defined below.
    Patel and Shah                                               4
                                MDHCP                    11/20/97
   2.  MDHCP messages and options.
   The following options and flags are used by MDHCP extensions.
  2.1. M flag
   A new flag (M) is defined to differentiate the MDHCP messages from
   DHCP messages.  All the messages (DHCPDISCOVER, DHCPOFFER etc.) use
   M flag 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(es). It is also used to indicate
   the scope of the assigned address by the DHCP server. If this option
   is not specified, the DHCP server MAY allocate an address from a
   DEFAULT scope or reject the request.
         Code  Len      Scope Id
        | 101 | 4   | i1  | i2  | i3  | i4  |
   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 and the length is 4.
    Patel and Shah                                               5
                                MDHCP                    11/20/97
  2.3. Start time Option
   The start time is used in a client request (DHCPDISCOVER or
   DHCPREQUEST) to allow the client to request the starting time for
   the use of the assigned address. This option allows client to
   request a multicast address for use at a future time.
         Code  Len      Time
        | 102 | 8   | t1  | t2  | t3  | t4  | t5  | t6  | t7  | t8  |
   The time value is the decimal representation of Network Time
   Protocol (NTP) time values in seconds [5].
   The 'code' for this option is 102 and the length is 8.
   If IP Address Lease Time option specifies [2] the duration of the
   lease beginning at Start Time option value.
  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. 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.
  2.5. Number of Addresses Requested Option
   This option specifies the number of addresses requested by the
   client. The client MAY obtain more than one address either by
   repeating the protocol for every address or by requesting all the
   addresses at the same time via this option. The server MAY use this
   option to indicate to the client the number of addresses it has
   allocated to the client. When the client is requesting only one
   address, this option need not be included.
         Code  Len    Number of Addresses
        | 104 | 2   | n         |
   The 'code' for this option is 104 and the length is 2.
    Patel and Shah                                               6
                                MDHCP                    11/20/97
  2.6. Client Port Option
  In order to facilitate implementations outside the operating system
  kernel, and to allow two separate client implementations: one for
  DHCP and one for MDHCP, if this option is specified, the MDHCP server
  MUST use the source port number used in the DHCPDISCOVER,
  DHCPREQUEST, DHCPINFORM, and DHCPRESEASE as the destination port
  number in the response messages.
         Code  Len    Port
        | 105 | 1   | n   |
   The 'code' for this option is 105 and the length is 1.
  2.7. 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 client requests more than
  one addresses. When a client requests only one address, the server
  uses the ‘yiaddr’ field specify the allocated address. When a client
  requests more than one address, additional address ranges are listed
  via this option.
         Code  Len     Address Range List
        | 105 | n   | L1  | L2  |     | Ln  |
   Where the Address Range List is of the follwing format.
        StartAddress1  BlockSize1 StartAddress2 BlockSize2 ...
        |S11|S12|S13|S14|B11|B12|S21|S22|S23|S24|B21|B22|       |
   The 'code' for this option is TBD and the minimum length is 6.
  3. MDHP protocol
   The client first needs to know the group multicast address of the
   MDHCP servers, and the multicast scope list. This address and the
   scope list may be obtained by requesting the options specified in
   [3] from DHCP servers via DHCPINFORM or from other repository of
   network configurations.
   At this point, client has two ways of obtaining the multicast
   address(es) from the server.
    Patel and Shah                                               7
                                MDHCP                    11/20/97
   In the first method [see Figure 1], the client is requesting
   address(es) from any of the MDHCP servers configured to hand out
   addresses from a given scope. The client selects a scope and sends
   message to the multicast address of the MDHCP servers. The server
   responds by sending DHCPOFFER message directly to the client. The
   client then sends DHCPREQUEST messages to the multicast address.
   of the MDHCP servers. The selected server responds by sending
   DHCPACK message directly to the client as in normal DHCP protocol.
   The multicast DHCPDICOVER and DHCPREQUEST messages are received by
   only the multicast 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. The
   fields and options that are different from the normal DHCP message
   exchange are summarized in Table 1 to 3.  For details on rest of the
   fields, please refer DHCP RFC [1].
   The client can later renew or release the multicast address by using
   DHCPREQUEST and DHCPRELEASE message exchanges as defined in the DHCP
   RFC [1].
   At any time, if the MDHCP server is unable to satisfy the
   DHCPREQUEST message (e.g., the requested address has been
   allocated), the server MUST respond with a DHCPNAK message.
   Note that all the messages in this exchange have their M flag set
   and B flag not set.
   In the second method [see Figure 2] the client is requesting
   address(es) directly from a specific MDHCP server. When a client
   knows the IP address of the MDHCP server from which it can obtain a
   multicast address(es) from a give scope, it MAY skip the discover
   phase ( i.e. DHCPDISCOVER and DHCPOFFER message exchange ) and
   directly start with unicasting DHCPREQUEST message to the server. If
   this fails, the client SHOULD revert back to the first method.
   The MDHCP client may need to be deployed on the client machines
   where DHCP client implementation is not capable of filtering out the
   MDHCP messages. In that case, the MDHCP client MUST use a port
   number different from ‘DHCP client port(68)’. The MDHCP client MUST
   specify this port in the DHCPDISCOVER and DHCPREQUEST messages via
   ‘Client Port Option’.
   The MDHCP Client MUST provide client identifier option when sending
   messages for multicast address assignment. The client generates a
   unique key and uses that as a client identifier in the DHCPDISCOVER
   message. The client identifier is the key to distinguish the client
   request and to avoid duplicate address allocation.
   Each client may be running several different multicast enabled
   applications, and each application may require separate multicast
   address(es). Client MUST use separate unique client identifier when
    Patel and Shah                                               8
                                MDHCP                    11/20/97
   requesting separate multicast address(es) for each request. A client
   implementation may choose to use hardware address, application
   instance and time of request to generate unique client identifiers.
   The following tables [Table 1, Table 2] describes the fields and
   options that are relavent to MDHCP protocol but are different from
   the normal DHCP protocol [1]
   Field      DHCPOFFER            DHCPACK             DHCPNAK
   -----      ---------            -------             -------
  'flags'    Set 'M' Bit.         set 'M' Bit         set 'M' bit
             BROADCAST bit 0      BROADCAST bit 0     BROADCAST bit 0
  'ciaddr'   'ciaddr' from        'ciaddr' from       0
             DHCPDISCOVER or 0    DHCPREQUEST or 0
  'yiaddr'   Multicast address    Multicast address
             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               MUST NOT
   Lease Start Time          MUST         MUST               MUST NOT
   Server identifier         MUST         MUST               MUST
   Multicast Scope           MUST         MUST               MUST NOT
              Table 1:  Fields and options that are different in
                           multicast DHCP server messages.
    Patel and Shah                                               9
                                MDHCP                    11/20/97
     -----      ------------      -----------           -----------
     'flags'    Set 'M' Bit.      set 'M' Bit           set 'M' bit
                BROADCAST bit 0   BROADCAST bit 0       BROADCAST bit 0
     'ciaddr'   0 or client's     0 or client's         0
                network addr      network addr
     'chaddr'   ignored           ignored               ignored
     'options'  options           options               (unused)
     Option                  DHCPDISCOVER   DHCPREQUEST    DHCPRELEASE
     ------                  ------------   -----------    -----------
     Start time              MAY            MAY            MUST NOT
     Client identifier       MUST           MUST           MAY
     Multicast Scope         SHOULD         SHOULD         MAY
     Client Port             MUST(if using  MUST (if using MUST NOT
                             a different    a different
                             port)          port)
                Table 2:  Fields and options that are different in
                                  multicast DHCP client messages
    Patel and Shah                                              10
                                MDHCP                    11/20/97
                Server          Client          Server
            (not selected)                    (selected)
                  v               v               v
                  |               |               |
                  |     Obtain IP address         |
                  |               |               |
                  |Begin multicast address request|
                  |               |               |
                  | _____________/|\_____________ |
                  |/ DHCPDISCOVER | DHCPDISCOVER \|
                  |               |               |
              Determines          |          Determines
              address(es)         |          address(es)
                  |               |               |
                  |\              |  ____________/|
                  | \_________    | /DHCPOFFER    |
                  |  DHCPOFFER\   |/              |
                  |            \  |               |
                  |       Collects replies        |
                  |              \|               |
                  |     Selects Address(es)       |
                  |               |               |
                  | _____________/|\_____________ |
                  |/ DHCPREQUEST  |  DHCPREQUEST \|
                  |               |               |
                  |               |     Commits address(es)
                  |               |               |
                  |               | _____________/|
                  |               |/ DHCPACK      |
                  |               |               |
                  | assignment complete           |
                  |               |               |
                  .               .               .
                  |               |               |
                  |      Graceful release         |
                  |               |               |
                  |               |\_____________ |
                  |               |  DHCPRELEASE \|
                  |               |               |
                  |               |        Discards lease
                  |               |               |
                  v               v               v
        Figure 1: Timeline diagram of messages exchanged between MDHCP
        client and servers using group multicast address for MDHCP
        capable servers.
    Patel and Shah                                              11
                                MDHCP                    11/20/97
               Client          Server
                  v               v
                  |               |
                  |\_____________ |
                  |  DHCPREQUEST \|
                  |               |
                  |     Commits address(es)
                  |               |
                  | _____________/|
                  |/ DHCPACK      |
                  |               |
                  | assignment complete
                  |               |
                  .               .
                  |               |
         Graceful release         |
                  |               |
                  |\_____________ |
                  |  DHCPRELEASE \|
                  |               |
                  |        Discards lease
                  |               |
                  v               v               v
        Figure 2: Timeline diagram of messages exchanged between MDHCP
                  client and servers when MDHCP server has already been
   4.  MDHCP Protocol properties
   Conflict free address allocation: In the intranet case, each MDHCP
   server MAY be allocated part of the administratively scoped address
   space. As long as the address space managed by MDHCP servers is
   non-overlapping for a given administrative scope, the protocol
   will allocate conflict free addresses. MDHCP protocol does not
   directly address the mechanisms for determining address allocation
   outside Intranet. However, we propose to use MDHCP as a front end
   to any future address allocation protocol for the Internet. The DHCP
   protocol will preserve conflict free address allocation property of
   the internet multicast address allocation 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
    Patel and Shah                                              12
                                MDHCP                    11/20/97
   Multicast address scopes: The administratively scoped multicast
   address may be directly allocated by MDHCP server. However, it is
   envisioned that the MDHCP protocol will be indirectly used for
   Internet wide Multicast addresses allocation. In such deployment,
   the MDHCP server will act as a front-end to future Internet
   multicast address allocation protocols.
   Efficient use of address space: The multicast address space may be
   statically partitioned between MDHCP servers to provide sufficient
   reliability and load management on servers. However, the multicast
   based address request will be able to obtain addresses from any of
   the available servers.
   5.  Security Considerations
   This document does not explicitly address security considerations to
   avoid redundant effort with the work in progress in DHC working
   group of IETF on securing DHCP.
   6.  Acknowledgements
   The authors would like to thank Rajeev Byrisetty, Steve Deering,
   Peter Ford, Mark Handley, Van Jacobson, David Oran, Thomas Pfenning,
   Dave Thayler, Ramesh Vyaghrapuri and the participants of IETF for
   their assistance with this protocol.
   7.  References
   [1] Droms, R., "Dynamic Host Configuration Protocol", RFC1541,
   October 1993.
   [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
   Extensions", RFC 1533, Lachman Technology, Inc., Bucknell
   University, October 1993.
   [3] Patel, B., and Shah, M., ``Multicast address allocation
   extensions options'' <draft-ietf-dhc-multopt-00.txt>
   [4] Meyer, D., ``Administratively scoped IP Multicast'', Internet
   draft, <draft-ietf-mboned-admin-ip-space-01.txt>
   [5] D. Mills, ``Network Time Protocol version 2 specification and
   8.  Author's Address
      Baiju V. Patel
      Intel Corp.
      2111 NE 25th Ave.
      Hillsboro, OR 97124
    Patel and Shah                                              13
                                MDHCP                    11/20/97
      Phone: 503 264 2422
      EMail: baiju@mailbox.jf.intel.com
      Munil Shah
      Microsoft Corporation
      One Microsoft Way
      Redmond, WA 98052
      Phone:425 703 3924
      This document will expire on April, 1998
    Patel and Shah                                              14