DHCPv6 branch merged to HEAD.

1 files changed, 0 insertions, 1291 deletions

diff --git a/doc/rfc1542.txt b/doc/rfc1542.txt
deleted file mode 100644
index cc03e669..00000000
--- a/doc/rfc1542.txt
+++ /dev/null
@@ -1,1291 +0,0 @@
-
-
-
-
-
-
-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