File: rfc1532.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 (1235 lines) | stat: -rw-r--r-- 51,545 bytes parent folder | download | duplicates (8)
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






Network Working Group                                           W. Wimer
Request for Comments: 1532                    Carnegie Mellon University
Updates: 951                                                October 1993
Category: Standards Track


        Clarifications and Extensions for the Bootstrap Protocol

Status of this Memo

   This RFC specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" for the standardization state and status
   of this protocol.  Distribution of this memo is unlimited.

Abstract

   Some aspects of the BOOTP protocol were rather loosely defined in its
   original specification.  In particular, only a general description
   was provided for the behavior of "BOOTP relay agents" (originally
   called BOOTP forwarding agents").  The client behavior description
   also suffered in certain ways.  This memo attempts to clarify and
   strengthen the specification in these areas.

   In addition, new issues have arisen since the original specification
   was written.  This memo also attempts to address some of these.

Table of Contents

   1. Introduction.................................................  2
   1.1 Requirements................................................  2
   1.2 Terminology.................................................  3
   1.3 Data Transmission Order.....................................  4
   2. General Issues...............................................  5
   2.1 General BOOTP Processing....................................  5
   2.2 Definition of the 'flags' Field.............................  5
   2.3 Bit Ordering of Hardware Addresses..........................  7
   2.4 BOOTP Over IEEE 802.5 Token Ring Networks...................  8
   3. BOOTP Client Behavior........................................  9
   3.1 Client use of the 'flags' field.............................  9
   3.1.1 The BROADCAST flag........................................  9
   3.1.2 The remainder of the 'flags' field........................  9
   3.2 Definition of the 'secs' field..............................  9
   3.3 Use of the 'ciaddr' and 'yiaddr' fields..................... 10
   3.4 Interpretation of the 'giaddr' field........................ 11
   3.5 Vendor information "magic cookie"........................... 12
   4. BOOTP Relay Agents........................................... 13



Wimer                                                           [Page 1]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


   4.1 General BOOTP Processing for Relay Agents................... 13
   4.1.1 BOOTREQUEST Messages...................................... 14
   4.1.2 BOOTREPLY Messages........................................ 16
   5. BOOTP Server Behavior........................................ 18
   5.1 Reception of BOOTREQUEST Messages........................... 18
   5.2 Use of the 'secs' field..................................... 19
   5.3 Use of the 'ciaddr' field................................... 19
   5.4 Strategy for Delivery of BOOTREPLY Messages................. 19
   Acknowledgements................................................ 21
   References...................................................... 21
   Security Considerations......................................... 22
   Author's Address................................................ 22

1. Introduction

   The Bootstrap Protocol (BOOTP) is a UDP/IP-based protocol which
   allows a booting host to configure itself dynamically and without
   user supervision.  BOOTP provides a means to notify a host of its
   assigned IP address, the IP address of a boot server host, and the
   name of a file to be loaded into memory and executed [1].  Other
   configuration information such as the local subnet mask, the local
   time offset, the addresses of default routers, and the addresses of
   various Internet servers can also be communicated to a host using
   BOOTP [2].

   Unfortunately, the original BOOTP specification [1] left some issues
   of the protocol open to question.  The exact behavior of BOOTP relay
   agents formerly called "BOOTP forwarding agents") was not clearly
   specified.  Some parts of the overall protocol specification actually
   conflict, while other parts have been subject to misinterpretation,
   indicating that clarification is needed.  This memo addresses these
   problems.

   Since the introduction of BOOTP, the IEEE 802.5 Token Ring Network
   has been developed which presents a unique problem for BOOTP's
   particular message-transfer paradigm.  This memo also suggests a
   solution for this problem.

   NOTE: Unless otherwise specified in this document or a later
   document, the information and requirements specified througout this
   document also apply to extensions to BOOTP such as the Dynamic Host
   Configuration Protocol (DHCP) [3].

1.1 Requirements

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




Wimer                                                           [Page 2]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


      o "MUST"

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

      o "MUST NOT"

        This phrase means that the item is an absolute prohibition
        of the 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.

      o "MAY"

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

1.2 Terminology

   This memo uses the following terms:

      BOOTREQUEST

         A BOOTREQUEST message is a BOOTP message sent from a BOOTP
         client to a BOOTP server, requesting configuration information.

      BOOTREPLY

         A BOOTREPLY message is a BOOTP message sent from a BOOTP server
         to a BOOTP client, providing configuration information.




Wimer                                                           [Page 3]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


      Silently discard

         This memo specifies several cases where a BOOTP entity is to
         "silently discard" a received BOOTP message.  This means that
         the entity is to discard the message without further
         processing, and that the entity will not send any ICMP error
         message as a result.  However, for diagnosis of problems, the
         entity SHOULD provide the capability of logging the error,
         including the contents of the silently-discarded message, and
         SHOULD record the event in a statistics counter.

1.3 Data Transmission Order

   The order of transmission of the header and data described in this
   document is resolved to the octet level.  Whenever a diagram shows a
   group of octets, the order of transmission of those octets is the
   normal order in which they are read in English.  For example, in the
   following diagram, the octets are transmitted in the order they are
   numbered.

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

   Whenever an octet represents a numeric quantity, the leftmost bit in
   the diagram is the high order or most significant bit.  That is, the
   bit labeled 0 is the most significant bit.  For example, the
   following diagram represents the value 170 (decimal).

                               0 1 2 3 4 5 6 7
                              +-+-+-+-+-+-+-+-+
                              |1 0 1 0 1 0 1 0|
                              +---------------+

   Similarly, whenever a multi-octet field represents a numeric quantity
   the leftmost bit of the whole field is the most significant bit.
   When a multi-octet quantity is transmitted the most significant octet
   is transmitted first.







Wimer                                                           [Page 4]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


2. General Issues

   This section covers issues of general relevance to all BOOTP entities
   (clients, servers, and relay agents).

2.1 General BOOTP Processing

   The following consistency checks SHOULD be performed on BOOTP
   messages:

      o The IP Total Length and UDP Length must be large enough to
        contain the minimal BOOTP header of 300 octets (in the UDP
        data field) specified in [1].

   NOTE: Future extensions to the BOOTP protocol may increase the size
   of BOOTP messages.  Therefore, BOOTP messages which, according to the
   IP Total Length and UDP Length fields, are larger than the minimum
   size specified by [1] MUST also be accepted.

      o The 'op' (opcode) field of the message must contain either the
        code for a BOOTREQUEST (1) or the code for a BOOTREPLY (2).

   BOOTP messages not meeting these consistency checks MUST be silently
   discarded.

2.2 Definition of the 'flags' Field

   The standard BOOTP message format defined in [1] includes a two-octet
   field located between the 'secs' field and the 'ciaddr' field.  This
   field is merely designated as "unused" and its contents left
   unspecified, although Section 7.1 of [1] does offer the following
   suggestion:

      "Before setting up the packet for the first time, it is a good
      idea to clear the entire packet buffer to all zeros; this will
      place all fields in their default state."

      This memo hereby designates this two-octet field as the 'flags'
      field.

      This memo hereby defines the most significant bit of the 'flags'
      field as the BROADCAST (B) flag.  The semantics of this flag are
      discussed in Sections 3.1.1 and 4.1.2 of this memo.

      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.




Wimer                                                           [Page 5]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


      The 'flags' field, then, appears as follows:

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

   where:

      B    BROADCAST flag (discussed in Sections 3.1.1 and 4.1.2)

      MBZ  MUST BE ZERO (reserved for future use)

   The format of a BOOTP message is shown below.  The numbers in
   parentheses indicate the size of each field in octets.



































Wimer                                                           [Page 6]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


   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)                        |
   +---------------------------------------------------------------+
   |                                                               |
   |                           vend   (64)                         |
   +---------------------------------------------------------------+

2.3 Bit Ordering of Hardware Addresses

   The bit ordering used for link-level hardware addresses in the
   protocol [4] on the client's link-level network (assuming ARP is
   defined for that network).

   The 'chaddr' field MUST be preserved as it was specified by the BOOTP
   client.  A relay agent MUST NOT reverse the bit ordering of the two
   networks which use different bit orderings.

      DISCUSSION:

         One of the primary reasons the 'chaddr' field exists is to
         enable BOOTP servers and relay agents to communicate directly
         with clients without the use of broadcasts.  In practice, the
         contents of the the same way the normal ARP protocol would



Wimer                                                           [Page 7]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


         have.  Clearly, interoperability can only be achieved if a
         consistent interpretation of the 'chaddr' field is used.

         As a practical example, this means that the bit ordering used
         for the is the opposite of the bit ordering used by a BOOTP
         client on a DIX ethernet network.

2.4 BOOTP Over IEEE 802.5 Token Ring Networks

   Special consideration of the client/server and client/relay agent
   interactions must be given to IEEE 802.5 networks because of non-
   transparent bridging.

   The client SHOULD send its broadcast BOOTREQUEST with an All Routes
   Explorer RIF.  This will enable servers/relay agents to cache the
   return route if they choose to do so.  For those server/relay agents
   which cannot cache the return route (because they are stateless, for
   example), the BOOTREPLY message SHOULD be sent to the client's
   hardware address, as taken from the BOOTP message, with a Spanning
   Tree Rooted RIF.  The actual bridge route will be recorded by the
   client and server/relay agent by normal ARP processing code.

      DISCUSSION:

         In the simplest case, an unbridged, single ring network, the
         broadcast behavior of the BOOTP protocol is identical to that
         of Ethernet networks.  However, a BOOTP client cannot know, a
         priori, that an 802.5 network is not bridged.  In fact, the
         likelihood is that the server, or relay agent, will not know
         either.

         Of the four possible scenerios, only two are interesting: where
         the assumption is that the 802.5 network is not bridged and it
         is, and the assumption that the network is bridged and it is
         not.  In the former case, the Routing Information Field (RIF)
         will not be used; therefore, if the server/relay agent are on
         another segment of the ring, the client cannot reach it.  In
         the latter case, the RIF field will be used, resulting in a few
         extraneous bytes on the ring.  It is obvious that an almost
         immeasurable inefficiency is to be preferred over a complete
         failure to communicate.

         Given that the assumption is that RIF fields will be needed, it
         is necesary to determine the optimum method for the client to
         reach the server/relay agent, and the optimum method for the
         response to be returned.





Wimer                                                           [Page 8]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


3. BOOTP Client Behavior

   This section clarifies various issues regarding BOOTP client
   behavior.

3.1 Client use of the 'flags' field

3.1.1 The BROADCAST flag

   Normally, BOOTP servers and relay agents attempt to deliver BOOTREPLY
   messages directly to a client using unicast delivery.  The IP
   destination address (in the IP header) is set to the BOOTP 'yiaddr'
   address and the link-layer destination address is set to the BOOTP
   unable to receive such unicast IP datagrams until they know their own
   IP address (thus we have a "chicken and egg" issue).  Often, however,
   they can receive broadcast IP datagrams (those with a valid IP
   broadcast address as the IP destination and the link-layer broadcast
   address as the link-layer destination).

   If a client falls into this category, it SHOULD set (to 1) the
   newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY
   messages it generates.  This will provide a hint to BOOTP servers and
   relay agents that they should attempt to broadcast their BOOTREPLY
   messages to the client.

   If a client does not have this limitation (i.e., it is perfectly able
   to receive unicast BOOTREPLY messages), it SHOULD NOT set the
   BROADCAST flag (i.e., it SHOULD clear the BROADCAST flag to 0).

      DISCUSSION:

         This addition to the protocol is a workaround for old host
         implementations.  Such implementations SHOULD be modified so
         that they may receive unicast BOOTREPLY messages, thus making
         use of this workaround unnecessary.  In general, the use of
         this mechanism is discouraged.

3.1.2 The remainder of the 'flags' field

   The remaining bits of the 'flags' field are reserved for future use.
   A client MUST set these bits to zero in all BOOTREQUEST messages it
   generates.  A client MUST ignore these bits in all BOOTREPLY messages
   it receives.

3.2 Definition of the 'secs' field

   The 'secs' field of a BOOTREQUEST message SHOULD represent the
   elapsed time, in seconds, since the client sent its first BOOTREQUEST



Wimer                                                           [Page 9]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


   message.  Note that this implies that the 'secs' field of the first
   BOOTREQUEST message SHOULD be set to zero.

   Clients SHOULD NOT set the 'secs' field to a value which is constant
   for all BOOTREQUEST messages.

      DISCUSSION:

         The original definition of the 'secs' field was vague.  It was
         not clear whether it represented the time since the first
         BOOTREQUEST message was sent or some other time period such as
         the time since the client machine was powered-up.  This has
         limited its usefulness as a policy control mechanism for BOOTP
         servers and relay agents.  Furthermore, certain client
         implementations have been known to simply set this field to a
         constant value or use incorrect byte-ordering.  Incorrect
         byte-ordering usually makes it appear as if a client has been
         waiting much longer than it really has, so a relay agent will
         relay the BOOTREQUEST sooner than desired (usually
         immediately).  These implementation errors have further
         undermined the usefulness of the 'secs' field.  These incorrect
         implementations SHOULD be corrected.

3.3 Use of the 'ciaddr' and 'yiaddr' fields

   If a BOOTP client does not know what IP address it should be using,
   the client SHOULD set the 'ciaddr' field to 0.0.0.0.  If the client
   has the ability to remember the last IP address it was assigned, or
   it has been preconfigured with an IP address via some alternate
   mechanism, the client MAY fill the 'ciaddr' field with that IP
   address.  If the client does place a non-zero IP address in the
   datagrams addressed to that IP address and also answer ARP requests
   for that IP address (if ARP is used on that network).

   The BOOTP server is free to assign a different IP address (in the
   SHOULD adopt the IP address specified in 'yiaddr' and begin using it
   as soon as possible.

      DISCUSSION:

         There are various interpretations about the purpose of the
         'ciaddr' field and, unfortunately, no agreement on a single
         correct interpretation.  One interpretation is that if a client
         is willing to accept whatever IP address the BOOTP server
         assigns to it, the client should always place 0.0.0.0 in the
         'ciaddr' field, regardless of whether it knows its previously-
         assigned address.  Conversely, if the client wishes to assert
         that it must have a particular IP address (e.g., the IP address



Wimer                                                          [Page 10]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


         was hand-configured by the host administrator and BOOTP is only
         being used to obtain a boot file and/or information from the
         'vend' field), the client will then fill the 'ciaddr' field
         with the desired IP address and ignore the IP address assigned
         by the BOOTP server as indicated in the 'yiaddr' field.  An
         alternate interpretation holds that the client always fills the
         'ciaddr' field with its most recently-assigned IP address (if
         known) even if that address may be incorrect.  Such a client
         will still accept and use the address assigned by the BOOTP
         server as indicated in the 'yiaddr' field.  The motivation for
         this interpretation is to aid the server in identifying the
         client and/or in delivering the BOOTREPLY to the client.  Yet a
         third (mis)interpretation allows the client to use client has
         never used that address before or is not currently using that
         address.

         The last interpretation is incorrect as it may prevent the
         BOOTREPLY from reaching the client.  The server will usually
         unicast the reply to the address given in 'ciaddr' but the
         client may not be listening on that address yet, or the client
         may be connected to an incorrect subnet such that normal IP
         routing (correctly) routes the reply to a different subnet.

         The second interpretation also suffers from the "incorrect
         subnet" problem.

         The first interpretation seems to be the safest and most likely
         to promote interoperability.

3.4 Interpretation of the 'giaddr' field

   The 'giaddr' field is rather poorly named.  It exists to facilitate
   the transfer of BOOTREQUEST messages from a client, through BOOTP
   relay agents, to servers on different networks than the client.
   Similarly, it facilitates the delivery of BOOTREPLY messages from the
   servers, through BOOTP relay agents, back to the client.  In no case
   does it represent a general IP router to be used by the client.  A
   BOOTP client MUST set the 'giaddr' field to zero (0.0.0.0) in all
   BOOTREQUEST messages it generates.

   A BOOTP client MUST NOT interpret the 'giaddr' field of a BOOTREPLY
   message to be the IP address of an IP router.  A BOOTP client SHOULD
   completely ignore the contents of the 'giaddr' field in BOOTREPLY
   messages.







Wimer                                                          [Page 11]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


      DISCUSSION:

         The semantics of the 'giaddr' field were poorly defined.
         Section 7.5 of [1] states:

           "If 'giaddr' (gateway address) is nonzero, then the packets
           should be forwarded there first, in order to get to the
           server."

   In that sentence, "get to" refers to communication from the client to
   the server subsequent to the BOOTP exchange, such as a TFTP session.
   Unfortunately, the 'giaddr' field may contain the address of a BOOTP
   relay agent that is not itself an IP router (according to [1],
   Section 8, fifth paragraph), in which case, it will be useless as a
   first-hop for TFTP packets sent to the server (since, by definition,
   non-routers don't forward datagrams at the IP layer).

   Although now prohibited by Section 4.1.1 of this memo, the 'giaddr'
   field might contain a broadcast address according to Section 8, sixth
   paragraph of [1].  Not only would such an address be useless as a
   router address, it might also cause the client to ARP for the
   broadcast address (since, if the client didn't receive a subnet mask
   in the BOOTREPLY message, it would be unable to recognize a subnet
   broadcast address).  This is clearly undesirable.

   To reach a non-local server, clients can obtain a first-hop router
   address from the "Gateway" subfield of the "Vendor Information
   Extensions" [2] (if present), or via the ICMP router discovery
   protocol [5] or other similar mechanism.

3.5 Vendor information "magic cookie"

   It is RECOMMENDED that a BOOTP client always fill the first four
   octets of the 'vend' (vendor information) field of a BOOTREQUEST with
   a four-octet identifier called a "magic cookie."  A BOOTP client
   SHOULD do this even if it has no special information to communicate
   to the BOOTP server using the 'vend' field.  This aids the BOOTP
   server in determining what vendor information format it should use in
   its BOOTREPLY messages.

   If a special vendor-specific magic cookie is not being used, a BOOTP
   client SHOULD use the dotted decimal value 99.130.83.99 as specified
   in [2].  In this case, if the client has no information to
   communicate to the server, the octet immediately following the magic
   cookie SHOULD be set to the "End" tag (255) and the remaining octets
   of the 'vend' field SHOULD be set to zero.





Wimer                                                          [Page 12]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


      DISCUSSION:

         Sometimes different operating systems or networking packages
         are run on the same machine at different times (or even at the
         same time!).  Since the hardware address placed in the 'chaddr'
         field will likely be the same, BOOTREQUESTs from completely
         different BOOTP clients on the same machine will likely be
         difficult for a BOOTP server to differentiate.  If the client
         includes a magic cookie in its BOOTREQUESTs, the server will at
         least know what format the client expects and can understand in
         corresponding BOOTREPLY messages.

4. BOOTP Relay Agents

         In many cases, BOOTP clients and their associated BOOTP
         server(s) do not reside on the same IP network or subnet.  In
         such cases, some kind of third-party agent is required to
         transfer BOOTP messages between clients and servers.  Such an
         agent was originally referred to as a "BOOTP forwarding agent."
         However, in order to avoid confusion with the IP forwarding
         function of an IP router, the name "BOOTP relay agent" is
         hereby adopted instead.

      DISCUSSION:

         A BOOTP relay agent performs a task which is distinct from an
         IP router's normal IP forwarding function.  While a router
         normally switches IP datagrams between networks more-or-less
         transparently, a BOOTP relay agent may more properly be thought
         to receive BOOTP messages as a final destination and then
         generate new BOOTP messages as a result.  It is incorrect for a
         relay agent implementation to simply forward a BOOTP message
         "straight through like a regular packet."

         This relay-agent functionality is most conveniently located in
         the routers which interconnect the clients and servers, but may
         alternatively be located in a host which is directly connected
         to the client subnet.

         Any Internet host or router which provides BOOTP relay-agent
         capability MUST conform to the specifications in this memo.

4.1 General BOOTP Processing for Relay Agents

   All locally delivered UDP messages whose UDP destination port number
   is BOOTPS (67) are considered for special processing by the host or
   router's logical BOOTP relay agent.




Wimer                                                          [Page 13]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


   In the case of a host, locally delivered datagrams are simply all
   datagrams normally received by that host, i.e., broadcast and
   multicast datagrams as well as unicast datagrams addressed to IP
   addresses of that host.

   In the case of a router, locally delivered datagrams are broadcast
   and multicast datagrams as well as unicast datagrams addressed to IP
   addresses of that router.  These are datagrams for which the router
   should be considered an end destination as opposed to an intermediate
   switching node.  Thus a unicast datagram with an IP destination not
   matching any of the router's IP addresses is not considered for
   processing by the router's logical BOOTP relay agent.

   Hosts and routers are usually required to silently discard incoming
   datagrams containing illegal IP source addresses.  This is generally
   known as "Martian address filtering."  One of these illegal addresses
   is 0.0.0.0 (or actually anything on network 0).  However, hosts or
   routers which support a BOOTP relay agent MUST accept for local
   delivery to the relay agent BOOTREQUEST messages whose IP source
   address is 0.0.0.0.  BOOTREQUEST messages from legal IP source
   addresses MUST also be accepted.

   A relay agent MUST silently discard any received UDP messages whose
   UDP destination port number is BOOTPC (68).

      DISCUSSION:

         There should be no need for a relay agent to process messages
         addressed to the BOOTPC port.  Careful reading of the original
         BOOTP specification [1] will show this.  Nevertheless, some
         relay agent implementations incorrectly relay such messages.

   The consistency checks specified in Section 2.1 SHOULD be performed
   by the relay agent.  BOOTP messages not meeting these consistency
   checks MUST be silently discarded.

4.1.1 BOOTREQUEST Messages

   Some configuration mechanism MUST exist to enable or disable the
   relaying of BOOTREQUEST messages.  Relaying MUST be disabled by
   default.

   When the BOOTP relay agent receives a BOOTREQUEST message, it MAY use
   the value of the 'secs' (seconds since client began booting) field of
   the request as a factor in deciding whether to relay the request.  If
   such a policy mechanism is implemented, its threshold SHOULD be
   configurable.




Wimer                                                          [Page 14]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


      DISCUSSION:

         To date, this feature of the BOOTP protocol has not necessarily
         been shown to be useful.  See Section 3.2 for a discussion.

   The relay agent MUST silently discard BOOTREQUEST messages whose
   provided to set this threshold to a smaller value if desired by the
   network manager.  The default setting for a configurable threshold
   SHOULD be 4.

   If the relay agent does decide to relay the request, it MUST examine
   the 'giaddr' ("gateway" IP address) field.  If this field is zero,
   the relay agent MUST fill this field with the IP address of the
   interface on which the request was received.  If the interface has
   more than one IP address logically associated with it, the relay
   agent SHOULD choose one IP address associated with that interface and
   use it consistently for all BOOTP messages it relays.  If the
   'giaddr' field contains some non-zero value, the 'giaddr' field MUST
   NOT be modified.  The relay agent MUST NOT, under any circumstances,
   fill the 'giaddr' field with a broadcast address as is suggested in
   [1] (Section 8, sixth paragraph).

   The value of the 'hops' field MUST be incremented.

   All other BOOTP fields MUST be preserved intact.

   At this point, the request is relayed to its new destination (or
   destinations).  This destination MUST be configurable.  Further, this
   destination configuration SHOULD be independent of the destination
   configuration for any other so-called "broadcast forwarders" (e.g.,
   for the UDP-based TFTP, DNS, Time, etc.  protocols).

      DISCUSSION:

         The network manager may wish the relaying destination to be an
         IP unicast, multicast, broadcast, or some combination.  A
         configurable list of destination IP addresses provides good
         flexibility.  More flexible configuration schemes are
         encouraged.  For example, it may be desirable to send to the
         limited broadcast address (255.255.255.255) on specific
         physical interfaces.  However, if the BOOTREQUEST message was
         received as a broadcast, the relay agent MUST NOT rebroadcast
         the BOOTREQUEST on the physical interface from whence it came.

         A relay agent MUST use the same destination (or set of
         destinations) for all BOOTREQUEST messages it relays from a
         given client.




Wimer                                                          [Page 15]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


      DISCUSSION:

         At least one known relay agent implementation uses a round-
         robin scheme to provide load balancing across multiple BOOTP
         servers.  Each time it receives a new BOOTREQUEST message, it
         relays the message to the next BOOTP server in a list of
         servers.  Thus, with this relay agent, multiple consecutive
         BOOTREQUEST messages from a given client will be delivered to
         different servers.

         Unfortunately, this well-intentioned scheme reacts badly with
         DHCP [3] and perhaps other variations of the BOOTP protocol
         which depend on multiple exchanges of BOOTREQUEST and BOOTREPLY
         messages between clients and servers.  Therefore, all
         BOOTREQUEST messages from a given client MUST be relayed to the
         same destination (or set of destinations).

         One way to meet this requirement while providing some load-
         balancing benefit is to hash the client's link-layer address
         (or some other reliable client-identifying information) and use
         the resulting hash value to select the appropriate relay
         destination (or set of destinations).  The simplest solution,
         of course, is to not use a load-balancing scheme and just relay
         ALL received BOOTREQUEST messages to the same destination (or
         set of destinations).

         When transmitting the request to its next destination, the
         relay agent may set the IP Time-To-Live field to either the
         default value for new datagrams originated by the relay agent,
         or to the TTL of the original BOOTREQUEST decremented by (at
         least) one.

      DISCUSSION:

         As an extra precaution against BOOTREQUEST loops, it is
         preferable to use the decremented TTL from the original
         BOOTREQUEST.  Unfortunately, this may be difficult to do in
         some implementations.

         If the BOOTREQUEST has a UDP checksum (i.e., the UDP checksum
         is non-zero), the checksum must be recalculated before
         transmitting the request.

4.1.2 BOOTREPLY Messages

   BOOTP relay agents relay BOOTREPLY messages only to BOOTP clients.
   It is the responsibility of BOOTP servers to send BOOTREPLY messages
   directly to the relay agent identified in the BOOTREPLY messages it



Wimer                                                          [Page 16]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


   receives are intended for BOOTP clients on its directly-connected
   networks.

   When a relay agent receives a BOOTREPLY message, it should examine
   the BOOTP 'giaddr', 'yiaddr', 'chaddr', 'htype', and for the relay
   agent to deliver the BOOTREPLY message to the client.

   The 'giaddr' field can be used to identify the logical interface from
   which the reply must be sent (i.e., the host or router interface
   connected to the same network as the BOOTP client).  If the content
   of the 'giaddr' field does not match one of the relay agent's
   directly-connected logical interfaces, the BOOTREPLY messsage MUST be
   silently discarded.

   The 'htype', 'hlen', and 'chaddr' fields supply the link-layer
   hardware type, hardware address length, and hardware address of the
   client as defined in the ARP protocol [4] and the Assigned Numbers
   document [6].  The 'yiaddr' field is the IP address of the client, as
   assigned by the BOOTP server.

   The relay agent SHOULD examine the newly-defined BROADCAST flag (see
   Sections 2.2 and 3.1.1 for more information).  If this flag is set to
   1, the reply SHOULD be sent as an IP broadcast using the IP limited
   broadcast address 255.255.255.255 as the IP destination address and
   the link-layer broadcast address as the link-layer destination
   address.  If the BROADCAST flag is cleared (0), the reply SHOULD be
   sent as an IP unicast to the IP address specified by the 'yiaddr'
   field and the link-layer address specified in the 'chaddr' field.  If
   unicasting is not possible, the reply MAY be sent as a broadcast, in
   which case it SHOULD be sent to the link-layer broadcast address
   using the IP limited broadcast address 255.255.255.255 as the IP
   destination address.

      DISCUSSION:

         The addition of the BROADCAST flag to the protocol is a
         workaround to help promote interoperability with certain client
         implementations.

         Note that since the 'flags' field was previously defined in [1]
         simply as an "unused" field, it is possible that old client or
         server implementations may accidentally and unknowingly set the
         new BROADCAST flag.  It is actually expected that such
         implementations will be rare (most implementations seem to
         zero-out this field), but interactions with such
         implementations must nevertheless be considered.  If an old
         client or server does set the BROADCAST flag to 1 incorrectly,
         conforming relay agents will generate broadcast BOOTREPLY



Wimer                                                          [Page 17]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


         messages to the corresponding client.  The BOOTREPLY messages
         should still properly reach the client, at the cost of one
         (otherwise unnecessary) additional broadcast.  This, however,
         is no worse than a server or relay agent which always
         broadcasts its BOOTREPLY messages.

         Older client or server implementations which accidentally set
         the BROADCAST flag SHOULD be corrected to properly comply with
         this newer specification.

         All BOOTP fields MUST be preserved intact.  The relay agent
         MUST NOT modify any BOOTP field of the BOOTREPLY message when
         relaying it to the client.

         The reply MUST have its UDP destination port set to BOOTPC
         (68).

         If the BOOTREPLY has a UDP checksum (i.e., the UDP checksum is
         non-zero), the checksum must be recalculated before
         transmitting the reply.

5. BOOTP Server Behavior

   This section provides clarifications on the behavior of BOOTP
   servers.

5.1 Reception of BOOTREQUEST Messages

   All received UDP messages whose UDP destination port number is BOOTPS
   (67) are considered for processing by the BOOTP server.

   Hosts and routers are usually required to silently discard incoming
   datagrams containing illegal IP source addresses.  This is generally
   known as "Martian address filtering."  One of these illegal addresses
   is 0.0.0.0 (or actually anything on network 0).  However, hosts or
   routers which support a BOOTP server MUST accept for local delivery
   to the server BOOTREQUEST messages whose IP source address is
   0.0.0.0.  BOOTREQUEST messages from legal IP source addresses MUST
   also be accepted.

   A BOOTP server MUST silently discard any received UDP messages whose
   UDP destination port number is BOOTPC (68).

      DISCUSSION:

         There should be no need for a BOOTP server to process messages
         addressed to the BOOTPC port.  Careful reading of the original
         BOOTP specification [1] will show this.



Wimer                                                          [Page 18]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


         The consistency checks specified in Section 2.1 SHOULD be
         performed by the BOOTP server.  BOOTP messages not meeting
         these consistency checks MUST be silently discarded.

5.2 Use of the 'secs' field

   When the BOOTP server receives a BOOTREQUEST message, it MAY use the
   value of the 'secs' (seconds since client began booting) field of the
   request as a factor in deciding whether and/or how to reply to the
   request.

      DISCUSSION:

         To date, this feature of the BOOTP protocol has not necessarily
         been shown to be useful.  See Section 3.2 for a discussion.

5.3 Use of the 'ciaddr' field

   There have been various client interpretations of the 'ciaddr' field
   for which Section 3.3 should be consulted.  A BOOTP server SHOULD be
   prepared to deal with these varying interpretations.  In general, the
   client; the contents of the 'ciaddr', 'chaddr', 'htype', and 'hlen'
   fields, and probably other information (perhaps in the 'file' and
   respond to a given client.

   BOOTP servers SHOULD preserve the contents of the 'ciaddr' field in
   BOOTREPLY messages; the contents of 'ciaddr' in a BOOTREPLY message
   SHOULD exactly match the contents of 'ciaddr' in the corresponding
   BOOTREQUEST message.

      DISCUSSION:

   It has been suggested that a client may wish to use the contents of
   indeed intended for it.

5.4 Strategy for Delivery of BOOTREPLY Messages

   Once the BOOTP server has created an appropriate BOOTREPLY message,
   that BOOTREPLY message must be properly delivered to the client.

   The server SHOULD first check the 'ciaddr' field.  If the 'ciaddr'
   field is non-zero, the BOOTREPLY message SHOULD be sent as an IP
   unicast to the IP address identified in the 'ciaddr' field.  The UDP
   destination port MUST be set to BOOTPC (68).  However, the server
   MUST be aware of the problems identified in Section 3.3.  The server
   MAY choose to ignore the 'ciaddr' field and act as if the 'ciaddr'
   field contains 0.0.0.0 (and thus continue with the rest of the
   delivery algorithm below).



Wimer                                                          [Page 19]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


   The server SHOULD next check the 'giaddr' field.  If this field is
   non-zero, the server SHOULD send the BOOTREPLY as an IP unicast to
   the IP address identified in the 'giaddr' field.  The UDP destination
   port MUST be set to BOOTPS (67).  This action will deliver the
   BOOTREPLY message directly to the BOOTP relay agent closest to the
   client; the relay agent will then perform the final delivery to the
   client.  If the BOOTP server has prior knowledge that a particular
   client cannot receive unicast BOOTREPLY messages (e.g., the network
   manager has explicitly configured the server with such knowledge),
   the server MAY set the newly-defined BROADCAST flag to indicate that
   relay agents SHOULD broadcast the BOOTREPLY message to the client.
   Otherwise, the server MUST preserve the state of the BROADCAST flag
   so that the relay agent can correctly act upon it.

   If the 'giaddr' field is set to 0.0.0.0, then the client resides on
   one of the same networks as the BOOTP server.  The server SHOULD
   examine the newly-defined BROADCAST flag (see Sections 2.2, 3.1.1 and
   4.1.2 for more information).  If this flag is set to 1 or the server
   has prior knowledge that the client is unable to receive unicast
   BOOTREPLY messages, the reply SHOULD be sent as an IP broadcast using
   the IP limited broadcast address 255.255.255.255 as the IP
   destination address and the link-layer broadcast address as the
   link-layer destination address.  If the BROADCAST flag is cleared
   (0), the reply SHOULD be sent as an IP unicast to the IP address
   specified by the field.  If unicasting is not possible, the reply MAY
   be sent as a broadcast in which case it SHOULD be sent to the link-
   layer broadcast address using the IP limited broadcast address
   255.255.255.255 as the IP destination address.  In any case, the UDP
   destination port MUST be set to BOOTPC (68).

      DISCUSSION:

         The addition of the BROADCAST flag to the protocol is a
         workaround to help promote interoperability with certain client
         implementations.

         The following table summarizes server delivery decisions for
         BOOTREPLY messages based upon information in BOOTREQUEST
         messages:












Wimer                                                          [Page 20]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


      BOOTREQUEST fields     BOOTREPLY values for UDP, IP, link-layer
   +-----------------------+-----------------------------------------+
   | 'ciaddr'  'giaddr'  B | UDP dest     IP destination   link dest |
   +-----------------------+-----------------------------------------+
   | non-zero     X      X | BOOTPC (68)  'ciaddr'         normal    |
   | 0.0.0.0   non-zero  X | BOOTPS (67)  'giaddr'         normal    |
   | 0.0.0.0   0.0.0.0   0 | BOOTPC (68)  'yiaddr'         'chaddr'  |
   | 0.0.0.0   0.0.0.0   1 | BOOTPC (68)  255.255.255.255  broadcast |
   +-----------------------+-----------------------------------------+

        B = BROADCAST flag

        X = Don't care

   normal = determine from the given IP destination using normal
            IP routing mechanisms and/or ARP as for any other
            normal datagram

Acknowledgements

   The author would like to thank Gary Malkin for his contribution of
   the "BOOTP over IEEE 802.5 Token Ring Networks" section, and Steve
   Deering for his observations on the problems associated with the
   'giaddr' field.

   Ralph Droms and the many members of the IETF Dynamic Host
   Configuration and Router Requirements working groups provided ideas
   for this memo as well as encouragement to write it.

   Philip Almquist and David Piscitello offered many helpful suggestions
   for improving the clarity, accuracy, and organization of this memo.
   These contributions are graciously acknowledged.

References

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

   [2] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
       USC/Information Sciences Institute, August 1993.  This RFC is
       occasionally reissued with a new number.  Please be sure to
       consult the latest version.

   [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 1531,
       Bucknell University, October 1993.

   [4] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37,
       RFC 826, MIT, November 1982.



Wimer                                                          [Page 21]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


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

   [6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
       USC/Information Sciences Institute, July, 1992.  This RFC is
       periodically reissued with a new number.  Please be sure to
       consult the latest version.

Security Considerations

   There are many factors which make BOOTP in its current form quite
   insecure.  BOOTP is built directly upon UDP and IP which are as yet
   inherently insecure themselves.  Furthermore, BOOTP 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.  This makes it difficult to
   provide any form of reasonable authentication between servers and
   clients.

   Unauthorized BOOTP servers may easily be 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"
   mis-information is planted, an attacker can further compromise the
   affected systems.

   Unauthorized BOOTP relay agents may present some of the same problems
   as unauthorized BOOTP servers.

   Malicious BOOTP 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.

Author's Address

   Walt Wimer
   Network Development
   Carnegie Mellon University
   5000 Forbes Avenue
   Pittsburgh, PA  15213-3890

   Phone: (412) 268-6252
   EMail:  Walter.Wimer@CMU.EDU





Wimer                                                          [Page 22]