As per Relevance of the word broadcast, we have this rfc below:
Network Working Group W.
Request for Comments: 1542 Carnegie Mellon
Updates: 951 October 1993
Obsoletes: 1532
Category: Standards
Clarifications and Extensions for the Bootstrap
Status of this
This RFC specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" for the standardization state and
of this protocol. Distribution of this memo is unlimited
Some aspects of the BOOTP protocol were rather loosely defined in
original specification. In particular, only a general
was provided for the behavior of "BOOTP relay agents" (
called BOOTP forwarding agents"). The client behavior
also suffered in certain ways. This memo attempts to clarify
strengthen the specification in these areas. Due to some
introduced into RFC 1532 in the editorial process, this memo
reissued as RFC 1542.
In addition, new issues have arisen since the original
was written. This memo also attempts to address some of these
Table of
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.
The Bootstrap Protocol (BOOTP) is a UDP/IP-based protocol
allows a booting host to configure itself dynamically and
user supervision. BOOTP provides a means to notify a host of
assigned IP address, the IP address of a boot server host, and
name of a file to be loaded into memory and executed [1].
configuration information such as the local subnet mask, the
time offset, the addresses of default routers, and the addresses
various Internet servers can also be communicated to a host
BOOTP [2].
Unfortunately, the original BOOTP specification [1] left some
of the protocol open to question. The exact behavior of BOOTP
agents formerly called "BOOTP forwarding agents") was not
specified. Some parts of the overall protocol specification
conflict, while other parts have been subject to misinterpretation
indicating that clarification is needed. This memo addresses
problems
Since the introduction of BOOTP, the IEEE 802.5 Token Ring
has been developed which presents a unique problem for BOOTP'
particular message-transfer paradigm. This memo also suggests
solution for this problem
NOTE: Unless otherwise specified in this document or a
document, the information and requirements specified througout
document also apply to extensions to BOOTP such as the Dynamic
Configuration Protocol (DHCP) [3].
Wimer [Page 2]
RFC 1542 Clarifications and Extensions for BOOTP October 1993
1.1
In this memo, the words that are used to define the significance
particular requirements are capitalized. These words are
o "MUST
This word or the adjective "REQUIRED" means that the
is an absolute requirement of the specification
o "MUST NOT
This phrase means that the item is an absolute
of the specification
o "SHOULD
This word or the adjective "RECOMMENDED" means that
may exist valid reasons in particular circumstances
ignore this item, but the full implications should
understood and the case carefully weighed before choosing
different course
o "SHOULD NOT
This phrase means that there may exist valid reasons
particular circumstances when the listed behavior
acceptable or even useful, but the full implications
be understood and the case carefully weighed
implementing any behavior described with this label
o "MAY
This word or the adjective "OPTIONAL" means that this
is truly optional. One vendor may choose to include
item because a particular marketplace requires it
because it enhances the product, for example;
vendor may omit the same item
1.2
This memo uses the following terms
A BOOTREQUEST message is a BOOTP message sent from a
client to a BOOTP server, requesting configuration information
Wimer [Page 3]
RFC 1542 Clarifications and Extensions for BOOTP October 1993
A BOOTREPLY message is a BOOTP message sent from a BOOTP
to a BOOTP client, providing configuration information
Silently
This memo specifies several cases where a BOOTP entity is
"silently discard" a received BOOTP message. This means
the entity is to discard the message without
processing, and that the entity will not send any ICMP
message as a result. However, for diagnosis of problems,
entity SHOULD provide the capability of logging the error
including the contents of the silently-discarded message,
SHOULD record the event in a statistics counter
1.3 Data Transmission
The order of transmission of the header and data described in
document is resolved to the octet level. Whenever a diagram shows
group of octets, the order of transmission of those octets is
normal order in which they are read in English. For example, in
following diagram, the octets are transmitted in the order they
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
the diagram is the high order or most significant bit. That is,
bit labeled 0 is the most significant bit. For example,
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
the leftmost bit of the whole field is the most significant bit
When a multi-octet quantity is transmitted the most significant
Wimer [Page 4]
RFC 1542 Clarifications and Extensions for BOOTP October 1993
is transmitted first
2. General
This section covers issues of general relevance to all BOOTP
(clients, servers, and relay agents).
2.1 General BOOTP
The following consistency checks SHOULD be performed on
messages
o The IP Total Length and UDP Length must be large enough
contain the minimal BOOTP header of 300 octets (in the
data field) specified in [1].
NOTE: Future extensions to the BOOTP protocol may increase the
of BOOTP messages. Therefore, BOOTP messages which, according to
IP Total Length and UDP Length fields, are larger than the
size specified by [1] MUST also be accepted
o The 'op' (opcode) field of the message must contain either
code for a BOOTREQUEST (1) or the code for a BOOTREPLY (2).
BOOTP messages not meeting these consistency checks MUST be
discarded
2.2 Definition of the 'flags'
The standard BOOTP message format defined in [1] includes a two-
field located between the 'secs' field and the 'ciaddr' field.
field is merely designated as "unused" and its contents
unspecified, although Section 7.1 of [1] does offer the
suggestion
"Before setting up the packet for the first time, it is a
idea to clear the entire packet buffer to all zeros; this
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
discussed in Sections 3.1.1 and 4.1.2 of this memo
The remaining bits of the 'flags' field are reserved for
use. They MUST be set to zero by clients and ignored by
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
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
The bit ordering used for link-level hardware addresses in
'chaddr' field SHOULD be the same as the ordering used for the
protocol [4] on the client's link-level network (assuming ARP
defined for that network).
The 'chaddr' field MUST be preserved as it was specified by the
client. A relay agent MUST NOT reverse the bit ordering of
'chaddr' field even if it happens to be relaying a
between two networks which use different bit orderings
DISCUSSION
One of the primary reasons the 'chaddr' field exists is
enable BOOTP servers and relay agents to communicate
Wimer [Page 7]
RFC 1542 Clarifications and Extensions for BOOTP October 1993
with clients without the use of broadcasts. In practice,
contents of the 'chaddr' field is often used to create an ARP
cache entry in exactly the same way the normal ARP
would have. Clearly, interoperability can only be achieved
a consistent interpretation of the 'chaddr' field is used
As a practical example, this means that the bit ordering
for the 'chaddr' field by a BOOTP client on an IEEE 802.5
Ring network is the opposite of the bit ordering used by
BOOTP client on a DIX ethernet network
2.4 BOOTP Over IEEE 802.5 Token Ring
Special consideration of the client/server and client/relay
interactions must be given to IEEE 802.5 networks because of non
transparent bridging
The client SHOULD send its broadcast BOOTREQUEST with an All
Explorer RIF. This will enable servers/relay agents to cache
return route if they choose to do so. For those server/relay
which cannot cache the return route (because they are stateless,
example), the BOOTREPLY message SHOULD be sent to the client'
hardware address, as taken from the BOOTP message, with a
Tree Rooted RIF. The actual bridge route will be recorded by
client and server/relay agent by normal ARP processing code
DISCUSSION
In the simplest case, an unbridged, single ring network,
broadcast behavior of the BOOTP protocol is identical to
of Ethernet networks. However, a BOOTP client cannot know,
priori, that an 802.5 network is not bridged. In fact,
likelihood is that the server, or relay agent, will not
either
Of the four possible scenerios, only two are interesting:
the assumption is that the 802.5 network is not bridged and
is, and the assumption that the network is bridged and it
not. In the former case, the Routing Information Field (RIF
will not be used; therefore, if the server/relay agent are
another segment of the ring, the client cannot reach it.
the latter case, the RIF field will be used, resulting in a
extraneous bytes on the ring. It is obvious that an
immeasurable inefficiency is to be preferred over a
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,
is necesary to determine the optimum method for the client
reach the server/relay agent, and the optimum method for
response to be returned
3. BOOTP Client
This section clarifies various issues regarding BOOTP
behavior
3.1 Client use of the 'flags'
3.1.1 The BROADCAST
Normally, BOOTP servers and relay agents attempt to deliver
messages directly to a client using unicast delivery. The
destination address (in the IP header) is set to the BOOTP 'yiaddr
address and the link-layer destination address is set to the
'chaddr' address. Unfortunately, some client implementations
unable to receive such unicast IP datagrams until they know their
IP address (thus we have a "chicken and egg" issue). Often, however
they can receive broadcast IP datagrams (those with a valid
broadcast address as the IP destination and the link-layer
address as the link-layer destination).
If a client falls into this category, it SHOULD set (to 1)
newly-defined BROADCAST flag in the 'flags' field of
messages it generates. This will provide a hint to BOOTP servers
relay agents that they should attempt to broadcast their
messages to the client
If a client does not have this limitation (i.e., it is perfectly
to receive unicast BOOTREPLY messages), it SHOULD NOT set
BROADCAST flag (i.e., it SHOULD clear the BROADCAST flag to 0).
DISCUSSION
This addition to the protocol is a workaround for old
implementations. Such implementations SHOULD be modified
that they may receive unicast BOOTREPLY messages, thus
use of this workaround unnecessary. In general, the use
this mechanism is discouraged
3.1.2 The remainder of the 'flags'
The remaining bits of the 'flags' field are reserved for future use
A client MUST set these bits to zero in all BOOTREQUEST messages
generates. A client MUST ignore these bits in all BOOTREPLY
Wimer [Page 9]
RFC 1542 Clarifications and Extensions for BOOTP October 1993
it receives
3.2 Definition of the 'secs'
The 'secs' field of a BOOTREQUEST message SHOULD represent
elapsed time, in seconds, since the client sent its first
message. Note that this implies that the 'secs' field of the
BOOTREQUEST message SHOULD be set to zero
Clients SHOULD NOT set the 'secs' field to a value which is
for all BOOTREQUEST messages
DISCUSSION
The original definition of the 'secs' field was vague. It
not clear whether it represented the time since the
BOOTREQUEST message was sent or some other time period such
the time since the client machine was powered-up. This
limited its usefulness as a policy control mechanism for
servers and relay agents. Furthermore, certain
implementations have been known to simply set this field to
constant value or use incorrect byte-ordering.
byte-ordering usually makes it appear as if a client has
waiting much longer than it really has, so a relay agent
relay the BOOTREQUEST sooner than desired (
immediately). These implementation errors have
undermined the usefulness of the 'secs' field. These
implementations SHOULD be corrected
3.3 Use of the 'ciaddr' and 'yiaddr'
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
has the ability to remember the last IP address it was assigned,
it has been preconfigured with an IP address via some
mechanism, the client MAY fill the 'ciaddr' field with that
address. If the client does place a non-zero IP address in
'ciaddr' field, the client MUST be prepared to accept
unicast datagrams addressed to that IP address and also answer
requests for that IP address (if ARP is used on that network).
The BOOTP server is free to assign a different IP address (in
'yiaddr' field) than the client expressed in 'ciaddr'. The
SHOULD adopt the IP address specified in 'yiaddr' and begin using
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
'ciaddr' field and, unfortunately, no agreement on a
correct interpretation. One interpretation is that if a
is willing to accept whatever IP address the BOOTP
assigns to it, the client should always place 0.0.0.0 in
'ciaddr' field, regardless of whether it knows its previously
assigned address. Conversely, if the client wishes to
that it must have a particular IP address (e.g., the IP
was hand-configured by the host administrator and BOOTP is
being used to obtain a boot file and/or information from
'vend' field), the client will then fill the 'ciaddr'
with the desired IP address and ignore the IP address
by the BOOTP server as indicated in the 'yiaddr' field.
alternate interpretation holds that the client always fills
'ciaddr' field with its most recently-assigned IP address (
known) even if that address may be incorrect. Such a
will still accept and use the address assigned by the
server as indicated in the 'yiaddr' field. The motivation
this interpretation is to aid the server in identifying
client and/or in delivering the BOOTREPLY to the client. Yet
third (mis)interpretation allows the client to use 'ciaddr'
express the client's desired IP address, even if the client
never used that address before or is not currently using
address
The last interpretation is incorrect as it may prevent
BOOTREPLY from reaching the client. The server will
unicast the reply to the address given in 'ciaddr' but
client may not be listening on that address yet, or the
may be connected to an incorrect subnet such that normal
routing (correctly) routes the reply to a different subnet
The second interpretation also suffers from the "
subnet" problem
The first interpretation seems to be the safest and most
to promote interoperability
3.4 Interpretation of the 'giaddr'
The 'giaddr' field is rather poorly named. It exists to
the transfer of BOOTREQUEST messages from a client, through
relay agents, to servers on different networks than the client
Similarly, it facilitates the delivery of BOOTREPLY messages from
servers, through BOOTP relay agents, back to the client. In no
does it represent a general IP router to be used by the client.
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
BOOTREQUEST messages it generates
A BOOTP client MUST NOT interpret the 'giaddr' field of a
message to be the IP address of an IP router. A BOOTP client
completely ignore the contents of the 'giaddr' field in
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
should be forwarded there first, in order to get to
server."
In that sentence, "get to" refers to communication from the client
the server subsequent to the BOOTP exchange, such as a TFTP session
Unfortunately, the 'giaddr' field may contain the address of a
relay agent that is not itself an IP router (according to [1],
Section 8, fifth paragraph), in which case, it will be useless as
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,
paragraph of [1]. Not only would such an address be useless as
router address, it might also cause the client to ARP for
broadcast address (since, if the client didn't receive a subnet
in the BOOTREPLY message, it would be unable to recognize a
broadcast address). This is clearly undesirable
To reach a non-local server, clients can obtain a first-hop
address from the "Gateway" subfield of the "Vendor
Extensions" [2] (if present), or via the ICMP router
protocol [5] or other similar mechanism
3.5 Vendor information "magic cookie
It is RECOMMENDED that a BOOTP client always fill the first
octets of the 'vend' (vendor information) field of a BOOTREQUEST
a four-octet identifier called a "magic cookie." A BOOTP
SHOULD do this even if it has no special information to
to the BOOTP server using the 'vend' field. This aids the
server in determining what vendor information format it should use
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
client SHOULD use the dotted decimal value 99.130.83.99 as
in [2]. In this case, if the client has no information
communicate to the server, the octet immediately following the
cookie SHOULD be set to the "End" tag (255) and the remaining
of the 'vend' field SHOULD be set to zero
DISCUSSION
Sometimes different operating systems or networking
are run on the same machine at different times (or even at
same time!). Since the hardware address placed in the 'chaddr
field will likely be the same, BOOTREQUESTs from
different BOOTP clients on the same machine will likely
difficult for a BOOTP server to differentiate. If the
includes a magic cookie in its BOOTREQUESTs, the server will
least know what format the client expects and can understand
corresponding BOOTREPLY messages
4. BOOTP Relay
In many cases, BOOTP clients and their associated
server(s) do not reside on the same IP network or subnet.
such cases, some kind of third-party agent is required
transfer BOOTP messages between clients and servers. Such
agent was originally referred to as a "BOOTP forwarding agent."
However, in order to avoid confusion with the IP
function of an IP router, the name "BOOTP relay agent"
hereby adopted instead
DISCUSSION
A BOOTP relay agent performs a task which is distinct from
IP router's normal IP forwarding function. While a
normally switches IP datagrams between networks more-or-
transparently, a BOOTP relay agent may more properly be
to receive BOOTP messages as a final destination and
generate new BOOTP messages as a result. It is incorrect for
relay agent implementation to simply forward a BOOTP
"straight through like a regular packet."
This relay-agent functionality is most conveniently located
the routers which interconnect the clients and servers, but
alternatively be located in a host which is directly
to the client subnet
Any Internet host or router which provides BOOTP relay-
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
All locally delivered UDP messages whose UDP destination port
is BOOTPS (67) are considered for special processing by the host
router's logical BOOTP relay agent
In the case of a host, locally delivered datagrams are simply
datagrams normally received by that host, i.e., broadcast
multicast datagrams as well as unicast datagrams addressed to
addresses of that host
In the case of a router, locally delivered datagrams are
and multicast datagrams as well as unicast datagrams addressed to
addresses of that router. These are datagrams for which the
should be considered an end destination as opposed to an
switching node. Thus a unicast datagram with an IP destination
matching any of the router's IP addresses is not considered
processing by the router's logical BOOTP relay agent
Hosts and routers are usually required to silently discard
datagrams containing illegal IP source addresses. This is
known as "Martian address filtering." One of these illegal
is 0.0.0.0 (or actually anything on network 0). However, hosts
routers which support a BOOTP relay agent MUST accept for
delivery to the relay agent BOOTREQUEST messages whose IP
address is 0.0.0.0. BOOTREQUEST messages from legal IP
addresses MUST also be accepted
A relay agent MUST silently discard any received UDP messages
UDP destination port number is BOOTPC (68).
DISCUSSION
There should be no need for a relay agent to process
addressed to the BOOTPC port. Careful reading of the
BOOTP specification [1] will show this. Nevertheless,
relay agent implementations incorrectly relay such messages
The consistency checks specified in Section 2.1 SHOULD be
by the relay agent. BOOTP messages not meeting these
checks MUST be silently discarded
4.1.1 BOOTREQUEST
Some configuration mechanism MUST exist to enable or disable
relaying of BOOTREQUEST messages. Relaying MUST be disabled
default
Wimer [Page 14]
RFC 1542 Clarifications and Extensions for BOOTP October 1993
When the BOOTP relay agent receives a BOOTREQUEST message, it MAY
the value of the 'secs' (seconds since client began booting) field
the request as a factor in deciding whether to relay the request.
such a policy mechanism is implemented, its threshold SHOULD
configurable
DISCUSSION
To date, this feature of the BOOTP protocol has not
been shown to be useful. See Section 3.2 for a discussion
The relay agent MUST silently discard BOOTREQUEST messages
'hops' field exceeds the value 16. A configuration option SHOULD
provided to set this threshold to a smaller value if desired by
network manager. The default setting for a configurable
SHOULD be 4.
If the relay agent does decide to relay the request, it MUST
the 'giaddr' ("gateway" IP address) field. If this field is zero
the relay agent MUST fill this field with the IP address of
interface on which the request was received. If the interface
more than one IP address logically associated with it, the
agent SHOULD choose one IP address associated with that interface
use it consistently for all BOOTP messages it relays. If
'giaddr' field contains some non-zero value, the 'giaddr' field
NOT be modified. The relay agent MUST NOT, under any circumstances
fill the 'giaddr' field with a broadcast address as is suggested
[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 (
destinations). This destination MUST be configurable. Further,
destination configuration SHOULD be independent of the
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
IP unicast, multicast, broadcast, or some combination.
configurable list of destination IP addresses provides
flexibility. More flexible configuration schemes
encouraged. For example, it may be desirable to send to
limited broadcast address (255.255.255.255) on
physical interfaces. However, if the BOOTREQUEST message
Wimer [Page 15]
RFC 1542 Clarifications and Extensions for BOOTP October 1993
received as a broadcast, the relay agent MUST NOT
the BOOTREQUEST on the physical interface from whence it came
A relay agent MUST use the same destination (or set
destinations) for all BOOTREQUEST messages it relays from
given client
DISCUSSION
At least one known relay agent implementation uses a round
robin scheme to provide load balancing across multiple
servers. Each time it receives a new BOOTREQUEST message,
relays the message to the next BOOTP server in a list
servers. Thus, with this relay agent, multiple
BOOTREQUEST messages from a given client will be delivered
different servers
Unfortunately, this well-intentioned scheme reacts badly
DHCP [3] and perhaps other variations of the BOOTP
which depend on multiple exchanges of BOOTREQUEST and
messages between clients and servers. Therefore,
BOOTREQUEST messages from a given client MUST be relayed to
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
(or some other reliable client-identifying information) and
the resulting hash value to select the appropriate
destination (or set of destinations). The simplest solution
of course, is to not use a load-balancing scheme and just
ALL received BOOTREQUEST messages to the same destination (
set of destinations).
When transmitting the request to its next destination,
relay agent may set the IP Time-To-Live field to either
default value for new datagrams originated by the relay agent
or to the TTL of the original BOOTREQUEST decremented by (
least) one
DISCUSSION
As an extra precaution against BOOTREQUEST loops, it
preferable to use the decremented TTL from the
BOOTREQUEST. Unfortunately, this may be difficult to do
some implementations
If the BOOTREQUEST has a UDP checksum (i.e., the UDP
is non-zero), the checksum must be recalculated
Wimer [Page 16]
RFC 1542 Clarifications and Extensions for BOOTP October 1993
transmitting the request
4.1.2 BOOTREPLY
BOOTP relay agents relay BOOTREPLY messages only to BOOTP clients
It is the responsibility of BOOTP servers to send BOOTREPLY
directly to the relay agent identified in the 'giaddr' field
Therefore, a relay agent may assume that all BOOTREPLY messages
receives are intended for BOOTP clients on its directly-
networks
When a relay agent receives a BOOTREPLY message, it should
the BOOTP 'giaddr', 'yiaddr', 'chaddr', 'htype', and 'hlen' fields
These fields should provide adequate information for the relay
to deliver the BOOTREPLY message to the client
The 'giaddr' field can be used to identify the logical interface
which the reply must be sent (i.e., the host or router
connected to the same network as the BOOTP client). If the
of the 'giaddr' field does not match one of the relay agent'
directly-connected logical interfaces, the BOOTREPLY messsage MUST
silently discarded
The 'htype', 'hlen', and 'chaddr' fields supply the link-
hardware type, hardware address length, and hardware address of
client as defined in the ARP protocol [4] and the Assigned
document [6]. The 'yiaddr' field is the IP address of the client,
assigned by the BOOTP server
The relay agent SHOULD examine the newly-defined BROADCAST flag (
Sections 2.2 and 3.1.1 for more information). If this flag is set
1, the reply SHOULD be sent as an IP broadcast using the IP
broadcast address 255.255.255.255 as the IP destination address
the link-layer broadcast address as the link-layer
address. If the BROADCAST flag is cleared (0), the reply SHOULD
sent as an IP unicast to the IP address specified by the 'yiaddr
field and the link-layer address specified in the 'chaddr' field.
unicasting is not possible, the reply MAY be sent as a broadcast,
which case it SHOULD be sent to the link-layer broadcast
using the IP limited broadcast address 255.255.255.255 as the
destination address
DISCUSSION
The addition of the BROADCAST flag to the protocol is
workaround to help promote interoperability with certain
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
server implementations may accidentally and unknowingly set
new BROADCAST flag. It is actually expected that
implementations will be rare (most implementations seem
zero-out this field), but interactions with
implementations must nevertheless be considered. If an
client or server does set the BROADCAST flag to 1 incorrectly
conforming relay agents will generate broadcast
messages to the corresponding client. The BOOTREPLY
should still properly reach the client, at the cost of
(otherwise unnecessary) additional broadcast. This, however
is no worse than a server or relay agent which
broadcasts its BOOTREPLY messages
Older client or server implementations which accidentally
the BROADCAST flag SHOULD be corrected to properly comply
this newer specification
All BOOTP fields MUST be preserved intact. The relay
MUST NOT modify any BOOTP field of the BOOTREPLY message
relaying it to the client
The reply MUST have its UDP destination port set to
(68).
If the BOOTREPLY has a UDP checksum (i.e., the UDP checksum
non-zero), the checksum must be recalculated
transmitting the reply
5. BOOTP Server
This section provides clarifications on the behavior of
servers
5.1 Reception of BOOTREQUEST
All received UDP messages whose UDP destination port number is
(67) are considered for processing by the BOOTP server
Hosts and routers are usually required to silently discard
datagrams containing illegal IP source addresses. This is
known as "Martian address filtering." One of these illegal
is 0.0.0.0 (or actually anything on network 0). However, hosts
routers which support a BOOTP server MUST accept for local
to the server BOOTREQUEST messages whose IP source address
0.0.0.0. BOOTREQUEST messages from legal IP source addresses
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
UDP destination port number is BOOTPC (68).
DISCUSSION
There should be no need for a BOOTP server to process
addressed to the BOOTPC port. Careful reading of the
BOOTP specification [1] will show this
The consistency checks specified in Section 2.1 SHOULD
performed by the BOOTP server. BOOTP messages not
these consistency checks MUST be silently discarded
5.2 Use of the 'secs'
When the BOOTP server receives a BOOTREQUEST message, it MAY use
value of the 'secs' (seconds since client began booting) field of
request as a factor in deciding whether and/or how to reply to
request
DISCUSSION
To date, this feature of the BOOTP protocol has not
been shown to be useful. See Section 3.2 for a discussion
5.3 Use of the 'ciaddr'
There have been various client interpretations of the 'ciaddr'
for which Section 3.3 should be consulted. A BOOTP server SHOULD
prepared to deal with these varying interpretations. In general,
'ciaddr' field SHOULD NOT be trusted as a sole key in identifying
client; the contents of the 'ciaddr', 'chaddr', 'htype', and 'hlen
fields, and probably other information (perhaps in the 'file'
'vend' fields) SHOULD all be considered together in deciding how
respond to a given client
BOOTP servers SHOULD preserve the contents of the 'ciaddr' field
BOOTREPLY messages; the contents of 'ciaddr' in a BOOTREPLY
SHOULD exactly match the contents of 'ciaddr' in the
BOOTREQUEST message
DISCUSSION
It has been suggested that a client may wish to use
contents of 'ciaddr' to further verify that a
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
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
unicast to the IP address identified in the 'ciaddr' field. The
destination port MUST be set to BOOTPC (68). However, the
MUST be aware of the problems identified in Section 3.3. The
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
delivery algorithm below).
The server SHOULD next check the 'giaddr' field. If this field
non-zero, the server SHOULD send the BOOTREPLY as an IP unicast
the IP address identified in the 'giaddr' field. The UDP
port MUST be set to BOOTPS (67). This action will deliver
BOOTREPLY message directly to the BOOTP relay agent closest to
client; the relay agent will then perform the final delivery to
client. If the BOOTP server has prior knowledge that a
client cannot receive unicast BOOTREPLY messages (e.g., the
manager has explicitly configured the server with such knowledge),
the server MAY set the newly-defined BROADCAST flag to indicate
relay agents SHOULD broadcast the BOOTREPLY message to the client
Otherwise, the server MUST preserve the state of the BROADCAST
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
one of the same networks as the BOOTP server. The server
examine the newly-defined BROADCAST flag (see Sections 2.2, 3.1.1
4.1.2 for more information). If this flag is set to 1 or the
has prior knowledge that the client is unable to receive
BOOTREPLY messages, the reply SHOULD be sent as an IP broadcast
the IP limited broadcast address 255.255.255.255 as the
destination address and the link-layer broadcast address as
link-layer destination address. If the BROADCAST flag is
(0), the reply SHOULD be sent as an IP unicast to the IP
specified by the 'yiaddr' field and the link-layer address
in the 'chaddr' field. If unicasting is not possible, the reply
be sent as a broadcast in which case it SHOULD be sent to the link
layer broadcast address using the IP limited broadcast
255.255.255.255 as the IP destination address. In any case, the
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
workaround to help promote interoperability with certain
implementations
The following table summarizes server delivery decisions
BOOTREPLY messages based upon information in
messages
BOOTREQUEST fields BOOTREPLY values for UDP, IP, link-
+-----------------------+-----------------------------------------+
| '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
X = Don't
normal = determine from the given IP destination using
IP routing mechanisms and/or ARP as for any
normal
The author would like to thank Gary Malkin for his contribution
the "BOOTP over IEEE 802.5 Token Ring Networks" section, and
Deering for his observations on the problems associated with
'giaddr' field
Ralph Droms and the many members of the IETF Dynamic
Configuration and Router Requirements working groups provided
for this memo as well as encouragement to write it
Philip Almquist and David Piscitello offered many helpful
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
[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
occasionally reissued with a new number. Please be sure
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,
PARC, September 1991.
[6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
USC/Information Sciences Institute, July, 1992. This RFC
periodically reissued with a new number. Please be sure
consult the latest version
Wimer [Page 22]
RFC 1542 Clarifications and Extensions for BOOTP October 1993
Security
There are many factors which make BOOTP in its current form
insecure. BOOTP is built directly upon UDP and IP which are as
inherently insecure themselves. Furthermore, BOOTP is
intended to make maintenance of remote and/or diskless hosts easier
While perhaps not impossible, configuring such hosts with passwords
keys may be difficult and inconvenient. This makes it difficult
provide any form of reasonable authentication between servers
clients
Unauthorized BOOTP servers may easily be set up. Such servers
then send false and potentially disruptive information to clients
as incorrect or duplicate IP addresses, incorrect routing
(including spoof routers, etc.), incorrect domain nameserver
(such as spoof nameservers), and so on. Clearly, once this "seed
mis-information is planted, an attacker can further compromise
affected systems
Unauthorized BOOTP relay agents may present some of the same
as unauthorized BOOTP servers
Malicious BOOTP clients could masquerade as legitimate clients
retrieve information intended for those legitimate clients.
dynamic allocation of resources is used, a malicious client
claim all resources for itself, thereby denying resources
legitimate clients
Author's
Walt
Network
Carnegie Mellon
5000 Forbes
Pittsburgh, PA 15213-3890
Phone: (412) 268-6252
EMail: Walter.Wimer@CMU.
Wimer [Page 23]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
