+===+====================================================+===+==========+=====+ | # | 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 | - | | |use (e.g., through the use of ARP), the client MUST | | | | | |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 | - | | |DHCPACK message is already in use, the client MUST | | | | | |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. | | | | +---+----------------------------------------------------+---+----------+-----+