RFC conformity

In this document the status of conformity with regards to DHCP-related IETF standards is laid out. The descriptions are taken verbatim from the respective RFC document. In case where more information is needed to put the requirement into context the description starts with a keyword enclosed in curly brackets ({}).

Note
any references (e.g enclosed in square brackets "[]") are from the original document and can be resolved by consulting the RFCs references section.

The requirements are separated into three categories as defined by the IETF: must (!), should (*) and may (+). The state column shows the conformity of ADHCP with regard to the specific requirement: fully conformant (c), not conformant (x) or not implemented (-).

+===+====================================================+===+==========+=====+
| # | Description                                        |Cat| Standard |State|
+===+====================================================+===+==========+=====+
| 1 |The 'client identifier' chosen by a DHCP client MUST| ! | RFC 2131 |  -  |
|   |be unique to that client within the subnet to which |   |          |     |
|   |the client is attached. If the client uses a        |   |          |     |
|   |'client identifier' in one message, it MUST use that|   |          |     |
|   |same identifier in all subsequent messages, to      |   |          |     |
|   |ensure that all servers correctly identify the      |   |          |     |
|   |client.                                             |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
| 2 |A DHCP client must be prepared to receive DHCP      | ! | RFC 2131 |  c  |
|   |messages with an 'options' field of at least length |   |          |     |
|   |312 octets.  This requirement implies that a DHCP   |   |          |     |
|   |client must be prepared to receive a message of up  |   |          |     |
|   |to 576 octets, the minimum IP datagram size an IP   |   |          |     |
|   |host must be prepared to accept [3].                |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
| 3 |The remaining bits of the flags field are reserved  | ! | RFC 2131 |  c  |
|   |for future use. They MUST be set to zero by clients |   |          |     |
|   |and ignored by servers and relay agents.            |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
| 4 |The first four octets of the 'options' field of the | ! | RFC 2131 |  c  |
|   |DHCP message contain the (decimal) values 99, 130,  |   |          |     |
|   |83 and 99, respectively (this is the same magic     |   |          |     |
|   |cookie as is defined in RFC 1497 [17]).             |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
| 5 |The client broadcasts a DHCPREQUEST message that    | ! | RFC 2131 |  c  |
|   |MUST include the 'server identifier' option to      |   |          |     |
|   |indicate which server it has selected, and that MAY |   |          |     |
|   |include other options specifying desired            |   |          |     |
|   |configuration values.  The 'requested IP address'   |   |          |     |
|   |option MUST be set to the value of 'yiaddr' in the  |   |          |     |
|   |DHCPOFFER message from the server.                  |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
| 6 |To help ensure that any BOOTP relay agents forward  | ! | RFC 2131 |  c  |
|   |the DHCPREQUEST message to the same set of DHCP     |   |          |     |
|   |servers that received the original DHCPDISCOVER     |   |          |     |
|   |message, the DHCPREQUEST message MUST use the same  |   |          |     |
|   |value in the DHCP message header's 'secs' field and |   |          |     |
|   |be sent to the same IP broadcast address as the     |   |          |     |
|   |original DHCPDISCOVER message.                      |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
| 7 |If the client detects that the address is already in| ! | RFC 2131 |  c  |
|   |use (e.g., through the use of ARP), the client MUST |   | RFC 5227 |     |
|   |send a DHCPDECLINE message to the server and        |   |          |     |
|   |restarts the configuration process.                 |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
| 8 |If the client used a 'client identifier' when it    | ! | RFC 2131 |  -  |
|   |obtained the lease, it MUST use the same            |   |          |     |
|   |'client identifier' in the DHCPRELEASE message.     |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
| 9 |{REBOOT} As the client has not received its network | ! | RFC 2131 |  -  |
|   |address, it MUST NOT fill in the 'ciaddr' field.    |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|10 |If the client used a 'client identifier' to obtain  | ! | RFC 2131 |  -  |
|   |its address, the client MUST use the same           |   |          |     |
|   |'client identifier' in the DHCPREQUEST message.     |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|11 |If 'giaddr' is 0x0 in the DHCPREQUEST message, the  | ! | RFC 2131 |  -  |
|   |client is on the same subnet as the server. The     |   |          |     |
|   |server MUST broadcast the DHCPNAK message to the    |   |          |     |
|   |0xffffffff broadcast address because the client may |   |          |     |
|   |not have a correct network address or subnet mask,  |   |          |     |
|   |and the client may not be answering ARP requests.   |   |          |     |
|   |Otherwise, the server MUST send the DHCPNAK message |   |          |     |
|   |to the IP address of the BOOTP relay agent, as      |   |          |     |
|   |recorded in 'giaddr'.                               |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|12 |If the client detects that the IP address in the    | ! | RFC 2131 |  c  |
|   |DHCPACK message is already in use, the client MUST  |   | RFC 5227 |     |
|   |send a DHCPDECLINE message to the server and        |   |          |     |
|   |restarts the configuration process by requesting a  |   |          |     |
|   |new network address.                                |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|13 |If the client receives no parameters from the server| ! | RFC 2131 |  c  |
|   |that override the defaults, a client uses those     |   |          |     |
|   |default values.                                     |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|14 |If the client includes a list of parameters in a    | ! | RFC 2131 |  c  |
|   |DHCPDISCOVER message, it MUST include that list in  |   |          |     |
|   |any subsequent DHCPREQUEST messages.                |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|15 |The 'requested IP address' option is to be filled in| ! | RFC 2131 |  c  |
|   |only in a DHCPREQUEST message when the client is    |   |          |     |
|   |verifying network parameters obtained previously.   |   |          |     |
|   |The client fills in the 'ciaddr' field only when    |   |          |     |
|   |correctly configured with an IP address in BOUND,   |   |          |     |
|   |RENEWING or REBINDING state.                        |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|16 |A client with multiple network interfaces must use  | ! | RFC 2131 |  c  |
|   |DHCP through each interface independently to obtain |   |          |     |
|   |configuration information parameters for those      |   |          |     |
|   |separate interfaces.                                |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|17 |If the lease expires before the client can contact a| ! | RFC 2131 |  -  |
|   |DHCP server, the client must immediately discontinue|   |          |     |
|   |use of the previous network address and may inform  |   |          |     |
|   |local users of the problem.                         |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|18 |The last option must always be the 'end' option.    | ! | RFC 2131 |  c  |
+---+----------------------------------------------------+---+----------+-----+
|19 |DHCP messages from a client to a server are sent to | ! | RFC 2131 |  c  |
|   |the 'DHCP server' port (67), and DHCP messages from |   |          |     |
|   |a server to a client are sent to the 'DHCP client'  |   |          |     |
|   |port (68).                                          |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|20 |A server with multiple network addresses MUST be    | ! | RFC 2131 |  -  |
|   |prepared to to accept any of its network addresses  |   |          |     |
|   |as identifying that server in a DHCP message.  To   |   |          |     |
|   |accommodate potentially incomplete network          |   |          |     |
|   |connectivity, a server MUST choose an address as a  |   |          |     |
|   |'server identifier' that, to the best of the        |   |          |     |
|   |server's knowledge, is reachable from the client    |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|21 |DHCP clients MUST use the IP address provided in the| ! | RFC 2131 |  c  |
|   |'server identifier' option for any unicast requests |   |          |     |
|   |to the DHCP server.                                 |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|22 |DHCP messages broadcast by a client prior to that   | ! | RFC 2131 |  c  |
|   |client obtaining its IP address must have the source|   |          |     |
|   |address field in the IP header set to 0.            |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|23 |If the options in a DHCP message extend into the    | ! | RFC 2131 |  -  |
|   |'sname' and 'file' fields, the 'option overload'    |   |          |     |
|   |option MUST appear in the 'options' field, with     |   |          |     |
|   |value 1, 2 or 3, as specified in RFC 1533.  If the  |   |          |     |
|   |'option overload' option is present in the 'options'|   |          |     |
|   |field, the options in the 'options' field MUST be   |   |          |     |
|   |terminated by an 'end' option,  and MAY contain one |   |          |     |
|   |or more 'pad' options to fill the options field. The|   |          |     |
|   |options in the 'sname' and 'file' fields (if in use |   |          |     |
|   |as indicated by the 'options overload' option) MUST |   |          |     |
|   |begin with the first octet of the field, MUST be    |   |          |     |
|   |terminated by an 'end' option, and MUST be followed |   |          |     |
|   |by 'pad' options to fill the remainder of the field.|   |          |     |
|   |Any individual option in the 'options', 'sname' and |   |          |     |
|   |'file' fields MUST be entirely contained in that    |   |          |     |
|   |field.  The options in the 'options' field MUST be  |   |          |     |
|   |interpreted first, so that any 'option overload'    |   |          |     |
|   |options may be interpreted.  The 'file' field MUST  |   |          |     |
|   |be interpreted next (if the 'option overload' option|   |          |     |
|   |indicates that the 'file' field contains DHCP       |   |          |     |
|   |options), followed by the 'sname' field.            |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|24 |Options may appear only once, unless otherwise      | ! | RFC 2131 |  x  |
|   |specified in the options document. The client       |   |          |     |
|   |concatenates the values of multiple instances of the|   |          |     |
|   |same option into a single parameter list for        |   |          |     |
|   |configuration.                                      |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|25 |The client MUST adopt a retransmission strategy that| ! | RFC 2131 |  x  |
|   |incorporates a randomized exponential backoff       |   |          |     |
|   |algorithm to determine the delay between            |   |          |     |
|   |retransmissions.                                    |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|26 |The 'xid' field is used by the client to match      | ! | RFC 2131 |  c  |
|   |incoming DHCP messages with pending requests. A DHCP|   |          |     |
|   |client MUST choose 'xid's in such a way as to       |   |          |     |
|   |minimize the chance of using an 'xid' identical to  |   |          |     |
|   |one used by another client.                         |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|27 |If the client supplies a 'client identifier', the   | ! | RFC 2131 |  c  |
|   |client MUST use the same 'client identifier' in all |   |          |     |
|   |subsequent messages, and the server MUST use that   |   |          |     |
|   |identifier to identify the client.  If the client   |   |          |     |
|   |does not provide a 'client identifier' option, the  |   |          |     |
|   |server MUST use the contents of the 'chaddr' field  |   |          |     |
|   |to identify the client.                             |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|28 |{DHCPREQUEST during SELECTING} Client inserts the   | ! | RFC 2131 |  c  |
|   |address of the selected server in 'server           |   |          |     |
|   |identifier', 'ciaddr' MUST be zero, 'requested IP   |   |          |     |
|   |address' MUST be filled in with the yiaddr value    |   |          |     |
|   |from the chosen DHCPOFFER.                          |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|29 |{DHCPREQUEST during INIT-REBOOT} 'server identifier'| ! | RFC 2131 |  -  |
|   |MUST NOT be filled in, 'requested IP address' option|   |          |     |
|   |MUST be filled in with client's notion of its       |   |          |     |
|   |previously assigned address. 'ciaddr' MUST be zero. |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|30 |{DHCPREQUEST during RENEWING} 'server identifier'   | ! | RFC 2131 |  c  |
|   |MUST NOT be filled in, 'requested IP address' option|   |          |     |
|   |MUST NOT be filled in, 'ciaddr' MUST be filled in   |   |          |     |
|   |with client's IP address.                           |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|31 |{DHCPREQUEST during REBINDING} 'server identifier'  | ! | RFC 2131 |  c  |
|   |MUST NOT be filled in, 'requested IP address' option|   |          |     |
|   |MUST NOT be filled in, 'ciaddr' MUST be filled in   |   |          |     |
|   |with client's IP address.                           |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|32 |The client sets 'ciaddr' to 0x00000000.             | ! | RFC 2131 |  c  |
+---+----------------------------------------------------+---+----------+-----+
|33 |The client MUST include its hardware address in the | ! | RFC 2131 |  c  |
|   |'chaddr' field, if necessary for delivery of DHCP   |   |          |     |
|   |reply messages.                                     |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|34 |If the client included a list of requested          | ! | RFC 2131 |  c  |
|   |parameters in a DHCPDISCOVER message, it MUST       |   |          |     |
|   |include that list in all subsequent messages.       |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|35 |The client generates and records a random           | ! | RFC 2131 |  c  |
|   |transaction identifier and inserts that identifier  |   |          |     |
|   |into the 'xid' field.  The client records its own   |   |          |     |
|   |local time for later use in computing the lease     |   |          |     |
|   |expiration.  The client then broadcasts the         |   |          |     |
|   |DHCPDISCOVER on the local hardware broadcast address|   |          |     |
|   |to the 0xffffffff IP broadcast address and 'DHCP    |   |          |     |
|   |server' UDP port.                                   |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|36 |If the 'xid' of an arriving DHCPOFFER message does  | ! | RFC 2131 |  c  |
|   |not match the 'xid' of the most recent DHCPDISCOVER |   |          |     |
|   |message, the DHCPOFFER message must be silently     |   |          |     |
|   |discarded. Any arriving DHCPACK messages must be    |   |          |     |
|   |silently discarded.                                 |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|37 |The client collects DHCPOFFER messages over a period| ! | RFC 2131 |  c  |
|   |of time, selects one DHCPOFFER message from the     |   |          |     |
|   |(possibly many) incoming DHCPOFFER messages (e.g.,  |   |          |     |
|   |the first DHCPOFFER message or the DHCPOFFER message|   |          |     |
|   |from the previously used server) and extracts the   |   |          |     |
|   |server address from the 'server identifier' option  |   |          |     |
|   |in the DHCPOFFER message.                           |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|38 |If the parameters are acceptable, the client records| ! | RFC 2131 |  c  |
|   |the address of the server that supplied the         |   |          |     |
|   |parameters from the 'server identifier' field and   |   |          |     |
|   |sends that address in the 'server identifier' field |   |          |     |
|   |of a DHCPREQUEST broadcast message. Once the DHCPACK|   |          |     |
|   |message from the server arrives, the client is      |   |          |     |
|   |initialized and moves to BOUND state. The           |   |          |     |
|   |DHCPREQUEST message contains the same 'xid' as the  |   |          |     |
|   |DHCPOFFER message. The client records the lease     |   |          |     |
|   |expiration time as the sum of the time at which the |   |          |     |
|   |original request was sent and the duration of the   |   |          |     |
|   |lease from the DHCPACK message.                     |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|39 |The client MUST insert its known network address as | ! | RFC 2131 |  c  |
|   |a 'requested IP address' option in the DHCPREQUEST  |   |          |     |
|   |message.                                            |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|40 |The client generates and records a random           | ! | RFC 2131 |  c  |
|   |transaction identifier and inserts that identifier  |   |          |     |
|   |into the 'xid' field.  The client records its own   |   |          |     |
|   |local time for later use in computing the lease     |   |          |     |
|   |expiration.  The client MUST NOT include a 'server  |   |          |     |
|   |identifier' in the DHCPREQUEST message.  The client |   |          |     |
|   |then broadcasts the DHCPREQUEST on the local        |   |          |     |
|   |hardware broadcast address to the 'DHCP server' UDP |   |          |     |
|   |port.                                               |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|41 |Once a DHCPACK message with an 'xid' field matching | ! | RFC 2131 |  c  |
|   |that in the client's DHCPREQUEST message arrives    |   |          |     |
|   |from any server, the client is initialized and moves|   |          |     |
|   |to BOUND state.  The client records the lease       |   |          |     |
|   |expiration time as the sum of the time at which the |   |          |     |
|   |DHCPREQUEST message was sent and the duration of the|   |          |     |
|   |lease from the DHCPACK message.                     |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|42 |The client then unicasts the DHCPINFORM to the DHCP | ! | RFC 2131 |  -  |
|   |server if it knows the server's address, otherwise  |   |          |     |
|   |it broadcasts the message to the limited (all 1s)   |   |          |     |
|   |broadcast address.  DHCPINFORM messages MUST be     |   |          |     |
|   |directed to the 'DHCP server' UDP port.             |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|43 |The client maintains two times, T1 and T2, that     | ! | RFC 2131 |  c  |
|   |specify the times at which the client tries to      |   |          |     |
|   |extend its lease on its network address. T1 is the  |   |          |     |
|   |time at which the client enters the RENEWING state  |   |          |     |
|   |and attempts to contact the server that originally  |   |          |     |
|   |issued the client's network address.  T2 is the time|   |          |     |
|   |at which the client enters the REBINDING state and  |   |          |     |
|   |attempts to contact any server. T1 MUST be earlier  |   |          |     |
|   |than T2, which, in turn, MUST be earlier than the   |   |          |     |
|   |time at which the client's lease will expire.       |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|44 |At time T1 the client moves to RENEWING state and   | ! | RFC 2131 |  c  |
|   |sends (via unicast) a DHCPREQUEST message to the    |   |          |     |
|   |server to extend its lease. The client sets the     |   |          |     |
|   |'ciaddr' field in the DHCPREQUEST to its current    |   |          |     |
|   |network address. The client records the local time  |   |          |     |
|   |at which the DHCPREQUEST message is sent for        |   |          |     |
|   |computation of the lease expiration time.  The      |   |          |     |
|   |client MUST NOT include a 'server identifier' in the|   |          |     |
|   |DHCPREQUEST message.                                |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|45 |Any DHCPACK messages that arrive with an 'xid' that | ! | RFC 2131 |  c  |
|   |does not match the 'xid' of the client's DHCPREQUEST|   |          |     |
|   |message are silently discarded. When the client     |   |          |     |
|   |receives a DHCPACK from the server, the client      |   |          |     |
|   |computes the lease expiration time as the sum of the|   |          |     |
|   |time at which the client sent the DHCPREQUEST       |   |          |     |
|   |message and the duration of the lease in the DHCPACK|   |          |     |
|   |message.  The client has successfully reacquired its|   |          |     |
|   |network address, returns to BOUND state and may     |   |          |     |
|   |continue network processing.                        |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|46 |If no DHCPACK arrives before time T2, the client    | ! | RFC 2131 |  c  |
|   |moves to REBINDING state and sends (via broadcast) a|   |          |     |
|   |DHCPREQUEST message to extend its lease. The client |   |          |     |
|   |sets the 'ciaddr' field in the DHCPREQUEST to its   |   |          |     |
|   |current network address.  The client MUST NOT       |   |          |     |
|   |include a 'server identifier' in the DHCPREQUEST    |   |          |     |
|   |message.                                            |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|47 |Times T1 and T2 are configurable by the server      | ! | RFC 2131 |  c  |
|   |through options.                                    |   |          |     |
|   |T1 defaults to (0.5 * duration_of_lease). T2        |   |          |     |
|   |defaults to (0.875 * duration_of_lease).            |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|48 |If the lease expires before the client receives a   | ! | RFC 2131 |  -  |
|   |DHCPACK, the client moves to INIT state, MUST       |   |          |     |
|   |immediately stop any other network processing and   |   |          |     |
|   |requests network initialization parameters as if the|   |          |     |
|   |client were uninitialized.                          |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|49 |If the client is given a new network address, it    | ! | RFC 2131 |  c  |
|   |MUST NOT continue using the previous network address|   |          |     |
|   |and SHOULD notify the local users of the problem.   |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|50 |This memo hereby defines the most significant bit of| ! | RFC 1542 |  c  |
|   |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 and relay agents.                           |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|51 |The 'chaddr' field MUST be preserved as it was      | ! | RFC 1542 |  c  |
|   |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.                                          |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|52 |The remaining bits of the 'flags' field are reserved| ! | RFC 1542 |  c  |
|   |for future use. A client MUST set these bits to zero|   |          |     |
|   | in all BOOTREQUEST messages it generates.          |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|53 |A client MUST ignore these bits in all BOOTREPLY    | ! | RFC 1542 |  c  |
|   |messages it receives.                               |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|54 |If the client does place a non-zero IP address in   | ! | RFC 1542 |  c  |
|   |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).           |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|55 |A BOOTP client MUST set the 'giaddr' field to zero  | ! | RFC 1542 |  c  |
|   |(0.0.0.0) in all BOOTREQUEST messages it generates. |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|56 |A BOOTP client MUST NOT interpret the 'giaddr' field| ! | RFC 1542 |  c  |
|   |of a BOOTREPLY message to be the IP address of an IP|   |          |     |
|   |router.                                             |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|57 |Any Internet host or router which provides BOOTP    | ! | RFC 1542 |  c  |
|   |relay-agent capability MUST conform to the          |   |          |     |
|   |specifications in this memo.                        |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|58 |However, hosts or routers which support a BOOTP     | ! | RFC 1542 |  c  |
|   |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.          |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|59 |A relay agent MUST silently discard any received UDP| ! | RFC 1542 |  c  |
|   |messages whose UDP destination port number is BOOTPC|   |          |     |
|   |(68).                                               |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|60 |BOOTP messages not meeting these consistency checks | ! | RFC 1542 |  c  |
|   |MUST be silently discarded.                         |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|61 |Some configuration mechanism MUST exist to enable or| ! | RFC 1542 |  -  |
|   |disable the relaying of BOOTREQUEST messages.       |   |          |     |
|   |Relaying MUST be disabled by default.               |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|62 |The relay agent MUST silently discard BOOTREQUEST   | ! | RFC 1542 |  c  |
|   |messages whose 'hops' field exceeds the value 16.   |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|63 |If the relay agent does decide to relay the request,| ! | RFC 1542 |  c  |
|   |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.        |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|64 |If the 'giaddr' field contains some non-zero value, | ! | RFC 1542 |  c  |
|   |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).      |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|65 |The value of the 'hops' field MUST be incremented.  | ! | RFC 1542 |  c  |
+---+----------------------------------------------------+---+----------+-----+
|66 |All other BOOTP fields MUST be preserved intact.    | ! | RFC 1542 |  c  |
+---+----------------------------------------------------+---+----------+-----+
|67 |At this point, the request is relayed to its new    | ! | RFC 1542 |  c  |
|   |destination (or destinations).  This destination    |   |          |     |
|   |MUST be configurable.                               |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|68 |However, if the BOOTREQUEST message was received as | ! | RFC 1542 |  c  |
|   |a broadcast, the relay agent MUST NOT rebroadcast   |   |          |     |
|   |the BOOTREQUEST on the physical interface from      |   |          |     |
|   |whence it came.                                     |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|69 |A relay agent MUST use the same destination (or set | ! | RFC 1542 |  c  |
|   |of destinations) for all BOOTREQUEST messages it    |   |          |     |
|   |relays from a given client.                         |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|70 |If the BOOTREQUEST has a UDP checksum (i.e., the UDP| ! | RFC 1542 |  c  |
|   |checksum is non-zero), the checksum must be         |   |          |     |
|   |recalculated before transmitting the request.       |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|71 |If the content of the 'giaddr' field does not match | ! | RFC 1542 |  c  |
|   |one of the relay agent's directly-connected logical |   |          |     |
|   |interfaces, the BOOTREPLY messsage MUST be silently |   |          |     |
|   |discarded.                                          |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|72 |All BOOTP fields MUST be preserved intact.  The     | ! | RFC 1542 |  c  |
|   |relay agent MUST NOT modify any BOOTP field of the  |   |          |     |
|   |BOOTREPLY message when relaying it to the client.   |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|73 |The reply MUST have its UDP destination port set to | ! | RFC 1542 |  c  |
|   |BOOTPC (68).                                        |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|74 |If the BOOTREPLY has a UDP checksum (i.e., the UDP  | ! | RFC 1542 |  c  |
|   | checksum is non-zero), the checksum must be        |   |          |     |
|   |recalculated before transmitting the reply.         |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|75 |{DHCPINFORM} The client generates and records a     | ! | RFC 2131 |  -  |
|   |random transaction identifier and inserts that      |   |          |     |
|   |identifier into the 'xid' field. The client places  |   |          |     |
|   |its own network address in the 'ciaddr' field.      |   |          |     |
+===+====================================================+===+==========+=====+
|76 |The TCP/IP software SHOULD accept and forward to the| * | RFC 2131 |  c  |
|   |IP layer any IP packets delivered to the client's   |   |          |     |
|   |hardware address before the IP address is configured|   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|77 |As a consistency check, the allocating server SHOULD| * | RFC 2131 |  -  |
|   |probe the reused address before allocating the      |   |          |     |
|   |address, e.g., with an ICMP echo request, and the   |   |          |     |
|   |client SHOULD probe the newly received address,     |   |          |     |
|   |e.g., with ARP.                                     |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|78 |When allocating a new address, servers SHOULD check | * | RFC 2131 |  -  |
|   |that the offered network address is not already in  |   |          |     |
|   |use; e.g., the server may probe the offered address |   |          |     |
|   |with an ICMP Echo Request.  Servers SHOULD be       |   |          |     |
|   |implemented so that network administrators MAY      |   |          |     |
|   |choose to disable probes of newly allocated         |   |          |     |
|   |addresses.                                          |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|79 |Servers SHOULD be implemented so that network       | * | RFC 2131 |  -  |
|   |administrators MAY choose to disable probes of newly|   |          |     |
|   |allocated addresses.                                |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|80 |Any configuration parameters in the DHCPACK message | * | RFC 2131 |  -  |
|   |SHOULD NOT conflict with those in the earlier       |   |          |     |
|   |DHCPOFFER message to which the client is responding.|   |          |     |
|   |The server SHOULD NOT check the offered network     |   |          |     |
|   |address at this point.                              |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|81 |If the selected server is unable to satisfy the     | * | RFC 2131 |  -  |
|   |DHCPREQUEST message (e.g., the requested network    |   |          |     |
|   |address has been allocated), the server SHOULD      |   |          |     |
|   |respond with a DHCPNAK message.                     |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|82 |The server SHOULD mark an address offered to a      | * | RFC 2131 |  -  |
|   |client in a DHCPOFFER message as available if the   |   |          |     |
|   |server receives no DHCPREQUEST message from that    |   |          |     |
|   |client.                                             |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|83 |The client SHOULD perform a final check on the      | * | RFC 2131 |  x  |
|   |parameters (e.g., ARP for allocated network address)|   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|84 |The client SHOULD wait a minimum of ten seconds     | * | RFC 2131 |  c  |
|   |before restarting the configuration process to avoid|   |          |     |
|   |excessive network traffic in case of looping.       |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|85 |The client SHOULD notify the user that the          | * | RFC 2131 |  c  |
|   |initialization process has failed and is restarting.|   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|86 |Servers SHOULD NOT check that the client's network  | * | RFC 2131 |  -  |
|   |address is already in use.                          |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|87 |If the client's request is invalid (e.g., the client| * | RFC 2131 |  -  |
|   |has moved to a new subnet), servers SHOULD respond  |   |          |     |
|   |with a DHCPNAK message to the client. Servers SHOULD|   |          |     |
|   |NOT respond if their information is not guaranteed  |   |          |     |
|   |to be accurate.                                     |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|88 |The servers SHOULD unicast the DHCPACK reply to the | * | RFC 2131 |  -  |
|   |address given in the 'ciaddr' field of the          |   |          |     |
|   |DHCPINFORM message.                                 |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|89 |The server SHOULD check the network address in a    | * | RFC 2131 |  -  |
|   |DHCPINFORM message for consistency, but MUST NOT    |   |          |     |
|   |check for an existing lease.                        |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|90 |The client SHOULD include the 'maximum DHCP message | * | RFC 2131 |  x  |
|   |size' option to let the server know how large the   |   |          |     |
|   |server may make its DHCP messages.                  |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|91 |If a server receives a DHCPREQUEST message with an  | * | RFC 2131 |  -  |
|   |invalid 'requested IP address', the server SHOULD   |   |          |     |
|   |respond to the client with a DHCPNAK message and may|   |          |     |
|   |choose to report the problem to the system          |   |          |     |
|   |administrator.                                      |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|92 |A client SHOULD use DHCP to reacquire or verify its | * | RFC 2131 |  c  |
|   |IP address and network parameters whenever the local|   |          |     |
|   |network parameters may have changed;                |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|93 |A client that cannot receive unicast IP datagrams   | * | RFC 2131 |  c  |
|   |until its protocol software has been configured with|   |          |     |
|   |an IP address SHOULD set the BROADCAST bit in the   |   |          |     |
|   |'flags' field to 1 in any DHCPDISCOVER or           |   |          |     |
|   |DHCPREQUEST messages that client sends.             |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|94 |A client that can receive unicast IP datagrams      | * | RFC 2131 |  c  |
|   |before its protocol software has been configured    |   |          |     |
|   |SHOULD clear the BROADCAST bit to 0.                |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|95 |The client implementation of DHCP SHOULD provide a  | * | RFC 2131 |  x  |
|   |mechanism for the user to select directly the       |   |          |     |
|   |'vendor class identifier' values.                   |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|96 |The client SHOULD wait a random time between one and| * | RFC 2131 |  -  |
|   |ten seconds to desynchronize the use of DHCP at     |   |          |     |
|   |startup.                                            |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|97 |The client SHOULD perform a check on the suggested  | * | RFC 2131 |  x  |
|   |address to ensure that the address is not already in|   |          |     |
|   |use. For example, if the client is on a network that|   |          |     |
|   |supports ARP, the client may issue an ARP request   |   |          |     |
|   |for the suggested request. When broadcasting an ARP |   |          |     |
|   |request for the suggested address, the client must  |   |          |     |
|   |fill in its own hardware address as the sender's    |   |          |     |
|   |hardware address, and 0 as the sender's IP address, |   |          |     |
|   |to avoid confusing ARP caches in other hosts on the |   |          |     |
|   |same subnet. If the network address appears to be in|   |          |     |
|   |use, the client MUST send a DHCPDECLINE message to  |   |          |     |
|   |the server.                                         |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|98 |{DHCPINFORM} The client SHOULD NOT request lease    | * | RFC 2131 |  -  |
|   |time parameters.                                    |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|99 |{DHCPINFORM} If the client does not receive a       | * | RFC 2131 |  -  |
|   |DHCPACK within a reasonable period of time (60      |   |          |     |
|   |seconds or 4 tries if using timeout suggested in    |   |          |     |
|   |section 4.1), then it SHOULD display a message      |   |          |     |
|   |informing the user of the problem, and then SHOULD  |   |          |     |
|   |begin network processing using suitable defaults as |   |          |     |
|   |per Appendix A.                                     |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|100|{Server} Times T1 and T2 SHOULD be chosen with some | * | RFC 2131 |  -  |
|   |random "fuzz" around a fixed value, to avoid        |   |          |     |
|   |synchronization of client reacquisition.            |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|101|The server SHOULD return T1 and T2, and their values| * | RFC 2131 |  -  |
|   |SHOULD be adjusted from their original values to    |   |          |     |
|   |take account of the time remaining on the lease.    |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|102|In both RENEWING and REBINDING states, if the client| * | RFC 2131 |  -  |
|   |receives no response to its DHCPREQUEST message, the|   |          |     |
|   |client SHOULD wait one-half of the remaining time   |   |          |     |
|   |until T2 (in RENEWING state) and one-half of the    |   |          |     |
|   |remaining lease time (in REBINDING state), down to a|   |          |     |
|   |minimum of 60 seconds, before retransmitting the    |   |          |     |
|   |DHCPREQUEST message.                                |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|103|This memo specifies several cases where a BOOTP     | * | RFC 1542 |  x  |
|   |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.                      |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|104|The following consistency checks SHOULD be performed| * | RFC 1542 |  c  |
|   |on BOOTP messages: 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]. 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.                         |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|105|The bit ordering used for link-level hardware       | * | RFC 1542 |  c  |
|   |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).                                  |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|106|If a client falls into this category, it SHOULD set | * | RFC 1542 |  c  |
|   |(to 1) the newly-defined BROADCAST flag in the      |   |          |     |
|   |'flags' field of BOOTREPLY messages it generates.   |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|107|If a client does not have this limitation (i.e., it | * | RFC 1542 |  c  |
|   |is perfectly ableb to receive unicast BOOTREPLY     |   |          |     |
|   |messages), it SHOULD NOT set the BROADCAST flag     |   |          |     |
|   |(i.e., it SHOULD clear the BROADCAST flag to 0).    |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|108|The 'secs' field of a BOOTREQUEST message SHOULD    | * | RFC 1542 |  -  |
|   |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.          |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|109|Clients SHOULD NOT set the 'secs' field to a value  | * | RFC 1542 |  x  |
|   |which is constant for all BOOTREQUEST messages.     |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|110|If a BOOTP client does not know what IP address it  | * | RFC 1542 |  c  |
|   |should be using, the client SHOULD set the 'ciaddr' |   |          |     |
|   |field to 0.0.0.0.                                   |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|111|The client SHOULD adopt the IP address specified in | * | RFC 1542 |  c  |
|   |'yiaddr' and begin using it as soon as possible.    |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|112|A BOOTP client SHOULD completely ignore the contents| * | RFC 1542 |  c  |
|   |of the 'giaddr' field in BOOTREPLY messages.        |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|113|If a special vendor-specific magic cookie is not    | * | RFC 1542 |  c  |
|   |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.                 |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|114|The consistency checks specified in Section 2.1     | * | RFC 1542 |  c  |
|   |SHOULD be performed by the relay agent.             |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|115|{Hops} A configuration option SHOULD be provided to | * | RFC 1542 |  -  |
|   |set this threshold to a smaller value if desired by |   |          |     |
|   |the network manager.  The default setting for a     |   |          |     |
|   |configurable threshold SHOULD be 4.                 |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|116|If the interface has more than one IP address       | * | RFC 1542 |  c  |
|   |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.                                             |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|117|Further, this destination configuration SHOULD be   | * | RFC 1542 |  c  |
|   |independent of the destination configuration for any|   |          |     |
|   |other so-called "broadcast forwarders" (e.g., for   |   |          |     |
|   |the UDP-based TFTP, DNS, Time, etc. protocols).     |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|118|The relay agent SHOULD examine the newly-defined    | * | RFC 1542 |  c  |
|   |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.                    |   |          |     |
+===+====================================================+===+==========+=====+
|119|{DHCPINFORM} The client may request specific        | + | RFC 2131 |  c  |
|   |configuration parameters by including the 'parameter|   |          |     |
|   | request list' option.                              |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|120|The DHCPDISCOVER message MAY include options that   | + | RFC 2131 |  -  |
|   |suggest values for the network address and lease    |   |          |     |
|   |duration.                                           |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|121|The client may choose to wait for multiple responses| + | RFC 2131 |  -  |
+---+----------------------------------------------------+---+----------+-----+
|122|A server MAY choose to mark addresses offered to    | + | RFC 2131 |  -  |
|   |clients in DHCPOFFER messages as unavailable.       |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|123|The client may suggest values for the network       | + | RFC 2131 |  -  |
|   |address and lease time in the DHCPDISCOVER message. |   |          |     |
|   |The client may include the 'requested IP address'   |   |          |     |
|   |option to suggest that a particular IP address be   |   |          |     |
|   |assigned, and may include the 'IP address lease     |   |          |     |
|   |time' option to suggest the lease time it would     |   |          |     |
|   |like.                                               |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|124|The client may continue to use the previous network | + | RFC 2131 |  c  |
|   |address until the lease for that address expires.   |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|125|A server with multiple network address (e.g., a     | + | RFC 2131 |  -  |
|   |multi-homed host) MAY use any of its network        |   |          |     |
|   |addresses in outgoing DHCP messages.                |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|126|Selecting a new 'xid' for each retransmission is an | + | RFC 2131 |  -  |
|   |implementation decision. A client may choose to     |   |          |     |
|   |reuse the same 'xid' or select a new 'xid' for each |   |          |     |
|   |retransmitted message.                              |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|127|The client MAY choose to explicitly provide the     | + | RFC 2131 |  -  |
|   |identifier through the 'client identifier' option.  |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|128|The client MAY request specific parameters by       | + | RFC 2131 |  c  |
|   |including the 'parameter request list' option.      |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|129|The client MAY suggest a network address and/or     | + | RFC 2131 |  -  |
|   |lease time by including the 'requested IP address'  |   |          |     |
|   |and 'IP address lease time' options.                |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|130|The client may request specific configuration       | + | RFC 2131 |  c  |
|   |parameters by including the 'parameter request list'|   |          |     |
|   |option.                                             |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|131|When the DHCP client knows the address of a DHCP    | + | RFC 2131 |  -  |
|   |server, in either INIT or REBOOTING state, the      |   |          |     |
|   |client may use that address in the DHCPDISCOVER or  |   |          |     |
|   |DHCPREQUEST rather than the IP broadcast address.   |   |          |     |
|   |The client may also use unicast to send DHCPINFORM  |   |          |     |
|   |messages to a known DHCP server. If the client      |   |          |     |
|   |receives no response to DHCP messages sent to the IP|   |          |     |
|   |address of a known DHCP server, the DHCP client     |   |          |     |
|   |reverts to using the IP broadcast address.          |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|132|A client MAY choose to renew or extend its lease    | + | RFC 2131 |  -  |
|   |prior to T1. The server MAY choose to extend the    |   |          |     |
|   |client's lease according to policy set by the       |   |          |     |
|   |network administrator.                              |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|133|If the client has the ability to remember the last  | + | RFC 1542 |  -  |
|   |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.                               |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|134|When the BOOTP relay agent receives a BOOTREQUEST   | + | RFC 1542 |  -  |
|   |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.                   |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|135|When transmitting the request to its next           | + | RFC 1542 |  -  |
|   |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.                                     |   |          |     |
+---+----------------------------------------------------+---+----------+-----+
|136|If unicasting is not possible, the reply MAY be sent| + | RFC 1542 |  c  |
|   |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.                                |   |          |     |
+---+----------------------------------------------------+---+----------+-----+