1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
|
Network Working Group R. Droms
Request for Comments: 1534 Bucknell University
Category: Standards Track October 1993
Interoperation Between DHCP and BOOTP
Status of this Memo
This RFC specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" for the standardization state and status
of this protocol. Distribution of this memo is unlimited.
Abstract
DHCP provides a superset of the functions provided by BOOTP. This
document describes the interactions between DHCP and BOOTP network
participants.
1. Introduction
The Dynamic Host Configuration Protocol (DHCP) provides a mechanism
for transmitting configuration parameters to hosts using the TCP/IP
protocol suite. The format of DHCP messages is based on the format
of BOOTP messages, so that, in certain circumstances, DHCP and BOOTP
participants may exchange messages. This document specifies the ways
in which DHCP and BOOTP participants may interoperate.
DHCP introduces a small change in terminology intended to clarify the
meaning of one of the fields. What was the "vendor extensions" field
in BOOTP has been re-named the "options" field in DHCP. Similarly,
the tagged data items that were used inside the BOOTP "vendor
extensions" field, which were formerly referred to as "vendor
extensions", are now termed simply "options". This document will
refer to BOOTP vendor extensions and DHCP options uniformly as
"options".
Throughout this document, DHCP messages that include a 'DHCP message
type' option will be referred to by the type of the message; e.g., a
DHCP message with 'DHCP message type' option type 1 will be referred
to as a "DHCPDISCOVER" message.
Droms [Page 1]
^L
RFC 1534 Interoperation Between DHCP and BOOTP October 1993
2. BOOTP clients and DHCP servers
The format of DHCP messages is defined to be compatible with the
format of BOOTP messages, so that existing BOOTP clients can
interoperate with DHCP servers. Any message received by a DHCP
server that includes a 'DHCP message type' (51) option is assumed to
have been sent by a DHCP client. Messages without the DHCP Message
Type option are assumed to have been sent by a BOOTP client. Support
of BOOTP clients by a DHCP server is optional at the discretion of
the local system administrator. If a DHCP server that is not
configured to support BOOTP clients receives a BOOTREQUEST message
from a BOOTP client, that server silently discards the BOOTREQUEST
message.
If a DHCP server is configured to support BOOTP clients, it may be
configured to supply static addresses, automatic addresses or both.
Static addresses are those that have been previously assigned by a
system administrator and are stored in a database available to the
DHCP server. Automatic addresses are those selected by the DHCP
server from its pool of unassigned addresses.
Since BOOTP clients may not be prepared to receive automatic
addresses, the decision to allow a DHCP server to return automatic
addresses must be under the control of the system administrator. If
a DHCP server supports supplying automatic addresses to BOOTP
clients, this feature must be configurable, and the feature must
default off. Enabling of the feature must be the result of an active
decision by the system administrator.
If a DHCP server returns a automatic address, the BOOTP client will
not be aware of the DHCP lease mechanism for network address
assignment. Thus the DHCP server must assign an infinite lease
duration to for automatic addresses assigned to BOOTP clients. Such
network addresses cannot be automatically reassigned by the server.
The local system administrator may choose to manually release network
addresses assigned to BOOTP clients.
A DHCP server that supports BOOTP clients MUST interact with BOOTP
clients according to the BOOTP protocol. The server MUST formulate a
BOOTP BOOTREPLY message rather than a DHCP DHCPOFFER message (i.e.,
the server MUST NOT include the 'DHCP message type' option and MUST
NOT exceed the size limit for BOOTREPLY messages). The server marks
a binding for a BOOTP client as BOUND after sending the BOOTP
BOOTREPLY, as a non-DHCP client will not send a DHCPREQUEST message
nor will that client expect a DHCPACK message.
DHCP servers MAY send any DHCP Options to a BOOTP client as allowed
by the "DHCP Options and BOOTP Vendor Extensions" RFC [2].
Droms [Page 2]
^L
RFC 1534 Interoperation Between DHCP and BOOTP October 1993
In summary, a DHCP server:
o MAY support BOOTP clients,
o May return automatic addresses to BOOTP clients,
o MUST provide a configuration switch if returning automatic
addresses to BOOTP clients,
o MUST default this optional configuration to OFF,
o MUST abide by the BOOTP specification when interacting with
BOOTP clients, and
o MAY send DHCP options (those options defined in the DHCP options
document but not in the BOOTP vendor extensions documents) to
a BOOTP client.
3. DHCP clients and BOOTP servers
A DHCP client MAY use a reply from a BOOTP server if the
configuration returned from the BOOTP server is acceptable to the
DHCP client. A DHCP client MUST assume that an IP address returned
in a message from a BOOTP server has an infinite lease. A DHCP
client SHOULD choose to use a reply from a DHCP server in preference
to a reply from a BOOTP server.
4. References
[1] Wimer, W., "Clarifications and Extensions for the Bootstrap
Protocol", RFC 1532, Carnegie Mellon University, October 1993.
[2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 1533, Lachman Technology, Inc., Bucknell
University, October 1993.
[3] Droms, R., "Dynamic Host Configuration Protocol", RFC 1531,
Bucknell University, October 1993.
5. Security Considerations
Security issues are not discussed in this memo.
Droms [Page 3]
^L
RFC 1534 Interoperation Between DHCP and BOOTP October 1993
6. Author's Address
Ralph Droms
Computer Science Department
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837
Phone:(717) 524-1145
EMail: droms@bucknell.edu
Droms [Page 4]
^L
|
