[ih] Origin of the loopback interface

[Toerless Eckert]

On Mon, Oct 23, 2017 at 12:42:29PM -0700, Joe Touch wrote:
> The fundamental problem is that ip networking doesn???t see far enough into the os to be sufficient as the sole IPC mechanism. There arren???t enough demuxing identifiers. 
> 
> It would preclude having a multiprocess stack too. You can???t coordinate components to process Ip using ip. 

Routing based on ever longer prefixes could IMHO equally be expanded inside of
nodes to create more hierarchy as needed.

> The problem with loop back is the assumption of locality, which is false without additional filters. Ipc typicallly defaults to local only until extended, which naps better to expectations.

I think there is only an assumption of locality on loopback addresses,
not interfaces. Which can be broken of course, but so can locality
expectations of other mechanisms. Unless one would even start to
define the exact behacvior of specific interfaces, yo could never make
an assumption of behavior using some type of interface (across different
implementations).

Toerless

> Jie
> 
> > On Oct 23, 2017, at 11:47 AM, Toerless Eckert <tte at cs.fau.de> wrote:
> > 
> >> On Mon, Oct 23, 2017 at 11:17:52AM -0700, Joe Touch wrote:
> >> 
> >> 
> >>> On Oct 23, 2017, at 10:30 AM, Toerless Eckert <tte at cs.fau.de> wrote:
> >>> 
> >>> n Mon, Oct 23, 2017 at 07:26:28AM -0700, Joe Touch wrote:
> >>>> Loopback should not be a substitute for IPC. At least one additional reason is that packets sent there might not end up where you think (they could be tunneled elsewhere, e.g..).
> >>> 
> >>> [ Btw: I could also tunnel any non-IP form of IPC if i have access to the OS.
> >>> ]
> >> 
> >> You can but why would you? Ipc should be more efficient and necessary anyway  
> > 
> > You said that loopback IP traffic would not stay local to a node. You did not
> > say wether that would be an attack or a feature. I just said i could do the
> > same thing with any other IPC, eg: security and performance IMHO are
> > not arguments to decide between IP and other IPC.
> > 
> > I do not see a need for non-IP based IPC. Ultimately, whenever i want highest
> > performance, i am primarily talking about APIs atypical to classical TCP/IP
> > stacks (aka: beyond message passing APIs. Like RDMA APIs. Ylu just want to
> > make sure your API uses IP addressing of entities, and e voila, you can now
> > provide optimized local and remote implementations in the stacks without apps
> > having to bother learning two separate mechanisms. E.g.: RoCEv2. If you
> > want to constrain the scope of communications, you just use the right
> > addressing.
> > 
> > Cheers
> >    Toerless
> > 
> >> Joe
> >> 
> >>> 
> >>> Cheers
> >>>   Teorless
> > 
> > -- 
> > ---
> > tte at cs.fau.de

-- 
---
tte at cs.fau.de