From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1542.txt | 1291 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1291 insertions(+) create mode 100644 doc/rfc/rfc1542.txt (limited to 'doc/rfc/rfc1542.txt') diff --git a/doc/rfc/rfc1542.txt b/doc/rfc/rfc1542.txt new file mode 100644 index 0000000..cc03e66 --- /dev/null +++ b/doc/rfc/rfc1542.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group W. Wimer +Request for Comments: 1542 Carnegie Mellon University +Updates: 951 October 1993 +Obsoletes: 1532 +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. Due to some errors + introduced into RFC 1532 in the editorial process, this memo is + reissued as RFC 1542. + + 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................................................ 3 + 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.............................. 10 + 3.3 Use of the 'ciaddr' and 'yiaddr' fields..................... 10 + + + +Wimer [Page 1] + +RFC 1542 Clarifications and Extensions for BOOTP October 1993 + + + 3.4 Interpretation of the 'giaddr' field........................ 11 + 3.5 Vendor information "magic cookie"........................... 12 + 4. BOOTP Relay Agents........................................... 13 + 4.1 General BOOTP Processing for Relay Agents................... 14 + 4.1.1 BOOTREQUEST Messages...................................... 14 + 4.1.2 BOOTREPLY Messages........................................ 17 + 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................. 20 + Acknowledgements................................................ 21 + References...................................................... 22 + Security Considerations......................................... 23 + Author's Address................................................ 23 + +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]. + + + + + + +Wimer [Page 2] + +RFC 1542 Clarifications and Extensions for BOOTP October 1993 + + +1.1 Requirements + + In this memo, the words that are used to define the significance of + particular requirements are capitalized. These words are: + + o "MUST" + + This word or the adjective "REQUIRED" means that the item + is an absolute requirement of 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. + + + + +Wimer [Page 3] + +RFC 1542 Clarifications and Extensions for BOOTP October 1993 + + + BOOTREPLY + + A BOOTREPLY message is a BOOTP message sent from a BOOTP server + to a BOOTP client, providing configuration information. + + 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 + + + +Wimer [Page 4] + +RFC 1542 Clarifications and Extensions for BOOTP October 1993 + + + is transmitted first. + +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 + + + +Wimer [Page 5] + +RFC 1542 Clarifications and Extensions for BOOTP October 1993 + + + and relay agents. + + 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 1542 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 + 'chaddr' field SHOULD be the same as the ordering used for the ARP + 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 + 'chaddr' field even if it happens to be relaying a BOOTREQUEST + between 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 + + + +Wimer [Page 7] + +RFC 1542 Clarifications and Extensions for BOOTP October 1993 + + + with clients without the use of broadcasts. In practice, the + contents of the 'chaddr' field is often used to create an ARP- + cache entry in exactly the same way the normal ARP protocol + would 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 'chaddr' field by a BOOTP client on an IEEE 802.5 Token + Ring network 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. + + + + + + +Wimer [Page 8] + +RFC 1542 Clarifications and Extensions for BOOTP October 1993 + + + 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. + +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 + 'chaddr' address. Unfortunately, some client implementations are + 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 + + + +Wimer [Page 9] + +RFC 1542 Clarifications and Extensions for BOOTP October 1993 + + + 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 + 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 + 'ciaddr' field, the client MUST be prepared to accept incoming + unicast 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 + 'yiaddr' field) than the client expressed in 'ciaddr'. The client + SHOULD adopt the IP address specified in 'yiaddr' and begin using it + as soon as possible. + + + + + + +Wimer [Page 10] + +RFC 1542 Clarifications and Extensions for BOOTP October 1993 + + + 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 + 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 'ciaddr' to + express the client's desired IP address, even if the 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 + + + +Wimer [Page 11] + +RFC 1542 Clarifications and Extensions for BOOTP October 1993 + + + 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. + + 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. + + + + +Wimer [Page 12] + +RFC 1542 Clarifications and Extensions for BOOTP October 1993 + + + 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. + + 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. + + + +Wimer [Page 13] + +RFC 1542 Clarifications and Extensions for BOOTP October 1993 + + +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. + + 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. + + + + +Wimer [Page 14] + +RFC 1542 Clarifications and Extensions for BOOTP October 1993 + + + 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. + + 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 + 'hops' field exceeds the value 16. A configuration option SHOULD be + 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 + + + +Wimer [Page 15] + +RFC 1542 Clarifications and Extensions for BOOTP October 1993 + + + 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. + + 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 + + + +Wimer [Page 16] + +RFC 1542 Clarifications and Extensions for BOOTP October 1993 + + + 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 'giaddr' field. + Therefore, a relay agent may assume that all BOOTREPLY messages it + 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 'hlen' fields. + These fields should provide adequate information 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. + + + + +Wimer [Page 17] + +RFC 1542 Clarifications and Extensions for BOOTP October 1993 + + + 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 + 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. + + + +Wimer [Page 18] + +RFC 1542 Clarifications and Extensions for BOOTP October 1993 + + + 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. + + 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 + 'ciaddr' field SHOULD NOT be trusted as a sole key in identifying a + client; the contents of the 'ciaddr', 'chaddr', 'htype', and 'hlen' + fields, and probably other information (perhaps in the 'file' and + 'vend' fields) SHOULD all be considered together in deciding how to + 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 'ciaddr' to further verify that a particular + BOOTREPLY message was indeed intended for it. + + + + + +Wimer [Page 19] + +RFC 1542 Clarifications and Extensions for BOOTP October 1993 + + +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). + + 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 '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. In any case, the UDP + destination port MUST be set to BOOTPC (68). + + + + + + + +Wimer [Page 20] + +RFC 1542 Clarifications and Extensions for BOOTP October 1993 + + + 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: + + 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. + + + + + + + + + +Wimer [Page 21] + +RFC 1542 Clarifications and Extensions for BOOTP October 1993 + + +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 1541, + Bucknell University, October 1993. + + [4] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37, + RFC 826, MIT, November 1982. + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wimer [Page 22] + +RFC 1542 Clarifications and Extensions for BOOTP October 1993 + + +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 23] + \ No newline at end of file -- cgit v1.2.3