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/ |