Is it possible for a device to request to be assigned a specific ip from the DHCP server (static or dynamic) [duplicate]

Networking beginner, but my experience is in web and mobile app development for 10+ years, so I'm not at all new to technology.

I recently started working on a new team with some dev-ops engineers and they are very familiar with networking, systems, services, automation, and provisioning. In an effort to inexpensively learn more I got 4 raspberry pis and an unmanaged switch.

I'm starting with basic networking and linux administration on my path to learn more about the peripheral and platform technologies that support the applications that I build.

I want my Raspberry Pis to be assigned static IPs from my modem/router/wifi-access-point device (Motorola Surfboard G6580), anytime any Raspberry Pi connects. Is it possible to have the Raspberry Pi (or any other device for that matter) request a specific static IP from the DHCP server?

The modem has a 192.168.0.1 web address that will allow me to manage the dhcp assignment of static ips based on mac addresses. However, I am curious to know if this is possible to automate with a request from the raspberry pi itself.

Static IPs

I want my Raspberry Pis to be assigned static IPs

With my terminology, those are not "static". A device chooses its own "static IP" address.

But, based on the question, I can tell what you're looking for: a dynamic address, which the server has reserved.

If the Raspberry Pi doesn't even bother asking the DHCP server, then it is static (and the DHCP server can still be reserving the address). If the address is coming "from" the DHCP server, as you specified, then Raspberry Pi does ask the DHCP server from the address, so it is "dynamic" (in the sense that the Raspberry Pi is accepting whatever the server specifies, and so if the DHCP server did change the address then the Raspberry Pi would presumably accept the change. So, from the Raspberry Pi's perspective, it is dynamic, even if the DHCP server refers to it as a Reserved dynamic address.

Is it possible to have the Raspberry Pi (or any other device for that matter) request a specific static IP from the DHCP server?

No, because if the address is being requested, then it isn't static. (It could make a request and get a Reserved address.)

The modem has a 192.168.0.1 web address that will allow me to manage the dhcp assignment of static ips based on mac addresses.

Those are reserved addresses, not static.

I'm sorry to harp on this point so many times, but the question did use the phrase "static" in a way that I'm not agreeing with, so I'm hoping to get a habit corrected nice and early. Networking can be plenty confusing even when terminology is used in correct ways, so I encourage you to use the term "static IP" to not refer to addresses received from an automatic address assignment protocol like DHCP. (Although DHCP is the most prevalent with IPv4, it is not the only possible option. For instance, there is "Router Advertisements", which is probably more widely used with IPv6 than IPv4, just because DHCP was so, so, so widely supported in IPv4 and experience shows it works okay).

Requesting an IP

Is it possible for a device to request to be assigned a specific ip from the DHCP server (static or dynamic)

Yes. The DHCP protocol allows this. It would not be static, but "reserved".

If you look at the DHCP communications, DHCP follows a DORA approach. DORA stands for DISCOVER, OFFER, REQUEST, ACKNOWLEDGE.

In a simple transaction, the sequence can be as simple as DORA. (That means there is one DISCOVER, one OFFER, one REQUEST, and one ACKNOWLEDGE.) A DHCP client can request whatever address it wants. This can often be done if a client leaves a network, and then returns, and favors an address that was previously used. If a DHCP client requests an address that isn't acceptable, that can lead to some longer communications, like a DORORA. Following is a summary of such communications.

First, a few notes:

• Bold letters describing one of the DORA steps represent a communication that is actually sent.
• Bold letters are also used to help identify machines.
• In the following examples, the 192.0.2 subnet was used in accordance with RFC 5737
• the following addresses were literal:
  • 0.0.0.0
  • 255.255.255.255
  • FF-FF-FF-FF-FF-FF
• The following were more sample addresses, and would be customized:
  • 11-11-11-22-22-22
  • and 33-33-33-44-44-44

And now, the promised summary of communications:

• [Client]: "I have no IP address. I want that to change."
• [Client] uses IP address 0.0.0.0, MAC 11-11-11-22-22-22, and sends to 255.255.255.255, FF-FF-FF-FF-FF-FF: and sends a DISCOVER message. (Hey! Any DHCP servers out there?)
• Optional step: [DHCP Relay Agent] communicates to [DHCP server], which might be on another subnet. To simplify, we won't get into the details of the communications between the [DHCP Relay Agent] and the [DHCP Server]. Note that a [DHCP Client] does not need to notice any difference between a [DHCP Server] or a [DHCP Relay Agent]. (Offhand, I'm not remembering if it is even possible for a [DHCP Client] to make such a distinction.)
• [DHCP Server or Relay Agent], on the same subnet, responds from IP address 192.0.2.1 MAC-48 address 33-33-33-44-44-44, to 0.0.0.0 MAC-48 address 11-11-11-22-22-22: OFFER 192.0.2.140. (What this OFFER means is that [Server or Relay Agent] could let client reserve 192.0.2.140, if desired.)
  • If multiple [DHCP Clients] communicate at the same time, that is okay, even though they may share an IP address like 0.0.0.0, because the individual MAC-48 addresses can be used to keep track of the individual conversations.
• [DHCP Client] ignores that offered 192.0.2.140 address, because [Client] would prefer 192.0.2.135 address that Client had yesterday. So, client is allowed to completely ignore the address that was provided by the OFFER, and just request whatever it wants to. (This is about to be demonstrated by the next communication.)
  • This represents the "leverage" that the client has. It is not absolute power, but may be influential if the [DHCP Server] would just kindly cooperate.
  • (In real-world use, this might be somewhat common for laptops that wake up from a hibernation?)
• [DCHP Client] to [DHCP Server or Relay Agent], on the same subnet, from 0.0.0.0 MAC-48 11-11-11-22-22-22, and sends to 192.0.2.1 address 33-33-33-44-44-44: REQUEST for desirable 192.0.2.135
  • At this point, the Client sent its REQUEST and hopes to get an ACKNOWLEDGE.
• [DHCP Server] realizes that 192.0.2.135 is no longer available.
• [DHCP Server or Relay Agent], from 192.0.2.1 address 33-33-33-44-44-44, to 0.0.0.0 MAC-48 11-11-11-22-22-22: OFFER 192.0.2.140
• [DHCP Client] gets disappointed that the OFFER did not match the REQUEST. The client, disappointed that it didn't get a desirable offer, falls back to trying something that is more likely to be accepted by this somewhat-uncooperative server.
• [DHCP Client], from 0.0.0.0 MAC-48 11-11-11-22-22-22, to 192.0.2.1 address 33-33-33-44-44-44, REQUEST 192.0.2.140
• [DHCP Server or Relay Agent] decides to cooperate. It does two things:
  • [DHCP Server] Makes note of a lease, so that it won't hand out the same address again.
    • The address is now officially unavailable for anyone else. Presumably the client will be happy with this address, because it was requested. The client does not need to specify any further agreement
  • [DHCP Server or Relay Agent], from 192.0.2.1 MAC-48 33-33-33-44-44-44, to MAC-48 11-11-11-22-22-22, notes that it has decided to ACKNOWLEDGE (and, thereby, approve) the 192.0.2.140 request.

A DHCP client is only allowed to start using an offered address after that client receives the ACKNOWLEDGE. (In fact, a DHCP server is allowed to OFFER an address to multiple computers, and that should cause no conflict because those addresses should remain unused until an actual ACKNOWLDGE is provided.) So, in this sense, the DHCP client doesn't get any absolute permission until it gets an ACKNOWLEDGE response, but it can still have some influential power by deciding what it wants to REQUEST.

If a server doesn't want to cooperate with a REQUEST, all it has to do is not ACKNOWLEDGE. It can be polite by choosing to OFFER something else, or could just ignore the inappropriate REQUEST, all without running any risk of authorizing use of an unwanted IP address. When the DHCP server receives a REQUEST, the DHCP server can decide to look at the requesting MAC-48 address and use that information when deciding what it wants to OFFER. That is how the server can effectively restrict the OFFERed address to only use what is shown in a DHCP Reservation.

So, yes, a REQUEST can ask for any specific IP address it desires. If the DHCP client doesn't know what IP address is likely to be safe for a REQUEST, the DHCP client can look at the last OFFER, or send out a DISCOVER package and look for a new OFFER.

Finally,

I am curious to know if this is possible to automate with a request from the raspberry pi itself.

If using Unix, check for a /etc/dhclient.conf file. I know that such a file can be used to specify which DHCP options are used. (Examples of the most common "DHCP options" are the subnet's size ("subnet mask"), router's address ("default gateway"), but other information can also be shared by the DHCP server, and used (or ignored) by the DHCP client. I would suspect that file may be where you can specify a desired address. It looks like the desired line may be: "send dhcp-requested-address 192.0.2.135;" (See: ISC dhclient.conf man page, and ISC man page for dhcp-options, and Self-answered question: How to request a specific IP address from DHCP server?)