draft-ietf-dhc-mdhcp-01.txt   draft-ietf-dhc-mdhcp-02.txt 
Network Working Group Baiju V. Patel Dynamic Host Configuration working group Baiju V. Patel,
INTERNET DRAFT Intel Corporation Internet Draft Intel Corp,
Munil Shah Munil Shah
Microsoft Corporation Microsoft Corp.
September 16, 1997
March 1997
Multicast address allocation extensions to the Multicast address allocation extensions to the
Dynamic Host Configuration Protocol Dynamic Host Configuration Protocol
<draft-ietf-dhc-mdhcp-01.txt> <draft-ietf-dhc-mdhcp-02.txt>
Status of this memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its working groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months. Internet Drafts may be updated, replaced, or obsoleted by
time. It is inappropriate to use Internet-Drafts as reference other documents at any time. It is not appropriate to use Internet
material or to cite them other than as ``work in progress.'' 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 To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au.
ftp.isi.edu (US West Coast).
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 Abstract
The Dynamic Host Configuration Protocol (DHCP) provides a framework The Dynamic Host Configuration Protocol (DHCP) provides a framework
for passing configuration information to hosts on a TCP/IP network. for passing configuration information to hosts on a TCP/IP network.
The multicast extensions to DHCP add additional capability of The multicast extensions to DHCP add additional capability of
dynamic allocation of the multicast addresses and additional dynamic allocation of the multicast addresses and additional
configuration options. configuration options.
1. Introduction 1. Introduction
skipping to change at page 1, line 42 skipping to change at line 45
Abstract Abstract
The Dynamic Host Configuration Protocol (DHCP) provides a framework The Dynamic Host Configuration Protocol (DHCP) provides a framework
for passing configuration information to hosts on a TCP/IP network. for passing configuration information to hosts on a TCP/IP network.
The multicast extensions to DHCP add additional capability of The multicast extensions to DHCP add additional capability of
dynamic allocation of the multicast addresses and additional dynamic allocation of the multicast addresses and additional
configuration options. configuration options.
1. Introduction 1. Introduction
The multicast extensions to DHCP (MDHCP) provide configuration The multicast extensions to DHCP (MDHCP) provide configuration
parameters to the multicast applications. MDHCP is built on a parameters to the multicast applications. MDHCP is built on a
client-server model, where designated DHCP server allocate client-server model, where designated DHCP server allocate
multicast addresses and deliver parameters associated with the multicast addresses and deliver parameters associated with the MDHCP 09/16/97
address to dynamically configured hosts. Throughout the remainder address to dynamically configured hosts. Throughout the remainder
of this document, the term "server" refers to a host providing of this document, the term "server" refers to a host providing
multicast address(es) and parameters through DHCP, and the term multicast address(es) and parameters through DHCP, and the term
"client" refers to a host requesting multicast address(es) and "client" refers to a host requesting multicast address(es) and
parameters from a DHCP server. MDHCP server is used at times, to parameters from a DHCP server. MDHCP server is used at times, to
indicate a DHCP server capable of handling MDHCP extensions to the indicate a DHCP server capable of handling MDHCP extensions to the
DHCP protocol and the MDHCP client is used to indicate the MDHCP DHCP protocol and the MDHCP client is used to indicate the MDHCP
capable DHCP client. MDHCP is not a separate protocol, but is capable DHCP client. MDHCP is not a separate protocol, but is
simply extensions to the DHCP protocol. simply extensions to the DHCP protocol.
MDHCP supports two mechanisms for multicast address allocation. In MDHCP supports two mechanisms for multicast address allocation. In
"automatic allocation", MDHCP assigns a permanent multicast address "automatic allocation", MDHCP assigns a permanent multicast address
to a client. In "dynamic allocation", MDHCP assigns a multicast to a client. In "dynamic allocation", MDHCP assigns a multicast
address to a client for a limited period of time (or until the address to a client for a limited period of time (or until the
client explicitly relinquishes the address). In "manual client explicitly relinquishes the address). In "manual
allocation", a client's IP address is assigned by the network allocation", a client's IP address is assigned by the network
administrator, and DHCP is used simply to convey the assigned administrator, and DHCP is used simply to convey the assigned
address to the client. A particular network will use one or more address to the client. A particular network will use one or more
of these mechanisms, depending on the policies of the network of these mechanisms, depending on the policies of the network
administrator. administrator.
Like DHCP, MDHCP should be a mechanism rather than a policy. MDHCP Like DHCP, MDHCP should be a mechanism rather than a policy. MDHCP
must allow local system administrators control over configuration must allow local system administrators control over configuration
parameters where desired; e.g., local system administrators should parameters where desired; e.g., local system administrators should
be able to enforce local policies concerning allocation and access be able to enforce local policies concerning allocation and access
to local resources where desired. to local resources where desired.
The MDHCP client is not required to obtain IP address from a DHCP The MDHCP client is not required to obtain IP address from a DHCP
skipping to change at page 2, line 31 skipping to change at line 86
must allow local system administrators control over configuration must allow local system administrators control over configuration
parameters where desired; e.g., local system administrators should parameters where desired; e.g., local system administrators should
be able to enforce local policies concerning allocation and access be able to enforce local policies concerning allocation and access
to local resources where desired. to local resources where desired.
The MDHCP client is not required to obtain IP address from a DHCP The MDHCP client is not required to obtain IP address from a DHCP
server in order to use MDHCP protocol. server in order to use MDHCP protocol.
The design goals specified in the DHCP RFC also apply to MDHCP. The design goals specified in the DHCP RFC also apply to MDHCP.
1.1 Requirements 1.1. Requirements
Throughout this document, the words that are used to define the Throughout this document, the words that are used to define the
significance of particular requirements are capitalized. These words significance of particular requirements are capitalized. These
are: words are:
o "MUST" o "MUST"
This word or the adjective "REQUIRED" means that the This word or the adjective "REQUIRED" means that the
item is an absolute requirement of this specification. item is an absolute requirement of this specification.
o "MUST NOT" o "MUST NOT" MDHCP 09/16/97
This phrase means that the item is an absolute prohibition This phrase means that the item is an absolute prohibition
of this specification. of this specification.
o "SHOULD" o "SHOULD"
This word or the adjective "RECOMMENDED" means that there This word or the adjective "RECOMMENDED" means that there
may exist valid reasons in particular circumstances to ignore may exist valid reasons in particular circumstances to ignore
this item, but the full implications should be understood and this item, but the full implications should be understood and
the case carefully weighed before choosing a different course. the case carefully weighed before choosing a different course.
skipping to change at page 3, line 17 skipping to change at line 125
described with this label. described with this label.
o "MAY" o "MAY"
This word or the adjective "OPTIONAL" means that this item is This word or the adjective "OPTIONAL" means that this item is
truly optional. One vendor may choose to include the item truly optional. One vendor may choose to include the item
because a particular marketplace requires it or because it because a particular marketplace requires it or because it
enhances the product, for example; another vendor may omit the enhances the product, for example; another vendor may omit the
same item. same item.
1.2 Terminology 1.2. Terminology
This document uses the following terms: This document uses the following terms[1]:
o "DHCP client" o "DHCP client"
A DHCP client is an Internet host using DHCP to obtain A DHCP client is an Internet host using DHCP to obtain
configuration parameters such as a network address. configuration parameters such as a network address.
o "DHCP server" o "DHCP server"
A DHCP server is an Internet host that returns configuration A DHCP server is an Internet host that returns configuration
parameters to DHCP clients. parameters to DHCP clients.
o "MDHCP client" o "MDHCP client"
A MDHCP client is a DHCP client that supports MDHCP extensions. A MDHCP client is a DHCP client that supports MDHCP extensions.
o "MDHCP server" o "MDHCP server" MDHCP 09/16/97
A MDHCP server is a DHCP server that supports MDHCP extensions. A MDHCP server is a DHCP server that supports MDHCP extensions.
o "BOOTP relay agent" o "BOOTP relay agent"
A BOOTP relay agent or relay agent is an Internet host or router A BOOTP relay agent or relay agent is an Internet host or
that passes DHCP messages between DHCP clients and DHCP servers. router that passes DHCP messages between DHCP clients and DHCP
DHCP is designed to use the same relay agent behavior as servers. DHCP is designed to use the same relay agent behavior
specified in the BOOTP protocol specification. as specified in the BOOTP protocol specification.
o "binding" o "binding"
A binding is a collection of configuration parameters, including A binding is a collection of configuration parameters,
at least an IP address, associated with or "bound to" a DHCP including at least an IP address, associated with or "bound to"
client. Bindings are managed by DHCP servers. a DHCP client. Bindings are managed by DHCP servers.
1.3 Motivation and protocol requirements. 1.3. Motivation and protocol requirements.
For multicast applications to be ubiquitous, there is a need to For multicast applications to be ubiquitous, there is a need to
standardize on a protocol to allocate multicast addresses to the standardize on a protocol to allocate multicast addresses to the
applications. Following are the set of requirements on such a applications. Following are the set of requirements on such a
protocol. protocol.
Conflict Free Allocation: When two applications obtain a Conflict Free Allocation: When two applications obtain a
multiast address (using a common multicast address allocation multicast address (using a common multicast address allocation
protocol), both applications are allocated identical addresses
protocol), both applications are allocated identical addresses
only if it can be guaranteed that no hosts will receive multicasts only if it can be guaranteed that no hosts will receive multicasts
using same address from both the applications on the same network using same address from both the applications on the same network
interface provided that the multicast scoping is implemented correctly. interface provided that the multicast scoping is implemented
correctly.
Session protocol independence: The address allocation protocol Session protocol independence: The address allocation protocol
should be independent of existing and future session control should be independent of existing and future session control
protocol. For example, it must be suitable for applications that protocol. For example, it must be suitable for applications that
use SAP (session announcement protocol) and SIP (session invitation use SAP (session announcement protocol) and SIP (session invitation
protocol). protocol).
Small response time: The application should not have to wait for a 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 long time before it can be sure that it can use a multicast
address. The response time should be function of network and address. The response time should be function of network and
system delays only and should not be in the order of several system delays only and should not be in the order of several
minutes. minutes.
Low network load: The multicast address allocation protocol is a Low network load: The multicast address allocation protocol is a
control protocol. It should be designed to impose minimal load on control protocol. It should be designed to impose minimal load on
the network. In particular, it should not require periodic the network. In particular, it should not require periodic
broadcast/multicast messages from every application. Specifically, broadcast/multicast messages from every application. Specifically, MDHCP 09/16/97
the address allocation protocol should not overload a modem line the address allocation protocol should not overload a modem line
when used by a dial-in user. when used by a dial-in user.
Work with power managed systems: The protocol should not require Work with power managed systems: The protocol should not require
the client systems to be on all the time. It is perfectly the client systems to be on all the time. It is perfectly
acceptable that once the multicast address is allocated, the system acceptable that once the multicast address is allocated, the system
may suspend or turn off for some time. The system may come back to may suspend or turn off for some time. The system may come back to
full power just before the application starts multicasting full power just before the application starts multicasting
traffic. traffic.
skipping to change at page 4, line 36 skipping to change at line 206
when used by a dial-in user. when used by a dial-in user.
Work with power managed systems: The protocol should not require Work with power managed systems: The protocol should not require
the client systems to be on all the time. It is perfectly the client systems to be on all the time. It is perfectly
acceptable that once the multicast address is allocated, the system acceptable that once the multicast address is allocated, the system
may suspend or turn off for some time. The system may come back to may suspend or turn off for some time. The system may come back to
full power just before the application starts multicasting full power just before the application starts multicasting
traffic. traffic.
Multicast address scopes: The protocol must be able to Multicast address scopes: The protocol must be able to
allocate both the administratively scoped addresses and global allocate both the administratively scoped addresses and global
addresses. addresses.
Efficient use of address space: The multicast address space is Efficient use of address space: The multicast address space is
smaller then IP address space. Moreover, a host or application may smaller then IP address space. Moreover, a host or application may
require multiple address. Therefore, efficient use of address space require multiple address. Therefore, efficient use of address space
is a design goad of multicast address allocation protocol. is a design goad of multicast address allocation protocol.
1.4 MHDCP Protocol Summary 1.4. MHDCP Protocol Summary
From the client's point of view, MDHCP is an extension of the DHCP From the client's point of view, MDHCP is an extension of the DHCP
mechanisms. The MDHCP servers assigns multicast addresses to the mechanisms. The MDHCP servers assigns multicast addresses to the
hosts to be used within a specific scope, and valid for a specific hosts to be used within a specific scope, and valid for a specific
period. A client may request multiple multicast addresses. period. A client may request multiple multicast addresses.
The client requests a multicast address(es) to be used for a The client requests a multicast address(es) to be used for a
specific multicast scope available to it, and for a specific lease specific multicast scope available to it, and for a specific lease
period. The MDHCP server would ideally assign the address from the period. The MDHCP server would ideally assign the address from the
requested scope or may allocate it for a different scope. However, requested scope or may allocate it for a different scope. However,
if it allocates the address from a different scope, it will provide if it allocates the address from a different scope, it will provide
this information as an option. The DHCP server MUST provide a TTL this information as an option. The DHCP server MUST provide a TTL
value. The multicast packets using the assigned address MUST NOT value. The multicast packets using the assigned address MUST NOT
use a TTL value larger then the one provided. The lease period is 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 defined by the duration of the lease and the time at which the lease
becomes effective. Since the client may want to extend lease
lease becomes effective. Since the client may want to extend lease
at a later time, the DHCP server SHOULD make every attempt at at a later time, the DHCP server SHOULD make every attempt at
allocating an address which is not currently allocated to any other allocating an address which is not currently allocated to any other
client. The DHCP server MUST NOT allocate the same addresses to client. The DHCP server MUST NOT allocate the same addresses to
different clients with overlapping lease period. The multicast different clients with overlapping lease period. The multicast
scope list is one of the DHCP configuration parameters. scope list is one of the DHCP configuration parameters.
The scope list may be obtained through the DHCP option described in The scope list may be obtained through the DHCP option described in
[3], or may be obtained with some other means. Similarly, the MDHCP [3], or may be obtained with some other means. Similarly, the MDHCP
server address (unicast or multicast) may also be obtained by the server address (unicast or multicast) may also be obtained by the
option described in [3] or by some other means. 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. The MDHCP protocol uses M flag and a set of options defined below.
2 MDHCP messages and options. 2. MDHCP messages and options.
The following options and flags are used by MDHCP extensions. The following options and flags are used by MDHCP extensions.
2.1 M flag 2.1. M flag
A new flag (M) is defined to differentiate the MDHCP messages from A new flag (M) is defined to differentiate the MDHCP messages from
DHCP messages. All the messages (DHCPDISCOVER, DHCPOFFER etc.) use DHCP messages. All the messages (DHCPDISCOVER, DHCPOFFER etc.) use
M flag (this is a new flag) defined below to indicate multicast M flag (this is a new flag) defined below to indicate multicast
address negotiations. The second bit of the flag field (bit 1) address negotiations. The second bit of the flag field (bit 1)
defines M (multicast) flag. The M bit must be set for all the defines M (multicast) flag. The M bit must be set for all the
message exchanges pertinent to the multicast address assignment. message exchanges pertinent to the multicast address assignment.
The client MUST obtain an IP address prior to requesting a The client MUST obtain an IP address prior to requesting a
multicast address. Therefore, B flag MUST not be set when M flag is multicast address. Therefore, B flag MUST not be set when M flag is
set. set.
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B|M| MBZ | |B|M| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B: BROADCAST flag B: BROADCAST flag
M: Multicast address request flag. M: Multicast address request flag.
MBZ: MUST BE ZERO (reserved for future use) MBZ: MUST BE ZERO (reserved for future use)
2.2 Multicast Scope Option 2.2. Multicast Scope Option
This option is used by the client to indicate the multicast scope This option is used by the client to indicate the multicast scope
for the requested multicast address. It is also used to indicate for the requested multicast address. It is also used to indicate
the scope of the assigned address by the DHCP server. If this the scope of the assigned address by the DHCP server. If this
option is not specified, the DHCP server MAY allocate an address option is not specified, the DHCP server MAY allocate an address
from a DEFAULT scope or reject the request. from a DEFAULT scope or reject the request. MDHCP 09/16/97
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| code | length=4 | | code | length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope id | | Scope id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope id | | Scope id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The client may obtain the scope list through the option described in 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 [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 The start time is used in a client request (DHCPDISCOVER or
DHCPREQUEST) to allow the client to request the starting time for DHCPREQUEST) to allow the client to request the starting time for
the use of the assigned address. This option allows client to the use of the assigned address. This option allows client to
request a multicast address for use at a future time. request a multicast address for use at a future time.
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| code | length=4 | | code | length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| t1 | t2 | | t1 | t2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| t3 | t4 | | t3 | t4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The time is the Coordinated Universal Time(UTC) in unit of seconds | t5 | t6 |
and is specified as a 32-bit integer and is specified in the network +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
time format. | 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. The 'code' for this option is 102.
If IP Address Lease Time option specifies the duration of the lease If IP Address Lease Time option specifies the duration of the lease
beginning at Start Time option value. beginning at Start Time option value. MDHCP 09/16/97
2.4 Multicast TTL Option 2.4. Multicast TTL Option
This option specifies the TTL value to be used with the multicast 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 address. The TTL is specified as an octet with a value between 1
and 255. and 255.
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| code | length=1 | | code | length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL | | TTL |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The 'code' for this option is 103. The 'code' for this option is 103.
2.5 Multicast Block Size option 2.5. Client Port Option
In some cases, an application may require a group of consecutive
addresses to be assigned. This option is used by a client to request
n consecutive addresses. It is also used by the DHCP server to
indicate number of consecutive addresses assigned starting at the
address specified in ``yiaddr'' field.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n |
+-+-+-+-+-+-+-+-+
The 'code' for this option is 104.
2.6 Client Port Option
In order to facilitate implementations outside the operating system In order to facilitate implementations outside the operating system
kernel, and to allow two separate client implementations: one for kernel, and to allow two separate client implementations: one for
DHCP and one for MDHCP, if this option is specified, the MDHCP DHCP and one for MDHCP, if this option is specified, the MDHCP
server MUST use the source port number used in the server MUST use the source port number used in the
DHCPDISCOVER, DHCPREQUEST, DHCPINFORM, and DHCPRESEASE DHCPDISCOVER, DHCPREQUEST, DHCPINFORM, and DHCPRESEASE
as the destination port number in the response messages. as the destination port number in the response messages.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| code | | code |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The 'code' for this option is 105. The 'code' for this option is 105.
skipping to change at page 7, line 39 skipping to change at line 366
DHCPDISCOVER, DHCPREQUEST, DHCPINFORM, and DHCPRESEASE DHCPDISCOVER, DHCPREQUEST, DHCPINFORM, and DHCPRESEASE
as the destination port number in the response messages. as the destination port number in the response messages.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| code | | code |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The 'code' for this option is 105. The 'code' for this option is 105.
2.7 Cookie Option
The MDHCP server may issue a cookie along with the multicast
address(es) so that a different user may use the cookie to renew
lease on address(es).
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| code | length=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This option is useful when the "owner" of the address leaves a
multicast group and some other member decides to either renew or
terminate the lease. If a different member of the group from the
one who was assigned the multicast address wants to modify the
terms of multicast address, it must use this cookie as its client
identifier option. For example, if host X was issued a multicast
address, who decides to leave the multicast group that is using the
assigned the address. Then, another participant in the group
determines that the work group must continue beyond the lease time
for the multicast address, it may renew the lease by specifying the
cookie to uniquely identify the group of multicast addresses. Note
that cookie is not used as a security capability but is used to
simplify the client and server implementations.
The 'code' for this option is 106.
3. MDHP protocol 3. MDHP protocol
The client needs to obtain the IP address of the MDHCP server (this 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 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 multicast scope list. This list may be obtained as part of the
normal DHCP protocol using the options specified in [3] or by some normal DHCP protocol using the options specified in [3] or by some
other means. other means.
The client selects one of multicast scopes and requests multicast The client selects one of multicast scopes and requests multicast
address(es) from the MDHCP servers. The fields and options that address(es) from the MDHCP servers. The fields and options that
skipping to change at page 8, line 23 skipping to change at line 376
3. MDHP protocol 3. MDHP protocol
The client needs to obtain the IP address of the MDHCP server (this 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 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 multicast scope list. This list may be obtained as part of the
normal DHCP protocol using the options specified in [3] or by some normal DHCP protocol using the options specified in [3] or by some
other means. other means.
The client selects one of multicast scopes and requests multicast The client selects one of multicast scopes and requests multicast
address(es) from the MDHCP servers. The fields and options that address(es) from the MDHCP servers. The fields and options that
are different from the normal DHCP message exchange are summarized are different from the normal DHCP message exchange are summarized
in Table 1 to 3. details on rest of the parameters, please in Table 1 to 3. details on rest of the parameters, please MDHCP 09/16/97
consult DHCP RFC[1]. The mutlicast addresses are renewed or
consult DHCP RFC [1]. The multicast addresses are renewed or
released using the DHCP exchanges for network addresses as defined released using the DHCP exchanges for network addresses as defined
in the DHCP RFC[1]. in the DHCP RFC[1].
Note that all the messages in this exchange have their M flag set Note that all the messages in this exchange have their M flag set
and B flag not set. and B flag not set.
The MDHCP Client MUST provide client identifier option when sending The MDHCP Client MUST provide client identifier option when sending
messages for multicast address assignment. The client generates a messages for multicast address assignment. The client generates a
unique key and uses that as a client identifier in the DHCPDISCOVER unique key and uses that as a client identifier in the DHCPDISCOVER
message. When the server responds to this with DHCPOFFER, it also message.
provides a cookie along with it. This cookie is generated on the
server and it uniquely identifies the transaction associated with the
multicast address(es) being offered to this client. For all the
subsequent messages, client uses this cookie as a client identifier.
Each client may be running several different multicast enabled Each client may be running several different multicast enabled
applications, and each application may require separate multicast applications, and each application may require separate multicast
address(es). Client MUST use separate unique client identifier when address(es). Client MUST use separate unique client identifier when
requesting separate multicast address(es) for each application. requesting separate multicast address(es) for each application.
A client implementation may choose to use hardware address, hardware A client implementation may choose to use hardware address, hardware
type and application instance number to generate unique client type and application instance number to generate unique client
identifier identifier. MDHCP 09/16/97
Field DHCPOFFER DHCPACK DHCPNAK Field DHCPOFFER DHCPACK DHCPNAK
----- --------- ------- ------- ----- --------- ------- -------
'ciaddr' 'ciaddr' from 'ciaddr' from 0 'ciaddr' 'ciaddr' from 'ciaddr' from 0
DHCPDISCOVER or 0 DHCPREQUEST or 0 DHCPDISCOVER or 0 DHCPREQUEST or 0
'yiaddr' Starting address of Starting address of 0 'yiaddr' Starting address of Starting address of 0
the multicast block the multicast block the multicast block the multicast block
assigned to client assigned to client assigned to client assigned to client
'siaddr' Server's IP address Server's IP address 0 'siaddr' Server's IP address Server's IP address 0
reachable from the reachable from the reachable from the reachable from the
client. client. client. client.
'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from 'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from
client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
message message message message message message
'file' may contain options may contain options (unused) 'file' may contain options may contain options (unused)
'options' options options 'options' options options
Option DHCPOFFER DHCPACK DHCPNAK Option DHCPOFFER DHCPACK DHCPNAK
------ --------- ------- ------- ------ --------- ------- -------
IP address lease time MUST MUST (DHCPREQUEST) MUST NOT IP address lease time MUST MUST (DHCPREQUEST) MUST NOT
Server identifier MUST MUST MUST Server identifier MUST MUST MUST
Multicast TTL MUST MUST MUST NOT Multicast TTL MUST MUST MUST NOT
Multicast Block size MAY MAY MUST NOT Multicast Block size MAY MAY MUST NOT
Cookie MUST MAY MUST NOT Cookie MUST MAY MUST NOT
Table 1: Fields and options that are different in Table 1: Fields and options that are different in
multicast DHCP server messages. multicast DHCP server messages. MDHCP 09/16/97
Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE, Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
DHCPRELEASE DHCPRELEASE
----- ------------ ----------- ----------- ----- ------------ ----------- -----------
'flags' Set 'M' Bit. set 'M' Bit set 'M' bit 'flags' Set 'M' Bit. set 'M' Bit set 'M' bit
BROADCAST bit 0 BROADCAST bit 0 BROADCAST bit 0 BROADCAST bit 0 BROADCAST bit 0 BROADCAST bit 0
'ciaddr' client's network client's network 0 'ciaddr' client's network client's network 0
addr reachable addr reachable addr reachable addr reachable
from the server from the server from the server from the server
'chaddr' may contain may contain may contain 'chaddr' may contain may contain may contain
hardware address hardware address hardware address hardware address hardware address hardware address
'options' options options (unused) 'options' options options (unused)
Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE, Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
DHCPRELEASE DHCPRELEASE
------ ------------ ----------- ----------- ------ ------------ ----------- -----------
Requested IP address MAY MUST (in MUST Requested IP address MAY MUST (in MUST
SELECTING or (DHCPDECLINE), SELECTING or (DHCPDECLINE),
INIT-REBOOT) MUST NOT INIT-REBOOT) MUST NOT
MUST NOT (in (DHCPRELEASE) MUST NOT (in (DHCPRELEASE)
BOUND or BOUND or
RENEWING) RENEWING)
Start time MAY MAY MUST NOT Start time MAY MAY MUST NOT
Client identifier MUST MUST MAY Client identifier MUST MUST MAY
Table 2: Fields and options that are different in Table 2: Fields and options that are different in
multicast DHCP client messages multicast DHCP client messages
skipping to change at page 10, line ? skipping to change at line 463
INIT-REBOOT) MUST NOT INIT-REBOOT) MUST NOT
MUST NOT (in (DHCPRELEASE) MUST NOT (in (DHCPRELEASE)
BOUND or BOUND or
RENEWING) RENEWING)
Start time MAY MAY MUST NOT Start time MAY MAY MUST NOT
Client identifier MUST MUST MAY Client identifier MUST MUST MAY
Table 2: Fields and options that are different in Table 2: Fields and options that are different in
multicast DHCP client messages multicast DHCP client messages
--------------------------------------------------------------------- --------------------------------------------------------------------
| |INIT-REBOOT |SELECTING |RENEWING|REBINDING | | |INIT-REBOOT |SELECTING |RENEWING|REBINDING |
---------------------------------------------------------------------
--------------------------------------------------------------------
|multi/unicast |multicast |multicast if |unicast |multicast | |multi/unicast |multicast |multicast if |unicast |multicast |
| | |multicast DISCOVER| | | | | |multicast DISCOVER| | |
| | |unicast otherwise | | | | | |unicast otherwise | | |
|server-ip |MUST NOT |MUST |MUST NOT|MUST NOT | |server-ip |MUST NOT |MUST |MUST NOT|MUST NOT |
|requested-ip |MUST |MUST |MUST NOT|MUST NOT | |requested-ip |MUST |MUST |MUST NOT|MUST NOT |
|ciaddr |IP addr |IP addr |IP addr |IP address| |ciaddr |IP addr |IP addr |IP addr |IP address|
--------------------------------------------------------------------- ---------------------------------------------------------------------
Table 3: Client messages from different states Table 3: Client messages from different states MDHCP 09/16/97
3.1 DHCPDISCOVER Message. 3.1. DHCPDISCOVER Message.
If the unicast address of a MDHCP server is known and it supports If the unicast address of a MDHCP server is known and it supports
the desired multicast scope, the MDHCP client SHOULD send a the desired multicast scope, the MDHCP client SHOULD send a
DHCPDISCOVER address to the MDHCP server. If the MDHCP server fails DHCPDISCOVER address to the MDHCP server. If the MDHCP server fails
to allocate address(es) or fails to respond, the DHCP client SHOULD to allocate address(es) or fails to respond, the DHCP client SHOULD
send a multicast DHCPDISCOVER message to the group address send a multicast DHCPDISCOVER message to the group address
(multicast) of the MDHCP server. In both cases, if the client uses (multicast) of the MDHCP server. In both cases, if the client uses
non-standard DHCP port number, it MUST specify the client port non-standard DHCP port number, it MUST specify the client port
option. The client MUST also specify its IP address in the ciaddr option. The client MUST also specify its IP address in the ciaddr
field so that the MDHCP server and respond to the client request 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 with a unicast message. The B flag must not be set and M flag MUST
be set. be set.
The client MUST include client identifier option. The client MUST include client identifier option.
In addition, the DHCPDISCOVER option SHOULD include the following In addition, the DHCPDISCOVER option SHOULD include the following
options: options:
o DHCP Scope, o DHCP Scope,
o Start time, o Start time,
o Lease time (duration) o Lease time (duration)
If any of these options are not specified, the DHCP server If any of these options are not specified, the DHCP server
may assume default values. may assume default values.
3.2 DHCPOFFER Message. 3.2. DHCPOFFER Message.
The DHCP server may respond to a DHCPDISCOVER message with a The DHCP server may respond to a DHCPDISCOVER message with a
unicast DHCPOFFER the client. This message MUST includes an unicast DHCPOFFER the client. This message MUST includes an
available multicast address using ``yiaddr'' field. The available multicast address using ``yiaddr'' field. The
MDHCP server SHOULD reserve the offered address. When allocating MDHCP server SHOULD reserve the offered address. When allocating
the address, the server MUST make every effort to ensure that the the address, the server MUST make every effort to ensure that the
address is not in use for the lease period. address is not in use for the lease period.
The server MUST include configuration parameters such as DHCP The server MUST include configuration parameters such as DHCP
scope, start and lease time, in the DHCPOFFER message, if different scope, start and lease time, in the DHCPOFFER message, if different
from the ones requested. The MDHCP server must specify a cookie from the ones requested. The MDHCP server must specify a cookie
value in this message and this cookie MUST be specified in all the value in this message and this cookie MUST be specified in all the
subsequent messages exchanged between the MDHCP clients and server subsequent messages exchanged between the MDHCP clients and server
pertaining to associated address(es). The MDHCP server MUST use the pertaining to associated address(es). The MDHCP server MUST use the
cookie to identify the addresses instead of the client IP address.
cookie to identify the addresses instead of the client IP 3.3. DHCPREQUEST
address.
3.3 DHCPREQUEST The client will select a multicast address(es) from a DHCPOFFER MDHCP 09/16/97
The client will select a multicast address(es) from a DHCPOFFER
response. The client SHOULD send a unicast DHCPREQUEST message response. The client SHOULD send a unicast DHCPREQUEST message
indicating the selected multicast address(es) to the MDHCP server, indicating the selected multicast address(es) to the MDHCP server,
when the DHCPOFFER was in response to a unicast DHCPDISCOVER when the DHCPOFFER was in response to a unicast DHCPDISCOVER
message, and using a multicast message, when the DHCPOFFER was in message, and using a multicast message, when the DHCPOFFER was in
response to a multicast address. It MUST include multicast address response to a multicast address. It MUST include multicast address
option field in the response. If the number of address selected are option field in the response. If the number of address selected are
different from the number of offerred address, the client MUST also different from the number of offered address, the client MUST also
include the multicast block size option. include the multicast block size option.
The M flag MUST be set and B flag MUST NOT be set. The M flag MUST be set and B flag MUST NOT be set.
3.4 DHCPACK. 3.4. DHCPACK.
If the multicast address(es) are still available, the MDHCP server If the multicast address(es) are still available, the MDHCP server
MUST reserve the address and send a DHCPACK message. Any MUST reserve the address and send a DHCPACK message. Any
configuration parameters in the DHCPACK message SHOULD NOT conflict configuration parameters in the DHCPACK message SHOULD NOT conflict
with the ones in earlier DHCPOFFER message. The M flag MUST be set with the ones in earlier DHCPOFFER message. The M flag MUST be set
and B flag MUST NOT be set. and B flag MUST NOT be set.
3.5 DHCPNACK 3.5. DHCPNACK
The server MAY choose to mark the multicast address in DHCPOFFER The server MAY choose to mark the multicast address in DHCPOFFER
unavailable to the client. In that case it will send DHCPNACK 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. message. The M flag MUST be set and B flag MUST NOT be set.
3.6 Renewing and termination of lease 3.6. Renewing and termination of lease
The client may choose to release address(es) before the lease time The client may choose to release address(es) before the lease time
has expired. The usual DHCP messages are used for this purpose. 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 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 client port option SHOULD be specified, if the client is using a
port different from the standard DHCP port. The cookie MUST be port different from the standard DHCP port. The cookie MUST be
specified with RENEW and RELEASE messages. specified with RENEW and RELEASE messages.
4. Examples of usage 4. Examples of usage
The MDHCP server is not required to be co-located with a DHCP The MDHCP server is not required to be co-located with a DHCP
skipping to change at page 11, line 53 skipping to change at line 573
port different from the standard DHCP port. The cookie MUST be port different from the standard DHCP port. The cookie MUST be
specified with RENEW and RELEASE messages. specified with RENEW and RELEASE messages.
4. Examples of usage 4. Examples of usage
The MDHCP server is not required to be co-located with a DHCP The MDHCP server is not required to be co-located with a DHCP
server. Therefore, in a typical deployment, there may be fewer server. Therefore, in a typical deployment, there may be fewer
MDHCP servers then the DHCP servers. We consider specific examples MDHCP servers then the DHCP servers. We consider specific examples
of DHCP configurations and the use of MDHCP protocol extensions. of DHCP configurations and the use of MDHCP protocol extensions.
4.1 One MDHCP server 4.1. One MDHCP server MDHCP 09/16/97
There is one MDHCP server which is configured to allocate multicast There is one MDHCP server which is configured to allocate multicast
addresses to a client and there may be many DHCP servers. The DHCP addresses to a client and there may be many DHCP servers. The DHCP
servers should be configured to provide the address of the MDHCP servers should be configured to provide the address of the MDHCP
server capable of allocating multicast address to the MDHCP client, server capable of allocating multicast address to the MDHCP client,
and should include a multicast scope list supported by the MDHCP and should include a multicast scope list supported by the MDHCP
server. The client may obtain the DHCP server address and scope server. The client may obtain the DHCP server address and scope
list through DHCP client configuration procedure (and may use list through DHCP client configuration procedure (and may use
DHCPINFORM message). The client then selects a multicast scope from DHCPINFORM message). The client then selects a multicast scope from
which the multicast address is to be requested and sends out a which the multicast address is to be requested and sends out a
unicast DHCPDISCOVER address and includes multicast scope, start unicast DHCPDISCOVER address and includes multicast scope, start
time, and lease time information using DHCP options. It time, and lease time information using DHCP options. It
may also specify multicast block size. The MDHCP server may also specify multicast block size. The MDHCP server
responds with an DHCPOFFER for multicast address and includes a TTL responds with an DHCPOFFER for multicast address and includes a TTL
value to be used with this address. The client sends out a value to be used with this address. The client sends out a
DHCPREQUEST message and includes the selected. If the address is DHCPREQUEST message and includes the selected. If the address is
still available, the server responds with an DHCPACK message, else still available, the server responds with an DHCPACK message, else
responds with a NACK message. responds with a NACK message.
Since the DHCP messages are directly send to the MDHCP server, the Since the DHCP messages are directly send to the MDHCP server, the
server is capable of interpreting M flag and therefore, there will server is capable of interpreting M flag and therefore, there will
be no conflict between the interpretation of DHCP and MDHCP be no conflict between the interpretation of DHCP and MDHCP
skipping to change at page 12, line 25 skipping to change at line 598
may also specify multicast block size. The MDHCP server may also specify multicast block size. The MDHCP server
responds with an DHCPOFFER for multicast address and includes a TTL responds with an DHCPOFFER for multicast address and includes a TTL
value to be used with this address. The client sends out a value to be used with this address. The client sends out a
DHCPREQUEST message and includes the selected. If the address is DHCPREQUEST message and includes the selected. If the address is
still available, the server responds with an DHCPACK message, else still available, the server responds with an DHCPACK message, else
responds with a NACK message. responds with a NACK message.
Since the DHCP messages are directly send to the MDHCP server, the Since the DHCP messages are directly send to the MDHCP server, the
server is capable of interpreting M flag and therefore, there will server is capable of interpreting M flag and therefore, there will
be no conflict between the interpretation of DHCP and MDHCP be no conflict between the interpretation of DHCP and MDHCP
messages. messages. MDHCP 09/16/97
Client Server
(selected)
Client Server (selected)
v v v v
| | | |
Obtain IP address | Obtain IP address |
| | | |
| | | |
Begin multicast address request| Begin multicast address request|
| | | |
| | | |
|\_____________ | |\_____________ |
| DHCPDISCOVER \| | DHCPDISCOVER \|
| | | |
| Determines | Determines
| address(es) | address(es)
| | | |
| ____________/| | ____________/|
| /DHCPOFFER | | /DHCPOFFER |
|/ | |/ |
| | | |
\| | \| |
Selects Address(es) | Selects Address(es) |
| | | |
|\_____________ | |\_____________ |
| DHCPREQUEST \| | DHCPREQUEST \|
| | | |
| Commits address(es) | Commits address(es)
| | | |
| _____________/| | _____________/|
|/ DHCPACK | |/ DHCPACK |
| | | |
assignment complete | assignment complete |
| | | |
. . . .
. . . .
| | | |
Graceful release | Graceful release |
| | | |
|\_____________ | |\_____________ |
| DHCPRELEASE \| | DHCPRELEASE \|
| | | |
| Discards lease | Discards lease
| | | |
v v v v
Figure 1: Timeline diagram of messages exchanged between MDHCP Figure 1: Timeline diagram of messages exchanged between MDHCP
client and servers when allocating multicast client and servers when allocating multicast address(es) using
address(es) using unicast messages to a MDHCP capable unicast messages to a MDHCP capable server. MDHCP 09/16/97
server.
4.2 One or more MDHCP servers 4.2. One or more MDHCP servers
If one or more MDHCP servers are available to a MDHCP client for If one or more MDHCP servers are available to a MDHCP client for
the purpose of assigning multicast addresses, the DHCP scope list the purpose of assigning multicast addresses, the DHCP scope list
option SHOULD specify an administratively scoped group address used option SHOULD specify an administratively scoped group address used
by the MDHCP servers to receive DHCPDISCOVER messages. Each scope by the MDHCP servers to receive DHCPDISCOVER messages. Each scope
in the scope list MUST be supported by atleast one server listening in the scope list MUST be supported by atleast one server listening
to the group multicast address used by MDHCP servers. to the group multicast address used by MDHCP servers.
The client SHOULD select a scope and send out a DHCPDISCOVER, The client SHOULD select a scope and send out a DHCPDISCOVER,
DHCPREQUEST messages to the group multicast address. The multicast DHCPREQUEST messages to the group multicast address. The multicast
DHCPREQUEST message is only received by the MDHCP capable DHCP DHCPREQUEST message is only received by the MDHCP capable DHCP
servers, and therefore, there is no conflict between the MDHCP and servers, and therefore, there is no conflict between the MDHCP and
DHCP messages. Further, the messages for renewing and releasing DHCP messages. Further, the messages for renewing and releasing
lease are sent directly to the MDHCP servers only, and therefore, lease are sent directly to the MDHCP servers only, and therefore,
there is conflict between DHCP and MDHCP message interpretation by there is conflict between DHCP and MDHCP message interpretation by
a non-MDHCP capable server. a non-MDHCP capable server.
A summary of fields of MDHCP in messages that are different from A summary of fields of MDHCP in messages that are different from
the corresponding DHCP [1] messages are specified in Tables 1 to 3. 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 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 MDHCP capable server, and may also be aware of the group multicast
skipping to change at page 14, line 30 skipping to change at line 680
there is conflict between DHCP and MDHCP message interpretation by there is conflict between DHCP and MDHCP message interpretation by
a non-MDHCP capable server. a non-MDHCP capable server.
A summary of fields of MDHCP in messages that are different from A summary of fields of MDHCP in messages that are different from
the corresponding DHCP [1] messages are specified in Tables 1 to 3. 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 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 MDHCP capable server, and may also be aware of the group multicast
address of the MDHCP capable servers. In that case, the client address of the MDHCP capable servers. In that case, the client
SHOULD first try to use the unicast address, and if unsuccessful, SHOULD first try to use the unicast address, and if unsuccessful,
SHOULD try the group multicast address for MDHCP servers. SHOULD try the group multicast address for MDHCP servers. MDHCP 09/16/97
Server Client Server Server Client Server
(not selected) (selected) (not selected) (selected)
v v v v v v
| | | | | |
| Obtain IP address | | Obtain IP address |
| | | | | |
| | |
|Begin multicast address request| |Begin multicast address request|
| | | | | |
| | |
| _____________/|\_____________ | | _____________/|\_____________ |
|/ DHCPDISCOVER | DHCPDISCOVER \| |/ DHCPDISCOVER | DHCPDISCOVER \|
| | | | | |
Determines | Determines Determines | Determines
address(es) | address(es) address(es) | address(es)
| | | | | |
|\ | ____________/| |\ | ____________/|
| \_________ | /DHCPOFFER | | \_________ | /DHCPOFFER |
| DHCPOFFER\ |/ | | DHCPOFFER\ |/ |
| \ | | | \ | |
| Collects replies | | Collects replies |
| \| | | \| |
| Selects Address(es) | | Selects Address(es) |
| | | | | |
| _____________/|\_____________ | | _____________/|\_____________ |
|/ DHCPREQUEST | DHCPREQUEST \| |/ DHCPREQUEST | DHCPREQUEST \|
| | | | | |
| | Commits address(es) | | Commits address(es)
| | | | | |
| | _____________/| | | _____________/|
| |/ DHCPACK | | |/ DHCPACK |
| | | | | |
| assignment complete | | assignment complete |
| | | | | |
. . . . . .
. . .
| | | | | |
| Graceful release | | Graceful release |
| | | | | |
| |\_____________ | | |\_____________ |
| | DHCPRELEASE \| | | DHCPRELEASE \|
| | | | | |
| | Discards lease | | Discards lease
| | | | | |
v v v v v v
Figure 2: Timeline diagram of messages exchanged between MDHCP Figure 2: Timeline diagram of messages exchanged between MDHCP
client and servers when allocating multicast client and servers when allocating multicast
address(es) using group multicast address for MDHCP address(es) using group multicast address for MDHCP
capable servers. capable servers. MDHCP 09/16/97
5. MDHCP Protocol properties 5. MDHCP Protocol properties
Conflict free address allocation: In the intranet case, each MDHCP Conflict free address allocation: In the intranet case, each MDHCP
server is allocated part of the administratively scoped address server is allocated part of the administratively scoped address
space. As long as the address space managed by MDHCP servers is space. As long as the address space managed by MDHCP servers is
non-overlapping for a given administratrices scope, the protocol non-overlapping for a given administrative scope, the protocol
will allocate conflict free addresses. MDHCP protocol does not will allocate conflict free addresses. MDHCP protocol does not
directly address the mechanisms for determining address allocation directly address the mechanisms for determining address allocation
outside Intranet. However, we propose to use MDHCP as a front end outside Intranet. However, we propose to use MDHCP as a front end
to any future address allocation protocol for the to any future address allocation protocol for the
Internet. The MDHCP protocol will preserve conflict free address Internet. The MDHCP protocol will preserve conflict free address
allocation property of the internet multicast address allocation allocation property of the internet multicast address allocation
protocol. protocol.
Session protocol independence: The MDHCP protocol does not dictate Session protocol independence: The MDHCP protocol does not dictate
use of the address allocated, and does not rely on any session use of the address allocated, and does not rely on any session
control protocol. Therefore, it will work with SIP or SAP based control protocol. Therefore, it will work with SIP or SAP based
session control protocol. session control protocol.
Small response time: The response time for MDHCP protocol is Small response time: The response time for MDHCP protocol is
strictly based on the network propagation delay and the load on the strictly based on the network propagation delay and the load on the
MDHCP server. MDHCP server.
The MDHCP protocol does not require a client system to be on all The MDHCP protocol does not require a client system to be on all
the time. Thus, it poses no additional requirements on power the time. Thus, it poses no additional requirements on power
managed systems. managed systems.
skipping to change at page 16, line 35 skipping to change at line 767
strictly based on the network propagation delay and the load on the strictly based on the network propagation delay and the load on the
MDHCP server. MDHCP server.
The MDHCP protocol does not require a client system to be on all The MDHCP protocol does not require a client system to be on all
the time. Thus, it poses no additional requirements on power the time. Thus, it poses no additional requirements on power
managed systems. managed systems.
Multicast address scopes: The administratively scoped multicast Multicast address scopes: The administratively scoped multicast
address may be directly allocated by MDHCP server. However, it is address may be directly allocated by MDHCP server. However, it is
envisioned that the MDHCP protocol will be indirectly used for envisioned that the MDHCP protocol will be indirectly used for
Internet wide Multicast addresses allocation. In such deployment, Internet wide Multicast addresses allocation. In such deployment,
the MDHCP server will act as a front-end to future Internet the MDHCP server will act as a front-end to future Internet
multicast address allocation protocols. multicast address allocation protocols.
Efficient use of address space: The multicast address space may be Efficient use of address space: The multicast address space may be
statically partitioned between MDHCP servers to provide sufficient statically partitioned between MDHCP servers to provide sufficient
reliability and load management on servers. However, the multicast reliability and load management on servers. However, the multicast
based address request will be able to obtain addresses from any of based address request will be able to obtain addresses from any of
the available servers. Alternately, the MDHCP server can be the available servers. Alternately, the MDHCP server can be
organized hierarchically where a master server allocates blocks of organized hierarchically where a master server allocates blocks of
addresses to the child servers (using MDHCP protocol). It is also addresses to the child servers (using MDHCP protocol). It is also
possible to provide further fault-tolerance using DHCP server-server possible to provide further fault-tolerance using DHCP server-server
protocol. protocol. MDHCP 09/16/97
6. Acknowledgements 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.
The authors would like to thank Thomas Pfenning, Rajeev Byrisetty, 7. Acknowledgements
and Ramesh Vyaghrapuri for their assistance in creating this
document.
7. References 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.
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC1541, 8. References
October 1993
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC1541,
October 1993.
[2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 1533, Lachman Technology, Inc., Bucknell Extensions", RFC 1533, Lachman Technology, Inc., Bucknell
University, October 1993. University, October 1993.
[3] Patel, B., and Shah, M., ``Multicast address allocation [3] Patel, B., and Shah, M., ``Multicast address allocation
extensions options'' extensions options'' <draft-ietf-dhc-multopt-00.txt>
<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
[4] Meyer, D., ``Administratively scoped IP Multicast'', Internet draft, implementation'',
<draft-ietf-mboned-admin-ip-space-01.txt>
7. Author's Address 9. Author's Address
Baiju V. Patel Baiju V. Patel
Intel Corp. Intel Corp.
2111 NE 25th Ave. 2111 NE 25th Ave.
Hillsboro, OR 97124 Hillsboro, OR 97124
Phone: 503 264 2422 Phone: 503 264 2422
EMail: baiju@ibeam.intel.com EMail: baiju@mailbox.jf.intel.com
Munil Shah Munil Shah
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Phone:206 703 3924 Phone:206 703 3924
Email:munils@microsoft.com Email:munils@microsoft.com
This document will expire on Sept, 1997 This document will expire on Sept, 1997 MDHCP 09/16/97
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/