Does dhcpcd prevent a remote DHCP server serving an IP address that is declared static?

Question

Dhcpcd is a DHCP client and asks a remote DHCP server for an IP address. The DHCP server selects one free IP address from its pool and gives it to the client.

Now in /etc/dhcpcd.conf of the client I can declare for example:

static ip_address=192.168.0.10/24

man dhcpcd.conf says:

Configures a static value. If you set ip_address then dhcpcd will not attempt to obtain a lease and just use the value for the address with an infinite lease time.

For my understanding "will not attempt to obtain a lease" means the DHCP server will never get a request for an IP address from this client which means 192.168.0.10 is free and could go to another client. That will break communication for two clients.

Is that true? Do I have to select a static IP address outside of the range the DHCP server has reserved for serving? Or does dhcpcd tell the remote DHCP server not to serve locally defined static IP addresses?

I ask it here because dhcpcd is the default setup on Raspbian and because there are already two questions that may fight with this problem ^{(1), (2)}.

references:
[1] Web access, Static IP outside of DHCP
[2] setting up a static ip address using wifi but cannot access internet

Answer 1

From RFC2131:

DHCP supports three mechanisms for IP address allocation. In "automatic allocation", DHCP assigns a permanent IP address to a client. In "dynamic allocation", DHCP assigns an IP address to a client for a limited period of time (or until the client explicitly relinquishes the address). In "manual allocation", a client's IP address is assigned by the network administrator, and DHCP is used simply to convey the assigned address to the client. A particular network will use one or more of these mechanisms, depending on the policies of the network administrator.

Assuming your interpretation of the quoted passage from man dhcpcd is correct (and it certainly sounds like the correct interpretation to me), this means that the client never initiates the DHCP sequence, and so the DHCP server would (or certainly could) remain ignorant of that (static) IP address assignment. If the DHCP server has no knowledge that a particular IP address in its "pool" has been used, then it could allocate it to another client. And so, I believe the answer to your first question is, "Yes, it's true."

BEGIN EDIT:

Note that in the case you have asked about (absence of the DHCP sequence-initiating broadcast by the client) the DHCP server may remain ignorant of an address conflict despite the ping-check facility used in some servers. This can happen under several scenarios:

1. the host with the static-configured IP address is offline when the ping-check is issued by the DHCP server, then subsequently re-started,

2. network or client latencies preclude a response from the static-configured host within the (default) 1 second time limit,

3. the static-configured client host is configured not to respond to a ping (e.g. using iptables for security reasons)

4. ping-check is not implemented in the DHCP server that's being used (as in older "router appliances" sold or distributed by vendors and ISPs)

5. ping-check was disabled by the network administrator, or simply failed due to a "bug" (for example)

Again, the answer to your question is, "Yes"; a static-assigned IP address that is in the DHCP server's address pool could be assigned to another client and break communications. The answer is "Yes" even if the DHCP server has the ping-check facility available to it, and the answer is "Yes" again in some cases (ref above), even when ping-check is actively employed.

Hopefully, it is now clear that ping-check is not a panacea for IP address conflicts, and that they can occur in spite of it.

END EDIT:

And so, under these conditions, it is the responsibility of the client to ensure that its IP address is not included in the "pool" of IP addresses used by DHCP server.

Note also the final sentence in the above excerpt from RFC 2131 that there are three mechanisms available to a DHCP server in general. Also note that either the "manual allocation" or "automatic allocation" mechanisms would seem to provide a method appropriate to the question you've referenced. But that will only work IF the network admin has configured the server to use that (manual/automatic allocation) mechanism, AND the client uses DHCP.

Answer 2

For my understanding "will not attempt to obtain a lease" means the DHCP server will never get a request for an ip address from this client so it means 192.168.0.10 is free and will give it to another client.

Setting a static IP is not a matter of just configuring the machine you would like to have that IP. Otherwise, what would happen when multiple people walk into a WLAN with a device set to use 192.168.0.10? First come first served?

What if the owner of the WLAN wants his or her devices to take precedence? In that case, the router must either reserve the IP, or take it away from whomever when the owner wants it, which means it is not really a static IP for anyone else -- it may change just like a dynamically assigned one.

In fact it is the router which grants this privilege by reserving the address. When you use a static IP, you must configure the client device and the router. If you don't, on a small LAN it may still work, however, you may have mysterious problems (such as being invisible to other devices on the LAN).

Your router should have a configuration page for reserving IP addresses fo specific MACs. However, not all ISP provided routers have this functionality (I presume they do this to prevent people from having problems because they do not understand properly how to configure and use certain features).

I don't know the details of the DHCP protocol here (pretty sure it is involved); in any case you should investigate this further on Super User or ServerFault.

Answer 3

The static IP configuration for dhcpcd is often used as a fallback setting so that a system is always guaranteed of having an IP address to connect to. As you correctly guessed, static settings do not check to see if they would interfere with the network (although you can check for duplicate addresses using ARP. Windows does this by default.) Thus, you'd want static IP addresses to be outside of the DHCP server pool range to avoid this. Remember that statically-configured IP addresses will not receive any DHCP information, so you need to also set the addresses for DNS, NTP, etc.

Sometimes, however, you may need a system to be in the server pool range: For example, I have a system at home that originally was just another computer but now hosts a service. Rather than reconfigure the system, I made a reservation on the DHCP server (this is the "manual allocation" DHCP mechanism that Seamus referred to) so that whenever that system asks for an address, it always receives the same one; it's also been essentially removed from the pool of addresses. You also get the advantages of DHCP, such as receiving DNS addresses and other configuration details.