doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

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