Network Working Group
DHC working group                           Baiju V. Patel
INTERNET DRAFT Patel, Intel Corporation Corp.
Internet Draft                              Munil Shah Shah, Microsoft Corporation

                                                              March 1997 Corp.
August 1998                    Stephen R. Hanna, Sun Microsystems, Inc.
Expires: February 1999                    draft-ietf-dhc-multopt-03.txt

           Multicast address allocation extensions options
                        <draft-ietf-dhc-multopt-02.txt> Address Allocation Configuration Options

Status of this memo

   This document is an Internet-Draft. Internet-Drafts Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas, Areas,
   and its working groups. Working Groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six months
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is inappropriate not appropriate to use Internet-Drafts Internet
   Drafts as reference material or to cite them other than as ``work a "working
   draft" or "work in progress.'' 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 (Africa), (Europe), (Pacific Rim), (US East Coast),,,, or (US West Coast).

1. Abstract


   A revised version of this draft document describes host configuration options that may will be used
   by multicast address allocation protocols[3]. The options include
   critical information such as the multicast address
   of the multicast address allocation server(s) and a list of
   multicast scopes supported by respective servers. These options are
   designed submitted to work with the extensions to DHCP [1] servers to support
   multicast address allocation (described in RFC
   editor as a separate draft),
   however, their use may not be limited to the above protocol.

2 Requirements

   Throughout this document, the words that are used to define Proposed Standard for the
   significance of particular requirements Internet Community. Discussion
   and suggestions for improvement are capitalized.  These
   words are:

      o "MUST" requested.  This word or the adjective "REQUIRED" means that the
        item is an absolute requirement document will
   expire before February 1999. Distribution of this specification.

      o "MUST NOT"

        This phrase means that the item draft is an absolute prohibition
        of this specification.

      o "SHOULD" unlimited.


   This word or the adjective "RECOMMENDED" means document describes DHCP options 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 used to provide
   access to Multicast Address Allocation servers, such as MDHCP

1. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

        This phrase means that there may exist valid reasons NOT", "RECOMMENDED",  "MAY", and"OPTIONAL" 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
   document are 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.

3 Terminology be interpreted as described in RFC 2119.

   This document uses the following terms:

      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"


        An MDHCP client is a DHCP client that supports MDHCP extensions. an Internet host requesting multicast
        address allocation services via MDHCP.

      o "MDHCP server"


        An MDHCP server is a DHCP server that supports MDHCP extensions.

4 an Internet host providing multicast
        address allocation services via MDHCP.

2. Multicast Address Allocation Configuration Options

   Any client attempting

   The MDHCP protocol [3] allows hosts (known as MDHCP clients) to
   request a multicast address must know the allocation services from multicast group address to which the server
   allocation servers (known as MDHCP servers). One way that MDHCP
   clients communicate with MDHCP servers is listening by sending multicast
   messages to an MDHCP Server Multicast Address.

   This document defines a DHCP option (as described in [1] and a
   list of multicast scopes supported by the multicast address servers.
   The following two options are specifically designed to provide the
   multicast address server address and the scope list [2])
   that can
   specifically may be used by the protocol described in [3], however, its
   use is not limited to the protocol described in [3].

4.1 configure MDHCP clients with an appropriate MDHCP
   Server Multicast Group Address of and TTL.

2.1. MDHCP Servers.

   This Server Multicast Address option is used DHCP servers to provide the

   The MDHCP Server Multicast Address option specifies a multicast group
   address of the and TTL that MDHCP servers. The clients SHOULD use to contact MDHCP

   A DHCP client can obtain this parameter as part of the normal DHCP
   protocol message exchange or separately via DHCPINFORM.

         Code  Len      Multicast Address
        +-----+-----+-----+-----+-----+-----+     TTL
        | TBD | 4 5   | i1  | i2  | i3  | i4  |
        +-----+-----+-----+-----+-----+-----+ ttl |

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

4.2 Multicast Scople List Option.

   The format of the multicast scope list option is:

         Code  Len      IP Address           Count  List
        | 107 | n   | i1  | i2  | i3  | i4  | N   | l1  |     | ln  |

   Where IP address is the address of the MDHCP server, to its best
   knowledge, reachable from the client via unicast.
   The scope list a list of N tuples, where each tuple is of
   the form,

        Scope ID ( 4 Bytes )    TTL   Desc  Scope Description.
       | ID1 | ID2 | ID3 | ID4 | T   | n   | d1  |     | dn  |

   where scope ID is a unique identifier to designate the scope,
   TTL is the multicast TTL value for the multicast addresses of
   the scope, scope
   description is a string describing the scope (need not be null
   terminated) and scope len is the length of scope description.

   Scope id is numeric representation of the scope and is used by the
   client to indicate a multicast scope to the server. In order to
   keep the usage of scope id consistent in the MBONE, this draft
   SHOULD be coordinated with [3] reserve a scope id for each
   multicast range in [3]. The scope id with its MSB(most significant
   bit) of 1 should be used for administratively scoped multicast
   address range. And the scope id with its MSB of 0 should be used to
   represent other pre-defined internet scopes.

   The code for this option is 107.


   The IP address of the MDHCP server is There are two
   scopes supported by the multicast address allocation server:
   1) Inside the, 2) world. Then this option will be used as:

         Code  Len      IP Address           Count
        | 107 | 32  | 10  | 1   | 1   | 1   | 2   |

        Scope ID    TTL Len Desc
       |         1 |10 |16 | Inside |
       |         2 |16 |5  | world           |

4 5.

3. References

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

   [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
       Extensions", RFC 1533, Lachman Technology, Inc., Bucknell
       University, October 1993. 2132, March 1997.

   [3] Meyer, D., ``Administratively scoped IP Multicast''

   [4] Patel, B., and M. Shah, M., ``Multicast and S. Hanna, "Multicast address
       extensions to based on the Dynamic Host Configuration
       Protocol''  <draft-ietf-dhc-mdhcp-00.txt>

5  Author's Address Protocol",
       draft-ietf-malloc-mdhcp-00.txt, August 1998.

4. Authors' Addresses

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

   Phone: 503 264 2422

   Munil Shah
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052


   Phone: 425 703 3924

   This document will expire on April, 1998

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

   Phone: +1.978.442.0166