wdiff draft-ietf-dhc-mdhcp-02.txt draft-ietf-dhc-mdhcp-03.txt

Dynamic Host Configuration working group Baiju V. Patel,
Internet Draft Intel Corp,
Munil Shah
Microsoft Corp.
September 16,
November 20, 1997

Multicast address allocation extensions to the

Dynamic Host Configuration Protocol
<draft-ietf-dhc-mdhcp-02.txt>

<draft-ietf-dhc-mdhcp-03.txt>

Status of this Memo

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

Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
"working draft" or "work in progress".

To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au.

A revised version of this draft document will be submitted to the
RFC editor as a Proposed Standard for the Internet Community.
Discussion and suggestions for improvement are requested. This
document will expire before February 1998. Distribution of this
draft is unlimited.

Abstract

The Dynamic Host Configuration Protocol (DHCP) provides a framework
for passing configuration information to hosts on a TCP/IP network.
The multicast extensions to DHCP add additional capability of
dynamic allocation of the multicast addresses and additional
configuration options.

1. Introduction

The multicast extensions to DHCP (MDHCP) provide configuration
parameters to the multicast applications. MDHCP is built on a
client-server model, where designated DHCP server allocate allocates
multicast addresses and deliver delivers parameters associated with the MDHCP 09/16/97
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 extensions an extension to the DHCP protocol.

MDHCP supports two mechanisms for multicast address allocation. In

"automatic allocation", MDHCP assigns a permanent multicast address
to a client. In "dynamic allocation", MDHCP assigns a multicast
address to a client for a limited period of time (or until the
client explicitly relinquishes the address). In "manual
allocation", a client's IP address is assigned by the network
administrator, and DHCP is used simply to convey the assigned
address to the client. A particular network will use one or more

of these mechanisms, depending on the policies of the network
administrator.

Like DHCP, MDHCP should be a mechanism rather than a policy. MDHCP
must allow local system administrators control over configuration
parameters where desired; e.g., local system administrators should
be able to enforce local policies concerning allocation and access
to local resources where desired.

The MDHCP client is not required to obtain IP address from a DHCP
server in order to use MDHCP protocol.

The design goals specified in the DHCP RFC also apply to MDHCP.

1.1. Requirements

Throughout this document, the words that are used to define the
significance of particular requirements are capitalized. These
words are:

o "MUST"

This word or the adjective "REQUIRED" means that the
item is an absolute requirement of this specification.

o "MUST NOT" MDHCP 09/16/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

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 using DHCP to obtain that obtains configuration
parameters such as a (e.g., network address. address) using DHCP protocol

o "DHCP server"

A DHCP server is an Internet host that returns provides
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. an
application. Following are the set of requirements on such a
protocol.

Conflict Free Allocation: When two applications obtain a multicast
address (using a common multicast address allocation protocol), both
applications are 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.

Session protocol independence: The address allocation protocol

should be independent of existing

Patel 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: Shah 3
MDHCP 11/20/97

Quick response: The application should not have to wait for a long
time before it can be sure that 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
minutes.

Low network load: The multicast address allocation protocol is a
control protocol. It Therefore, 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 System may suspend or turn be in on, off for some time. The system may come back to
full or low
power just before state between the application starts multicasting
traffic. address allocation and usage period.

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. addresses. Therefore, efficient use of address
space is a design goad goal of multicast address allocation protocol.

1.4. MHDCP Protocol Summary

From the client's point of view, protocol standpoint, MDHCP is an extension of the DHCP. As
in normal DHCP
mechanisms. protocol, a MDHCP client requests multicast
address(es) from the MDHCP server for a specified multicast scope.
The MDHCP servers assigns multicast addresses address(es) to the hosts to be
used within a specific the requested 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 over 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. value of the address. The multicast packets client,
when using the assigned address MUST NOT should not use a the TTL value larger then
than 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 address to different clients
with overlapping lease period. period and scope. The protocol also allows
client to request more than one address at a time.

Before requesting a multicast
scope address, a client needs to obtain the
list of multicast scopes available on the MDHCP server. The
multicast scope-list is one of the DHCP MDHCP configuration parameters.
The scope list may be obtained through the DHCP option described in
[3], or may be obtained with by some other means. Similarly, the MDHCP
server address (unicast or multicast) (multicast) may also be obtained by the option
described in [3] or by some other means. can be configured on the client.

The MDHCP server is not required to be co-located with a DHCP
server. Therefore, in a typical deployment, there may be fewer MDHCP 09/16/97
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 (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. address(es). It is also used to indicate
the scope of the assigned address by the DHCP server. If this option
is not specified, the DHCP server MAY allocate an address from a
DEFAULT scope or reject the request. MDHCP 09/16/97

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

Code Len Scope Id

+-----+-----+-----+-----+-----+-----+

| 101 | 4 5

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| code | length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i1 | Scope id i2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i3 | Scope id 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. 101 and the length is 4.

Patel and Shah 5
MDHCP 11/20/97

2.3. Start time Option

The start time is used in a client request (DHCPDISCOVER or
DHCPREQUEST) to allow the client to request the starting time for
the use of the assigned address. This option allows client to
request a multicast address for use at a future time.

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| code

Code Len Time

+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+

| length=4 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. 102 and the length is 8.

If IP Address Lease Time option specifies [2] the duration of the
lease beginning at Start Time option value. MDHCP 09/16/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. The implied value of this option is 255 when not included.

Code Len Multicast TTL

+-----+-----+-----+

| 103 | 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | code 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

+-----+-----+-----+-----+

| length=1 104 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | TTL n |
+-+-+-+-+-+-+-+-+

+-----+-----+-----+-----+

The 'code' for this option is 103.

2.5. 104 and the length is 2.

Patel and Shah 6
MDHCP 11/20/97

2.6. Client Port Option

In order to facilitate implementations outside the operating system
kernel, and to allow two separate client implementations: one for
DHCP and one for MDHCP, if this option is specified, the MDHCP server
MUST use the source port number used in the DHCPDISCOVER,
DHCPREQUEST, DHCPINFORM, and DHCPRESEASE as the destination port
number in the response messages.

Code Len Port

+-----+-----+-----+

| 105 | 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ | code n |
+-+-+-+-+-+-+-+-+

+-----+-----+-----+

The 'code' for this option is 105.

3. MDHP protocol

The client needs to obtain 105 and the IP address length is 1.

2.7. List of Address Ranges Allocated

This option is used by the MDHCP server (this
may be a unicast or a multicast address for MDHCP group), and to provide the
multicast scope list. This list may be obtained as part of all the
normal DHCP protocol using
address ranges allocated to the options specified in 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 by some from other means.

The repository of
network configurations.

At this point, client selects one has two ways of obtaining the multicast scopes
address(es) from the server.

Patel and requests multicast 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. servers configured to hand out
addresses from a given scope. The fields client selects a scope and options that

are different from sends
out a DHCPDISCOVER
message to the normal DHCP multicast address of the MDHCP servers. The server
responds by sending DHCPOFFER message exchange are summarized
in Table 1 directly to 3. details on rest the client. The
client then sends DHCPREQUEST messages to the multicast address.
of the parameters, please MDHCP 09/16/97

consult servers. The selected server responds by sending
DHCPACK message directly to the client as in normal DHCP RFC [1]. protocol.
The multicast addresses DHCPDICOVER and DHCPREQUEST messages are renewed or
released using received by
only the multicast capable DHCP exchanges for network addresses as defined
in servers, and therefore, there is no
conflict between the MDHCP and DHCP RFC [1].

Note that all messages. Further, the messages in this
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 application. request. A client
implementation may choose to use hardware address, hardware

type and application
instance number and time of request to generate unique client
identifier. MDHCP 09/16/97

Field DHCPOFFER 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' Starting Multicast address of Starting Multicast 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

Lease Start Time MUST MUST MUST
Multicast TTL NOT

Server identifier MUST MUST MUST NOT

Multicast Block size MAY MAY Scope MUST NOT
Cookie MUST MAY MUST NOT

Table 1: Fields and options that are different in
multicast DHCP server messages.

Patel and Shah 9
MDHCP 09/16/97 11/20/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' 0 or client's network 0 or client's network 0

network addr reachable network addr reachable
from the server from the server

'chaddr' may contain may contain may contain

hardware address hardware address hardware address ignored ignored ignored

'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

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

|/ |
| |
\| |
Selects Address(es) |
| |
|\_____________ |
| DHCPREQUEST \|
| |

. .
. .
| |
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 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 non-MDHCP capable server.

A summary of fields of MDHCP in messages different a different

port) port)

Table 2: Fields and options 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 DHCP client
SHOULD first try to use the unicast address, messages

Patel and if unsuccessful,
SHOULD try the group multicast address for MDHCP servers. Shah 10
MDHCP 09/16/97 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 2: 1: Timeline diagram of messages exchanged between MDHCP
client and servers when allocating multicast
address(es) using group multicast address for MDHCP
capable servers.

Patel and Shah 11
MDHCP 09/16/97

5. 11/20/97

Client Server

v v

| |

|\_____________ |

| DHCPREQUEST \|

| |

| Commits address(es)

| |

| _____________/|

|/ DHCPACK |

| |

| assignment complete

| |

. .

| |

Graceful release |

| |

|\_____________ |

| DHCPRELEASE \|

| |

| Discards lease

| |

v v v

Figure 2: Timeline diagram of messages exchanged between MDHCP
client and servers when MDHCP server has already been
selected

4. MDHCP Protocol properties

Conflict free address allocation: In the intranet case, each MDHCP
server is 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 MDHCP DHCP
protocol will preserve conflict free address allocation property of
the internet multicast address allocation protocol.

Session protocol independence: The MDHCP protocol does not dictate
use of the address allocated, and does not rely on any session

control protocol. Therefore, it will work with SIP or SAP based
session control protocol.

Small response time: The response time for MDHCP protocol is
strictly based on the network propagation delay and the load on the
MDHCP server.

The MDHCP protocol does not require a client system to be on all the
time. Thus, it poses no additional requirements on power managed
systems.

Patel and Shah 12
MDHCP 11/20/97

Multicast address scopes: The administratively scoped multicast
address may be directly allocated by MDHCP server. However, it is
envisioned that the MDHCP protocol will be indirectly used for
Internet wide Multicast addresses allocation. In such deployment,
the MDHCP server will act as a front-end to future Internet
multicast address allocation protocols.

Efficient use of address space: The multicast address space may be
statically partitioned between MDHCP servers to provide sufficient
reliability and load management on servers. However, the multicast
based address request will be able to obtain addresses from any of
the available servers. Alternately, the MDHCP server can be
organized hierarchically where a master server allocates blocks of
addresses to the child servers (using MDHCP protocol). It is also
possible to provide further fault-tolerance using DHCP server-server
protocol. MDHCP 09/16/97

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

implementation'',

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:206

Phone:425 703 3924
Email:munils@microsoft.com

This document will expire on Sept, 1997 MDHCP 09/16/97 April, 1998

Patel and Shah 14