mjhjmtu

I can do this:

/sbin/ip addr add 172.17.0.12 dev eth0

This possibility conflicts with my (apparently overly simplistic and untrue) mental model of how assigning IP addresses work.

According this mental model:

• Computers do not assign IP addresses to themselves;


• Instead, computers are assigned IP addresses by servers managing the networks they connect to.


• This will mean routers for home PCs, ISP servers for these routers, and so on.

To me, the idea of assigning an IP address to oneself seems... senseless? So what if a computer declares "this is my IP address"? The point of IP addresses is so that routers may know where should a packet be forwarded to.

In the above example, when a computer assigns a private network address 172.17.0.12 to itself, this would only make sense if the router of that private network knew and agreed that this computer has this address. But in this case this will not be true! So can any packet ever come to eth0 to this computer?

While the other answer(s) outline why static IP addressing exists, I want to answer your part of the question as to how it works.

What you are missing here is the ARP. Imagine a 172.17.0.0/16 private network. One of your clients has "given itself" the static IP address 172.17.0.12. A second client 172.17.0.42 wants to communicate with 172.17.0.12. Following ARP, 172.17.0.42 sends a broadcast. It is effectively yelling all over the place "Who has the IP Address 172.17.0.12?". 172.17.0.12 answers and communication is established. Note that if there are two clients who claim to have the same IP address, chaos ensues.

An IP address can be assigned by a responsible device on the LAN, for example a Server or Router, using a called DHCP. (This is defined in RFC 2131 and extended in at least RFC 2132.)

A device can also self-configure its address and avoid the need for DHCP. The ip command you have demonstrated does exactly this.

Note that there are two main caveats in this scenario

1. If you choose an address that is already actively in use by another device you will conflict traffic to both devices (yours and the other one).


2. If you choose an address that is not part of the LAN subnet you will get no useful communication with any other device (for example, setting 192.168.1.1/24 on a network that expects 172.12.1.*/24).

Finally, you asked why a server should want to self-configure. The quick answer here is that the DHCP server itself needs to know its own IP address before it can start serving requests. Other possibilities are network routers, and central authentication servers (a Domain Controller in the Active Directory world of Windows, or an LDAP server in the UNIX/Linux world).

Assigning oneself an IP address makes it easier to know what IP that computer has. Routers will do this by DHCP or a reserved DHCP address based on mac address.

• Pure DHCP will assign any given unused address in a range of IP addresses this is not Ideal if you are running servers/services on a number of systems.




• DHCP reserved IP address will stay with any given mac address. This is ideal but it is cumbersome having to write down or have the target computer online to add it to the reserved lists. Plus if the router dies you have to do that all over again.




• Assigning your own IP address is great in that you can do so from the computer itself. It will stay with the computer if you move it within or to another network. The downside is that if your address is already taken the network interface won't go online until the address conflict is settled. However if you assign it an IP outside of the DHCP region and make a note not to assign other computers on the network that address and you will not have that problem.

Most network pre-routing traffic hits all interfaces and/or the interface with the IP that is in the header responds. So yes packets will get to the eth0 interface but whether or not it responds or will operate on that network is dependant on if the IP and subnet mask are correct also the duplex full or half setting and such. Most default settings are good enough for most home or unsophisticated networks.

Actually, all hosts on a network do claim their own IP address themselves. Always!

On the local network side a router has an IP address in a certain range (e.g.
192.168.9.x) and if a router receives a packet of bytes for, say, 192.168.9.12,
the router forwards it to its physical port that has the IP range
(192.168.9.0/24) configured that matches the destination address. On that port, it broadcasts on the local network: "Which host
claim IP address 192.168.9.12?". And any host that has its NIC configured to
have that specific IP address will answer, thus claiming the address. If all is
well, there is exactly only one host that claims it, and the router will send
the data packet to that host.

This broadcasting "who has IP address x.x.x.x" and claiming it by replying,
happens at a lower level and only works on a LAN (local network). This protocol
is called "ARP" (Address Resolution Protocol)

To put it in other words:

The address the router sends the data package to, on this lower level, is
actually the MAC address of the network interface card (NIC) of the host that
claims the IP address. It does so by replying to the ARP-request broadcast by the router.

So, it really is the host itself that decides what IP address it will
claim to have on a network.

On networks bigger than just a few hosts it will be a tedious task to keep
track of what IP address is to be used by what host. And then imagine editing a file on all computers allowed on the network to only tell it its IP address!

Also, if two (or more) hosts claim the same IP address, both will have a
serious network problem! That is why it is very practical to have a central
service on the local network that keeps track of which MAC address can use
which IP address. This is called "DHCP" (Dynamic Host Configuration Protocol), which can also be used to inform hosts
of many other configuration parameters on the local network.

The DHCP protocol also operates on the same lower level as the ARP protocol. When a hosts
configures its NIC's (Network Interface Card), most often at boot time, it
broadcasts "Which IP address can I use on this network?". This is done by DHCP
client software. Since it's a broadcast, all hosts receive it, but only a DHCP
server will answer, hopefully mentioning a unique IP address, its netmask, the
gateway (router) address and possibly other things. The host keeps this in
memory knowing it can safely claim this IP address on the network for some time.

But this only works because the hosts cooperate by asking a DHCP-server for an IP address to use. Ultimately it is always the hosts who decide what IP address they'll claim....