idnits 2.17.1 draft-ietf-dhc-bootp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 287 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 164: '...ms, the relay agent SHOULD provide the...' RFC 2119 keyword, line 166: '...ded message, and SHOULD record the eve...' RFC 2119 keyword, line 248: '... They MUST be set to zero by client...' RFC 2119 keyword, line 263: '... MBZ MUST BE ZERO (reserved...' RFC 2119 keyword, line 291: '... MUST conform to the specifications...' (57 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1048 (ref. '2') (Obsoleted by RFC 1084, RFC 1395, RFC 1497, RFC 1533) ** Obsolete normative reference: RFC 1084 (ref. '3') (Obsoleted by RFC 1395, RFC 1497, RFC 1533) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1340 (ref. '7') (Obsoleted by RFC 1700) Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force W. Wimer 2 Internet Draft Carnegie Mellon University 3 September, 1992 5 DRAFT 7 Clarifications and Extensions for the Bootstrap Protocol 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, and 13 its Working Groups. (Note that other groups may also distribute working 14 documents as Internet Drafts.) 16 Internet Drafts are draft documents valid for a maximum of six months. 17 Internet Drafts may be updated, replaced, or obsoleted by other 18 documents at any time. It is not appropriate to use Internet Drafts as 19 reference material or to cite them other than as a "working draft" or 20 "work in progress." 22 Please check the I-D abstract listing contained in each Internet Draft 23 directory to learn the current status of this or any other Internet 24 Draft. This Internet Draft expires on February 28, 1993. 26 This memo suggests several updates to the specification of the Bootstrap 27 Protocol (BOOTP) based on experience with the protocol. 29 This proposal is a product of the IETF Dynamic Host Configuration 30 Working Group. This draft document will be submitted to the RFC editor 31 as a protocol specification. Comments on this memo should be sent to 32 the IETF Dynamic Host Configuration Working Group mailing list, 33 host-conf@sol.bucknell.edu. 35 Distribution of this memo is unlimited. 37 Abstract 39 Some aspects of the BOOTP protocol were rather loosely defined in its 40 original specification. In particular, only a general description was 41 provided for the behavior of "BOOTP relay agents" (originally called 42 "BOOTP forwarding agents"). The client behavior description also 43 suffered in certain ways. This memo attempts to clarify and strengthen 44 the specification in these areas. 46 In addition, new issues have arisen since the original specification was 47 written. This memo also attempts to address some of these. 49 Table of Contents 51 1. Introduction 3 52 1.1 Requirements 3 53 1.2 Terminology 4 54 1.3 Data Transmission Order 5 56 2. Definition of the 'flags' Field 6 58 3. BOOTP Relay Agents 7 59 3.1 General BOOTP Processing 8 60 3.1.1 BOOTREQUEST Messages 8 61 3.1.2 BOOTREPLY Messages 11 63 4. BOOTP Client Behavior 13 64 4.1 Client use of the 'flags' field 13 65 4.1.1 The BROADCAST flag 13 66 4.1.2 The remainder of the 'flags' field 14 67 4.2 Definition of the 'secs' field 14 68 4.3 Interpretation of the 'giaddr' field 14 69 4.4 Vendor information "magic cookie" 15 71 5. Bit Ordering of Hardware Addresses 16 73 6. BOOTP Over IEEE 802.5 Token Ring Networks 16 75 Security Considerations 18 77 Acknowledgements 18 79 References 19 81 Author's Address 19 82 1. Introduction 84 The Bootstrap Protocol (BOOTP) is a UDP/IP-based protocol which allows a 85 booting host to configure itself dynamically and without user 86 supervision. BOOTP provides a means to notify a host of its assigned IP 87 address, the IP address of a boot server host, and the name of a file to 88 be loaded into memory and executed [1]. Other configuration information 89 such as the local subnet mask, the local time offset, the addresses of 90 default routers, and the addresses of various Internet servers can also 91 be communicated to a host using BOOTP [2,3]. 93 Unfortunately, the original BOOTP specification [1] left some issues of 94 the protocol open to question. The exact behavior of BOOTP relay agents 95 (formerly called "BOOTP forwarding agents") was not clearly specified. 96 Some parts of the overall protocol specification actually conflict, 97 while other parts have been subject to misinterpretation, indicating 98 that clarification is needed. This memo addresses these problems. 100 Since the introduction of BOOTP, the IEEE 802.5 Token Ring Network has 101 been developed which presents a unique problem for BOOTP's particular 102 message-transfer paradigm. This memo also suggests a solution for this 103 problem. 105 1.1 Requirements 107 In this memo, the words that are used to define the significance of 108 particular requirements are capitalized. These words are: 110 o "MUST" 112 This word or the adjective "REQUIRED" means that the item 113 is an absolute requirement of the specification. 115 o "MUST NOT" 117 This phrase means that the item is an absolute prohibition 118 of the specification. 120 o "SHOULD" 122 This word or the adjective "RECOMMENDED" means that there 123 may exist valid reasons in particular circumstances to 124 ignore this item, but the full implications should be 125 understood and the case carefully weighed before choosing a 126 different course. 128 o "SHOULD NOT" 130 This phrase means that there may exist valid reasons in 131 particular circumstances when the listed behavior is 132 acceptable or even useful, but the full implications should 133 be understood and the case carefully weighed before 134 implementing any behavior described with this label. 136 o "MAY" 138 This word or the adjective "OPTIONAL" means that this item 139 is truly optional. One vendor may choose to include the 140 item because a particular marketplace requires it or 141 because it enhances the product, for example; another 142 vendor may omit the same item. 144 1.2 Terminology 146 This memo uses the following terms: 148 BOOTREQUEST 149 A BOOTREQUEST message is a BOOTP message sent from a BOOTP 150 client to a BOOTP server, requesting configuration 151 information. 153 BOOTREPLY 154 A BOOTREPLY message is a BOOTP message sent from a BOOTP 155 server to a BOOTP client, providing configuration 156 information. 158 Silently discard 159 This memo specifies several cases where a BOOTP relay agent 160 is to "silently discard" a received BOOTP message. This 161 means that the relay agent should discard the message 162 without further processing, and that the relay agent will 163 not send any ICMP error message as a result. However, for 164 diagnosis of problems, the relay agent SHOULD provide the 165 capability of logging the error, including the contents of 166 the silently-discarded message, and SHOULD record the event 167 in a statistics counter. 169 1.3 Data Transmission Order 171 The order of transmission of the header and data described in this 172 document is resolved to the octet level. Whenever a diagram shows a 173 group of octets, the order of transmission of those octets is the 174 normal order in which they are read in English. For example, in the 175 following diagram, the octets are transmitted in the order they are 176 numbered. 178 0 1 179 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | 1 | 2 | 182 +-------------------------------+ 183 | 3 | 4 | 184 +-------------------------------+ 185 | 5 | 6 | 186 +-------------------------------+ 188 Whenever an octet represents a numeric quantity, the leftmost bit in 189 the diagram is the high order or most significant bit. That is, the 190 bit labeled 0 is the most significant bit. For example, the 191 following diagram represents the value 170 (decimal). 193 0 1 2 3 4 5 6 7 194 +-+-+-+-+-+-+-+-+ 195 |1 0 1 0 1 0 1 0| 196 +---------------+ 198 Similarly, whenever a multi-octet field represents a numeric 199 quantity the leftmost bit of the whole field is the most significant 200 bit. When a multi-octet quantity is transmitted the most 201 significant octet is transmitted first. 203 2. Definition of the 'flags' Field 205 The standard BOOTP message format defined in [1] includes a two-octet 206 field located between the 'secs' field and the 'ciaddr' field. This 207 field is merely designated as "unused" and its contents left 208 unspecified, although Section 7.1 of [1] does offer the following 209 suggestion: 211 "Before setting up the packet for the first time, it is a good idea 212 to clear the entire packet buffer to all zeros; this will place all 213 fields in their default state." 215 This memo hereby designates this two-octet field as the 'flags' field. 217 The first 44 octets of a BOOTP message are shown below. The numbers in 218 parentheses indicate the size of each field in octets. 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | op (1) | htype (1) | hlen (1) | hops (1) | 224 +---------------+---------------+---------------+---------------+ 225 | xid (4) | 226 +-------------------------------+-------------------------------+ 227 | secs (2) | flags (2) | 228 +-------------------------------+-------------------------------+ 229 | ciaddr (4) | 230 +---------------------------------------------------------------+ 231 | yiaddr (4) | 232 +---------------------------------------------------------------+ 233 | siaddr (4) | 234 +---------------------------------------------------------------+ 235 | giaddr (4) | 236 +---------------------------------------------------------------+ 237 | | 238 | chaddr (16) | 239 | | 240 | | 241 +---------------------------------------------------------------+ 243 This document hereby defines the most significant bit of the 'flags' 244 field as the BROADCAST (B) flag. The semantics of this flag are 245 discussed in Sections 3.1.2 and 4.1.1 of this memo. 247 The remaining bits of the 'flags' field are reserved for future use. 248 They MUST be set to zero by clients and ignored by servers and relay 249 agents. 251 The 'flags' field, then, appears as follows: 253 0 1 254 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 |B| MBZ | 257 +-+-----------------------------+ 259 where: 261 B BROADCAST flag (discussed in Sections 3.1.2 and 4.1.1) 263 MBZ MUST BE ZERO (reserved for future use) 265 3. BOOTP Relay Agents 267 In many cases, BOOTP clients and their associated BOOTP server(s) do not 268 reside on the same IP network or subnet. In such cases, some kind of 269 third-party agent is required to transfer BOOTP messages between clients 270 and servers. Such an agent was originally referred to as a "BOOTP 271 forwarding agent." However, in order to avoid confusion with the IP 272 forwarding function of an IP router, the name "BOOTP relay agent" is 273 hereby adopted instead. 275 DISCUSSION: 276 A BOOTP relay agent performs a task which is distinct from an IP 277 router's normal IP forwarding function. While a router normally 278 switches IP datagrams between networks more-or-less 279 transparently, a BOOTP relay agent may more properly be thought 280 to receive BOOTP messages as a final destination and then 281 generate new BOOTP messages as a result. One should resist the 282 notion of simply forwarding a BOOTP message "straight through 283 like a regular packet." 285 This relay-agent functionality is most conveniently located in the 286 routers which interconnect the clients and servers, but may 287 alternatively be located in a host which is directly connected to the 288 client subnet. 290 Any Internet host or router which provides BOOTP relay-agent capability 291 MUST conform to the specifications in this memo. 293 3.1 General BOOTP Processing 295 All locally delivered UDP messages whose UDP destination port number 296 is BOOTPS (67) are considered for special processing by the host or 297 router's logical BOOTP relay agent. 299 In the case of a host, locally delivered datagrams are simply all 300 datagrams normally received by that host, i.e. broadcast and 301 multicast datagrams as well as unicast datagrams addressed to IP 302 addresses of that host. 304 In the case of a router, local delivery has a similar but somewhat 305 more careful definition for which [4] should be consulted. 307 Hosts and routers are usually required to silently discard incoming 308 datagrams containing illegal IP source addresses. This is generally 309 known as "Martian address filtering." One of these illegal 310 addresses is 0.0.0.0 (or actually anything on network 0). However, 311 hosts or routers which support a BOOTP relay agent MUST accept for 312 local delivery to the relay agent BOOTREQUEST messages whose IP 313 source address is 0.0.0.0. BOOTREQUEST messages from legal IP 314 source addresses MUST also be accepted, of course. 316 The following consistency checks SHOULD be performed on BOOTP 317 messages: 319 o The IP Total Length and UDP Length must be large enough to 320 contain the minimal BOOTP header of 300 octets (in the UDP 321 data field) specified in [1]. 323 NOTE: Future extensions to the BOOTP protocol may increase 324 the size of BOOTP messages. Therefore, BOOTP messages 325 which, according to the IP Total Length and UDP Length 326 fields, are larger than the minimum size specified by [1] 327 MUST also be accepted. 329 o The 'op' (opcode) field of the message must contain either 330 the code for a BOOTREQUEST (1) or the code for a BOOTREPLY 331 (2). 333 BOOTP messages not meeting these consistency checks MUST be silently 334 discarded. 336 3.1.1 BOOTREQUEST Messages 338 Some configuration mechanism MUST exist to enable or disable the 339 relaying of BOOTREQUEST messages. Relaying MUST be disabled by 340 default. 342 When the BOOTP relay agent receives a BOOTREQUEST message, it 343 MAY use the value of the 'secs' (seconds since client began 344 booting) field of the request as a factor in deciding whether to 345 relay the request. If such a policy mechanism is implemented, 346 its threshold SHOULD be configurable. 348 DISCUSSION: 349 To date, this feature of the BOOTP protocol has not 350 necessarily been shown to be useful. See Section 4.2 351 for a discussion. 353 The relay agent MUST silently discard BOOTREQUEST messages whose 354 'hops' field exceeds the value 16. A configuration option 355 SHOULD be provided to set this threshold to a smaller value if 356 desired by the network manager. The default setting for a 357 configurable threshold SHOULD be 4. 359 If the relay agent does decide to relay the request, it MUST 360 examine the 'giaddr' ("gateway" IP address) field. If this 361 field is zero, the relay agent MUST fill this field with the IP 362 address of the logical interface on which the request was 363 received. In addition, the relay agent MAY insert the subnet 364 mask of that logical interface into the vendor area (see the 365 next paragraph for details). If the 'giaddr' field contains 366 some non-zero value, the 'giaddr' field MUST NOT be modified and 367 the subnet mask MUST NOT be inserted into the vendor area nor 368 modified. The relay agent MUST NOT, under any circumstances, 369 fill the 'giaddr' field with a broadcast address as is suggested 370 in [1] (Section 8, sixth paragraph). 372 To insert the subnet mask into the vendor area as suggested 373 above, the relay agent MUST examine the first four octets of the 374 'vend' field (these first four octets are usually referred to as 375 the "vendor magic number" or "vendor magic cookie"). If these 376 four octets do not contain the dotted decimal value 99.130.83.99 377 as specified in [2,3], the subnet mask MUST NOT be inserted. If 378 these four octets do contain the value 99.130.83.99, it is safe 379 to insert the subnet mask. The relay agent MUST use the data 380 format as specified in [2,3] and MUST use the "Subnet Mask 381 Field" (Tag 1) specified in [2,3] to express the subnet mask. 382 The relay agent MUST be careful to preserve any and all existing 383 data in the 'vend' field. The subnet mask MUST either be placed 384 at the beginning of the data portion of the 'vend' field 385 (immediately after the four-octet magic cookie), or the relay 386 agent MUST be careful to replace any existing subnet mask 387 entries (Tag 1) with the correct subnet mask value. This is to 388 avoid any ambiguity in the event that the client supplied one or 389 more subnet mask entries somewhere in the 'vend' field. If the 390 subnet mask cannot be inserted without loss of data in the 391 'vend' field, the subnet mask MUST NOT be inserted. 393 DISCUSSION: 394 Having the relay agent insert the subnet mask into the 395 vendor area is an optimization for the proposed Dynamic 396 Host Configuration Protocol (DHCP) [5]. This 397 optimization should not be strictly necessary for 398 correct operation of the protocol, but it should make 399 configuration of the DHCP server much easier. It is 400 strongly encouraged that relay agents provide this 401 subnet mask feature, but it is not absolutely required. 403 The value of the 'hops' field MUST be incremented. 405 All other fields MUST be preserved intact. 407 At this point, the request is relayed to its new destination (or 408 destinations). This destination MUST be configurable. Further, 409 this destination configuration SHOULD be independent of the 410 destination configuration for any other so-called "broadcast 411 forwarders" (e.g. for the UDP-based TFTP, DNS, Time, etc. 412 protocols). 414 DISCUSSION: 415 The network manager may wish the relaying destination to 416 be an IP unicast, multicast, broadcast, or some 417 combination. A configurable list of destination IP 418 addresses provides good flexibility. More flexible 419 configuration schemes are encouraged. For example, it 420 may be desirable to send to the limited broadcast 421 address (255.255.255.255) on specific logical 422 interfaces. However, if the BOOTREQUEST message was 423 received as a broadcast, the relay agent MUST NOT 424 rebroadcast the BOOTREQUEST on the logical interface 425 from whence it came. 427 A relay agent MUST use the same destination (or set of 428 destinations) for all BOOTREQUEST messages it relays from a 429 given client. 431 DISCUSSION: 432 At least one known relay agent implementation uses a 433 round-robin scheme to provide load balancing across 434 multiple BOOTP servers. Each time it receives a new 435 BOOTREQUEST message, it relays the message to the next 436 BOOTP server in a list of servers. Thus, with this 437 relay agent, multiple consecutive BOOTREQUEST messages 438 from a given client will be delivered to different 439 servers. 441 Unfortunately, this well-intentioned scheme reacts badly 442 with certain variations of the BOOTP protocol which 443 depend on multiple exchanges of BOOTREQUEST and 444 BOOTREPLY messages between clients and servers. 445 Therefore, all BOOTREQUEST messages from a given client 446 MUST be relayed to the same destination (or set of 447 destinations). 449 One way to meet this requirement while providing some 450 load-balancing benefit is to hash the client's 451 link-layer address (or some other reliable 452 client-identifying information) and use the resulting 453 hash value to select the appropriate relay destination 454 (or set of destinations). The simplest solution, of 455 course, is to not use a load-balancing scheme and just 456 relay ALL received BOOTREQUEST messages to the same 457 destination (or set of destinations). 459 When transmitting the request to its next destination, the relay 460 agent may set the IP Time-To-Live field to either the default 461 value for new datagrams originated by the relay agent, or to the 462 TTL of the original BOOTREQUEST decremented by (at least) one. 464 DISCUSSION: 465 As an extra precaution against BOOTREQUEST loops, it is 466 preferable to use the decremented TTL from the original 467 BOOTREQUEST. Unfortunately, this may be difficult to do 468 in some implementations. 470 The UDP checksum must be recalculated before transmitting the 471 request. 473 3.1.2 BOOTREPLY Messages 475 BOOTP relay agents relay BOOTREPLY messages only to BOOTP 476 clients. It is the responsibility of BOOTP servers to send 477 BOOTREPLY messages directly to the relay agent identified in the 478 'giaddr' field. Therefore, a relay agent may assume that all 479 BOOTREPLY messages it receives are intended for BOOTP clients on 480 its directly-connected networks. 482 When a relay agent receives a BOOTREPLY message, it should 483 examine the BOOTP 'giaddr', 'yiaddr', 'chaddr', 'htype', and 484 'hlen' fields. These fields should provide adequate information 485 for the relay agent to deliver the BOOTREPLY message to the 486 client. 488 The 'giaddr' field can be used to identify the logical interface 489 to which the reply must be sent (i.e. the host or router 490 interface connected to the same network as the BOOTP client). 491 If the content of the 'giaddr' field does not match one of the 492 relay agent's directly-connected logical interfaces, the 493 BOOTREPLY messsage MUST be silently discarded. 495 The 'htype', 'hlen', and 'chaddr' fields supply the link-layer 496 hardware type, hardware address length, and hardware address of 497 the client as defined in the ARP protocol [6] and the Assigned 498 Numbers document [7]. The 'yiaddr' field is the IP address of 499 the client, as assigned by the BOOTP server. 501 The relay agent SHOULD examine the newly-defined BROADCAST flag 502 (see Sections 2 and 4.1.1 for more information). If this flag 503 is set to 1, the reply SHOULD be sent as an IP broadcast using 504 an IP broadcast address (preferably 255.255.255.255) as the IP 505 destination address and the link-layer broadcast address as the 506 link-layer destination address. If the BROADCAST flag is 507 cleared (0), the reply SHOULD be sent as an IP unicast to the IP 508 address specified by the 'yiaddr' field and the link-layer 509 address specified in the 'chaddr' field. If unicasting is not 510 possible, the reply MAY be sent to the link-layer broadcast 511 address using an IP broadcast address (preferably 512 255.255.255.255) as the IP destination address. 514 DISCUSSION: 515 The addition of the BROADCAST flag to the protocol is a 516 workaround to help promote interoperability with certain 517 client implementations. 519 Note that since the 'flags' field was previously defined 520 in [1] simply as an "unused" field, it is possible that 521 old client or server implementations may accidentally 522 and unknowingly set the new BROADCAST flag. It is 523 actually expected that such implementations will be rare 524 (most implementations seem to zero-out this field), but 525 interactions with such implementations must nevertheless 526 be considered. If an old client or server does set the 527 BROADCAST flag to 1 incorrectly, conforming relay agents 528 will generate broadcast BOOTREPLY messages to the 529 corresponding client. The BOOTREPLY messages should 530 still properly reach the client, at the cost of one 531 (otherwise unnecessary) additional broadcast. This, 532 however, is no worse than a server or relay agent which 533 always broadcasts its BOOTREPLY messages. 535 The reply MUST have its UDP destination port set to BOOTPC (68). 537 The UDP checksum must be recalculated before transmitting the 538 reply. 540 4. BOOTP Client Behavior 542 This section clarifies various issues regarding BOOTP client behavior. 544 4.1 Client use of the 'flags' field 546 4.1.1 The BROADCAST flag 548 Normally, BOOTP servers and relay agents attempt to deliver 549 BOOTREPLY messages directly to a client using unicast delivery. 550 The IP destination address (in the IP header) is set to the 551 BOOTP 'yiaddr' address and the link-layer destination address is 552 set to the BOOTP 'chaddr' address. Unfortunately, some client 553 implementations are unable to receive such unicast IP datagrams 554 until they know their own IP address (thus we have a "chicken 555 and egg" issue). Often, however, they can receive broadcast IP 556 datagrams (those with a valid IP broadcast address as the IP 557 destination and the link-layer broadcast address as the 558 link-layer destination). 560 If a client falls into this category, it SHOULD set (to 1) the 561 newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY 562 messages it generates. This will provide a hint to BOOTP 563 servers and relay agents that they should attempt to broadcast 564 their BOOTREPLY messages to the client. 566 If a client does not have this limitation (i.e. it is perfectly 567 able to receive unicast BOOTREPLY messages), it SHOULD NOT set 568 the BROADCAST flag (i.e. it SHOULD clear the BROADCAST flag to 569 0). 571 DISCUSSION: 572 This addition to the protocol is a workaround for old 573 host implementations. It is strongly recommended that 574 such implementations be modified so that they may 575 receive unicast BOOTREPLY messages, thus making use of 576 this workaround unnecessary. In general, the use of 577 this mechanism is discouraged. 579 4.1.2 The remainder of the 'flags' field 581 The remaining bits of the 'flags' field are reserved for future 582 use. A client MUST set these bits to zero in all BOOTREQUEST 583 messages it generates. A client MUST ignore these bits in all 584 BOOTREPLY messages it receives. 586 4.2 Definition of the 'secs' field 588 The 'secs' field of a BOOTREQUEST message SHOULD represent the 589 elapsed time, in seconds, since the client sent its first 590 BOOTREQUEST message. Note that this implies that the 'secs' field 591 of the first BOOTREQUEST message SHOULD be set to zero. 593 Clients SHOULD NOT set the 'secs' field to a value which is constant 594 for all BOOTREQUEST messages. 596 DISCUSSION: 597 The original definition of the 'secs' field was vague. It 598 was not clear whether it represented the time since the 599 first BOOTREQUEST message was sent or some other time period 600 such as the time since the client machine was powered-up. 601 This has limited its usefulness as a policy control for 602 BOOTP servers and relay agents. Furthermore, certain client 603 implementations have been known to simply set this field to 604 a constant value or use incorrect byte-ordering (usually 605 resulting in very inflated figures). 607 4.3 Interpretation of the 'giaddr' field 609 The 'giaddr' field is rather poorly named. It exists to facilitate 610 the transfer of BOOTREQUEST messages from a client, through BOOTP 611 relay agents, to servers on different networks than the client. 612 Similarly, it facilitates the delivery of BOOTREPLY messages from 613 the servers, through BOOTP relay agents, back to the client. In no 614 case does it represent a general IP router to be used by the client. 616 A BOOTP client MUST set the 'giaddr' field to zero (0.0.0.0) in all 617 BOOTREQUEST messages it generates. 619 A BOOTP client MUST NOT consider the 'giaddr' field of a BOOTREPLY 620 message to represent an IP router. A BOOTP client SHOULD completely 621 ignore the contents of the 'giaddr' field in BOOTREPLY messages. 623 DISCUSSION: 624 The semantics of the 'giaddr' field were poorly defined. 625 Section 7.5 of [1] states: 627 "If 'giaddr' (gateway address) is nonzero, then the 628 packets should be forwarded there first, in order to 629 get to the server." 631 In that sentence, "get to" refers to communication from the 632 client to the server subsequent to the BOOTP exchange, such 633 as a TFTP session. Unfortunately, the 'giaddr' field may 634 contain the address of a BOOTP relay agent that is not 635 itself an IP router (according to [1], Section 8, fifth 636 paragraph), in which case, it will be useless as a first-hop 637 for TFTP packets sent to the server (since, by definition, 638 non-routers don't forward datagrams at the IP layer). 640 Although now prohibited by Section 3.1.1 of this memo, the 641 'giaddr' field might contain a broadcast address according 642 to Section 8, sixth paragraph of [1]. Not only would such 643 an address be useless as a router address, it might also 644 cause the client to ARP for the broadcast address (since, if 645 the client didn't receive a subnet mask in the BOOTREPLY 646 message, it would be unable to recognize a subnet broadcast 647 address). This is clearly undesirable. 649 To reach a non-local server, clients can obtain a first-hop 650 router address from the "Gateway" subfield of the "Vendor 651 Information Extensions" [2,3] (if present), or from some 652 other router discovery protocol. 654 4.4 Vendor information "magic cookie" 656 It is RECOMMENDED that a BOOTP client always fill the first four 657 octets of the 'vend' (vendor information) field of a BOOTREQUEST 658 with a four-octet identifier called a "magic cookie." A BOOTP 659 client SHOULD do this even if it has no special information to 660 communicate to the BOOTP server using the 'vend' field. This aids 661 the BOOTP server in determining what vendor information format it 662 should use in its BOOTREPLY messages. 664 If a special vendor-specific magic cookie is not being used, a BOOTP 665 client SHOULD use the dotted decimal value 99.130.83.99 as specified 666 in [2,3]. In this case, if the client has no information to 667 communicate to the server, the octet immediately following the magic 668 cookie SHOULD be set to the "End" tag (255) and the remaining octets 669 of the 'vend' field SHOULD be set to zero. 671 DISCUSSION: 672 Sometimes different operating systems or networking packages 673 are run on the same machine at different times (or even at 674 the same time!). Since the hardware address placed in the 675 'chaddr' field will likely be the same, BOOTREQUESTs from 676 completely different BOOTP clients on the same machine will 677 likely be difficult for a BOOTP server to differentiate. If 678 the client includes a magic cookie in its BOOTREQUEST 679 messages, the server will at least know what format the 680 client expects and can understand in corresponding BOOTREPLY 681 messages. 683 5. Bit Ordering of Hardware Addresses 685 The bit ordering used for link-level hardware addresses in the 'chaddr' 686 field SHOULD be the same as the ordering used for the ARP protocol [6] 687 on the client's network (assuming ARP is defined for that network). 689 DISCUSSION: 690 One of the primary reasons the 'chaddr' field exists is to 691 enable BOOTP servers and relay agents to communicate directly 692 with clients without the use of broadcasts. In practice, the 693 contents of the 'chaddr' field is often used to create an 694 ARP-cache entry in exactly the same way the normal ARP protocol 695 would have. Clearly, interoperability can only be achieved if a 696 consistent interpretation of the 'chaddr' field is used. 698 6. BOOTP Over IEEE 802.5 Token Ring Networks 700 Special consideration of the client/server and client/relay agent 701 interactions must be given to 802.5 networks because of non-transparent 702 bridging. In the simplest case, an unbridged, single ring network, the 703 broadcast behavior of the BOOTP protocol is identical to that of 704 Ethernet networks. However, a BOOTP client cannot know, a priori, that 705 an 802.5 network is not bridged. In fact, the likelihood is that the 706 server, or relay agent, will not know either. 708 Of the four possible scenerios, only two are interesting: where the 709 assumption is that the 802.5 network is not bridged and it is, and the 710 assumption that the network is bridged and it is not. In the former 711 case, the Routing Information Field (RIF) will not be used; therefore, 712 if the server/relay agent are on another segment of the ring, the client 713 cannot reach it. In the latter case, the RIF field will be used, 714 resulting in a few extraneous bytes on the ring. It is obvious that an 715 almost immeasurable inefficiency is to be preferred over a complete 716 failure to communicate. 718 Given that the assumption is that RIF fields will be needed, it is 719 necesary to determine the optimum method for the client to reach the 720 server/relay agent, and the optimum method for the response to be 721 returned. 723 The client SHOULD send its broadcast BOOTREQUEST with an All Routes 724 Explorer RIF. This will enable servers/relay agents to cache the return 725 route if they choose to do so. For those server/relay agents which 726 cannot cache the return route (because they are stateless, for example), 727 the BOOTREPLY message is sent to the client's hardware address, as taken 728 from the BOOTP message, with a Spanning Tree Rooted RIF. The actual 729 bridge route will be recorded by the client and server/relay agent by 730 normal ARP processing code. 732 Security Considerations 734 BOOTP is built directly upon UDP and IP which are as yet inherently 735 insecure. Furthermore, BOOTP is generally intended to make maintenance 736 of remote and/or diskless hosts easier. While perhaps not impossible, 737 configuring such hosts with passwords or keys may be difficult and 738 inconvenient. Therefore, BOOTP in its current form is quite insecure. 740 Unauthorized BOOTP servers may easily be set up. Such servers can then 741 send false and potentially disruptive information to clients such as 742 incorrect or duplicate IP addresses, incorrect routing information 743 (including spoof routers, etc.), incorrect domain nameserver addresses 744 (such as spoof nameservers), and so on. Clearly, once this "seed" 745 mis-information is planted, an attacker can further compromise the 746 affected systems. 748 BOOTP relay agents suffer some of the same problems as BOOTP servers. 750 Malicious BOOTP clients could masquerade as legitimate clients and 751 retrieve information intended for those legitimate clients. Where 752 dynamic allocation of resources is used, a malicious client could claim 753 all resources for itself, thereby denying resources to legitimate 754 clients. 756 Acknowledgements 758 The author would like to thank Gary Malkin of FTP Software, Inc. for his 759 contribution of the "BOOTP over IEEE 802.5 Token Ring Networks" section, 760 and Steve Deering of Xerox PARC for his observations on the problems 761 associated with the 'giaddr' field. 763 Ralph Droms of Bucknell University and the many members of the IETF 764 Dynamic Host Configuration and Router Requirements working groups 765 provided ideas for this memo as well as encouragement to write it. 767 References 769 [1] Croft, B., and J. Gilmore. Bootstrap Protocol (BOOTP). Request 770 For Comments (RFC) 951, DDN Network Information Center, SRI 771 International, Menlo Park, California, USA, September, 1985. 773 [2] Prindeville, P. BOOTP Vendor Information Extensions. Request For 774 Comments (RFC) 1048, DDN Network Information Center, SRI 775 International, Menlo Park, California, USA, February, 1988. 777 [3] Reynolds, J. BOOTP Vendor Information Extensions. Request For 778 Comments (RFC) 1084, DDN Network Information Center, SRI 779 International, Menlo Park, California, USA, December, 1988. 781 [4] Almquist, P. Requirements for IP Routers. Internet Draft, 782 Corporation for National Research Initiatives, Reston, Virginia, 783 USA, May, 1991. 785 [5] Droms, R. Dynamic Host Configuration Protocol. Internet Draft, 786 Corporation for National Research Initiatives, Reston, Virginia, 787 USA, June, 1992. 789 [6] Plummer, D. An Ethernet Address Resolution Protocol. Request For 790 Comments (RFC) 826, DDN Network Information Center, SRI 791 International, Menlo Park, California, USA, November, 1982. 793 [7] Reynolds, J., and J. Postel. Assigned Numbers. Request For 794 Comments (RFC) 1340, DDN Network Information Center, SRI 795 International, Menlo Park, California, USA, July, 1992. This RFC 796 is periodically reissued with a new number. Please be sure to 797 consult the latest version. 799 Author's Address 801 Walt Wimer 802 Network Development 803 Carnegie Mellon University 804 4910 Forbes Avenue 805 Pittsburgh, PA 15213-3890 807 Phone: (412) 268-6252 809 EMail: Walter.Wimer@ANDREW.CMU.EDU