ADHCP

1

The client identifier chosen by a DHCP client MUST 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.

2131

-

2

A DHCP client must be prepared to receive DHCP 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].

2131

c

3

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.

2131

c

4

The first four octets of the options field of the 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]).

2131

c

5

The client broadcasts a DHCPREQUEST message that 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.

2131

c

6

To help ensure that any BOOTP relay agents forward 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.

2131

c

7

If the client detects that the address is already in use (e.g., through the use of ARP), the client MUST send a DHCPDECLINE message to the server and restarts the configuration process.

2131
5227

c

8

If the client used a client identifier when it obtained the lease, it MUST use the same client identifier in the DHCPRELEASE message.

2131

-

9

{REBOOT} As the client has not received its network address, it MUST NOT fill in the ciaddr field.

2131

-

10

If the client used a client identifier to obtain its address, the client MUST use the same client identifier in the DHCPREQUEST message.

2131

-

11

If giaddr is 0x0 in the DHCPREQUEST message, the 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.

2131

-

12

If the client detects that the IP address in the 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.

2131
5227

c

13

If the client receives no parameters from the server that override the defaults, a client uses those default values.

2131

c

14

If the client includes a list of parameters in a DHCPDISCOVER message, it MUST include that list in any subsequent DHCPREQUEST messages.

2131

c

15

The requested IP address option is to be filled in 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.

2131

c

16

A client with multiple network interfaces must use DHCP through each interface independently to obtain configuration information parameters for those separate interfaces.

2131

c

17

If the lease expires before the client can contact a DHCP server, the client must immediately discontinue use of the previous network address and may inform local users of the problem.

2131

-

18

The last option must always be the end option.

2131

c

19

DHCP messages from a client to a server are sent to the DHCP server port (67), and DHCP messages from a server to a client are sent to the DHCP client port (68).

2131

c

20

A server with multiple network addresses MUST be 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

2131

-

21

DHCP clients MUST use the IP address provided in the server identifier option for any unicast requests to the DHCP server.

2131

c

22

DHCP messages broadcast by a client prior to that client obtaining its IP address must have the source address field in the IP header set to 0.

2131

c

23

If the options in a DHCP message extend into the 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.

2131

-

24

Options may appear only once, unless otherwise specified in the options document. The client concatenates the values of multiple instances of the same option into a single parameter list for configuration.

2131

x

25

The client MUST adopt a retransmission strategy that incorporates a randomized exponential backoff algorithm to determine the delay between retransmissions.

2131

x

26

The xid field is used by the client to match 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.

2131

c

27

If the client supplies a client identifier, the 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.

2131

c

28

{DHCPREQUEST during SELECTING} Client inserts the 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.

2131

c

29

{DHCPREQUEST during INIT-REBOOT} server identifier 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.

2131

-

30

{DHCPREQUEST during RENEWING} server identifier MUST NOT be filled in, requested IP address option MUST NOT be filled in, ciaddr MUST be filled in with client’s IP address.

2131

c

31

{DHCPREQUEST during REBINDING} server identifier MUST NOT be filled in, requested IP address option MUST NOT be filled in, ciaddr MUST be filled in with client’s IP address.

2131

c

32

The client sets ciaddr to 0x00000000.

2131

c

33

The client MUST include its hardware address in the chaddr field, if necessary for delivery of DHCP reply messages.

2131

c

34

If the client included a list of requested parameters in a DHCPDISCOVER message, it MUST include that list in all subsequent messages.

2131

c

35

The client generates and records a random 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.

2131

c

36

If the xid of an arriving DHCPOFFER message does 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.

2131

c

37

The client collects DHCPOFFER messages over a period 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.

2131

c

38

If the parameters are acceptable, the client records 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.

2131

c

39

The client MUST insert its known network address as a requested IP address option in the DHCPREQUEST message.

2131

c

40

The client generates and records a random 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.

2131

c

41

Once a DHCPACK message with an xid field matching 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.

2131

c

42

The client then unicasts the DHCPINFORM to the DHCP 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.

2131

-

43

The client maintains two times, T1 and T2, that 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.

2131

c

44

At time T1 the client moves to RENEWING state and 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.

2131

c

45

Any DHCPACK messages that arrive with an xid that 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.

2131

c

46

If no DHCPACK arrives before time T2, the client 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.

2131

c

47

Times T1 and T2 are configurable by the server through options. T1 defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 * duration_of_lease).

2131

c

48

If the lease expires before the client receives a 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.

2131

-

49

If the client is given a new network address, it MUST NOT continue using the previous network address and SHOULD notify the local users of the problem.

2131

c

50

This memo hereby defines the most significant bit of the flags field as the BROADCAST (B) flag. The semantics of this flag are discussed in Sections 3.1.1 and 4.1.2 of this memo. The remaining bits of the flags field are reserved for future use. They MUST be set to zero by clients and ignored by servers and relay agents.

1542

c

51

The chaddr field MUST be preserved as it was specified by the BOOTP client. A relay agent MUST NOT reverse the bit ordering of the chaddr field even if it happens to be relaying a BOOTREQUEST between two networks which use different bit orderings.

1542

c

52

The remaining bits of the flags field are reserved for future use. A client MUST set these bits to zero in all BOOTREQUEST messages it generates.

1542

c

53

A client MUST ignore these bits in all BOOTREPLY messages it receives.

1542

c

54

If the client does place a non-zero IP address in the ciaddr field, the client MUST be prepared to accept incoming unicast datagrams addressed to that IP address and also answer ARP requests for that IP address (if ARP is used on that network).

1542

c

55

A BOOTP client MUST set the giaddr field to zero (0.0.0.0) in all BOOTREQUEST messages it generates

1542

c.

56

A BOOTP client MUST NOT interpret the giaddr field of a BOOTREPLY message to be the IP address of an IP router.

1542

c

57

Any Internet host or router which provides BOOTP relay-agent capability MUST conform to the specifications in this memo.

1542

c

58

However, hosts or routers which support a BOOTP relay agent MUST accept for local delivery to the relay agent BOOTREQUEST messages whose IP source address is 0.0.0.0. BOOTREQUEST messages from legal IP source addresses MUST also be accepted.

1542

c

59

A relay agent MUST silently discard any received UDP messages whose UDP destination port number is BOOTPC (68).

1542

c

60

BOOTP messages not meeting these consistency checks MUST be silently discarded.

1542

c

61

Some configuration mechanism MUST exist to enable or disable the relaying of BOOTREQUEST messages. Relaying MUST be disabled by default.

1542

-

62

The relay agent MUST silently discard BOOTREQUEST messages whose hops field exceeds the value 16.

1542

c

63

If the relay agent does decide to relay the request, it MUST examine the giaddr ("gateway" IP address) field. If this field is zero, the relay agent MUST fill this field with the IP address of the interface on which the request was received.

1542

c

64

If the giaddr field contains some non-zero value, the giaddr field MUST NOT be modified. The relay agent MUST NOT, under any circumstances, fill the giaddr field with a broadcast address as is suggested in [1] (Section 8, sixth paragraph).

1542

c

65

The value of the hops field MUST be incremented.

1542

c

66

All other BOOTP fields MUST be preserved intact.

1542

c

67

At this point, the request is relayed to its new destination (or destinations). This destination MUST be configurable.

1542

c

68

However, if the BOOTREQUEST message was received as a broadcast, the relay agent MUST NOT rebroadcast the BOOTREQUEST on the physical interface from whence it came.

1542

c

69

A relay agent MUST use the same destination (or set of destinations) for all BOOTREQUEST messages it relays from a given client.

1542

c

70

If the BOOTREQUEST has a UDP checksum (i.e., the UDP checksum is non-zero), the checksum must be recalculated before transmitting the request.

1542

c

71

If the content of the giaddr field does not match one of the relay agent’s directly-connected logical interfaces, the BOOTREPLY message MUST be silently discarded.

1542

c

72

All BOOTP fields MUST be preserved intact. The relay agent MUST NOT modify any BOOTP field of the BOOTREPLY message when relaying it to the client.

1542

c

73

The reply MUST have its UDP destination port set to BOOTPC (68).

1542

c

74

If the BOOTREPLY has a UDP checksum (i.e., the UDP checksum is non-zero), the checksum must be recalculated before transmitting the reply.

1542

c

75

{DHCPINFORM} The client generates and records a random transaction identifier and inserts that identifier into the xid field. The client places its own network address in the ciaddr field.

2131

-

76

The TCP/IP software SHOULD accept and forward to the IP layer any IP packets delivered to the client’s hardware address before the IP address is configured

2131

c

77

As a consistency check, the allocating server SHOULD 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.

2131

-

78

When allocating a new address, servers SHOULD check 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.

2131

-

79

Servers SHOULD be implemented so that network administrators MAY choose to disable probes of newly allocated addresses.

2131

-

80

Any configuration parameters in the DHCPACK message 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.

2131

-

81

If the selected server is unable to satisfy the DHCPREQUEST message (e.g., the requested network address has been allocated), the server SHOULD respond with a DHCPNAK message.

2131

-

82

The server SHOULD mark an address offered to a client in a DHCPOFFER message as available if the server receives no DHCPREQUEST message from that client.

2131

-

83

The client SHOULD perform a final check on the parameters (e.g., ARP for allocated network address)

2131

x

84

The client SHOULD wait a minimum of ten seconds before restarting the configuration process to avoid excessive network traffic in case of looping.

2131

c

85

The client SHOULD notify the user that the initialization process has failed and is restarting.

2131

c

86

Servers SHOULD NOT check that the client’s network address is already in use.

2131

-

87

If the client’s request is invalid (e.g., the client 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.

2131

-

88

The servers SHOULD unicast the DHCPACK reply to the address given in the ciaddr field of the DHCPINFORM message.

2131

-

89

The server SHOULD check the network address in a DHCPINFORM message for consistency, but MUST NOT check for an existing lease.

2131

-

90

The client SHOULD include the maximum DHCP message size option to let the server know how large the server may make its DHCP messages.

2131

x

91

If a server receives a DHCPREQUEST message with an 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.

2131

-

92

A client SHOULD use DHCP to reacquire or verify its IP address and network parameters whenever the local network parameters may have changed;

2131

c

93

A client that cannot receive unicast IP datagrams 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.

2131

c

94

A client that can receive unicast IP datagrams before its protocol software has been configured SHOULD clear the BROADCAST bit to 0.

2131

c

95

The client implementation of DHCP SHOULD provide a mechanism for the user to select directly the vendor class identifier values.

2131

x

96

The client SHOULD wait a random time between one and ten seconds to desynchronize the use of DHCP at startup.

2131

-

97

The client SHOULD perform a check on the suggested 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.

2131

x

98

{DHCPINFORM} The client SHOULD NOT request lease time parameters.

2131

-

99

{DHCPINFORM} If the client does not receive a 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.

2131

-

100

{Server} Times T1 and T2 SHOULD be chosen with some random "fuzz" around a fixed value, to avoid synchronization of client reacquisition.

2131

-

101

The server SHOULD return T1 and T2, and their values SHOULD be adjusted from their original values to take account of the time remaining on the lease.

2131

-

102

In both RENEWING and REBINDING states, if the client 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.

2131

-

103

This memo specifies several cases where a BOOTP entity is to "silently discard" a received BOOTP message. This means that the entity is to discard the message without further processing, and that the entity will not send any ICMP error message as a result. However, for diagnosis of problems, the entity SHOULD provide the capability of logging the error, including the contents of the silently-discarded message, and SHOULD record the event in a statistics counter.

1542

x

104

The following consistency checks SHOULD be performed 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.

1542

c

105

The bit ordering used for link-level hardware addresses in the chaddr field SHOULD be the same as the ordering used for the ARP protocol [4] on the client’s link-level network (assuming ARP is defined for that network).

1542

c

106

If a client falls into this category, it SHOULD set (to 1) the newly-defined BROADCAST flag in the flags field of BOOTREPLY messages it generates.

1542

c

107

If a client does not have this limitation (i.e., it 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).

1542

c

108

The secs field of a BOOTREQUEST message SHOULD represent the elapsed time, in seconds, since the client sent its first BOOTREQUEST message. Note that this implies that the secs field of the first BOOTREQUEST message SHOULD be set to zero.

1542

-

109

Clients SHOULD NOT set the secs field to a value which is constant for all BOOTREQUEST messages.

1542

x

110

If a BOOTP client does not know what IP address it should be using, the client SHOULD set the ciaddr field to 0.0.0.0.

1542

c

111

The client SHOULD adopt the IP address specified in yiaddr and begin using it as soon as possible.

1542

c

112

A BOOTP client SHOULD completely ignore the contents of the giaddr field in BOOTREPLY messages.

1542

c

113

If a special vendor-specific magic cookie is not being used, a BOOTP client SHOULD use the dotted decimal value 99.130.83.99 as specified in [2]. In this case, if the client has no information to communicate to the server, the octet immediately following the magic cookie SHOULD be set to the "End" tag (255) and the remaining octets of the vend field SHOULD be set to zero.

1542

c

114

The consistency checks specified in Section 2.1 SHOULD be performed by the relay agent.

1542

c

115

{Hops} A configuration option SHOULD be provided to set this threshold to a smaller value if desired by the network manager. The default setting for a configurable threshold SHOULD be 4.

1542

-

116

If the interface has more than one IP address logically associated with it, the relay agent SHOULD choose one IP address associated with that interface and use it consistently for all BOOTP messages it relays.

1542

c

117

Further, this destination configuration SHOULD be independent of the destination configuration for any other so-called "broadcast forwarders" (e.g., for the UDP-based TFTP, DNS, Time, etc. protocols).

1542

c

118

The relay agent SHOULD examine the newly-defined BROADCAST flag (see Sections 2.2 and 3.1.1 for more information). If this flag is set to 1, the reply SHOULD be sent as an IP broadcast using the IP limited broadcast address 255.255.255.255 as the IP destination address and the link-layer broadcast address as the link-layer destination address. If the BROADCAST flag is cleared (0), the reply SHOULD be sent as an IP unicast to the IP address specified by the yiaddr field and the link-layer address specified in the chaddr field.

1542

c

119

{DHCPINFORM} The client may request specific configuration parameters by including the parameter request list option.

2131

c

120

The DHCPDISCOVER message MAY include options that suggest values for the network address and lease duration.

2131

-

121

The client may choose to wait for multiple responses

2131

-

122

A server MAY choose to mark addresses offered to clients in DHCPOFFER messages as unavailable.

2131

-

123

The client may suggest values for the network 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.

2131

-

124

The client may continue to use the previous network address until the lease for that address expires.

2131

c

125

A server with multiple network address (e.g., a multi-homed host) MAY use any of its network addresses in outgoing DHCP messages.

2131

-

126

Selecting a new xid for each retransmission is an implementation decision. A client may choose to reuse the same xid or select a new xid for each retransmitted message.

2131

-

127

The client MAY choose to explicitly provide the identifier through the client identifier option.

2131

-

128

The client MAY request specific parameters by including the parameter request list option.

2131

c

129

The client MAY suggest a network address and/or lease time by including the requested IP address and IP address lease time options.

2131

-

130

The client may request specific configuration parameters by including the parameter request list option.

2131

c

131

When the DHCP client knows the address of a DHCP 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.

2131

-

132

A client MAY choose to renew or extend its lease prior to T1. The server MAY choose to extend the client’s lease according to policy set by the network administrator.

2131

-

133

If the client has the ability to remember the last IP address it was assigned, or it has been preconfigured with an IP address via some alternate mechanism, the client MAY fill the ciaddr field with that IP address.

1542

-

134

When the BOOTP relay agent receives a BOOTREQUEST message, it MAY use the value of the secs (seconds since client began booting) field of the request as a factor in deciding whether to relay the request. If such a policy mechanism is implemented, its threshold SHOULD be configurable.

1542

-

135

When transmitting the request to its next destination, the relay agent may set the IP Time-To-Live field to either the default value for new datagrams originated by the relay agent, or to the TTL of the original BOOTREQUEST decremented by (at least) one.

1542

-

136

If unicasting is not possible, the reply MAY be sent as a broadcast, in which case it SHOULD be sent to the link-layer broadcast address using the IP limited broadcast address 255.255.255.255 as the IP destination address.

1542

c