Do IP addresses belong to the interface or to the system?
 

The subject has the big question. I've read answers both ways. The kernel has documentation that says the IP addresses belong to the system. Yet the configuration works as though they belong to the interface.

Shouldn't we have it just one way and stick with it ... and make everything work that way?

If IP addresses truly belong to the system, then a command to configure an IP address should not need (and not even accept) the name of an interface. The only exceptions would be link-local addresses (which by their nature do suggest being interface specific ... and they should be autoconfigured by the kernel, anyway). Interfaces would only need to be brought up or down.

If I have understood what you are asking, I think the way to think about this is as follows:

• if you have a box with several interfaces, could you be concerned about which interface has which address?

I think that the answer to that question is yes, so you want the interface to have a particular address, rather than just say 'the box has 192.168.0.1 and 10.0.0.1 and I don't care which is which' and you'll particularly feel that if one is an wlan and another is a eth, or one is 10 or 100 times faster than another.

If you have only one interface, you might think that this is a rather hypothetical discussion, and not much care. My theory is that because of this, people get a bit sloppy about using the terminology correctly.

Short answer: The addresses belong to the local network.

Simple example: You are connected to a router. It can be set for a fixed IP on each connection, or it can be set for DHCP. Either way, the IP is dictated by the router.

IP addresses are assigned to interfaces only. The only IP address all systems will have is 127.0.0.1 but that belongs to the 'lo' *interface*.
Additionally, any interface can have multiple IP addresses. Also, you can have multiple interface aliases bound to one physical interface as well. Like "eth0:1".

If some tells you that IP addresses belong to system get their IP address and sue them :)

Cheers!

Have a look at ${kernelsourcetree}/Documentation/networking/ip-sysctl.txt and scroll down to around line 755, and/or search for the string "arp_filter" or "IP addresses are owned by". Read the description for the default behaviour of the "arp_filter" setting.

What I am finding is the actual behaviour is somewhere between these two.

The situation I'm running into is that in many cases a particular interface won't work for some packets (even though it is UP and RUNNING and can send and receive packets) for as-yet unknown reasons. I'd like some way to make it NOT send ARPs in these cases. I want it to only send ARP on the interface that will work, even though both interfaces get the ARP request. But I think this really needs to determine why things are not working, first. Unfortunately all the machines I have spare that I can do testing on only have one ethernet interface. So I'm limited on the testing I can sneak in on machines I'm trying to roll into production (which have 2 ethernet interfaces, with currently only one being configured UP due to these entangled issues).

....assigned to the interfaces by the local network. Going back to my simple router example, the router controls what IP is used for each machine. (How could it be otherwise?)

I'm having trouble relating this to the fundamental question of who owns the IP addresses that exist at each interface.

But what controls which interface that ARP queries for that IP may be answered on? And what if the route table specifies both interface devices (same gateway IP)?

I might have too simplistic a view of what the question is----Perhaps you could describe a physical configuration---eg "3 computers connected to a router using dhcp".....and then a specific scenario---eg "computer A requests/does something, and computer B responds"

It seems the way Linux is documented to behave, it should be possible to simply assign an IP address to the system, instead of an interface (without necessarily removing the capability to assign to an interface). With that, then an ARP arriving on any interface asking for that IP address should be answered. But shouldn't the DEFAULT be that if you assign an IP address to just ONE interface, then ARPs for that IP should only be answered on THAT interface? Well, that might be a more philosophical issue. I am currently trying to wrap MY head around the "inconsistent" (to me) notion that it can be both ways ... that the IP address can be owned by the system, while the only means of configuring them is specific to an interface. One exception might be the "lo" interface. You can assign more IP addresses to it. But it works even less consistently.

Same behaviour exists with IPv6.

I always thought the answer was the tcp/ip stack (layer 3) on the device concerned be it router or host. IP addresses being pure logical things and all that. That's 'who' and 'where' it belongs to.

How about the question in post #9?

I've always seen ip as an 'agreement' between devices to communicate, not as devA owns comm channel-1, and devB slaves to devA.. It's analogous to radio: a station broadcasts on a frequency, and the listener tunes into that frequency to quantify anything relevant - same w/ o/s vs interfase. the ARP is simply the signal In the frequency, and the interface must understand or pass it off to what can make sense of it. if one interface can interpret or transduce the signal, then its guts & firmware are wired for it, but the OS still has to manage what it means..

I believe that ip isn't owned by either, just like a radio signal isn't owned by its translating hardware. I'm sure there could be a software solution for what you've exampled to do for the ARP routing, per conditional handling, even if it's not yet specifically written. Just think of the interface as a transducer..

plz express if there's fault with this view.

Go back to my simple router example. The computers on the local network have to comply with the settings of the router. I don't think there is any ambiguity in this.