draft-ietf-dhc-bootp-01.txt   rfc1532.txt 
Internet Engineering Task Force W. Wimer Network Working Group W. Wimer
Internet Draft Carnegie Mellon University Request for Comments: 1532 Carnegie Mellon University
September, 1992 Updates: 951 October 1993
Category: Standards Track
DRAFT
Clarifications and Extensions for the Bootstrap Protocol Clarifications and Extensions for the Bootstrap Protocol
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This RFC specifies an Internet standards track protocol for the
documents of the Internet Engineering Task Force (IETF), its Areas, and Internet community, and requests discussion and suggestions for
its Working Groups. (Note that other groups may also distribute working improvements. Please refer to the current edition of the "Internet
documents as Internet Drafts.) Official Protocol Standards" for the standardization state and status
of this protocol. Distribution of this memo is unlimited.
Internet Drafts are draft documents valid for a maximum of six months. Abstract
Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet Drafts as
reference material or to cite them other than as a "working draft" or
"work in progress."
Please check the I-D abstract listing contained in each Internet Draft Some aspects of the BOOTP protocol were rather loosely defined in its
directory to learn the current status of this or any other Internet original specification. In particular, only a general description
Draft. This Internet Draft expires on February 28, 1993. 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.
This memo suggests several updates to the specification of the Bootstrap In addition, new issues have arisen since the original specification
Protocol (BOOTP) based on experience with the protocol. was written. This memo also attempts to address some of these.
This proposal is a product of the IETF Dynamic Host Configuration Table of Contents
Working Group. This draft document will be submitted to the RFC editor
as a protocol specification. Comments on this memo should be sent to
the IETF Dynamic Host Configuration Working Group mailing list,
host-conf@sol.bucknell.edu.
Distribution of this memo is unlimited. 1. Introduction................................................. 2
1.1 Requirements................................................ 2
1.2 Terminology................................................. 3
1.3 Data Transmission Order..................................... 4
2. General Issues............................................... 5
2.1 General BOOTP Processing.................................... 5
2.2 Definition of the 'flags' Field............................. 5
2.3 Bit Ordering of Hardware Addresses.......................... 7
2.4 BOOTP Over IEEE 802.5 Token Ring Networks................... 8
3. BOOTP Client Behavior........................................ 9
3.1 Client use of the 'flags' field............................. 9
3.1.1 The BROADCAST flag........................................ 9
3.1.2 The remainder of the 'flags' field........................ 9
3.2 Definition of the 'secs' field.............................. 9
3.3 Use of the 'ciaddr' and 'yiaddr' fields..................... 10
3.4 Interpretation of the 'giaddr' field........................ 11
3.5 Vendor information "magic cookie"........................... 12
4. BOOTP Relay Agents........................................... 13
4.1 General BOOTP Processing for Relay Agents................... 13
4.1.1 BOOTREQUEST Messages...................................... 14
4.1.2 BOOTREPLY Messages........................................ 16
5. BOOTP Server Behavior........................................ 18
5.1 Reception of BOOTREQUEST Messages........................... 18
5.2 Use of the 'secs' field..................................... 19
5.3 Use of the 'ciaddr' field................................... 19
5.4 Strategy for Delivery of BOOTREPLY Messages................. 19
Acknowledgements................................................ 21
References...................................................... 21
Security Considerations......................................... 22
Author's Address................................................ 22
Abstract 1. Introduction
Some aspects of the BOOTP protocol were rather loosely defined in its The Bootstrap Protocol (BOOTP) is a UDP/IP-based protocol which
original specification. In particular, only a general description was allows a booting host to configure itself dynamically and without
provided for the behavior of "BOOTP relay agents" (originally called user supervision. BOOTP provides a means to notify a host of its
"BOOTP forwarding agents"). The client behavior description also assigned IP address, the IP address of a boot server host, and the
suffered in certain ways. This memo attempts to clarify and strengthen name of a file to be loaded into memory and executed [1]. Other
the specification in these areas. 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].
In addition, new issues have arisen since the original specification was Unfortunately, the original BOOTP specification [1] left some issues
written. This memo also attempts to address some of these. 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.
Table of Contents 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.
1. Introduction 3 NOTE: Unless otherwise specified in this document or a later
1.1 Requirements 3 document, the information and requirements specified througout this
1.2 Terminology 4 document also apply to extensions to BOOTP such as the Dynamic Host
1.3 Data Transmission Order 5 Configuration Protocol (DHCP) [3].
2. Definition of the 'flags' Field 6 1.1 Requirements
3. BOOTP Relay Agents 7 In this memo, the words that are used to define the significance of
3.1 General BOOTP Processing 8 particular requirements are capitalized. These words are:
3.1.1 BOOTREQUEST Messages 8
3.1.2 BOOTREPLY Messages 11
4. BOOTP Client Behavior 13 o "MUST"
4.1 Client use of the 'flags' field 13
4.1.1 The BROADCAST flag 13
4.1.2 The remainder of the 'flags' field 14
4.2 Definition of the 'secs' field 14
4.3 Interpretation of the 'giaddr' field 14
4.4 Vendor information "magic cookie" 15
5. Bit Ordering of Hardware Addresses 16 This word or the adjective "REQUIRED" means that the item
is an absolute requirement of the specification.
6. BOOTP Over IEEE 802.5 Token Ring Networks 16 o "MUST NOT"
Security Considerations 18 This phrase means that the item is an absolute prohibition
of the specification.
Acknowledgements 18 o "SHOULD"
References 19 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.
Author's Address 19 o "SHOULD NOT"
1. Introduction
The Bootstrap Protocol (BOOTP) is a UDP/IP-based protocol which allows a This phrase means that there may exist valid reasons in
booting host to configure itself dynamically and without user particular circumstances when the listed behavior is
supervision. BOOTP provides a means to notify a host of its assigned IP acceptable or even useful, but the full implications should
address, the IP address of a boot server host, and the name of a file to be understood and the case carefully weighed before
be loaded into memory and executed [1]. Other configuration information implementing any behavior described with this label.
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,3].
Unfortunately, the original BOOTP specification [1] left some issues of o "MAY"
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 This word or the adjective "OPTIONAL" means that this item
been developed which presents a unique problem for BOOTP's particular is truly optional. One vendor may choose to include the
message-transfer paradigm. This memo also suggests a solution for this item because a particular marketplace requires it or
problem. because it enhances the product, for example; another
vendor may omit the same item.
1.1 Requirements 1.2 Terminology
In this memo, the words that are used to define the significance of This memo uses the following terms:
particular requirements are capitalized. These words are:
o "MUST" BOOTREQUEST
This word or the adjective "REQUIRED" means that the item A BOOTREQUEST message is a BOOTP message sent from a BOOTP
is an absolute requirement of the specification. client to a BOOTP server, requesting configuration information.
o "MUST NOT" BOOTREPLY
This phrase means that the item is an absolute prohibition A BOOTREPLY message is a BOOTP message sent from a BOOTP server
of the specification. to a BOOTP client, providing configuration information.
o "SHOULD" Silently discard
This word or the adjective "RECOMMENDED" means that there This memo specifies several cases where a BOOTP entity is to
may exist valid reasons in particular circumstances to "silently discard" a received BOOTP message. This means that
ignore this item, but the full implications should be the entity is to discard the message without further
understood and the case carefully weighed before choosing a processing, and that the entity will not send any ICMP error
different course. 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.
o "SHOULD NOT" 1.3 Data Transmission Order
This phrase means that there may exist valid reasons in The order of transmission of the header and data described in this
particular circumstances when the listed behavior is document is resolved to the octet level. Whenever a diagram shows a
acceptable or even useful, but the full implications should group of octets, the order of transmission of those octets is the
be understood and the case carefully weighed before normal order in which they are read in English. For example, in the
implementing any behavior described with this label. following diagram, the octets are transmitted in the order they are
numbered.
o "MAY" 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 |
+-------------------------------+
| 3 | 4 |
+-------------------------------+
| 5 | 6 |
+-------------------------------+
This word or the adjective "OPTIONAL" means that this item Whenever an octet represents a numeric quantity, the leftmost bit in
is truly optional. One vendor may choose to include the the diagram is the high order or most significant bit. That is, the
item because a particular marketplace requires it or bit labeled 0 is the most significant bit. For example, the
because it enhances the product, for example; another following diagram represents the value 170 (decimal).
vendor may omit the same item.
1.2 Terminology 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+---------------+
This memo uses the following terms: Similarly, whenever a multi-octet field represents a numeric quantity
the leftmost bit of the whole field is the most significant bit.
When a multi-octet quantity is transmitted the most significant octet
is transmitted first.
BOOTREQUEST 2. General Issues
A BOOTREQUEST message is a BOOTP message sent from a BOOTP
client to a BOOTP server, requesting configuration
information.
BOOTREPLY This section covers issues of general relevance to all BOOTP entities
A BOOTREPLY message is a BOOTP message sent from a BOOTP (clients, servers, and relay agents).
server to a BOOTP client, providing configuration
information.
Silently discard 2.1 General BOOTP Processing
This memo specifies several cases where a BOOTP relay agent
is to "silently discard" a received BOOTP message. This
means that the relay agent should discard the message
without further processing, and that the relay agent will
not send any ICMP error message as a result. However, for
diagnosis of problems, the relay agent 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 following consistency checks SHOULD be performed on BOOTP
messages:
The order of transmission of the header and data described in this o The IP Total Length and UDP Length must be large enough to
document is resolved to the octet level. Whenever a diagram shows a contain the minimal BOOTP header of 300 octets (in the UDP
group of octets, the order of transmission of those octets is the data field) specified in [1].
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 NOTE: Future extensions to the BOOTP protocol may increase the size
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 of BOOTP messages. Therefore, BOOTP messages which, according to the
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Total Length and UDP Length fields, are larger than the minimum
| 1 | 2 | size specified by [1] MUST also be accepted.
+-------------------------------+
| 3 | 4 |
+-------------------------------+
| 5 | 6 |
+-------------------------------+
Whenever an octet represents a numeric quantity, the leftmost bit in o The 'op' (opcode) field of the message must contain either the
the diagram is the high order or most significant bit. That is, the code for a BOOTREQUEST (1) or the code for a BOOTREPLY (2).
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 BOOTP messages not meeting these consistency checks MUST be silently
+-+-+-+-+-+-+-+-+ discarded.
|1 0 1 0 1 0 1 0|
+---------------+
Similarly, whenever a multi-octet field represents a numeric 2.2 Definition of the 'flags' Field
quantity the leftmost bit of the whole field is the most significant
bit. When a multi-octet quantity is transmitted the most
significant octet is transmitted first.
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:
The standard BOOTP message format defined in [1] includes a two-octet "Before setting up the packet for the first time, it is a good
field located between the 'secs' field and the 'ciaddr' field. This idea to clear the entire packet buffer to all zeros; this will
field is merely designated as "unused" and its contents left place all fields in their default state."
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 This memo hereby designates this two-octet field as the 'flags'
to clear the entire packet buffer to all zeros; this will place all field.
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 first 44 octets of a BOOTP message are shown below. The numbers in The remaining bits of the 'flags' field are reserved for future
parentheses indicate the size of each field in octets. use. They MUST be set to zero by clients and ignored by servers
and relay agents.
0 1 2 3 The 'flags' field, then, appears as follows:
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) |
| |
| |
+---------------------------------------------------------------+
This document hereby defines the most significant bit of the 'flags' 0 1
field as the BROADCAST (B) flag. The semantics of this flag are 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
discussed in Sections 3.1.2 and 4.1.1 of this memo. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| MBZ |
+-+-----------------------------+
The remaining bits of the 'flags' field are reserved for future use. where:
They MUST be set to zero by clients and ignored by servers and relay
agents.
The 'flags' field, then, appears as follows: B BROADCAST flag (discussed in Sections 3.1.1 and 4.1.2)
0 1 MBZ MUST BE ZERO (reserved for future use)
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| MBZ |
+-+-----------------------------+
where: The format of a BOOTP message is shown below. The numbers in
parentheses indicate the size of each field in octets.
B BROADCAST flag (discussed in Sections 3.1.2 and 4.1.1) 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) |
+---------------------------------------------------------------+
MBZ MUST BE ZERO (reserved for future use) 2.3 Bit Ordering of Hardware Addresses
3. BOOTP Relay Agents The bit ordering used for link-level hardware addresses in the
protocol [4] on the client's link-level network (assuming ARP is
defined for that network).
In many cases, BOOTP clients and their associated BOOTP server(s) do not The 'chaddr' field MUST be preserved as it was specified by the BOOTP
reside on the same IP network or subnet. In such cases, some kind of client. A relay agent MUST NOT reverse the bit ordering of the two
third-party agent is required to transfer BOOTP messages between clients networks which use different bit orderings.
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: 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. One should resist the
notion of simply forwarding a BOOTP message "straight through
like a regular packet."
This relay-agent functionality is most conveniently located in the One of the primary reasons the 'chaddr' field exists is to
routers which interconnect the clients and servers, but may enable BOOTP servers and relay agents to communicate directly
alternatively be located in a host which is directly connected to the with clients without the use of broadcasts. In practice, the
client subnet. contents of the 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.
Any Internet host or router which provides BOOTP relay-agent capability As a practical example, this means that the bit ordering used
MUST conform to the specifications in this memo. for the is the opposite of the bit ordering used by a BOOTP
client on a DIX ethernet network.
3.1 General BOOTP Processing 2.4 BOOTP Over IEEE 802.5 Token Ring Networks
All locally delivered UDP messages whose UDP destination port number Special consideration of the client/server and client/relay agent
is BOOTPS (67) are considered for special processing by the host or interactions must be given to IEEE 802.5 networks because of non-
router's logical BOOTP relay agent. transparent bridging.
In the case of a host, locally delivered datagrams are simply all The client SHOULD send its broadcast BOOTREQUEST with an All Routes
datagrams normally received by that host, i.e. broadcast and Explorer RIF. This will enable servers/relay agents to cache the
multicast datagrams as well as unicast datagrams addressed to IP return route if they choose to do so. For those server/relay agents
addresses of that host. 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.
In the case of a router, local delivery has a similar but somewhat DISCUSSION:
more careful definition for which [4] should be consulted.
Hosts and routers are usually required to silently discard incoming In the simplest case, an unbridged, single ring network, the
datagrams containing illegal IP source addresses. This is generally broadcast behavior of the BOOTP protocol is identical to that
known as "Martian address filtering." One of these illegal of Ethernet networks. However, a BOOTP client cannot know, a
addresses is 0.0.0.0 (or actually anything on network 0). However, priori, that an 802.5 network is not bridged. In fact, the
hosts or routers which support a BOOTP relay agent MUST accept for likelihood is that the server, or relay agent, will not know
local delivery to the relay agent BOOTREQUEST messages whose IP either.
source address is 0.0.0.0. BOOTREQUEST messages from legal IP
source addresses MUST also be accepted, of course.
The following consistency checks SHOULD be performed on BOOTP Of the four possible scenerios, only two are interesting: where
messages: 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.
o The IP Total Length and UDP Length must be large enough to Given that the assumption is that RIF fields will be needed, it
contain the minimal BOOTP header of 300 octets (in the UDP is necesary to determine the optimum method for the client to
data field) specified in [1]. reach the server/relay agent, and the optimum method for the
response to be returned.
NOTE: Future extensions to the BOOTP protocol may increase 3. BOOTP Client Behavior
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 This section clarifies various issues regarding BOOTP client
the code for a BOOTREQUEST (1) or the code for a BOOTREPLY behavior.
(2).
BOOTP messages not meeting these consistency checks MUST be silently 3.1 Client use of the 'flags' field
discarded.
3.1.1 BOOTREQUEST Messages 3.1.1 The BROADCAST flag
Some configuration mechanism MUST exist to enable or disable the Normally, BOOTP servers and relay agents attempt to deliver BOOTREPLY
relaying of BOOTREQUEST messages. Relaying MUST be disabled by messages directly to a client using unicast delivery. The IP
default. destination address (in the IP header) is set to the BOOTP 'yiaddr'
address and the link-layer destination address is set to the BOOTP
unable to receive such unicast IP datagrams until they know their own
IP address (thus we have a "chicken and egg" issue). Often, however,
they can receive broadcast IP datagrams (those with a valid IP
broadcast address as the IP destination and the link-layer broadcast
address as the link-layer destination).
When the BOOTP relay agent receives a BOOTREQUEST message, it If a client falls into this category, it SHOULD set (to 1) the
MAY use the value of the 'secs' (seconds since client began newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY
booting) field of the request as a factor in deciding whether to messages it generates. This will provide a hint to BOOTP servers and
relay the request. If such a policy mechanism is implemented, relay agents that they should attempt to broadcast their BOOTREPLY
its threshold SHOULD be configurable. messages to the client.
DISCUSSION: If a client does not have this limitation (i.e., it is perfectly able
To date, this feature of the BOOTP protocol has not to receive unicast BOOTREPLY messages), it SHOULD NOT set the
necessarily been shown to be useful. See Section 4.2 BROADCAST flag (i.e., it SHOULD clear the BROADCAST flag to 0).
for a discussion.
The relay agent MUST silently discard BOOTREQUEST messages whose DISCUSSION:
'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 This addition to the protocol is a workaround for old host
examine the 'giaddr' ("gateway" IP address) field. If this implementations. Such implementations SHOULD be modified so
field is zero, the relay agent MUST fill this field with the IP that they may receive unicast BOOTREPLY messages, thus making
address of the logical interface on which the request was use of this workaround unnecessary. In general, the use of
received. In addition, the relay agent MAY insert the subnet this mechanism is discouraged.
mask of that logical interface into the vendor area (see the
next paragraph for details). If the 'giaddr' field contains
some non-zero value, the 'giaddr' field MUST NOT be modified and
the subnet mask MUST NOT be inserted into the vendor area nor
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).
To insert the subnet mask into the vendor area as suggested 3.1.2 The remainder of the 'flags' field
above, the relay agent MUST examine the first four octets of the
'vend' field (these first four octets are usually referred to as
the "vendor magic number" or "vendor magic cookie"). If these
four octets do not contain the dotted decimal value 99.130.83.99
as specified in [2,3], the subnet mask MUST NOT be inserted. If
these four octets do contain the value 99.130.83.99, it is safe
to insert the subnet mask. The relay agent MUST use the data
format as specified in [2,3] and MUST use the "Subnet Mask
Field" (Tag 1) specified in [2,3] to express the subnet mask.
The relay agent MUST be careful to preserve any and all existing
data in the 'vend' field. The subnet mask MUST either be placed
at the beginning of the data portion of the 'vend' field
(immediately after the four-octet magic cookie), or the relay
agent MUST be careful to replace any existing subnet mask
entries (Tag 1) with the correct subnet mask value. This is to
avoid any ambiguity in the event that the client supplied one or
more subnet mask entries somewhere in the 'vend' field. If the
subnet mask cannot be inserted without loss of data in the
'vend' field, the subnet mask MUST NOT be inserted.
DISCUSSION: The remaining bits of the 'flags' field are reserved for future use.
Having the relay agent insert the subnet mask into the A client MUST set these bits to zero in all BOOTREQUEST messages it
vendor area is an optimization for the proposed Dynamic generates. A client MUST ignore these bits in all BOOTREPLY messages
Host Configuration Protocol (DHCP) [5]. This it receives.
optimization should not be strictly necessary for
correct operation of the protocol, but it should make
configuration of the DHCP server much easier. It is
strongly encouraged that relay agents provide this
subnet mask feature, but it is not absolutely required.
The value of the 'hops' field MUST be incremented. 3.2 Definition of the 'secs' field
All other fields MUST be preserved intact. 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.
At this point, the request is relayed to its new destination (or Clients SHOULD NOT set the 'secs' field to a value which is constant
destinations). This destination MUST be configurable. Further, for all BOOTREQUEST messages.
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: 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 logical
interfaces. However, if the BOOTREQUEST message was
received as a broadcast, the relay agent MUST NOT
rebroadcast the BOOTREQUEST on the logical interface
from whence it came.
A relay agent MUST use the same destination (or set of The original definition of the 'secs' field was vague. It was
destinations) for all BOOTREQUEST messages it relays from a not clear whether it represented the time since the first
given client. 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.
DISCUSSION: 3.3 Use of the 'ciaddr' and 'yiaddr' fields
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 If a BOOTP client does not know what IP address it should be using,
with certain variations of the BOOTP protocol which the client SHOULD set the 'ciaddr' field to 0.0.0.0. If the client
depend on multiple exchanges of BOOTREQUEST and has the ability to remember the last IP address it was assigned, or
BOOTREPLY messages between clients and servers. it has been preconfigured with an IP address via some alternate
Therefore, all BOOTREQUEST messages from a given client mechanism, the client MAY fill the 'ciaddr' field with that IP
MUST be relayed to the same destination (or set of address. If the client does place a non-zero IP address in the
destinations). datagrams addressed to that IP address and also answer ARP requests
for that IP address (if ARP is used on that network).
One way to meet this requirement while providing some The BOOTP server is free to assign a different IP address (in the
load-balancing benefit is to hash the client's SHOULD adopt the IP address specified in 'yiaddr' and begin using it
link-layer address (or some other reliable as soon as possible.
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 DISCUSSION:
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: There are various interpretations about the purpose of the
As an extra precaution against BOOTREQUEST loops, it is 'ciaddr' field and, unfortunately, no agreement on a single
preferable to use the decremented TTL from the original correct interpretation. One interpretation is that if a client
BOOTREQUEST. Unfortunately, this may be difficult to do is willing to accept whatever IP address the BOOTP server
in some implementations. 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 client has
never used that address before or is not currently using that
address.
The UDP checksum must be recalculated before transmitting the The last interpretation is incorrect as it may prevent the
request. 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.
3.1.2 BOOTREPLY Messages The second interpretation also suffers from the "incorrect
subnet" problem.
BOOTP relay agents relay BOOTREPLY messages only to BOOTP The first interpretation seems to be the safest and most likely
clients. It is the responsibility of BOOTP servers to send to promote interoperability.
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 3.4 Interpretation of the 'giaddr' field
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 The 'giaddr' field is rather poorly named. It exists to facilitate
to which the reply must be sent (i.e. the host or router the transfer of BOOTREQUEST messages from a client, through BOOTP
interface connected to the same network as the BOOTP client). relay agents, to servers on different networks than the client.
If the content of the 'giaddr' field does not match one of the Similarly, it facilitates the delivery of BOOTREPLY messages from the
relay agent's directly-connected logical interfaces, the servers, through BOOTP relay agents, back to the client. In no case
BOOTREPLY messsage MUST be silently discarded. does it represent a general IP router to be used by the client. A
BOOTP client MUST set the 'giaddr' field to zero (0.0.0.0) in all
BOOTREQUEST messages it generates.
The 'htype', 'hlen', and 'chaddr' fields supply the link-layer A BOOTP client MUST NOT interpret the 'giaddr' field of a BOOTREPLY
hardware type, hardware address length, and hardware address of message to be the IP address of an IP router. A BOOTP client SHOULD
the client as defined in the ARP protocol [6] and the Assigned completely ignore the contents of the 'giaddr' field in BOOTREPLY
Numbers document [7]. The 'yiaddr' field is the IP address of messages.
the client, as assigned by the BOOTP server.
The relay agent SHOULD examine the newly-defined BROADCAST flag DISCUSSION:
(see Sections 2 and 4.1.1 for more information). If this flag
is set to 1, the reply SHOULD be sent as an IP broadcast using
an IP broadcast address (preferably 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 to the link-layer broadcast
address using an IP broadcast address (preferably
255.255.255.255) as the IP destination address.
DISCUSSION: The semantics of the 'giaddr' field were poorly defined.
The addition of the BROADCAST flag to the protocol is a Section 7.5 of [1] states:
workaround to help promote interoperability with certain
client implementations.
Note that since the 'flags' field was previously defined "If 'giaddr' (gateway address) is nonzero, then the packets
in [1] simply as an "unused" field, it is possible that should be forwarded there first, in order to get to the
old client or server implementations may accidentally server."
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.
The reply MUST have its UDP destination port set to BOOTPC (68). 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).
The UDP checksum must be recalculated before transmitting the Although now prohibited by Section 4.1.1 of this memo, the 'giaddr'
reply. 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.
4. BOOTP Client Behavior 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.
This section clarifies various issues regarding BOOTP client behavior. 3.5 Vendor information "magic cookie"
4.1 Client use of the 'flags' field 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.
4.1.1 The BROADCAST flag 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.
Normally, BOOTP servers and relay agents attempt to deliver DISCUSSION:
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 Sometimes different operating systems or networking packages
newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY are run on the same machine at different times (or even at the
messages it generates. This will provide a hint to BOOTP same time!). Since the hardware address placed in the 'chaddr'
servers and relay agents that they should attempt to broadcast field will likely be the same, BOOTREQUESTs from completely
their BOOTREPLY messages to the client. 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.
If a client does not have this limitation (i.e. it is perfectly 4. BOOTP Relay Agents
able to receive unicast BOOTREPLY messages), it SHOULD NOT set
the BROADCAST flag (i.e. it SHOULD clear the BROADCAST flag to
0).
DISCUSSION: In many cases, BOOTP clients and their associated BOOTP
This addition to the protocol is a workaround for old server(s) do not reside on the same IP network or subnet. In
host implementations. It is strongly recommended that such cases, some kind of third-party agent is required to
such implementations be modified so that they may transfer BOOTP messages between clients and servers. Such an
receive unicast BOOTREPLY messages, thus making use of agent was originally referred to as a "BOOTP forwarding agent."
this workaround unnecessary. In general, the use of However, in order to avoid confusion with the IP forwarding
this mechanism is discouraged. function of an IP router, the name "BOOTP relay agent" is
hereby adopted instead.
4.1.2 The remainder of the 'flags' field DISCUSSION:
The remaining bits of the 'flags' field are reserved for future A BOOTP relay agent performs a task which is distinct from an
use. A client MUST set these bits to zero in all BOOTREQUEST IP router's normal IP forwarding function. While a router
messages it generates. A client MUST ignore these bits in all normally switches IP datagrams between networks more-or-less
BOOTREPLY messages it receives. 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."
4.2 Definition of the 'secs' field 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.
The 'secs' field of a BOOTREQUEST message SHOULD represent the Any Internet host or router which provides BOOTP relay-agent
elapsed time, in seconds, since the client sent its first capability MUST conform to the specifications in this memo.
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 4.1 General BOOTP Processing for Relay Agents
for all BOOTREQUEST messages.
DISCUSSION: All locally delivered UDP messages whose UDP destination port number
The original definition of the 'secs' field was vague. It is BOOTPS (67) are considered for special processing by the host or
was not clear whether it represented the time since the router's logical BOOTP relay agent.
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 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 (usually
resulting in very inflated figures).
4.3 Interpretation of the 'giaddr' field 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.
The 'giaddr' field is rather poorly named. It exists to facilitate In the case of a router, locally delivered datagrams are broadcast
the transfer of BOOTREQUEST messages from a client, through BOOTP and multicast datagrams as well as unicast datagrams addressed to IP
relay agents, to servers on different networks than the client. addresses of that router. These are datagrams for which the router
Similarly, it facilitates the delivery of BOOTREPLY messages from should be considered an end destination as opposed to an intermediate
the servers, through BOOTP relay agents, back to the client. In no switching node. Thus a unicast datagram with an IP destination not
case does it represent a general IP router to be used by the client. matching any of the router's IP addresses is not considered for
processing by the router's logical BOOTP relay agent.
A BOOTP client MUST set the 'giaddr' field to zero (0.0.0.0) in all Hosts and routers are usually required to silently discard incoming
BOOTREQUEST messages it generates. 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 BOOTP client MUST NOT consider the 'giaddr' field of a BOOTREPLY A relay agent MUST silently discard any received UDP messages whose
message to represent an IP router. A BOOTP client SHOULD completely UDP destination port number is BOOTPC (68).
ignore the contents of the 'giaddr' field in BOOTREPLY messages.
DISCUSSION: DISCUSSION:
The semantics of the 'giaddr' field were poorly defined.
Section 7.5 of [1] states:
"If 'giaddr' (gateway address) is nonzero, then the There should be no need for a relay agent to process messages
packets should be forwarded there first, in order to addressed to the BOOTPC port. Careful reading of the original
get to the server." BOOTP specification [1] will show this. Nevertheless, some
relay agent implementations incorrectly relay such messages.
In that sentence, "get to" refers to communication from the The consistency checks specified in Section 2.1 SHOULD be performed
client to the server subsequent to the BOOTP exchange, such by the relay agent. BOOTP messages not meeting these consistency
as a TFTP session. Unfortunately, the 'giaddr' field may checks MUST be silently discarded.
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 3.1.1 of this memo, the 4.1.1 BOOTREQUEST Messages
'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 Some configuration mechanism MUST exist to enable or disable the
router address from the "Gateway" subfield of the "Vendor relaying of BOOTREQUEST messages. Relaying MUST be disabled by
Information Extensions" [2,3] (if present), or from some default.
other router discovery protocol.
4.4 Vendor information "magic cookie" 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.
It is RECOMMENDED that a BOOTP client always fill the first four DISCUSSION:
octets of the 'vend' (vendor information) field of a BOOTREQUEST
with a four-octet identifier called a "magic cookie." A BOOTP
client SHOULD do this even if it has no special information to
communicate to the BOOTP server using the 'vend' field. This aids
the BOOTP server in determining what vendor information format it
should use in its BOOTREPLY messages.
If a special vendor-specific magic cookie is not being used, a BOOTP To date, this feature of the BOOTP protocol has not necessarily
client SHOULD use the dotted decimal value 99.130.83.99 as specified been shown to be useful. See Section 3.2 for a discussion.
in [2,3]. 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: The relay agent MUST silently discard BOOTREQUEST messages whose
Sometimes different operating systems or networking packages provided to set this threshold to a smaller value if desired by the
are run on the same machine at different times (or even at network manager. The default setting for a configurable threshold
the same time!). Since the hardware address placed in the SHOULD be 4.
'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 BOOTREQUEST
messages, the server will at least know what format the
client expects and can understand in corresponding BOOTREPLY
messages.
5. Bit Ordering of Hardware Addresses 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 bit ordering used for link-level hardware addresses in the 'chaddr' The value of the 'hops' field MUST be incremented.
field SHOULD be the same as the ordering used for the ARP protocol [6]
on the client's network (assuming ARP is defined for that network).
DISCUSSION: All other BOOTP fields MUST be preserved intact.
One of the primary reasons the 'chaddr' field exists is to
enable BOOTP servers and relay agents to communicate directly
with clients without the use of broadcasts. In practice, the
contents of the '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.
6. BOOTP Over IEEE 802.5 Token Ring Networks 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).
Special consideration of the client/server and client/relay agent DISCUSSION:
interactions must be given to 802.5 networks because of non-transparent
bridging. 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 The network manager may wish the relaying destination to be an
assumption is that the 802.5 network is not bridged and it is, and the IP unicast, multicast, broadcast, or some combination. A
assumption that the network is bridged and it is not. In the former configurable list of destination IP addresses provides good
case, the Routing Information Field (RIF) will not be used; therefore, flexibility. More flexible configuration schemes are
if the server/relay agent are on another segment of the ring, the client encouraged. For example, it may be desirable to send to the
cannot reach it. In the latter case, the RIF field will be used, limited broadcast address (255.255.255.255) on specific
resulting in a few extraneous bytes on the ring. It is obvious that an physical interfaces. However, if the BOOTREQUEST message was
almost immeasurable inefficiency is to be preferred over a complete received as a broadcast, the relay agent MUST NOT rebroadcast
failure to communicate. the BOOTREQUEST on the physical interface from whence it came.
Given that the assumption is that RIF fields will be needed, it is A relay agent MUST use the same destination (or set of
necesary to determine the optimum method for the client to reach the destinations) for all BOOTREQUEST messages it relays from a
server/relay agent, and the optimum method for the response to be given client.
returned.
The client SHOULD send its broadcast BOOTREQUEST with an All Routes DISCUSSION:
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 is 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.
Security Considerations 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.
BOOTP is built directly upon UDP and IP which are as yet inherently Unfortunately, this well-intentioned scheme reacts badly with
insecure. Furthermore, BOOTP is generally intended to make maintenance DHCP [3] and perhaps other variations of the BOOTP protocol
of remote and/or diskless hosts easier. While perhaps not impossible, which depend on multiple exchanges of BOOTREQUEST and BOOTREPLY
configuring such hosts with passwords or keys may be difficult and messages between clients and servers. Therefore, all
inconvenient. Therefore, BOOTP in its current form is quite insecure. BOOTREQUEST messages from a given client MUST be relayed to the
same destination (or set of destinations).
Unauthorized BOOTP servers may easily be set up. Such servers can then One way to meet this requirement while providing some load-
send false and potentially disruptive information to clients such as balancing benefit is to hash the client's link-layer address
incorrect or duplicate IP addresses, incorrect routing information (or some other reliable client-identifying information) and use
(including spoof routers, etc.), incorrect domain nameserver addresses the resulting hash value to select the appropriate relay
(such as spoof nameservers), and so on. Clearly, once this "seed" destination (or set of destinations). The simplest solution,
mis-information is planted, an attacker can further compromise the of course, is to not use a load-balancing scheme and just relay
affected systems. ALL received BOOTREQUEST messages to the same destination (or
set of destinations).
BOOTP relay agents suffer some of the same problems as BOOTP servers. 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.
Malicious BOOTP clients could masquerade as legitimate clients and DISCUSSION:
retrieve information intended for those legitimate clients. Where
dynamic allocation of resources is used, a malicious client could claim As an extra precaution against BOOTREQUEST loops, it is
all resources for itself, thereby denying resources to legitimate preferable to use the decremented TTL from the original
clients. BOOTREQUEST. Unfortunately, this may be difficult to do in
some implementations.
If the BOOTREQUEST has a UDP checksum (i.e., the UDP checksum
is non-zero), the checksum must be recalculated before
transmitting the request.
4.1.2 BOOTREPLY Messages
BOOTP relay agents relay BOOTREPLY messages only to BOOTP clients.
It is the responsibility of BOOTP servers to send BOOTREPLY messages
directly to the relay agent identified in the BOOTREPLY messages it
receives are intended for BOOTP clients on its directly-connected
networks.
When a relay agent receives a BOOTREPLY message, it should examine
the BOOTP 'giaddr', 'yiaddr', 'chaddr', 'htype', and for the relay
agent to deliver the BOOTREPLY message to the client.
The 'giaddr' field can be used to identify the logical interface from
which the reply must be sent (i.e., the host or router interface
connected to the same network as the BOOTP client). If the content
of the 'giaddr' field does not match one of the relay agent's
directly-connected logical interfaces, the BOOTREPLY messsage MUST be
silently discarded.
The 'htype', 'hlen', and 'chaddr' fields supply the link-layer
hardware type, hardware address length, and hardware address of the
client as defined in the ARP protocol [4] and the Assigned Numbers
document [6]. The 'yiaddr' field is the IP address of the client, as
assigned by the BOOTP server.
The relay agent SHOULD examine the newly-defined BROADCAST flag (see
Sections 2.2 and 3.1.1 for more information). If this flag is set to
1, the reply SHOULD be sent as an IP broadcast using the IP limited
broadcast address 255.255.255.255 as the IP destination address and
the link-layer broadcast address as the link-layer destination
address. If the BROADCAST flag is cleared (0), the reply SHOULD be
sent as an IP unicast to the IP address specified by the 'yiaddr'
field and the link-layer address specified in the 'chaddr' field. If
unicasting is not possible, the reply MAY be sent as a broadcast, in
which case it SHOULD be sent to the link-layer broadcast address
using the IP limited broadcast address 255.255.255.255 as the IP
destination address.
DISCUSSION:
The addition of the BROADCAST flag to the protocol is a
workaround to help promote interoperability with certain client
implementations.
Note that since the 'flags' field was previously defined in [1]
simply as an "unused" field, it is possible that old client or
server implementations may accidentally and unknowingly set the
new BROADCAST flag. It is actually expected that such
implementations will be rare (most implementations seem to
zero-out this field), but interactions with such
implementations must nevertheless be considered. If an old
client or server does set the BROADCAST flag to 1 incorrectly,
conforming relay agents will generate broadcast BOOTREPLY
messages to the corresponding client. The BOOTREPLY messages
should still properly reach the client, at the cost of one
(otherwise unnecessary) additional broadcast. This, however,
is no worse than a server or relay agent which always
broadcasts its BOOTREPLY messages.
Older client or server implementations which accidentally set
the BROADCAST flag SHOULD be corrected to properly comply with
this newer specification.
All BOOTP fields MUST be preserved intact. The relay agent
MUST NOT modify any BOOTP field of the BOOTREPLY message when
relaying it to the client.
The reply MUST have its UDP destination port set to BOOTPC
(68).
If the BOOTREPLY has a UDP checksum (i.e., the UDP checksum is
non-zero), the checksum must be recalculated before
transmitting the reply.
5. BOOTP Server Behavior
This section provides clarifications on the behavior of BOOTP
servers.
5.1 Reception of BOOTREQUEST Messages
All received UDP messages whose UDP destination port number is BOOTPS
(67) are considered for processing by the BOOTP server.
Hosts and routers are usually required to silently discard incoming
datagrams containing illegal IP source addresses. This is generally
known as "Martian address filtering." One of these illegal addresses
is 0.0.0.0 (or actually anything on network 0). However, hosts or
routers which support a BOOTP server MUST accept for local delivery
to the server BOOTREQUEST messages whose IP source address is
0.0.0.0. BOOTREQUEST messages from legal IP source addresses MUST
also be accepted.
A BOOTP server MUST silently discard any received UDP messages whose
UDP destination port number is BOOTPC (68).
DISCUSSION:
There should be no need for a BOOTP server to process messages
addressed to the BOOTPC port. Careful reading of the original
BOOTP specification [1] will show this.
The consistency checks specified in Section 2.1 SHOULD be
performed by the BOOTP server. BOOTP messages not meeting
these consistency checks MUST be silently discarded.
5.2 Use of the 'secs' field
When the BOOTP server receives a BOOTREQUEST message, it MAY use the
value of the 'secs' (seconds since client began booting) field of the
request as a factor in deciding whether and/or how to reply to the
request.
DISCUSSION:
To date, this feature of the BOOTP protocol has not necessarily
been shown to be useful. See Section 3.2 for a discussion.
5.3 Use of the 'ciaddr' field
There have been various client interpretations of the 'ciaddr' field
for which Section 3.3 should be consulted. A BOOTP server SHOULD be
prepared to deal with these varying interpretations. In general, the
client; the contents of the 'ciaddr', 'chaddr', 'htype', and 'hlen'
fields, and probably other information (perhaps in the 'file' and
respond to a given client.
BOOTP servers SHOULD preserve the contents of the 'ciaddr' field in
BOOTREPLY messages; the contents of 'ciaddr' in a BOOTREPLY message
SHOULD exactly match the contents of 'ciaddr' in the corresponding
BOOTREQUEST message.
DISCUSSION:
It has been suggested that a client may wish to use the contents of
indeed intended for it.
5.4 Strategy for Delivery of BOOTREPLY Messages
Once the BOOTP server has created an appropriate BOOTREPLY message,
that BOOTREPLY message must be properly delivered to the client.
The server SHOULD first check the 'ciaddr' field. If the 'ciaddr'
field is non-zero, the BOOTREPLY message SHOULD be sent as an IP
unicast to the IP address identified in the 'ciaddr' field. The UDP
destination port MUST be set to BOOTPC (68). However, the server
MUST be aware of the problems identified in Section 3.3. The server
MAY choose to ignore the 'ciaddr' field and act as if the 'ciaddr'
field contains 0.0.0.0 (and thus continue with the rest of the
delivery algorithm below).
The server SHOULD next check the 'giaddr' field. If this field is
non-zero, the server SHOULD send the BOOTREPLY as an IP unicast to
the IP address identified in the 'giaddr' field. The UDP destination
port MUST be set to BOOTPS (67). This action will deliver the
BOOTREPLY message directly to the BOOTP relay agent closest to the
client; the relay agent will then perform the final delivery to the
client. If the BOOTP server has prior knowledge that a particular
client cannot receive unicast BOOTREPLY messages (e.g., the network
manager has explicitly configured the server with such knowledge),
the server MAY set the newly-defined BROADCAST flag to indicate that
relay agents SHOULD broadcast the BOOTREPLY message to the client.
Otherwise, the server MUST preserve the state of the BROADCAST flag
so that the relay agent can correctly act upon it.
If the 'giaddr' field is set to 0.0.0.0, then the client resides on
one of the same networks as the BOOTP server. The server SHOULD
examine the newly-defined BROADCAST flag (see Sections 2.2, 3.1.1 and
4.1.2 for more information). If this flag is set to 1 or the server
has prior knowledge that the client is unable to receive unicast
BOOTREPLY messages, the reply SHOULD be sent as an IP broadcast using
the IP limited broadcast address 255.255.255.255 as the IP
destination address and the link-layer broadcast address as the
link-layer destination address. If the BROADCAST flag is cleared
(0), the reply SHOULD be sent as an IP unicast to the IP address
specified by the field. If unicasting is not possible, the reply MAY
be sent as a broadcast in which case it SHOULD be sent to the link-
layer broadcast address using the IP limited broadcast address
255.255.255.255 as the IP destination address. In any case, the UDP
destination port MUST be set to BOOTPC (68).
DISCUSSION:
The addition of the BROADCAST flag to the protocol is a
workaround to help promote interoperability with certain client
implementations.
The following table summarizes server delivery decisions for
BOOTREPLY messages based upon information in BOOTREQUEST
messages:
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 Acknowledgements
The author would like to thank Gary Malkin of FTP Software, Inc. for his The author would like to thank Gary Malkin for his contribution of
contribution of the "BOOTP over IEEE 802.5 Token Ring Networks" section, the "BOOTP over IEEE 802.5 Token Ring Networks" section, and Steve
and Steve Deering of Xerox PARC for his observations on the problems Deering for his observations on the problems associated with the
associated with the 'giaddr' field. 'giaddr' field.
Ralph Droms of Bucknell University and the many members of the IETF Ralph Droms and the many members of the IETF Dynamic Host
Dynamic Host Configuration and Router Requirements working groups Configuration and Router Requirements working groups provided ideas
provided ideas for this memo as well as encouragement to write it. for this memo as well as encouragement to write it.
Philip Almquist and David Piscitello offered many helpful suggestions
for improving the clarity, accuracy, and organization of this memo.
These contributions are graciously acknowledged.
References References
[1] Croft, B., and J. Gilmore. Bootstrap Protocol (BOOTP). Request [1] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
For Comments (RFC) 951, DDN Network Information Center, SRI Stanford University and Sun Microsystems, September 1985.
International, Menlo Park, California, USA, September, 1985.
[2] Prindeville, P. BOOTP Vendor Information Extensions. Request For [2] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
Comments (RFC) 1048, DDN Network Information Center, SRI USC/Information Sciences Institute, August 1993. This RFC is
International, Menlo Park, California, USA, February, 1988. occasionally reissued with a new number. Please be sure to
consult the latest version.
[3] Reynolds, J. BOOTP Vendor Information Extensions. Request For [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 1531,
Comments (RFC) 1084, DDN Network Information Center, SRI Bucknell University, October 1993.
International, Menlo Park, California, USA, December, 1988.
[4] Almquist, P. Requirements for IP Routers. Internet Draft, [4] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37,
Corporation for National Research Initiatives, Reston, Virginia, RFC 826, MIT, November 1982.
USA, May, 1991.
[5] Droms, R. Dynamic Host Configuration Protocol. Internet Draft, [5] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox
Corporation for National Research Initiatives, Reston, Virginia, PARC, September 1991.
USA, June, 1992.
[6] Plummer, D. An Ethernet Address Resolution Protocol. Request For [6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
Comments (RFC) 826, DDN Network Information Center, SRI USC/Information Sciences Institute, July, 1992. This RFC is
International, Menlo Park, California, USA, November, 1982. periodically reissued with a new number. Please be sure to
consult the latest version.
[7] Reynolds, J., and J. Postel. Assigned Numbers. Request For Security Considerations
Comments (RFC) 1340, DDN Network Information Center, SRI
International, Menlo Park, California, USA, July, 1992. This RFC
is periodically reissued with a new number. Please be sure to
consult the latest version.
Author's Address 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.
Walt Wimer Unauthorized BOOTP servers may easily be set up. Such servers can
Network Development then send false and potentially disruptive information to clients such
Carnegie Mellon University as incorrect or duplicate IP addresses, incorrect routing information
4910 Forbes Avenue (including spoof routers, etc.), incorrect domain nameserver addresses
Pittsburgh, PA 15213-3890 (such as spoof nameservers), and so on. Clearly, once this "seed"
mis-information is planted, an attacker can further compromise the
affected systems.
Phone: (412) 268-6252 Unauthorized BOOTP relay agents may present some of the same problems
as unauthorized BOOTP servers.
EMail: Walter.Wimer@ANDREW.CMU.EDU 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
 End of changes. 158 change blocks. 
645 lines changed or deleted 830 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/