[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ih] Origin of the loopback interface

On 22/10/2017 23:19, Paul Vixie wrote:
> Brian Carpenter wrote:
>>>  We could have another little chat about the loopback address in IP. I reached
>>>  the conclusion last night that it was never really necessary. All the TCP/IP
>>>  stacks that I know will happily send a message to any of their own assigned
>>>  addresses, without putting it on the wire. So having a dedicated address for
>>>  loopback tests seems useless today.
> it's nowhere near useless. 

I take your point. But parse my sentence: "for loopback *tests*". What you're
saying is that having an address that belongs to your own (virtual) machine
is beneficial for actual use, not just for tests. I agree with that.
It was the fact that it's conventionally assigned to a specific virtual
interface that caught my attention.

> i use a some virtual machines that aren't on 
> any network except their loopback. grateful am i that i can use IP 
> sockets to talk to my own services in that case, rather than having to 
> teach all my tooling, and the operating system's tools, to use UNIX 
> domain sockets.
> even when i have interfaces, they change their addresses, either due to 
> DHCP, or mobility, or migration. grateful am i, again, that most(*) of 
> my tools don't have to be able to reconnect their sockets when this 
> happens. i realize that INADDR_ANY was crafted to solve that problem, 
> but modern systems run different servers on the same port number, using 
> interface address to disambiguate.
> multihoming is one of the great unsolved problems in internetworking. we 
> do it properly on routers -- there, the loopback has the router's "real" 
> ip address -- but only because the router is on-path and can inject its 
> loopback address (which usually is not subnetted) into the topology.
> (*) name, file, and time servers have to know what interface they were 
> contacted on, and answer from that interface, so they have to 
> periodically rescan the interface list -- but nothing else does.

Actually the stuff we're developing in ANIMA needs to know exactly
which interfaces it's using too. That's one reason that I got
interested in this topic.