[ih] Origin of the loopback interface

[Toerless Eckert]

On Mon, Oct 23, 2017 at 02:20:28PM -0700, Paul Vixie wrote:
> [description of how to have every endpoint participate in IGP]
I must be missing one mail in the thread...

> >And thats just the tip of the iceberg.
> 
> since that was the straightforward way to do things when hosts got
> smarter and addresses were sprouting everywhere, i did it. the
> number of moving parts was high, and their state combinations and
> state transition ordering permutations were extreme, and debugging
> was hell, and i eventually had to say, it can't work with today's
> technology.
> 
> and that was before we learned about ARP spoofing. and before three
> decades of christmas tree packets and buffer overruns. so, i've
> revised my earlier "not with today's technology" assessment to "not
> ever."

Node-address based routing is becoming more and more popular in IOT
networks where each device ultimately is also a router with e.g. RPL
(or othrer lightweight state routing ptotocols).

Its also difficult to come to conclusions just looking at what can
be hacked together today. I'd rather look at whats the best that
could be built with host routes and then make a judgement call.

For example you definitely do not want hosts to participate
in an LSP but rather have some form of ES-IS and of course that needs
to be secured (unlike ARP). Etc. pp. 

Of course, user-created state in networks introduces another level of
architectural concerns, and Internet unicast routing didn't bother to design
for it.  But a lot of other areas did & do: Middleboxes, IP multicast,
Mobile networking - just to name a few. So it definitely can be done
at a good amount of scale and dynamics.

> i saw DEC AutoNet-II work at the Systems Research Center in 1990 or
> so and it was a thing of terrible power and beauty. i want a network
> that works like that. but, outside of the lab, and outside of
> hollywood, i aver that it cannot be done with multiple vendors, and
> should not be tried. forget about speed -- state is what kills.

Locator Identifier Separation mechanisms is of course one long understood mechanism
to layer the user created addressing so that you can keep an unmodified
underlay, but IMHo thats just a stopgap (which in Internet terms means
few decades ;-).

But except for the >>100Gbps/link underlay, we are also returning
back to the roots of getting single resource based forwarding & control
(X.86 / fd.io, DPDK, etc.pp). There has not been a lot of exploration
IMHO to best leverage that - data plane driven control & state. The big
no-no in the last 20 years design box: Very fast forwarding plane with
lots of state limits, bottleneck IPC to control plane, underpowered control
plane CPU.

Cheers
    Toerless
> 
> ---
> 
> Toerless Eckert wrote:
> > On Mon, Oct 23, 2017 at 12:42:29PM -0700, Joe Touch wrote:
> >> 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).
> 
> the internet is at its best an ad-hoc set of cooperative guidelines,
> and for all ad-hoc purposes for the last two decades, my template
> for every endpoint's host based firewall includes the following
> rules:
> 
> >add     pass    all     from any to any via lo0
> >add     deny    all     from any to { ::1 or 127.0.0.0/8 }
> >add     deny    all     from { ::1 or 127.0.0.0/8 } to any
> 
> i and many others have built mighty edifices upon the assumption of
> locality on the loopback interface. we merely ensure it as one of
> the requirements every endpoint must meet.
> 
> ---
> 
> noting, elsewhere in this thread, someone said high performance like
> RVM API would be hard with IP even via a loopback. sun microsystems
> and cmu mach both had page flipping for page aligned data, largely
> because we all got tired of having to special case the local data
> path through "doors" or shared memory or "unix domain sockets". so,
> it can be hacked.
> 
> i think XNS was clearly superior to IP. but then, betamax was
> clearly superior to VHS, and look where that superiority got them.
> my short time programming device drivers for an AMD-based multibus
> board at ungermann bass to make sunos properly speak to XNS was
> maybe the most fun i'd ever had up until that day. but: the market
> has its own path.
> 
> -- 
> P Vixie

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