File: rfc2131.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (2523 lines) | stat: -rw-r--r-- 113,738 bytes parent folder | download | duplicates (17)
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
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523






Network Working Group                                           R. Droms
Request for Comments: 2131                           Bucknell University
Obsoletes: 1541                                               March 1997
Category: Standards Track

                  Dynamic Host Configuration Protocol

Status of this memo

   This document 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" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   The Dynamic Host Configuration Protocol (DHCP) provides a framework
   for passing configuration information to hosts on a TCPIP network.
   DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the
   capability of automatic allocation of reusable network addresses and
   additional configuration options [19].  DHCP captures the behavior of
   BOOTP relay agents [7, 21], and DHCP participants can interoperate
   with BOOTP participants [9].

Table of Contents

   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .  2
   1.1 Changes to RFC1541. . . . . . . . . . . . . . . . . . . . . .  3
   1.2 Related Work. . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.3 Problem definition and issues . . . . . . . . . . . . . . . .  4
   1.4 Requirements. . . . . . . . . . . . . . . . . . . . . . . . .  5
   1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  6
   1.6 Design goals. . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.  Protocol Summary. . . . . . . . . . . . . . . . . . . . . . .  8
   2.1 Configuration parameters repository . . . . . . . . . . . . . 11
   2.2 Dynamic allocation of network addresses . . . . . . . . . . . 12
   3.  The Client-Server Protocol. . . . . . . . . . . . . . . . . . 13
   3.1 Client-server interaction - allocating a network address. . . 13
   3.2 Client-server interaction - reusing a  previously allocated
       network address . . . . . . . . . . . . . . . . . . . . . . . 17
   3.3 Interpretation and representation of time values. . . . . . . 20
   3.4 Obtaining parameters with externally configured network
       address . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
   3.5 Client parameters in DHCP . . . . . . . . . . . . . . . . . . 21
   3.6 Use of DHCP in clients with multiple interfaces . . . . . . . 22
   3.7 When clients should use DHCP. . . . . . . . . . . . . . . . . 22
   4.  Specification of the DHCP client-server protocol. . . . . . . 22



Droms                       Standards Track                     [Page 1]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   4.1 Constructing and sending DHCP messages. . . . . . . . . . . . 22
   4.2 DHCP server administrative controls . . . . . . . . . . . . . 25
   4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 26
   4.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . . 34
   5.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .42
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .42
   7.  Security Considerations. . . . . . . . . . . . . . . . . . . .43
   8.  Author's Address . . . . . . . . . . . . . . . . . . . . . . .44
   A.  Host Configuration Parameters  . . . . . . . . . . . . . . . .45
List of Figures
   1. Format of a DHCP message . . . . . . . . . . . . . . . . . . .  9
   2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 11
   3. Timeline diagram of messages exchanged between DHCP client and
      servers when allocating a new network address. . . . . . . . . 15
   4. Timeline diagram of messages exchanged between DHCP client and
      servers when reusing a previously allocated network address. . 18
   5. State-transition diagram for DHCP clients. . . . . . . . . . . 34
List of Tables
   1. Description of fields in a DHCP message. . . . . . . . . . . . 10
   2. DHCP messages. . . . . . . . . . . . . . . . . . . . . . . . . 14
   3. Fields and options used by DHCP servers. . . . . . . . . . . . 28
   4. Client messages from various states. . . . . . . . . . . . . . 33
   5. Fields and options used by DHCP clients. . . . . . . . . . . . 37

1. Introduction

   The Dynamic Host Configuration Protocol (DHCP) provides configuration
   parameters to Internet hosts.  DHCP consists of two components: a
   protocol for delivering host-specific configuration parameters from a
   DHCP server to a host and a mechanism for allocation of network
   addresses to hosts.

   DHCP is built on a client-server model, where designated DHCP server
   hosts allocate network addresses and deliver configuration parameters
   to dynamically configured hosts.  Throughout the remainder of this
   document, the term "server" refers to a host providing initialization
   parameters through DHCP, and the term "client" refers to a host
   requesting initialization parameters from a DHCP server.

   A host should not act as a DHCP server unless explicitly configured
   to do so by a system administrator.  The diversity of hardware and
   protocol implementations in the Internet would preclude reliable
   operation if random hosts were allowed to respond to DHCP requests.
   For example, IP requires the setting of many parameters within the
   protocol implementation software.  Because IP can be used on many
   dissimilar kinds of network hardware, values for those parameters
   cannot be guessed or assumed to have correct defaults.  Also,
   distributed address allocation schemes depend on a polling/defense



Droms                       Standards Track                     [Page 2]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   mechanism for discovery of addresses that are already in use.  IP
   hosts may not always be able to defend their network addresses, so
   that such a distributed address allocation scheme cannot be
   guaranteed to avoid allocation of duplicate network addresses.

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

   Dynamic allocation is the only one of the three mechanisms that
   allows automatic reuse of an address that is no longer needed by the
   client to which it was assigned.  Thus, dynamic allocation is
   particularly useful for assigning an address to a client that will be
   connected to the network only temporarily or for sharing a limited
   pool of IP addresses among a group of clients that do not need
   permanent IP addresses.  Dynamic allocation may also be a good choice
   for assigning an IP address to a new client being permanently
   connected to a network where IP addresses are sufficiently scarce
   that it is important to reclaim them when old clients are retired.
   Manual allocation allows DHCP to be used to eliminate the error-prone
   process of manually configuring hosts with IP addresses in
   environments where (for whatever reasons) it is desirable to manage
   IP address assignment outside of the DHCP mechanisms.

   The format of DHCP messages is based on the format of BOOTP messages,
   to capture the BOOTP relay agent behavior described as part of the
   BOOTP specification [7, 21] and to allow interoperability of existing
   BOOTP clients with DHCP servers.  Using BOOTP relay agents eliminates
   the necessity of having a DHCP server on each physical network
   segment.

1.1 Changes to RFC 1541

   This document updates the DHCP protocol specification that appears in
   RFC1541.  A new DHCP message type, DHCPINFORM, has been added; see
   section 3.4, 4.3 and 4.4 for details.  The classing mechanism for
   identifying DHCP clients to DHCP servers has been extended to include
   "vendor" classes as defined in sections 4.2 and 4.3.  The minimum
   lease time restriction has been removed.  Finally, many editorial
   changes have been made to clarify the text as a result of experience
   gained in DHCP interoperability tests.




Droms                       Standards Track                     [Page 3]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


1.2 Related Work

   There are several Internet protocols and related mechanisms that
   address some parts of the dynamic host configuration problem.  The
   Reverse Address Resolution Protocol (RARP) [10] (through the
   extensions defined in the Dynamic RARP (DRARP) [5]) explicitly
   addresses the problem of network address discovery, and includes an
   automatic IP address assignment mechanism.  The Trivial File Transfer
   Protocol (TFTP) [20] provides for transport of a boot image from a
   boot server.  The Internet Control Message Protocol (ICMP) [16]
   provides for informing hosts of additional routers via "ICMP
   redirect" messages.  ICMP also can provide subnet mask information
   through the "ICMP mask request" message and other information through
   the (obsolete) "ICMP information request" message.  Hosts can locate
   routers through the ICMP router discovery mechanism [8].

   BOOTP is a transport mechanism for a collection of configuration
   information.  BOOTP is also extensible, and official extensions [17]
   have been defined for several configuration parameters.  Morgan has
   proposed extensions to BOOTP for dynamic IP address assignment [15].
   The Network Information Protocol (NIP), used by the Athena project at
   MIT, is a distributed mechanism for dynamic IP address assignment
   [19].  The Resource Location Protocol RLP [1] provides for location
   of higher level services.  Sun Microsystems diskless workstations use
   a boot procedure that employs RARP, TFTP and an RPC mechanism called
   "bootparams" to deliver configuration information and operating
   system code to diskless hosts.  (Sun Microsystems, Sun Workstation
   and SunOS are trademarks of Sun Microsystems, Inc.)  Some Sun
   networks also use DRARP and an auto-installation mechanism to
   automate the configuration of new hosts in an existing network.

   In other related work, the path minimum transmission unit (MTU)
   discovery algorithm can determine the MTU of an arbitrary internet
   path [14].  The Address Resolution Protocol (ARP) has been proposed
   as a transport protocol for resource location and selection [6].
   Finally, the Host Requirements RFCs [3, 4] mention specific
   requirements for host reconfiguration and suggest a scenario for
   initial configuration of diskless hosts.

1.3 Problem definition and issues

   DHCP is designed to supply DHCP clients with the configuration
   parameters defined in the Host Requirements RFCs.  After obtaining
   parameters via DHCP, a DHCP client should be able to exchange packets
   with any other host in the Internet.  The TCP/IP stack parameters
   supplied by DHCP are listed in Appendix A.





Droms                       Standards Track                     [Page 4]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   Not all of these parameters are required for a newly initialized
   client.  A client and server may negotiate for the transmission of
   only those parameters required by the client or specific to a
   particular subnet.

   DHCP allows but does not require the configuration of client
   parameters not directly related to the IP protocol.  DHCP also does
   not address registration of newly configured clients with the Domain
   Name System (DNS) [12, 13].

   DHCP is not intended for use in configuring routers.

1.4 Requirements

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

      o "MUST"

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

      o "MUST NOT"

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

      o "SHOULD"

        This word or the adjective "RECOMMENDED" means that there
        may exist valid reasons in particular circumstances to ignore
        this item, but the full implications should be understood and
        the case carefully weighed before choosing a different course.

      o "SHOULD NOT"

        This phrase means that there may exist valid reasons in
        particular circumstances when the listed behavior is acceptable
        or even useful, but the full implications should be understood
        and the case carefully weighed before implementing any behavior
        described with this label.









Droms                       Standards Track                     [Page 5]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


      o "MAY"

        This word or the adjective "OPTIONAL" means that this item is
        truly optional.  One vendor may choose to include the item
        because a particular marketplace requires it or because it
        enhances the product, for example; another vendor may omit the
        same item.

1.5 Terminology

   This document uses the following terms:

      o "DHCP client"

      A DHCP client is an Internet host using DHCP to obtain
      configuration parameters such as a network address.

      o "DHCP server"

      A DHCP server is an Internet host that returns configuration
      parameters to DHCP clients.

      o "BOOTP relay agent"

      A BOOTP relay agent or relay agent is an Internet host or router
      that passes DHCP messages between DHCP clients and DHCP servers.
      DHCP is designed to use the same relay agent behavior as specified
      in the BOOTP protocol specification.

      o "binding"

      A binding is a collection of configuration parameters, including
      at least an IP address, associated with or "bound to" a DHCP
      client.  Bindings are managed by DHCP servers.

1.6 Design goals

   The following list gives general design goals for DHCP.

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







Droms                       Standards Track                     [Page 6]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


      o Clients should require no manual configuration.  Each client
        should be able to discover appropriate local configuration
        parameters without user intervention and incorporate those
        parameters into its own configuration.

      o Networks should require no manual configuration for individual
        clients.  Under normal circumstances, the network manager
        should not have to enter any per-client configuration
        parameters.

      o DHCP should not require a server on each subnet.  To allow for
        scale and economy, DHCP must work across routers or through the
        intervention of BOOTP relay agents.

      o A DHCP client must be prepared to receive multiple responses
        to a request for configuration parameters.  Some installations
        may include multiple, overlapping DHCP servers to enhance
        reliability and increase performance.

      o DHCP must coexist with statically configured, non-participating
        hosts and with existing network protocol implementations.

      o DHCP must interoperate with the BOOTP relay agent behavior as
        described by RFC 951 and by RFC 1542 [21].

      o DHCP must provide service to existing BOOTP clients.

   The following list gives design goals specific to the transmission of
   the network layer parameters.  DHCP must:

      o Guarantee that any specific network address will not be in
        use by more than one DHCP client at a time,

      o Retain DHCP client configuration across DHCP client reboot.  A
        DHCP client should, whenever possible, be assigned the same
        configuration parameters (e.g., network address) in response
        to each request,

      o Retain DHCP client configuration across server reboots, and,
        whenever possible, a DHCP client should be assigned the same
        configuration parameters despite restarts of the DHCP mechanism,

      o Allow automated assignment of configuration parameters to new
        clients to avoid hand configuration for new clients,

      o Support fixed or permanent allocation of configuration
        parameters to specific clients.




Droms                       Standards Track                     [Page 7]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


2. Protocol Summary

   From the client's point of view, DHCP is an extension of the BOOTP
   mechanism.  This behavior allows existing BOOTP clients to
   interoperate with DHCP servers without requiring any change to the
   clients' initialization software.  RFC 1542 [2] details the
   interactions between BOOTP and DHCP clients and servers [9].  There
   are some new, optional transactions that optimize the interaction
   between DHCP clients and servers that are described in sections 3 and
   4.

   Figure 1 gives the format of a DHCP message and table 1 describes
   each of the fields in the DHCP message.  The numbers in parentheses
   indicate the size of each field in octets.  The names for the fields
   given in the figure will be used throughout this document to refer to
   the fields in DHCP messages.

   There are two primary differences between DHCP and BOOTP.  First,
   DHCP defines mechanisms through which clients can be assigned a
   network address for a finite lease, allowing for serial reassignment
   of network addresses to different clients.  Second, DHCP provides the
   mechanism for a client to acquire all of the IP configuration
   parameters that it needs in order to operate.

   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."





















Droms                       Standards Track                     [Page 8]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     op (1)    |   htype (1)   |   hlen (1)    |   hops (1)    |
   +---------------+---------------+---------------+---------------+
   |                            xid (4)                            |
   +-------------------------------+-------------------------------+
   |           secs (2)            |           flags (2)           |
   +-------------------------------+-------------------------------+
   |                          ciaddr  (4)                          |
   +---------------------------------------------------------------+
   |                          yiaddr  (4)                          |
   +---------------------------------------------------------------+
   |                          siaddr  (4)                          |
   +---------------------------------------------------------------+
   |                          giaddr  (4)                          |
   +---------------------------------------------------------------+
   |                                                               |
   |                          chaddr  (16)                         |
   |                                                               |
   |                                                               |
   +---------------------------------------------------------------+
   |                                                               |
   |                          sname   (64)                         |
   +---------------------------------------------------------------+
   |                                                               |
   |                          file    (128)                        |
   +---------------------------------------------------------------+
   |                                                               |
   |                          options (variable)                   |
   +---------------------------------------------------------------+

                  Figure 1:  Format of a DHCP message

   DHCP defines a new 'client identifier' option that is used to pass an
   explicit client identifier to a DHCP server.  This change eliminates
   the overloading of the 'chaddr' field in BOOTP messages, where
   'chaddr' is used both as a hardware address for transmission of BOOTP
   reply messages and as a client identifier.  The 'client identifier'
   is an opaque key, not to be interpreted by the server; for example,
   the 'client identifier' may contain a hardware address, identical to
   the contents of the 'chaddr' field, or it may contain another type of
   identifier, such as a DNS name.  The 'client identifier' chosen by a
   DHCP client MUST be unique to that client within the subnet to which
   the client is attached. If the client uses a 'client identifier' in
   one message, it MUST use that same identifier in all subsequent
   messages, to ensure that all servers correctly identify the client.




Droms                       Standards Track                     [Page 9]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   DHCP clarifies the interpretation of the 'siaddr' field as the
   address of the server to use in the next step of the client's
   bootstrap process.  A DHCP server may return its own address in the
   'siaddr' field, if the server is prepared to supply the next
   bootstrap service (e.g., delivery of an operating system executable
   image).  A DHCP server always returns its own address in the 'server
   identifier' option.

   FIELD      OCTETS       DESCRIPTION
   -----      ------       -----------

   op            1  Message op code / message type.
                    1 = BOOTREQUEST, 2 = BOOTREPLY
   htype         1  Hardware address type, see ARP section in "Assigned
                    Numbers" RFC; e.g., '1' = 10mb ethernet.
   hlen          1  Hardware address length (e.g.  '6' for 10mb
                    ethernet).
   hops          1  Client sets to zero, optionally used by relay agents
                    when booting via a relay agent.
   xid           4  Transaction ID, a random number chosen by the
                    client, used by the client and server to associate
                    messages and responses between a client and a
                    server.
   secs          2  Filled in by client, seconds elapsed since client
                    began address acquisition or renewal process.
   flags         2  Flags (see figure 2).
   ciaddr        4  Client IP address; only filled in if client is in
                    BOUND, RENEW or REBINDING state and can respond
                    to ARP requests.
   yiaddr        4  'your' (client) IP address.
   siaddr        4  IP address of next server to use in bootstrap;
                    returned in DHCPOFFER, DHCPACK by server.
   giaddr        4  Relay agent IP address, used in booting via a
                    relay agent.
   chaddr       16  Client hardware address.
   sname        64  Optional server host name, null terminated string.
   file        128  Boot file name, null terminated string; "generic"
                    name or null in DHCPDISCOVER, fully qualified
                    directory-path name in DHCPOFFER.
   options     var  Optional parameters field.  See the options
                    documents for a list of defined options.

           Table 1:  Description of fields in a DHCP message

   The 'options' field is now variable length. A DHCP client must be
   prepared to receive DHCP messages with an 'options' field of at least
   length 312 octets.  This requirement implies that a DHCP client must
   be prepared to receive a message of up to 576 octets, the minimum IP



Droms                       Standards Track                    [Page 10]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   datagram size an IP host must be prepared to accept [3].  DHCP
   clients may negotiate the use of larger DHCP messages through the
   'maximum DHCP message size' option.  The options field may be further
   extended into the 'file' and 'sname' fields.

   In the case of a client using DHCP for initial configuration (before
   the client's TCP/IP software has been completely configured), DHCP
   requires creative use of the client's TCP/IP software and liberal
   interpretation of RFC 1122.  The TCP/IP software SHOULD accept and
   forward to the IP layer any IP packets delivered to the client's
   hardware address before the IP address is configured; DHCP servers
   and BOOTP relay agents may not be able to deliver DHCP messages to
   clients that cannot accept hardware unicast datagrams before the
   TCP/IP software is configured.

   To work around some clients that cannot accept IP unicast datagrams
   before the TCP/IP software is configured as discussed in the previous
   paragraph, DHCP uses the 'flags' field [21].  The leftmost bit is
   defined as the BROADCAST (B) flag.  The semantics of this flag are
   discussed in section 4.1 of this document.  The remaining bits of the
   flags field are reserved for future use.  They MUST be set to zero by
   clients and ignored by servers and relay agents.  Figure 2 gives the
   format of the 'flags' field.

                                    1 1 1 1 1 1
                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |B|             MBZ             |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                B:  BROADCAST flag

                MBZ:  MUST BE ZERO (reserved for future use)

                Figure 2:  Format of the 'flags' field

2.1 Configuration parameters repository

   The first service provided by DHCP is to provide persistent storage
   of network parameters for network clients.  The model of DHCP
   persistent storage is that the DHCP service stores a key-value entry
   for each client, where the key is some unique identifier (for
   example, an IP subnet number and a unique identifier within the
   subnet) and the value contains the configuration parameters for the
   client.

   For example, the key might be the pair (IP-subnet-number, hardware-
   address) (note that the "hardware-address" should be typed by the



Droms                       Standards Track                    [Page 11]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   type of hardware to accommodate possible duplication of hardware
   addresses resulting from bit-ordering problems in a mixed-media,
   bridged network) allowing for serial or concurrent reuse of a
   hardware address on different subnets, and for hardware addresses
   that may not be globally unique.  Alternately, the key might be the
   pair (IP-subnet-number, hostname), allowing the server to assign
   parameters intelligently to a DHCP client that has been moved to a
   different subnet or has changed hardware addresses (perhaps because
   the network interface failed and was replaced). The protocol defines
   that the key will be (IP-subnet-number, hardware-address) unless the
   client explicitly supplies an identifier using the 'client
   identifier' option.           A client can query the DHCP service to
   retrieve its configuration parameters.  The client interface to the
   configuration parameters repository consists of protocol messages to
   request configuration parameters and responses from the server
   carrying the configuration parameters.

2.2 Dynamic allocation of network addresses

   The second service provided by DHCP is the allocation of temporary or
   permanent network (IP) addresses to clients.  The basic mechanism for
   the dynamic allocation of network addresses is simple: a client
   requests the use of an address for some period of time.  The
   allocation mechanism (the collection of DHCP servers) guarantees not
   to reallocate that address within the requested time and attempts to
   return the same network address each time the client requests an
   address.  In this document, the period over which a network address
   is allocated to a client is referred to as a "lease" [11].  The
   client may extend its lease with subsequent requests.  The client may
   issue a message to release the address back to the server when the
   client no longer needs the address.  The client may ask for a
   permanent assignment by asking for an infinite lease.  Even when
   assigning "permanent" addresses, a server may choose to give out
   lengthy but non-infinite leases to allow detection of the fact that
   the client has been retired.

   In some environments it will be necessary to reassign network
   addresses due to exhaustion of available addresses.  In such
   environments, the allocation mechanism will reuse addresses whose
   lease has expired.  The server should use whatever information is
   available in the configuration information repository to choose an
   address to reuse.  For example, the server may choose the least
   recently assigned address.  As a consistency check, the allocating
   server SHOULD probe the reused address before allocating the address,
   e.g., with an ICMP echo request, and the client SHOULD probe the
   newly received address, e.g., with ARP.





Droms                       Standards Track                    [Page 12]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


3. The Client-Server Protocol

   DHCP uses the BOOTP message format defined in RFC 951 and given in
   table 1 and figure 1.  The 'op' field of each DHCP message sent from
   a client to a server contains BOOTREQUEST. BOOTREPLY is used in the
   'op' field of each DHCP message sent from a server to a client.

   The first four octets of the 'options' field of the DHCP message
   contain the (decimal) values 99, 130, 83 and 99, respectively (this
   is the same magic cookie as is defined in RFC 1497 [17]).  The
   remainder of the 'options' field consists of a list of tagged
   parameters that are called "options".  All of the "vendor extensions"
   listed in RFC 1497 are also DHCP options.  RFC 1533 gives the
   complete set of options defined for use with DHCP.

   Several options have been defined so far.  One particular option -
   the "DHCP message type" option - must be included in every DHCP
   message.  This option defines the "type" of the DHCP message.
   Additional options may be allowed, required, or not allowed,
   depending on the DHCP message type.

   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.

3.1 Client-server interaction - allocating a network address

   The following summary of the protocol exchanges between clients and
   servers refers to the DHCP messages described in table 2.  The
   timeline diagram in figure 3 shows the timing relationships in a
   typical client-server interaction.  If the client already knows its
   address, some steps may be omitted; this abbreviated interaction is
   described in section 3.2.

   1. The client broadcasts a DHCPDISCOVER message on its local physical
      subnet.  The DHCPDISCOVER message MAY include options that suggest
      values for the network address and lease duration.  BOOTP relay
      agents may pass the message on to DHCP servers not on the same
      physical subnet.

   2. Each server may respond with a DHCPOFFER message that includes an
      available network address in the 'yiaddr' field (and other
      configuration parameters in DHCP options).  Servers need not
      reserve the offered network address, although the protocol will
      work more efficiently if the server avoids allocating the offered
      network address to another client.  When allocating a new address,
      servers SHOULD check that the offered network address is not



Droms                       Standards Track                    [Page 13]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


      already in use; e.g., the server may probe the offered address
      with an ICMP Echo Request.  Servers SHOULD be implemented so that
      network administrators MAY choose to disable probes of newly
      allocated addresses.  The server transmits the DHCPOFFER message
      to the client, using the BOOTP relay agent if necessary.

   Message         Use
   -------         ---

   DHCPDISCOVER -  Client broadcast to locate available servers.

   DHCPOFFER    -  Server to client in response to DHCPDISCOVER with
                   offer of configuration parameters.

   DHCPREQUEST  -  Client message to servers either (a) requesting
                   offered parameters from one server and implicitly
                   declining offers from all others, (b) confirming
                   correctness of previously allocated address after,
                   e.g., system reboot, or (c) extending the lease on a
                   particular network address.

   DHCPACK      -  Server to client with configuration parameters,
                   including committed network address.

   DHCPNAK      -  Server to client indicating client's notion of network
                   address is incorrect (e.g., client has moved to new
                   subnet) or client's lease as expired

   DHCPDECLINE  -  Client to server indicating network address is already
                   in use.

   DHCPRELEASE  -  Client to server relinquishing network address and
                   cancelling remaining lease.

   DHCPINFORM   -  Client to server, asking only for local configuration
                   parameters; client already has externally configured
                   network address.

                          Table 2:  DHCP messages












Droms                       Standards Track                    [Page 14]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


                Server          Client          Server
            (not selected)                    (selected)

                  v               v               v
                  |               |               |
                  |     Begins initialization     |
                  |               |               |
                  | _____________/|\____________  |
                  |/DHCPDISCOVER | DHCPDISCOVER  \|
                  |               |               |
              Determines          |          Determines
             configuration        |         configuration
                  |               |               |
                  |\             |  ____________/ |
                  | \________    | /DHCPOFFER     |
                  | DHCPOFFER\   |/               |
                  |           \  |                |
                  |       Collects replies        |
                  |             \|                |
                  |     Selects configuration     |
                  |               |               |
                  | _____________/|\____________  |
                  |/ DHCPREQUEST  |  DHCPREQUEST\ |
                  |               |               |
                  |               |     Commits configuration
                  |               |               |
                  |               | _____________/|
                  |               |/ DHCPACK      |
                  |               |               |
                  |    Initialization complete    |
                  |               |               |
                  .               .               .
                  .               .               .
                  |               |               |
                  |      Graceful shutdown        |
                  |               |               |
                  |               |\ ____________ |
                  |               | DHCPRELEASE  \|
                  |               |               |
                  |               |        Discards lease
                  |               |               |
                  v               v               v
     Figure 3: Timeline diagram of messages exchanged between DHCP
               client and servers when allocating a new network address







Droms                       Standards Track                    [Page 15]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


  3. The client receives one or more DHCPOFFER messages from one or more
     servers.  The client may choose to wait for multiple responses.
     The client chooses one server from which to request configuration
     parameters, based on the configuration parameters offered in the
     DHCPOFFER messages.  The client broadcasts a DHCPREQUEST message
     that MUST include the 'server identifier' option to indicate which
     server it has selected, and that MAY include other options
     specifying desired configuration values.  The 'requested IP
     address' option MUST be set to the value of 'yiaddr' in the
     DHCPOFFER message from the server.  This DHCPREQUEST message is
     broadcast and relayed through DHCP/BOOTP relay agents.  To help
     ensure that any BOOTP relay agents forward the DHCPREQUEST message
     to the same set of DHCP servers that received the original
     DHCPDISCOVER message, the DHCPREQUEST message MUST use the same
     value in the DHCP message header's 'secs' field and be sent to the
     same IP broadcast address as the original DHCPDISCOVER message.
     The client times out and retransmits the DHCPDISCOVER message if
     the client receives no DHCPOFFER messages.

  4. The servers receive the DHCPREQUEST broadcast from the client.
     Those servers not selected by the DHCPREQUEST message use the
     message as notification that the client has declined that server's
     offer.  The server selected in the DHCPREQUEST message commits the
     binding for the client to persistent storage and responds with a
     DHCPACK message containing the configuration parameters for the
     requesting client.  The combination of 'client identifier' or
     'chaddr' and assigned network address constitute a unique
     identifier for the client's lease and are used by both the client
     and server to identify a lease referred to in any DHCP messages.
     Any configuration parameters in the DHCPACK message SHOULD NOT
     conflict with those in the earlier DHCPOFFER message to which the
     client is responding.  The server SHOULD NOT check the offered
     network address at this point. The 'yiaddr' field in the DHCPACK
     messages is filled in with the selected network address.

     If the selected server is unable to satisfy the DHCPREQUEST message
     (e.g., the requested network address has been allocated), the
     server SHOULD respond with a DHCPNAK message.

     A server MAY choose to mark addresses offered to clients in
     DHCPOFFER messages as unavailable.  The server SHOULD mark an
     address offered to a client in a DHCPOFFER message as available if
     the server receives no DHCPREQUEST message from that client.

  5. The client receives the DHCPACK message with configuration
     parameters.  The client SHOULD perform a final check on the
     parameters (e.g., ARP for allocated network address), and notes the
     duration of the lease specified in the DHCPACK message.  At this



Droms                       Standards Track                    [Page 16]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


     point, the client is configured.  If the client detects that the
     address is already in use (e.g., through the use of ARP), the
     client MUST send a DHCPDECLINE message to the server and restarts
     the configuration process.  The client SHOULD wait a minimum of ten
     seconds before restarting the configuration process to avoid
     excessive network traffic in case of looping.

     If the client receives a DHCPNAK message, the client restarts the
     configuration process.

     The client times out and retransmits the DHCPREQUEST message if the
     client receives neither a DHCPACK or a DHCPNAK message.  The client
     retransmits the DHCPREQUEST according to the retransmission
     algorithm in section 4.1.  The client should choose to retransmit
     the DHCPREQUEST enough times to give adequate probability of
     contacting the server without causing the client (and the user of
     that client) to wait overly long before giving up; e.g., a client
     retransmitting as described in section 4.1 might retransmit the
     DHCPREQUEST message four times, for a total delay of 60 seconds,
     before restarting the initialization procedure.  If the client
     receives neither a DHCPACK or a DHCPNAK message after employing the
     retransmission algorithm, the client reverts to INIT state and
     restarts the initialization process.  The client SHOULD notify the
     user that the initialization process has failed and is restarting.

  6. The client may choose to relinquish its lease on a network address
     by sending a DHCPRELEASE message to the server.  The client
     identifies the lease to be released with its 'client identifier',
     or 'chaddr' and network address in the DHCPRELEASE message. If the
     client used a 'client identifier' when it obtained the lease, it
     MUST use the same 'client identifier' in the DHCPRELEASE message.

3.2 Client-server interaction - reusing a previously allocated network
    address

   If a client remembers and wishes to reuse a previously allocated
   network address, a client may choose to omit some of the steps
   described in the previous section.  The timeline diagram in figure 4
   shows the timing relationships in a typical client-server interaction
   for a client reusing a previously allocated network address.











Droms                       Standards Track                    [Page 17]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   1. The client broadcasts a DHCPREQUEST message on its local subnet.
      The message includes the client's network address in the
      'requested IP address' option. As the client has not received its
      network address, it MUST NOT fill in the 'ciaddr' field. BOOTP
      relay agents pass the message on to DHCP servers not on the same
      subnet.  If the client used a 'client identifier' to obtain its
      address, the client MUST use the same 'client identifier' in the
      DHCPREQUEST message.

   2. Servers with knowledge of the client's configuration parameters
      respond with a DHCPACK message to the client.  Servers SHOULD NOT
      check that the client's network address is already in use; the
      client may respond to ICMP Echo Request messages at this point.

                Server          Client          Server

                  v               v               v
                  |                |               |
                  |              Begins            |
                  |          initialization        |
                  |                |               |
                  |                /|\             |
                  |   _________ __/ | \__________  |
                  | /DHCPREQU EST  |  DHCPREQUEST\ |
                  |/               |              \|
                  |                |               |
               Locates             |            Locates
            configuration          |         configuration
                  |                |               |
                  |\               |              /|
                  | \              |  ___________/ |
                  |  \             | /  DHCPACK    |
                  |   \ _______    |/              |
                  |     DHCPACK\   |               |
                  |          Initialization        |
                  |             complete           |
                  |               \|               |
                  |                |               |
                  |           (Subsequent          |
                  |             DHCPACKS           |
                  |             ignored)           |
                  |                |               |
                  |                |               |
                  v                v               v

     Figure 4: Timeline diagram of messages exchanged between DHCP
               client and servers when reusing a previously allocated
               network address



Droms                       Standards Track                    [Page 18]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


      If the client's request is invalid (e.g., the client has moved
      to a new subnet), servers SHOULD respond with a DHCPNAK message to
      the client. Servers SHOULD NOT respond if their information is not
      guaranteed to be accurate.  For example, a server that identifies a
      request for an expired binding that is owned by another server SHOULD
      NOT respond with a DHCPNAK unless the servers are using an explicit
      mechanism to maintain coherency among the servers.

      If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
      the same subnet as the server.  The server MUST
      broadcast the DHCPNAK message to the 0xffffffff broadcast address
      because the client may not have a correct network address or subnet
      mask, and the client may not be answering ARP requests.
      Otherwise, the server MUST send the DHCPNAK message to the IP
      address of the BOOTP relay agent, as recorded in 'giaddr'.  The
      relay agent will, in turn, forward the message directly to the
      client's hardware address, so that the DHCPNAK can be delivered even
      if the client has moved to a new network.

   3. The client receives the DHCPACK message with configuration
      parameters.  The client performs a final check on the parameters
      (as in section 3.1), and notes the duration of the lease specified
      in the DHCPACK message.  The specific lease is implicitly identified
      by the 'client identifier' or 'chaddr' and the network address.  At
      this point, the client is configured.

      If the client detects that the IP address in the DHCPACK message
      is already in use, the client MUST send a DHCPDECLINE message to the
      server and restarts the configuration process by requesting a
      new network address.  This action corresponds to the client
      moving to the INIT state in the DHCP state diagram, which is
      described in section 4.4.

      If the client receives a DHCPNAK message, it cannot reuse its
      remembered network address.  It must instead request a new
      address by restarting the configuration process, this time
      using the (non-abbreviated) procedure described in section
      3.1.  This action also corresponds to the client moving to
      the INIT state in the DHCP state diagram.

      The client times out and retransmits the DHCPREQUEST message if
      the client receives neither a DHCPACK nor a DHCPNAK message.  The
      client retransmits the DHCPREQUEST according to the retransmission
      algorithm in section 4.1.  The client should choose to retransmit
      the DHCPREQUEST enough times to give adequate probability of
      contacting the server without causing the client (and the user of
      that client) to wait overly long before giving up; e.g., a client
      retransmitting as described in section 4.1 might retransmit the



Droms                       Standards Track                    [Page 19]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


      DHCPREQUEST message four times, for a total delay of 60 seconds,
      before restarting the initialization procedure.  If the client
      receives neither a DHCPACK or a DHCPNAK message after employing
      the retransmission algorithm, the client MAY choose to use the
      previously allocated network address and configuration parameters
      for the remainder of the unexpired lease.  This corresponds to
      moving to BOUND state in the client state transition diagram shown
      in figure 5.

   4. The client may choose to relinquish its lease on a network
      address by sending a DHCPRELEASE message to the server.  The
      client identifies the lease to be released with its
      'client identifier', or 'chaddr' and network address in the
      DHCPRELEASE message.

      Note that in this case, where the client retains its network
      address locally, the client will not normally relinquish its
      lease during a graceful shutdown.  Only in the case where the
      client explicitly needs to relinquish its lease, e.g., the client
      is about to be moved to a different subnet, will the client send
      a DHCPRELEASE message.

3.3 Interpretation and representation of time values

   A client acquires a lease for a network address for a fixed period of
   time (which may be infinite).  Throughout the protocol, times are to
   be represented in units of seconds.  The time value of 0xffffffff is
   reserved to represent "infinity".

   As clients and servers may not have synchronized clocks, times are
   represented in DHCP messages as relative times, to be interpreted
   with respect to the client's local clock.  Representing relative
   times in units of seconds in an unsigned 32 bit word gives a range of
   relative times from 0 to approximately 100 years, which is sufficient
   for the relative times to be measured using DHCP.

   The algorithm for lease duration interpretation given in the previous
   paragraph assumes that client and server clocks are stable relative
   to each other.  If there is drift between the two clocks, the server
   may consider the lease expired before the client does.  To
   compensate, the server may return a shorter lease duration to the
   client than the server commits to its local database of client
   information.

3.4 Obtaining parameters with externally configured network address

   If a client has obtained a network address through some other means
   (e.g., manual configuration), it may use a DHCPINFORM request message



Droms                       Standards Track                    [Page 20]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   to obtain other local configuration parameters.  Servers receiving a
   DHCPINFORM message construct a DHCPACK message with any local
   configuration parameters appropriate for the client without:
   allocating a new address, checking for an existing binding, filling
   in 'yiaddr' or including lease time parameters.  The servers SHOULD
   unicast the DHCPACK reply to the address given in the 'ciaddr' field
   of the DHCPINFORM message.

   The server SHOULD check the network address in a DHCPINFORM message
   for consistency, but MUST NOT check for an existing lease.  The
   server forms a DHCPACK message containing the configuration
   parameters for the requesting client and sends the DHCPACK message
   directly to the client.

3.5 Client parameters in DHCP

   Not all clients require initialization of all parameters listed in
   Appendix A.  Two techniques are used to reduce the number of
   parameters transmitted from the server to the client.  First, most of
   the parameters have defaults defined in the Host Requirements RFCs;
   if the client receives no parameters from the server that override
   the defaults, a client uses those default values.  Second, in its
   initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the
   server with a list of specific parameters the client is interested
   in.  If the client includes a list of parameters in a DHCPDISCOVER
   message, it MUST include that list in any subsequent DHCPREQUEST
   messages.

   The client SHOULD include the 'maximum DHCP message size' option to
   let the server know how large the server may make its DHCP messages.
   The parameters returned to a client may still exceed the space
   allocated to options in a DHCP message.  In this case, two additional
   options flags (which must appear in the 'options' field of the
   message) indicate that the 'file' and 'sname' fields are to be used
   for options.

   The client can inform the server which configuration parameters the
   client is interested in by including the 'parameter request list'
   option.  The data portion of this option explicitly lists the options
   requested by tag number.

   In addition, the client may suggest values for the network address
   and lease time in the DHCPDISCOVER message.  The client may include
   the 'requested IP address' option to suggest that a particular IP
   address be assigned, and may include the 'IP address lease time'
   option to suggest the lease time it would like.  Other options
   representing "hints" at configuration parameters are allowed in a
   DHCPDISCOVER or DHCPREQUEST message.  However, additional options may



Droms                       Standards Track                    [Page 21]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   be ignored by servers, and multiple servers may, therefore, not
   return identical values for some options.  The 'requested IP address'
   option is to be filled in only in a DHCPREQUEST message when the
   client is verifying network parameters obtained previously. The
   client fills in the 'ciaddr' field only when correctly configured
   with an IP address in BOUND, RENEWING or REBINDING state.

   If a server receives a DHCPREQUEST message with an invalid 'requested
   IP address', the server SHOULD respond to the client with a DHCPNAK
   message and may choose to report the problem to the system
   administrator.  The server may include an error message in the
   'message' option.

3.6 Use of DHCP in clients with multiple interfaces

   A client with multiple network interfaces must use DHCP through each
   interface independently to obtain configuration information
   parameters for those separate interfaces.

3.7 When clients should use DHCP

   A client SHOULD use DHCP to reacquire or verify its IP address and
   network parameters whenever the local network parameters may have
   changed; e.g., at system boot time or after a disconnection from the
   local network, as the local network configuration may change without
   the client's or user's knowledge.

   If a client has knowledge of a previous network address and is unable
   to contact a local DHCP server, the client may continue to use the
   previous network address until the lease for that address expires.
   If the lease expires before the client can contact a DHCP server, the
   client must immediately discontinue use of the previous network
   address and may inform local users of the problem.

4. Specification of the DHCP client-server protocol

   In this section, we assume that a DHCP server has a block of network
   addresses from which it can satisfy requests for new addresses.  Each
   server also maintains a database of allocated addresses and leases in
   local permanent storage.

4.1 Constructing and sending DHCP messages

   DHCP clients and servers both construct DHCP messages by filling in
   fields in the fixed format section of the message and appending
   tagged data items in the variable length option area.  The options
   area includes first a four-octet 'magic cookie' (which was described
   in section 3), followed by the options.  The last option must always



Droms                       Standards Track                    [Page 22]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   be the 'end' option.

   DHCP uses UDP as its transport protocol.  DHCP messages from a client
   to a server are sent to the 'DHCP server' port (67), and DHCP
   messages from a server to a client are sent to the 'DHCP client' port
   (68). A server with multiple network address (e.g., a multi-homed
   host) MAY use any of its network addresses in outgoing DHCP messages.

   The 'server identifier' field is used both to identify a DHCP server
   in a DHCP message and as a destination address from clients to
   servers.  A server with multiple network addresses MUST be prepared
   to to accept any of its network addresses as identifying that server
   in a DHCP message.  To accommodate potentially incomplete network
   connectivity, a server MUST choose an address as a 'server
   identifier' that, to the best of the server's knowledge, is reachable
   from the client.  For example, if the DHCP server and the DHCP client
   are connected to the same subnet (i.e., the 'giaddr' field in the
   message from the client is zero), the server SHOULD select the IP
   address the server is using for communication on that subnet as the
   'server identifier'.  If the server is using multiple IP addresses on
   that subnet, any such address may be used.  If the server has
   received a message through a DHCP relay agent, the server SHOULD
   choose an address from the interface on which the message was
   recieved as the 'server identifier' (unless the server has other,
   better information on which to make its choice).  DHCP clients MUST
   use the IP address provided in the 'server identifier' option for any
   unicast requests to the DHCP server.

   DHCP messages broadcast by a client prior to that client obtaining
   its IP address must have the source address field in the IP header
   set to 0.

   If the 'giaddr' field in a DHCP message from a client is non-zero,
   the server sends any return messages to the 'DHCP server' port on the
   BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr'
   field is zero and the 'ciaddr' field is nonzero, then the server
   unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'.
   If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is
   set, then the server broadcasts DHCPOFFER and DHCPACK messages to
   0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and
   'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK
   messages to the client's hardware address and 'yiaddr' address.  In
   all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK
   messages to 0xffffffff.

   If the options in a DHCP message extend into the 'sname' and 'file'
   fields, the 'option overload' option MUST appear in the 'options'
   field, with value 1, 2 or 3, as specified in RFC 1533.  If the



Droms                       Standards Track                    [Page 23]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   'option overload' option is present in the 'options' field, the
   options in the 'options' field MUST be terminated by an 'end' option,
   and MAY contain one or more 'pad' options to fill the options field.
   The options in the 'sname' and 'file' fields (if in use as indicated
   by the 'options overload' option) MUST begin with the first octet of
   the field, MUST be terminated by an 'end' option, and MUST be
   followed by 'pad' options to fill the remainder of the field.  Any
   individual option in the 'options', 'sname' and 'file' fields MUST be
   entirely contained in that field.  The options in the 'options' field
   MUST be interpreted first, so that any 'option overload' options may
   be interpreted.  The 'file' field MUST be interpreted next (if the
   'option overload' option indicates that the 'file' field contains
   DHCP options), followed by the 'sname' field.

   The values to be passed in an 'option' tag may be too long to fit in
   the 255 octets available to a single option (e.g., a list of routers
   in a 'router' option [21]).  Options may appear only once, unless
   otherwise specified in the options document.  The client concatenates
   the values of multiple instances of the same option into a single
   parameter list for configuration.

   DHCP clients are responsible for all message retransmission.  The
   client MUST adopt a retransmission strategy that incorporates a
   randomized exponential backoff algorithm to determine the delay
   between retransmissions.  The delay between retransmissions SHOULD be
   chosen to allow sufficient time for replies from the server to be
   delivered based on the characteristics of the internetwork between
   the client and the server.  For example, in a 10Mb/sec Ethernet
   internetwork, the delay before the first retransmission SHOULD be 4
   seconds randomized by the value of a uniform random number chosen
   from the range -1 to +1.  Clients with clocks that provide resolution
   granularity of less than one second may choose a non-integer
   randomization value.  The delay before the next retransmission SHOULD
   be 8 seconds randomized by the value of a uniform number chosen from
   the range -1 to +1.  The retransmission delay SHOULD be doubled with
   subsequent retransmissions up to a maximum of 64 seconds.  The client
   MAY provide an indication of retransmission attempts to the user as
   an indication of the progress of the configuration process.

   The 'xid' field is used by the client to match incoming DHCP messages
   with pending requests.  A DHCP client MUST choose 'xid's in such a
   way as to minimize the chance of using an 'xid' identical to one used
   by another client. For example, a client may choose a different,
   random initial 'xid' each time the client is rebooted, and
   subsequently use sequential 'xid's until the next reboot.  Selecting
   a new 'xid' for each retransmission is an implementation decision.  A
   client may choose to reuse the same 'xid' or select a new 'xid' for
   each retransmitted message.



Droms                       Standards Track                    [Page 24]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   Normally, DHCP servers and BOOTP relay agents attempt to deliver
   DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
   uicast delivery.  The IP destination address (in the IP header) is
   set to the DHCP 'yiaddr' address and the link-layer destination
   address is set to the DHCP 'chaddr' address.  Unfortunately, some
   client implementations are unable to receive such unicast IP
   datagrams until the implementation has been configured with a valid
   IP address (leading to a deadlock in which the client's IP address
   cannot be delivered until the client has been configured with an IP
   address).

   A client that cannot receive unicast IP datagrams until its protocol
   software has been configured with an IP address SHOULD set the
   BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
   DHCPREQUEST messages that client sends.  The BROADCAST bit will
   provide a hint to the DHCP server and BOOTP relay agent to broadcast
   any messages to the client on the client's subnet.  A client that can
   receive unicast IP datagrams before its protocol software has been
   configured SHOULD clear the BROADCAST bit to 0.  The BOOTP
   clarifications document discusses the ramifications of the use of the
   BROADCAST bit [21].

   A server or relay agent sending or relaying a DHCP message directly
   to a DHCP client (i.e., not to a relay agent specified in the
   'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags'
   field.  If this bit is set to 1, the DHCP message SHOULD be sent as
   an IP broadcast using an IP broadcast address (preferably 0xffffffff)
   as the IP destination address and the link-layer broadcast address as
   the link-layer destination address.  If the BROADCAST bit is cleared
   to 0, the message SHOULD be sent as an IP unicast to the IP address
   specified in the 'yiaddr' field and the link-layer address specified
   in the 'chaddr' field.  If unicasting is not possible, the message
   MAY be sent as an IP broadcast using an IP broadcast address
   (preferably 0xffffffff) as the IP destination address and the link-
   layer broadcast address as the link-layer destination address.

4.2 DHCP server administrative controls

   DHCP servers are not required to respond to every DHCPDISCOVER and
   DHCPREQUEST message they receive.  For example, a network
   administrator, to retain stringent control over the clients attached
   to the network, may choose to configure DHCP servers to respond only
   to clients that have been previously registered through some external
   mechanism.  The DHCP specification describes only the interactions
   between clients and servers when the clients and servers choose to
   interact; it is beyond the scope of the DHCP specification to
   describe all of the administrative controls that system
   administrators might want to use.  Specific DHCP server



Droms                       Standards Track                    [Page 25]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   implementations may incorporate any controls or policies desired by a
   network administrator.

   In some environments, a DHCP server will have to consider the values
   of the vendor class options included in DHCPDISCOVER or DHCPREQUEST
   messages when determining the correct parameters for a particular
   client.

   A DHCP server needs to use some unique identifier to associate a
   client with its lease.  The client MAY choose to explicitly provide
   the identifier through the 'client identifier' option.  If the client
   supplies a 'client identifier', the client MUST use the same 'client
   identifier' in all subsequent messages, and the server MUST use that
   identifier to identify the client.  If the client does not provide a
   'client identifier' option, the server MUST use the contents of the
   'chaddr' field to identify the client. It is crucial for a DHCP
   client to use an identifier unique within the subnet to which the
   client is attached in the 'client identifier' option.  Use of
   'chaddr' as the client's unique identifier may cause unexpected
   results, as that identifier may be associated with a hardware
   interface that could be moved to a new client.  Some sites may choose
   to use a manufacturer's serial number as the 'client identifier', to
   avoid unexpected changes in a clients network address due to transfer
   of hardware interfaces among computers.  Sites may also choose to use
   a DNS name as the 'client identifier', causing address leases to be
   associated with the DNS name rather than a specific hardware box.

   DHCP clients are free to use any strategy in selecting a DHCP server
   among those from which the client receives a DHCPOFFER message.  The
   client implementation of DHCP SHOULD provide a mechanism for the user
   to select directly the 'vendor class identifier' values.

4.3 DHCP server behavior

   A DHCP server processes incoming DHCP messages from a client based on
   the current state of the binding for that client.  A DHCP server can
   receive the following messages from a client:

      o DHCPDISCOVER

      o DHCPREQUEST

      o DHCPDECLINE

      o DHCPRELEASE

      o DHCPINFORM




Droms                       Standards Track                    [Page 26]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   Table 3 gives the use of the fields and options in a DHCP message by
   a server.  The remainder of this section describes the action of the
   DHCP server for each possible incoming message.

4.3.1 DHCPDISCOVER message

   When a server receives a DHCPDISCOVER message from a client, the
   server chooses a network address for the requesting client.  If no
   address is available, the server may choose to report the problem to
   the system administrator. If an address is available, the new address
   SHOULD be chosen as follows:

      o The client's current address as recorded in the client's current
        binding, ELSE

      o The client's previous address as recorded in the client's (now
        expired or released) binding, if that address is in the server's
        pool of available addresses and not already allocated, ELSE

      o The address requested in the 'Requested IP Address' option, if that
        address is valid and not already allocated, ELSE

      o A new address allocated from the server's pool of available
        addresses; the address is selected based on the subnet from which
        the message was received (if 'giaddr' is 0) or on the address of
        the relay agent that forwarded the message ('giaddr' when not 0).

   As described in section 4.2, a server MAY, for administrative
   reasons, assign an address other than the one requested, or may
   refuse to allocate an address to a particular client even though free
   addresses are available.

   Note that, in some network architectures (e.g., internets with more
   than one IP subnet assigned to a physical network segment), it may be
   the case that the DHCP client should be assigned an address from a
   different subnet than the address recorded in 'giaddr'.  Thus, DHCP
   does not require that the client be assigned as address from the
   subnet in 'giaddr'.  A server is free to choose some other subnet,
   and it is beyond the scope of the DHCP specification to describe ways
   in which the assigned IP address might be chosen.

   While not required for correct operation of DHCP, the server SHOULD
   NOT reuse the selected network address before the client responds to
   the server's DHCPOFFER message.  The server may choose to record the
   address as offered to the client.

   The server must also choose an expiration time for the lease, as
   follows:



Droms                       Standards Track                    [Page 27]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   o IF the client has not requested a specific lease in the
     DHCPDISCOVER message and the client already has an assigned network
     address, the server returns the lease expiration time previously
     assigned to that address (note that the client must explicitly
     request a specific lease to extend the expiration time on a
     previously assigned address), ELSE

   o IF the client has not requested a specific lease in the
     DHCPDISCOVER message and the client does not have an assigned
     network address, the server assigns a locally configured default
     lease time, ELSE

   o IF the client has requested a specific lease in the DHCPDISCOVER
     message (regardless of whether the client has an assigned network
     address), the server may choose either to return the requested
     lease (if the lease is acceptable to local policy) or select
     another lease.

Field      DHCPOFFER            DHCPACK             DHCPNAK
-----      ---------            -------             -------
'op'       BOOTREPLY            BOOTREPLY           BOOTREPLY
'htype'    (From "Assigned Numbers" RFC)
'hlen'     (Hardware address length in octets)
'hops'     0                    0                   0
'xid'      'xid' from client    'xid' from client   'xid' from client
           DHCPDISCOVER         DHCPREQUEST         DHCPREQUEST
           message              message             message
'secs'     0                    0                   0
'ciaddr'   0                    'ciaddr' from       0
                                DHCPREQUEST or 0
'yiaddr'   IP address offered   IP address          0
           to client            assigned to client
'siaddr'   IP address of next   IP address of next  0
           bootstrap server     bootstrap server
'flags'    'flags' from         'flags' from        'flags' from
           client DHCPDISCOVER  client DHCPREQUEST  client DHCPREQUEST
           message              message             message
'giaddr'   'giaddr' from        'giaddr' from       'giaddr' from
           client DHCPDISCOVER  client DHCPREQUEST  client DHCPREQUEST
           message              message             message
'chaddr'   'chaddr' from        'chaddr' from       'chaddr' from
           client DHCPDISCOVER  client DHCPREQUEST  client DHCPREQUEST
           message              message             message
'sname'    Server host name     Server host name    (unused)
           or options           or options
'file'     Client boot file     Client boot file    (unused)
           name or options      name or options
'options'  options              options



Droms                       Standards Track                    [Page 28]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


Option                    DHCPOFFER    DHCPACK            DHCPNAK
------                    ---------    -------            -------
Requested IP address      MUST NOT     MUST NOT           MUST NOT
IP address lease time     MUST         MUST (DHCPREQUEST) MUST NOT
                                       MUST NOT (DHCPINFORM)
Use 'file'/'sname' fields MAY          MAY                MUST NOT
DHCP message type         DHCPOFFER    DHCPACK            DHCPNAK
Parameter request list    MUST NOT     MUST NOT           MUST NOT
Message                   SHOULD       SHOULD             SHOULD
Client identifier         MUST NOT     MUST NOT           MAY
Vendor class identifier   MAY          MAY                MAY
Server identifier         MUST         MUST               MUST
Maximum message size      MUST NOT     MUST NOT           MUST NOT
All others                MAY          MAY                MUST NOT

           Table 3:  Fields and options used by DHCP servers

   Once the network address and lease have been determined, the server
   constructs a DHCPOFFER message with the offered configuration
   parameters.  It is important for all DHCP servers to return the same
   parameters (with the possible exception of a newly allocated network
   address) to ensure predictable client behavior regardless of which
   server the client selects.  The configuration parameters MUST be
   selected by applying the following rules in the order given below.
   The network administrator is responsible for configuring multiple
   DHCP servers to ensure uniform responses from those servers.  The
   server MUST return to the client:

   o The client's network address, as determined by the rules given
     earlier in this section,

   o The expiration time for the client's lease, as determined by the
     rules given earlier in this section,

   o Parameters requested by the client, according to the following
     rules:

        -- IF the server has been explicitly configured with a default
           value for the parameter, the server MUST include that value
           in an appropriate option in the 'option' field, ELSE

        -- IF the server recognizes the parameter as a parameter
           defined in the Host Requirements Document, the server MUST
           include the default value for that parameter as given in the
           Host Requirements Document in an appropriate option in the
           'option' field, ELSE

        -- The server MUST NOT return a value for that parameter,



Droms                       Standards Track                    [Page 29]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


     The server MUST supply as many of the requested parameters as
     possible and MUST omit any parameters it cannot provide.  The
     server MUST include each requested parameter only once unless
     explicitly allowed in the DHCP Options and BOOTP Vendor
     Extensions document.

   o Any parameters from the existing binding that differ from the Host
     Requirements Document defaults,

   o Any parameters specific to this client (as identified by
     the contents of 'chaddr' or 'client identifier' in the DHCPDISCOVER
     or DHCPREQUEST message), e.g., as configured by the network
     administrator,

   o Any parameters specific to this client's class (as identified
     by the contents of the 'vendor class identifier'
     option in the DHCPDISCOVER or DHCPREQUEST message),
     e.g., as configured by the network administrator; the parameters
     MUST be identified by an exact match between the client's vendor
     class identifiers and the client's classes identified in the
     server,

   o Parameters with non-default values on the client's subnet.

   The server MAY choose to return the 'vendor class identifier' used to
   determine the parameters in the DHCPOFFER message to assist the
   client in selecting which DHCPOFFER to accept.  The server inserts
   the 'xid' field from the DHCPDISCOVER message into the 'xid' field of
   the DHCPOFFER message and sends the DHCPOFFER message to the
   requesting client.

4.3.2 DHCPREQUEST message

   A DHCPREQUEST message may come from a client responding to a
   DHCPOFFER message from a server, from a client verifying a previously
   allocated IP address or from a client extending the lease on a
   network address.  If the DHCPREQUEST message contains a 'server
   identifier' option, the message is in response to a DHCPOFFER
   message.  Otherwise, the message is a request to verify or extend an
   existing lease.  If the client uses a 'client identifier' in a
   DHCPREQUEST message, it MUST use that same 'client identifier' in all
   subsequent messages. If the client included a list of requested
   parameters in a DHCPDISCOVER message, it MUST include that list in
   all subsequent messages.







Droms                       Standards Track                    [Page 30]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   Any configuration parameters in the DHCPACK message SHOULD NOT
   conflict with those in the earlier DHCPOFFER message to which the
   client is responding.  The client SHOULD use the parameters in the
   DHCPACK message for configuration.

   Clients send DHCPREQUEST messages as follows:

   o DHCPREQUEST generated during SELECTING state:

      Client inserts the address of the selected server in 'server
      identifier', 'ciaddr' MUST be zero, 'requested IP address' MUST be
      filled in with the yiaddr value from the chosen DHCPOFFER.

      Note that the client may choose to collect several DHCPOFFER
      messages and select the "best" offer.  The client indicates its
      selection by identifying the offering server in the DHCPREQUEST
      message.  If the client receives no acceptable offers, the client
      may choose to try another DHCPDISCOVER message.  Therefore, the
      servers may not receive a specific DHCPREQUEST from which they can
      decide whether or not the client has accepted the offer.  Because
      the servers have not committed any network address assignments on
      the basis of a DHCPOFFER, servers are free to reuse offered
      network addresses in response to subsequent requests.  As an
      implementation detail, servers SHOULD NOT reuse offered addresses
      and may use an implementation-specific timeout mechanism to decide
      when to reuse an offered address.

   o DHCPREQUEST generated during INIT-REBOOT state:

      'server identifier' MUST NOT be filled in, 'requested IP address'
      option MUST be filled in with client's notion of its previously
      assigned address. 'ciaddr' MUST be zero. The client is seeking to
      verify a previously allocated, cached configuration. Server SHOULD
      send a DHCPNAK message to the client if the 'requested IP address'
      is incorrect, or is on the wrong network.

      Determining whether a client in the INIT-REBOOT state is on the
      correct network is done by examining the contents of 'giaddr', the
      'requested IP address' option, and a database lookup. If the DHCP
      server detects that the client is on the wrong net (i.e., the
      result of applying the local subnet mask or remote subnet mask (if
      'giaddr' is not zero) to 'requested IP address' option value
      doesn't match reality), then the server SHOULD send a DHCPNAK
      message to the client.







Droms                       Standards Track                    [Page 31]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


      If the network is correct, then the DHCP server should check if
      the client's notion of its IP address is correct. If not, then the
      server SHOULD send a DHCPNAK message to the client. If the DHCP
      server has no record of this client, then it MUST remain silent,
      and MAY output a warning to the network administrator. This
      behavior is necessary for peaceful coexistence of non-
      communicating DHCP servers on the same wire.

      If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
      the same subnet as the server.  The server MUST broadcast the
      DHCPNAK message to the 0xffffffff broadcast address because the
      client may not have a correct network address or subnet mask, and
      the client may not be answering ARP requests.

      If 'giaddr' is set in the DHCPREQUEST message, the client is on a
      different subnet.  The server MUST set the broadcast bit in the
      DHCPNAK, so that the relay agent will broadcast the DHCPNAK to the
      client, because the client may not have a correct network address
      or subnet mask, and the client may not be answering ARP requests.

   o DHCPREQUEST generated during RENEWING state:

      'server identifier' MUST NOT be filled in, 'requested IP address'
      option MUST NOT be filled in, 'ciaddr' MUST be filled in with
      client's IP address. In this situation, the client is completely
      configured, and is trying to extend its lease. This message will
      be unicast, so no relay agents will be involved in its
      transmission.  Because 'giaddr' is therefore not filled in, the
      DHCP server will trust the value in 'ciaddr', and use it when
      replying to the client.

      A client MAY choose to renew or extend its lease prior to T1.  The
      server may choose not to extend the lease (as a policy decision by
      the network administrator), but should return a DHCPACK message
      regardless.

   o DHCPREQUEST generated during REBINDING state:

      'server identifier' MUST NOT be filled in, 'requested IP address'
      option MUST NOT be filled in, 'ciaddr' MUST be filled in with
      client's IP address. In this situation, the client is completely
      configured, and is trying to extend its lease. This message MUST
      be broadcast to the 0xffffffff IP broadcast address.  The DHCP
      server SHOULD check 'ciaddr' for correctness before replying to
      the DHCPREQUEST.






Droms                       Standards Track                    [Page 32]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


      The DHCPREQUEST from a REBINDING client is intended to accommodate
      sites that have multiple DHCP servers and a mechanism for
      maintaining consistency among leases managed by multiple servers.
      A DHCP server MAY extend a client's lease only if it has local
      administrative authority to do so.

4.3.3 DHCPDECLINE message

   If the server receives a DHCPDECLINE message, the client has
   discovered through some other means that the suggested network
   address is already in use.  The server MUST mark the network address
   as not available and SHOULD notify the local system administrator of
   a possible configuration problem.

4.3.4 DHCPRELEASE message

   Upon receipt of a DHCPRELEASE message, the server marks the network
   address as not allocated.  The server SHOULD retain a record of the
   client's initialization parameters for possible reuse in response to
   subsequent requests from the client.

4.3.5 DHCPINFORM message

   The server responds to a DHCPINFORM message by sending a DHCPACK
   message directly to the address given in the 'ciaddr' field of the
   DHCPINFORM message.  The server MUST NOT send a lease expiration time
   to the client and SHOULD NOT fill in 'yiaddr'.  The server includes
   other parameters in the DHCPACK message as defined in section 4.3.1.

4.3.6 Client messages

   Table 4 details the differences between messages from clients in
   various states.

   ---------------------------------------------------------------------
   |              |INIT-REBOOT  |SELECTING    |RENEWING     |REBINDING |
   ---------------------------------------------------------------------
   |broad/unicast |broadcast    |broadcast    |unicast      |broadcast |
   |server-ip     |MUST NOT     |MUST         |MUST NOT     |MUST NOT  |
   |requested-ip  |MUST         |MUST         |MUST NOT     |MUST NOT  |
   |ciaddr        |zero         |zero         |IP address   |IP address|
   ---------------------------------------------------------------------

              Table 4: Client messages from different states







Droms                       Standards Track                    [Page 33]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


4.4 DHCP client behavior

   Figure 5 gives a state-transition diagram for a DHCP client.  A
   client can receive the following messages from a server:

         o DHCPOFFER

         o DHCPACK

         o DHCPNAK

   The DHCPINFORM message is not shown in figure 5.  A client simply
   sends the DHCPINFORM and waits for DHCPACK messages.  Once the client
   has selected its parameters, it has completed the configuration
   process.

   Table 5 gives the use of the fields and options in a DHCP message by
   a client.  The remainder of this section describes the action of the
   DHCP client for each possible incoming message.  The description in
   the following section corresponds to the full configuration procedure
   previously described in section 3.1, and the text in the subsequent
   section corresponds to the abbreviated configuration procedure
   described in section 3.2.




























Droms                       Standards Track                    [Page 34]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


 --------                               -------
|        | +-------------------------->|       |<-------------------+
| INIT-  | |     +-------------------->| INIT  |                    |
| REBOOT |DHCPNAK/         +---------->|       |<---+               |
|        |Restart|         |            -------     |               |
 --------  |  DHCPNAK/     |               |                        |
    |      Discard offer   |      -/Send DHCPDISCOVER               |
-/Send DHCPREQUEST         |               |                        |
    |      |     |      DHCPACK            v        |               |
 -----------     |   (not accept.)/   -----------   |               |
|           |    |  Send DHCPDECLINE |           |                  |
| REBOOTING |    |         |         | SELECTING |<----+            |
|           |    |        /          |           |     |DHCPOFFER/  |
 -----------     |       /            -----------   |  |Collect     |
    |            |      /                  |   |       |  replies   |
DHCPACK/         |     /  +----------------+   +-------+            |
Record lease, set|    |   v   Select offer/                         |
timers T1, T2   ------------  send DHCPREQUEST      |               |
    |   +----->|            |             DHCPNAK, Lease expired/   |
    |   |      | REQUESTING |                  Halt network         |
    DHCPOFFER/ |            |                       |               |
    Discard     ------------                        |               |
    |   |        |        |                   -----------           |
    |   +--------+     DHCPACK/              |           |          |
    |              Record lease, set    -----| REBINDING |          |
    |                timers T1, T2     /     |           |          |
    |                     |        DHCPACK/   -----------           |
    |                     v     Record lease, set   ^               |
    +----------------> -------      /timers T1,T2   |               |
               +----->|       |<---+                |               |
               |      | BOUND |<---+                |               |
  DHCPOFFER, DHCPACK, |       |    |            T2 expires/   DHCPNAK/
   DHCPNAK/Discard     -------     |             Broadcast  Halt network
               |       | |         |            DHCPREQUEST         |
               +-------+ |        DHCPACK/          |               |
                    T1 expires/   Record lease, set |               |
                 Send DHCPREQUEST timers T1, T2     |               |
                 to leasing server |                |               |
                         |   ----------             |               |
                         |  |          |------------+               |
                         +->| RENEWING |                            |
                            |          |----------------------------+
                             ----------
          Figure 5:  State-transition diagram for DHCP clients







Droms                       Standards Track                    [Page 35]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


4.4.1 Initialization and allocation of network address

   The client begins in INIT state and forms a DHCPDISCOVER message.
   The client SHOULD wait a random time between one and ten seconds to
   desynchronize the use of DHCP at startup.  The client sets 'ciaddr'
   to 0x00000000.  The client MAY request specific parameters by
   including the 'parameter request list' option.  The client MAY
   suggest a network address and/or lease time by including the
   'requested IP address' and 'IP address lease time' options.  The
   client MUST include its hardware address in the 'chaddr' field, if
   necessary for delivery of DHCP reply messages.  The client MAY
   include a different unique identifier in the 'client identifier'
   option, as discussed in section 4.2.  If the client included a list
   of requested parameters in a DHCPDISCOVER message, it MUST include
   that list in all subsequent messages.

   The client generates and records a random transaction identifier and
   inserts that identifier into the 'xid' field.  The client records its
   own local time for later use in computing the lease expiration.  The
   client then broadcasts the DHCPDISCOVER on the local hardware
   broadcast address to the 0xffffffff IP broadcast address and 'DHCP
   server' UDP port.

   If the 'xid' of an arriving DHCPOFFER message does not match the
   'xid' of the most recent DHCPDISCOVER message, the DHCPOFFER message
   must be silently discarded.  Any arriving DHCPACK messages must be
   silently discarded.

   The client collects DHCPOFFER messages over a period of time, selects
   one DHCPOFFER message from the (possibly many) incoming DHCPOFFER
   messages (e.g., the first DHCPOFFER message or the DHCPOFFER message
   from the previously used server) and extracts the server address from
   the 'server identifier' option in the DHCPOFFER message.  The time
   over which the client collects messages and the mechanism used to
   select one DHCPOFFER are implementation dependent.
















Droms                       Standards Track                    [Page 36]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


Field      DHCPDISCOVER          DHCPREQUEST           DHCPDECLINE,
           DHCPINFORM                                  DHCPRELEASE
-----      ------------          -----------           -----------
'op'       BOOTREQUEST           BOOTREQUEST           BOOTREQUEST
'htype'    (From "Assigned Numbers" RFC)
'hlen'     (Hardware address length in octets)
'hops'     0                     0                     0
'xid'      selected by client    'xid' from server     selected by
                                 DHCPOFFER message     client
'secs'     0 or seconds since    0 or seconds since    0
           DHCP process started  DHCP process started
'flags'    Set 'BROADCAST'       Set 'BROADCAST'       0
           flag if client        flag if client
           requires broadcast    requires broadcast
           reply                 reply
'ciaddr'   0 (DHCPDISCOVER)      0 or client's         0 (DHCPDECLINE)
           client's              network address       client's network
           network address       (BOUND/RENEW/REBIND)  address
           (DHCPINFORM)                                (DHCPRELEASE)
'yiaddr'   0                     0                     0
'siaddr'   0                     0                     0
'giaddr'   0                     0                     0
'chaddr'   client's hardware     client's hardware     client's hardware
           address               address               address
'sname'    options, if           options, if           (unused)
           indicated in          indicated in
           'sname/file'          'sname/file'
           option; otherwise     option; otherwise
           unused                unused
'file'     options, if           options, if           (unused)
           indicated in          indicated in
           'sname/file'          'sname/file'
           option; otherwise     option; otherwise
           unused                unused
'options'  options               options               (unused)
















Droms                       Standards Track                    [Page 37]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


Option                     DHCPDISCOVER  DHCPREQUEST      DHCPDECLINE,
                           DHCPINFORM                     DHCPRELEASE
------                     ------------  -----------      -----------
Requested IP address       MAY           MUST (in         MUST
                           (DISCOVER)    SELECTING or     (DHCPDECLINE),
                           MUST NOT      INIT-REBOOT)     MUST NOT
                           (INFORM)      MUST NOT (in     (DHCPRELEASE)
                                         BOUND or
                                         RENEWING)
IP address lease time      MAY           MAY              MUST NOT
                           (DISCOVER)
                           MUST NOT
                           (INFORM)
Use 'file'/'sname' fields  MAY           MAY              MAY
DHCP message type          DHCPDISCOVER/ DHCPREQUEST      DHCPDECLINE/
                           DHCPINFORM                     DHCPRELEASE
Client identifier          MAY           MAY              MAY
Vendor class identifier    MAY           MAY              MUST NOT
Server identifier          MUST NOT      MUST (after      MUST
                                         SELECTING)
                                         MUST NOT (after
                                         INIT-REBOOT,
                                         BOUND, RENEWING
                                         or REBINDING)
Parameter request list     MAY           MAY              MUST NOT
Maximum message size       MAY           MAY              MUST NOT
Message                    SHOULD NOT    SHOULD NOT       SHOULD
Site-specific              MAY           MAY              MUST NOT
All others                 MAY           MAY              MUST NOT

             Table 5:  Fields and options used by DHCP clients

   If the parameters are acceptable, the client records the address of
   the server that supplied the parameters from the 'server identifier'
   field and sends that address in the 'server identifier' field of a
   DHCPREQUEST broadcast message.  Once the DHCPACK message from the
   server arrives, the client is initialized and moves to BOUND state.
   The DHCPREQUEST message contains the same 'xid' as the DHCPOFFER
   message.  The client records the lease expiration time as the sum of
   the time at which the original request was sent and the duration of
   the lease from the DHCPACK message.    The client SHOULD perform a
   check on the suggested address to ensure that the address is not
   already in use.  For example, if the client is on a network that
   supports ARP, the client may issue an ARP request for the suggested
   request.  When broadcasting an ARP request for the suggested address,
   the client must fill in its own hardware address as the sender's
   hardware address, and 0 as the sender's IP address, to avoid
   confusing ARP caches in other hosts on the same subnet.  If the



Droms                       Standards Track                    [Page 38]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   network address appears to be in use, the client MUST send a
   DHCPDECLINE message to the server. The client SHOULD broadcast an ARP
   reply to announce the client's new IP address and clear any outdated
   ARP cache entries in hosts on the client's subnet.

4.4.2 Initialization with known network address

   The client begins in INIT-REBOOT state and sends a DHCPREQUEST
   message.  The client MUST insert its known network address as a
   'requested IP address' option in the DHCPREQUEST message.  The client
   may request specific configuration parameters by including the
   'parameter request list' option.  The client generates and records a
   random transaction identifier and inserts that identifier into the
   'xid' field.  The client records its own local time for later use in
   computing the lease expiration.  The client MUST NOT include a
   'server identifier' in the DHCPREQUEST message.  The client then
   broadcasts the DHCPREQUEST on the local hardware broadcast address to
   the 'DHCP server' UDP port.

   Once a DHCPACK message with an 'xid' field matching that in the
   client's DHCPREQUEST message arrives from any server, the client is
   initialized and moves to BOUND state.  The client records the lease
   expiration time as the sum of the time at which the DHCPREQUEST
   message was sent and the duration of the lease from the DHCPACK
   message.

4.4.3 Initialization with an externally assigned network address

   The client sends a DHCPINFORM message. The client may request
   specific configuration parameters by including the 'parameter request
   list' option. The client generates and records a random transaction
   identifier and inserts that identifier into the 'xid' field. The
   client places its own network address in the 'ciaddr' field. The
   client SHOULD NOT request lease time parameters.

   The client then unicasts the DHCPINFORM to the DHCP server if it
   knows the server's address, otherwise it broadcasts the message to
   the limited (all 1s) broadcast address.  DHCPINFORM messages MUST be
   directed to the 'DHCP server' UDP port.

   Once a DHCPACK message with an 'xid' field matching that in the
   client's DHCPINFORM message arrives from any server, the client is
   initialized.

   If the client does not receive a DHCPACK within a reasonable period
   of time (60 seconds or 4 tries if using timeout suggested in section
   4.1), then it SHOULD display a message informing the user of the
   problem, and then SHOULD begin network processing using suitable



Droms                       Standards Track                    [Page 39]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   defaults as per Appendix A.

4.4.4 Use of broadcast and unicast

   The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM
   messages, unless the client knows the address of a DHCP server.  The
   client unicasts DHCPRELEASE messages to the server.  Because the
   client is declining the use of the IP address supplied by the server,
   the client broadcasts DHCPDECLINE messages.

   When the DHCP client knows the address of a DHCP server, in either
   INIT or REBOOTING state, the client may use that address in the
   DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address.
   The client may also use unicast to send DHCPINFORM messages to a
   known DHCP server.  If the client receives no response to DHCP
   messages sent to the IP address of a known DHCP server, the DHCP
   client reverts to using the IP broadcast address.

4.4.5 Reacquisition and expiration

   The client maintains two times, T1 and T2, that specify the times at
   which the client tries to extend its lease on its network address.
   T1 is the time at which the client enters the RENEWING state and
   attempts to contact the server that originally issued the client's
   network address.  T2 is the time at which the client enters the
   REBINDING state and attempts to contact any server. T1 MUST be
   earlier than T2, which, in turn, MUST be earlier than the time at
   which the client's lease will expire.

   To avoid the need for synchronized clocks, T1 and T2 are expressed in
   options as relative times [2].

   At time T1 the client moves to RENEWING state and sends (via unicast)
   a DHCPREQUEST message to the server to extend its lease.  The client
   sets the 'ciaddr' field in the DHCPREQUEST to its current network
   address. The client records the local time at which the DHCPREQUEST
   message is sent for computation of the lease expiration time.  The
   client MUST NOT include a 'server identifier' in the DHCPREQUEST
   message.

   Any DHCPACK messages that arrive with an 'xid' that does not match
   the 'xid' of the client's DHCPREQUEST message are silently discarded.
   When the client receives a DHCPACK from the server, the client
   computes the lease expiration time as the sum of the time at which
   the client sent the DHCPREQUEST message and the duration of the lease
   in the DHCPACK message.  The client has successfully reacquired its
   network address, returns to BOUND state and may continue network
   processing.



Droms                       Standards Track                    [Page 40]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   If no DHCPACK arrives before time T2, the client moves to REBINDING
   state and sends (via broadcast) a DHCPREQUEST message to extend its
   lease.  The client sets the 'ciaddr' field in the DHCPREQUEST to its
   current network address.  The client MUST NOT include a 'server
   identifier' in the DHCPREQUEST message.

   Times T1 and T2 are configurable by the server through options.  T1
   defaults to (0.5 * duration_of_lease).  T2 defaults to (0.875 *
   duration_of_lease).  Times T1 and T2 SHOULD be chosen with some
   random "fuzz" around a fixed value, to avoid synchronization of
   client reacquisition.

   A client MAY choose to renew or extend its lease prior to T1.  The
   server MAY choose to extend the client's lease according to policy
   set by the network administrator.  The server SHOULD return T1 and
   T2, and their values SHOULD be adjusted from their original values to
   take account of the time remaining on the lease.

   In both RENEWING and REBINDING states, if the client receives no
   response to its DHCPREQUEST message, the client SHOULD wait one-half
   of the remaining time until T2 (in RENEWING state) and one-half of
   the remaining lease time (in REBINDING state), down to a minimum of
   60 seconds, before retransmitting the DHCPREQUEST message.

   If the lease expires before the client receives a DHCPACK, the client
   moves to INIT state, MUST immediately stop any other network
   processing and requests network initialization parameters as if the
   client were uninitialized.  If the client then receives a DHCPACK
   allocating that client its previous network address, the client
   SHOULD continue network processing.  If the client is given a new
   network address, it MUST NOT continue using the previous network
   address and SHOULD notify the local users of the problem.

4.4.6 DHCPRELEASE

   If the client no longer requires use of its assigned network address
   (e.g., the client is gracefully shut down), the client sends a
   DHCPRELEASE message to the server.  Note that the correct operation
   of DHCP does not depend on the transmission of DHCPRELEASE messages.












Droms                       Standards Track                    [Page 41]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


5. Acknowledgments

   The author thanks the many (and too numerous to mention!) members of
   the DHC WG for their tireless and ongoing efforts in the development
   of DHCP and this document.

   The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John
   Mendonca in organizing DHCP interoperability testing sessions are
   gratefully acknowledged.

   The development of this document was supported in part by grants from
   the Corporation for National Research Initiatives (CNRI), Bucknell
   University and Sun Microsystems.

6. References

   [1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December
       1983.

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

   [3] Braden, R., Editor, "Requirements for Internet Hosts --
       Communication Layers", STD 3, RFC 1122, USC/Information Sciences
       Institute, October 1989.

   [4] Braden, R., Editor, "Requirements for Internet Hosts --
       Application and Support, STD 3, RFC 1123, USC/Information
       Sciences Institute, October 1989.

   [5] Brownell, D, "Dynamic Reverse Address Resolution Protocol
       (DRARP)", Work in Progress.

   [6] Comer, D., and R. Droms, "Uniform Access to Internet Directory
       Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer
       Communications Review), 20(4):50--59, 1990.

   [7] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
       Stanford and SUN Microsystems, September 1985.

   [8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox
       PARC, September 1991.

   [9] Droms, D., "Interoperation between DHCP and BOOTP", RFC 1534,
       Bucknell University, October 1993.





Droms                       Standards Track                    [Page 42]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   [10] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse
        Address Resolution Protocol", RFC 903, Stanford, June 1984.

   [11] Gray C., and D. Cheriton, "Leases: An Efficient Fault-Tolerant
        Mechanism for Distributed File Cache Consistency", In Proc. of
        the Twelfth ACM Symposium on Operating Systems Design, 1989.

   [12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
        13, RFC 1034, USC/Information Sciences Institute, November 1987.

   [13] Mockapetris, P., "Domain Names -- Implementation and
        Specification", STD 13, RFC 1035, USC/Information Sciences
        Institute, November 1987.

   [14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191,
        November 1990.

   [15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached
        Hosts", Work in Progress.

   [16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
        USC/Information Sciences Institute, September 1981.

   [17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
        USC/Information Sciences Institute, August 1993.

   [18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
        USC/Information Sciences Institute, October 1994.

   [19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic
        Assignment of IP Addresses for use on an Ethernet. (Available
        from the Athena Project, MIT), 1989.

   [20] Sollins, K., "The TFTP Protocol (Revision 2)",  RFC 783, NIC,
        June 1981.

   [21] Wimer, W., "Clarifications and Extensions for the Bootstrap
        Protocol", RFC 1542, Carnegie Mellon University, October 1993.

7. Security Considerations

   DHCP is built directly on UDP and IP which are as yet inherently
   insecure.  Furthermore, DHCP is generally intended to make
   maintenance of remote and/or diskless hosts easier.  While perhaps
   not impossible, configuring such hosts with passwords or keys may be
   difficult and inconvenient.  Therefore, DHCP in its current form is
   quite insecure.




Droms                       Standards Track                    [Page 43]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   Unauthorized DHCP servers may be easily set up.  Such servers can
   then send false and potentially disruptive information to clients
   such as incorrect or duplicate IP addresses, incorrect routing
   information (including spoof routers, etc.), incorrect domain
   nameserver addresses (such as spoof nameservers), and so on.
   Clearly, once this seed information is in place, an attacker can
   further compromise affected systems.

   Malicious DHCP clients could masquerade as legitimate clients and
   retrieve information intended for those legitimate clients.  Where
   dynamic allocation of resources is used, a malicious client could
   claim all resources for itself, thereby denying resources to
   legitimate clients.

8. 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                       Standards Track                    [Page 44]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


A. Host Configuration Parameters

   IP-layer_parameters,_per_host:_

   Be a router                     on/off                 HRC 3.1
   Non-local source routing        on/off                 HRC 3.3.5
   Policy filters for
   non-local source routing        (list)                 HRC 3.3.5
   Maximum reassembly size         integer                HRC 3.3.2
   Default TTL                     integer                HRC 3.2.1.7
   PMTU aging timeout              integer                MTU 6.6
   MTU plateau table               (list)                 MTU 7
   IP-layer_parameters,_per_interface:_
   IP address                      (address)              HRC 3.3.1.6
   Subnet mask                     (address mask)         HRC 3.3.1.6
   MTU                             integer                HRC 3.3.3
   All-subnets-MTU                 on/off                 HRC 3.3.3
   Broadcast address flavor        0x00000000/0xffffffff  HRC 3.3.6
   Perform mask discovery          on/off                 HRC 3.2.2.9
   Be a mask supplier              on/off                 HRC 3.2.2.9
   Perform router discovery        on/off                 RD 5.1
   Router solicitation address     (address)              RD 5.1
   Default routers, list of:
           router address          (address)              HRC 3.3.1.6
           preference level        integer                HRC 3.3.1.6
   Static routes, list of:
           destination             (host/subnet/net)      HRC 3.3.1.2
           destination mask        (address mask)         HRC 3.3.1.2
           type-of-service         integer                HRC 3.3.1.2
           first-hop router        (address)              HRC 3.3.1.2
           ignore redirects        on/off                 HRC 3.3.1.2
           PMTU                    integer                MTU 6.6
           perform PMTU discovery  on/off                 MTU 6.6

   Link-layer_parameters,_per_interface:_
   Trailers                       on/off                 HRC 2.3.1
   ARP cache timeout              integer                HRC 2.3.2.1
   Ethernet encapsulation         (RFC 894/RFC 1042)     HRC 2.3.3

   TCP_parameters,_per_host:_
   TTL                            integer                HRC 4.2.2.19
   Keep-alive interval            integer                HRC 4.2.3.6
   Keep-alive data size           0/1                    HRC 4.2.3.6

Key:

   MTU = Path MTU Discovery (RFC 1191, Proposed Standard)
   RD = Router Discovery (RFC 1256, Proposed Standard)



Droms                       Standards Track                    [Page 45]