[ih] Origin of the loopback interface

[Brian E Carpenter]

Hi,

Over on ***@ietf.org we're discussing the issue of how to assign an address to a node without assigning it to a specific physical or tunnel interface. This is a minor gap in the IPv6 addressing architecture spec, but it creates a terminology issue in various other places.

The thread started with the following message, and has got surprisingly long:
https://mailarchive.ietf.org/arch/msg/ipv6/U0QzAWpZTypF8gyZZ8HPfXZLOPM

So the question came up of when and where the term 'loopback interface' arose. Does anybody here have an answer for that?

Regards
Brian Carpenter

[Jeremy C. Reed]

On Sat, 21 Oct 2017, Brian E Carpenter wrote:

> So the question came up of when and where the term 'loopback
> interface' arose. Does anybody here have an answer for that?

In my BSD history research, the earliest reference (for BSD) I have is:

BBN had successful tests with establishing connections and transmitting
data between processes using the loopback
mode.\cite{{bressler-bbn-198102}

% http://www.dtic.mil/dtic/tr/fulltext/u2/a096114.pdf
% R. D. Bressler
% for nov 1, 1980 to jan 31, 1981
% date stamped March 9, 1981
@BOOK{bressler-bbn-198102,
editor = "Robert D. Bressler",
title = "{Combined Quarterly Technical Report No. 20}",
publisher = "Bolt, Beranek, and Newman Inc.",
address = "Cambridge, Mass.",
year = 1981,
month = feb
}

Document page 82, PDF page 89
Now looking at it again I see that term used multiple times. I now
see earlier references for loopback for IMP and 1822 interfaces and in
early BBN reports but this is not about the "internet" interface as far
as I can tell.

The ARPANET Interface Message Processor (IMP) Port Expander (PE)
Technical Report 1080-140-1
November, 1980
http://www.dtic.mil/dtic/tr/fulltext/u2/a155753.pdf
recreated at
http://www.warthman.com/images/SRI%20ARPANET-IMP.book.pdf
talks about loopback mode.
(Also at same time it is mentioned in BBN Report No. 4526.)

The oldest Unix code reference I find is University of Illinois 'Network
Unix' ncpk/drivers/net_ill.h
/* defines for accessing bits in the imp interface */
...
#define imloop 0000400 /* loop back */

but I don't see anything using it. I don't know date of that but the
system was from 1974-1975 and the file stamp is May 17 1979. This code
is not about internet loopback though.

As for the earliest Unix "internet" style loopback interface I find
4.1c.1 BSD's /sys/netinet/if_loop.c. Maybe from Joy or Eric Cooper (even
if Joy committed it).

D 4.1 81/11/29 22:18:03 wnj 1 0 00059/00000/00000
MRs:
COMMENTS:
date and time created 81/11/29 22:18:03 by wnj

4.1 /* if_loop.c 4.1 81/11/29 */
4.1
4.1 /*
4.1 * Loopback interface driver for protocol testing and timing.

This was after the initial BBN code being added to CSRG's SCCS and I
don't see reference to it earlier in that code so I assume was not in
the BBN deliverables. I think the BBN reference in regards to the VAX
UNIX is using a loopback mode not in the Unix networking implementation
itself, so may be the earliest implementation of internet driver for
loopback interface. (It was originally hardcoded to be on 254 network,
but on Dec 22, 1981 changed to be 127 (hardcoded). In March 1982,
converted to use sockets and AF_INET. In May 1983, changed from
127.0.0.0 (broadcast) to 127.0.0.1. The hardcoded address was removed in
March 1985. This is the same code that ended up in the "greatest
software ever written" :)

Jeremy C. Reed

echo Fybjyl jevgvat zl OFQ uvfgbel obbx. Cyrnfr xrrc nfxvat zr. | \
tr "OQCFnortuvxyzabcefgjl" "BDPSabeghiklmnoprstwy"

[Jack Haverty]

IIRC, loopback was a term used in modems at least as early as the late
60s. Maybe before. When a line was put "in loopback" all the data
going out onto the line was reflected directly back to the sender.

Looping was used as a primary operations tool in the ARPANET. By
"looping a line" the NOC operator could determine what was likely to
have failed - the modem at either end, the line itself (backhoe attack),
or the interface card in the IMPs at either end of the line. The IMPs
could trigger the "looping" capability of the modems to cause loops to
be established at the various points. That was important to determine
whose Field Service to call to get a failure fixed.

When we implemented TCPs at BBN for various hardware choices, we
unabashedly adopted ideas and techniques from the ARPANET operational
experience. So the notion of having a means to "loop" the network
interface was a natural feature to include. The TCP spec itself didn't
contain such "fault isolation" tools, so things like ICMP echo were
defined to add such functionality in ICMP.

I wrote the first TCP (version 2) for Unix circa 1977-8 on a PDP-11/40.
It did not have a "loopback interface". There simply wasn't room in
kernel memory for such niceties. That Unix implementation was based on
Jim Mathis' earlier implementation for the LSI-11 and used in the Packet
Radio project. It didn't have a loopback facility either.

Shortly thereafter, several other Unix TCP implementations were done: a
PDP-11/70 version (Wingfield/Nemeth) under DCEC sponsorship, an HP-3000
implementation (Sax/Edmond) under ARPA sponsorship, and a Vax
implementation (Gurwitz) under ARPA sponsorship. Getting an
implementation to talk to itself by cobbling together some way to get
packets reflected back was a common early step in the test/debug of a
TCP implementation.

One of those Unix implementations may have introduced loopback
functionality. I can't remember... There is a lot of historical detail
at The Unix History Society (tuhs.org), including ancient listings,
which may be a good place to look.

So, the specific term "loopback interface" probably depends on the
context. It may have been first used in Unix, but the concept of
"looping an interface" was much older. It existed in modems, and in the
ARPANET, and in the Internet, and was used primarily for debugging and
fault isolation during operations. When something works, you just keep
using it.....

I probably wrote that BBN QTR (or more accurately, badgered people into
writing their sections and then put it all together). Bob (Bressler)
was officially the PI on the contracts, but he assigned all of the
Internet-related projects to me. Eventually we changed the name so I
was author of later QTRs. So if there's any other questions about BBN's
Internet work in that timeframe I might be able to answer.

HTH,
/Jack Haverty

On 10/20/2017 05:12 PM, Jeremy C. Reed wrote:
> On Sat, 21 Oct 2017, Brian E Carpenter wrote:
>
>> So the question came up of when and where the term 'loopback
>> interface' arose. Does anybody here have an answer for that?
>
> In my BSD history research, the earliest reference (for BSD) I have is:
>
> BBN had successful tests with establishing connections and transmitting
> data between processes using the loopback
> mode.\cite{{bressler-bbn-198102}
>
> % http://www.dtic.mil/dtic/tr/fulltext/u2/a096114.pdf
> % R. D. Bressler
> % for nov 1, 1980 to jan 31, 1981
> % date stamped March 9, 1981
> @BOOK{bressler-bbn-198102,
> editor = "Robert D. Bressler",
> title = "{Combined Quarterly Technical Report No. 20}",
> publisher = "Bolt, Beranek, and Newman Inc.",
> address = "Cambridge, Mass.",
> year = 1981,
> month = feb
> }
>
> Document page 82, PDF page 89
> Now looking at it again I see that term used multiple times. I now
> see earlier references for loopback for IMP and 1822 interfaces and in
> early BBN reports but this is not about the "internet" interface as far
> as I can tell.
>
> The ARPANET Interface Message Processor (IMP) Port Expander (PE)
> Technical Report 1080-140-1
> November, 1980
> http://www.dtic.mil/dtic/tr/fulltext/u2/a155753.pdf
> recreated at
> http://www.warthman.com/images/SRI%20ARPANET-IMP.book.pdf
> talks about loopback mode.
> (Also at same time it is mentioned in BBN Report No. 4526.)
>
> The oldest Unix code reference I find is University of Illinois 'Network
> Unix' ncpk/drivers/net_ill.h
> /* defines for accessing bits in the imp interface */
> ...
> #define imloop 0000400 /* loop back */
>
> but I don't see anything using it. I don't know date of that but the
> system was from 1974-1975 and the file stamp is May 17 1979. This code
> is not about internet loopback though.
>
> As for the earliest Unix "internet" style loopback interface I find
> 4.1c.1 BSD's /sys/netinet/if_loop.c. Maybe from Joy or Eric Cooper (even
> if Joy committed it).
>
> D 4.1 81/11/29 22:18:03 wnj 1 0 00059/00000/00000
> MRs:
> COMMENTS:
> date and time created 81/11/29 22:18:03 by wnj
>
> 4.1 /* if_loop.c 4.1 81/11/29 */
> 4.1
> 4.1 /*
> 4.1 * Loopback interface driver for protocol testing and timing.
>
> This was after the initial BBN code being added to CSRG's SCCS and I
> don't see reference to it earlier in that code so I assume was not in
> the BBN deliverables. I think the BBN reference in regards to the VAX
> UNIX is using a loopback mode not in the Unix networking implementation
> itself, so may be the earliest implementation of internet driver for
> loopback interface. (It was originally hardcoded to be on 254 network,
> but on Dec 22, 1981 changed to be 127 (hardcoded). In March 1982,
> converted to use sockets and AF_INET. In May 1983, changed from
> 127.0.0.0 (broadcast) to 127.0.0.1. The hardcoded address was removed in
> March 1985. This is the same code that ended up in the "greatest
> software ever written" :)
>
> Jeremy C. Reed
>
> echo Fybjyl jevgvat zl OFQ uvfgbel obbx. Cyrnfr xrrc nfxvat zr. | \
> tr "OQCFnortuvxyzabcefgjl" "BDPSabeghiklmnoprstwy"
> _______
> internet-history mailing list
> internet-***@postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-***@postel.org for assistance.
>

[Dave Walden]

Search for "loop test" at
http://www.dtic.mil/dtic/tr/fulltext/u2/686811.pdf , an early (the
earliest?) BBN ARPANET IMP development report to ARPA.

Bob Kahn was our modem expert and knew what the (Bell 303?) modem could
do.  See
   http://www.walden-family.com/impcode/bbn-report-1877.pdf
and search for "loop test".   While this is a 1973 revision of the
report, I believe this description was in the original version of the
report in 1969. My further memory is that such testing could be done
remotely under software control.

On 10/20/2017 11:44 PM, Jack Haverty wrote:
> IIRC, loopback was a term used in modems at least as early as the late
> 60s. Maybe before. When a line was put "in loopback" all the data
> going out onto the line was reflected directly back to the sender.
>
> Looping was used as a primary operations tool in the ARPANET. By
> "looping a line" the NOC operator could determine what was likely to
> have failed - the modem at either end, the line itself (backhoe attack),
> or the interface card in the IMPs at either end of the line. The IMPs
> could trigger the "looping" capability of the modems to cause loops to
> be established at the various points. That was important to determine
> whose Field Service to call to get a failure fixed.
>

[Bernie Cosell]

On 21 Oct 2017 at 8:09, Dave Walden wrote:

> Bob Kahn was our modem expert and knew what the (Bell 303?) modem could
> do.  See
>    http://www.walden-family.com/impcode/bbn-report-1877.pdf
> and search for "loop test".   While this is a 1973 revision of the
> report, I believe this description was in the original version of the
> report in 1969. My further memory is that such testing could be done
> remotely under software control.

My memory, too. On the a line test, the IMP would loop its interface,
loop its modem, and remotely loop the far-end modem back at it. This
allowed it to figure out if a line outage was either the modem crapping
out, the line being broken, or the remote IMP being down.

/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
mailto:***@fantasyfarm.com Pearisburg, VA
--> Too many people, too few sheep <--

[Miles Fidelman]

On 10/20/17 11:44 PM, Jack Haverty wrote:

> IIRC, loopback was a term used in modems at least as early as the late
> 60s. Maybe before. When a line was put "in loopback" all the data
> going out onto the line was reflected directly back to the sender.
>
> ....
>
> So, the specific term "loopback interface" probably depends on the
> context. It may have been first used in Unix, but the concept of
> "looping an interface" was much older. It existed in modems, and in the
> ARPANET, and in the Internet, and was used primarily for debugging and
> fault isolation during operations. When something works, you just keep
> using it.....
>
>
The term "loopback" goes all the way back to early electrical circuits -
bridging two wires with a cliplead, at various points, to test connectivity.

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra

[Brian E Carpenter]

On 22/10/2017 02:54, Miles Fidelman wrote:
> On 10/20/17 11:44 PM, Jack Haverty wrote:
>
>> IIRC, loopback was a term used in modems at least as early as the late
>> 60s. Maybe before. When a line was put "in loopback" all the data
>> going out onto the line was reflected directly back to the sender.
>>
>> ....
>>
>> So, the specific term "loopback interface" probably depends on the
>> context. It may have been first used in Unix, but the concept of
>> "looping an interface" was much older. It existed in modems, and in the
>> ARPANET, and in the Internet, and was used primarily for debugging and
>> fault isolation during operations. When something works, you just keep
>> using it.....
>>
>>
> The term "loopback" goes all the way back to early electrical circuits -
> bridging two wires with a cliplead, at various points, to test connectivity.

For sure. I would expect that it was standard practice in the days of
teleprinters and telegraphs, probably back into the 19th century. For the
notion of the loopback interface as a TCP/IP software construct, it seems
that BSD in 1981 is the origin.

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.

Thanks for all the feedback.

Brian

[Jack Haverty]

Hi Brian,

When we were designing those initial capabilities into TCP/IP
implementations, we were thinking not only of how everything would be
used in everyday operation, but also how you would deal with problems -
when things were not working as expected.

Especially in those early days, IIRC things were more often not working
than working... So tools, techniques, hooks, etc., for "fault
isolation" were introduced. The early Internet was explicitly
considered an "experiment", so lots of functions were needed to control
and monitor that experiment.

Loopback functionality is an example. So are other things, especially
in ICMP, e.g., Ping, Source Routing, timestamping, etc. The IP
"options" in particular was a means for hopefully adding new tools no
one had thought of yet.

Still-popular tools like Traceroute were possible because of the hooks
we put in place. For example, IP addressing was specifically set up to
provide each physical interface with an address. So a gateway/router,
for example, had a separate IP address for each wire attached to it.
That made it possible to use Ping, source-routing, etc., to "loop back"
at many different points and determine exactly where a problem was
occurring.

The downside of that architectural choice of IP address per physical
port was one of the items in the list of "things to work on" - namely
"Multi-homed hosts". Our conclusion at the time (circa 1978) was that
the advantages of having fault analysis tools exceeded the disadvantages
of not dealing well with IP nodes that had multiple physical ports -
something to be fixed "next year" as IPV4 phased into the next version.
Didn't quite happen that way...

So, I'd advise caution in concluding that some features are not needed
now, and were never really necessary. I'd advise the IPV6 crew to think
about not only how things should work when they work, but also how to
deal with the situation when they don't.

/Jack


On 10/21/2017 12:36 PM, Brian E Carpenter wrote:
> On 22/10/2017 02:54, Miles Fidelman wrote:
>> On 10/20/17 11:44 PM, Jack Haverty wrote:
>>
>>> IIRC, loopback was a term used in modems at least as early as the late
>>> 60s. Maybe before. When a line was put "in loopback" all the data
>>> going out onto the line was reflected directly back to the sender.
>>>
>>> ....
>>>
>>> So, the specific term "loopback interface" probably depends on the
>>> context. It may have been first used in Unix, but the concept of
>>> "looping an interface" was much older. It existed in modems, and in the
>>> ARPANET, and in the Internet, and was used primarily for debugging and
>>> fault isolation during operations. When something works, you just keep
>>> using it.....
>>>
>>>
>> The term "loopback" goes all the way back to early electrical circuits -
>> bridging two wires with a cliplead, at various points, to test connectivity.
>
> For sure. I would expect that it was standard practice in the days of
> teleprinters and telegraphs, probably back into the 19th century. For the
> notion of the loopback interface as a TCP/IP software construct, it seems
> that BSD in 1981 is the origin.
>
> 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.
>
> Thanks for all the feedback.
>
> Brian
>
> _______
> internet-history mailing list
> internet-***@postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-***@postel.org for assistance.
>

[Vint Cerf]

+1
v


On Sat, Oct 21, 2017 at 4:29 PM, Jack Haverty <***@3kitty.org> wrote:

> Hi Brian,
>
> When we were designing those initial capabilities into TCP/IP
> implementations, we were thinking not only of how everything would be
> used in everyday operation, but also how you would deal with problems -
> when things were not working as expected.
>
> Especially in those early days, IIRC things were more often not working
> than working... So tools, techniques, hooks, etc., for "fault
> isolation" were introduced. The early Internet was explicitly
> considered an "experiment", so lots of functions were needed to control
> and monitor that experiment.
>
> Loopback functionality is an example. So are other things, especially
> in ICMP, e.g., Ping, Source Routing, timestamping, etc. The IP
> "options" in particular was a means for hopefully adding new tools no
> one had thought of yet.
>
> Still-popular tools like Traceroute were possible because of the hooks
> we put in place. For example, IP addressing was specifically set up to
> provide each physical interface with an address. So a gateway/router,
> for example, had a separate IP address for each wire attached to it.
> That made it possible to use Ping, source-routing, etc., to "loop back"
> at many different points and determine exactly where a problem was
> occurring.
>
> The downside of that architectural choice of IP address per physical
> port was one of the items in the list of "things to work on" - namely
> "Multi-homed hosts". Our conclusion at the time (circa 1978) was that
> the advantages of having fault analysis tools exceeded the disadvantages
> of not dealing well with IP nodes that had multiple physical ports -
> something to be fixed "next year" as IPV4 phased into the next version.
> Didn't quite happen that way...
>
> So, I'd advise caution in concluding that some features are not needed
> now, and were never really necessary. I'd advise the IPV6 crew to think
> about not only how things should work when they work, but also how to
> deal with the situation when they don't.
>
> /Jack
>
>
> On 10/21/2017 12:36 PM, Brian E Carpenter wrote:
> > On 22/10/2017 02:54, Miles Fidelman wrote:
> >> On 10/20/17 11:44 PM, Jack Haverty wrote:
> >>
> >>> IIRC, loopback was a term used in modems at least as early as the late
> >>> 60s. Maybe before. When a line was put "in loopback" all the data
> >>> going out onto the line was reflected directly back to the sender.
> >>>
> >>> ....
> >>>
> >>> So, the specific term "loopback interface" probably depends on the
> >>> context. It may have been first used in Unix, but the concept of
> >>> "looping an interface" was much older. It existed in modems, and in
> the
> >>> ARPANET, and in the Internet, and was used primarily for debugging and
> >>> fault isolation during operations. When something works, you just keep
> >>> using it.....
> >>>
> >>>
> >> The term "loopback" goes all the way back to early electrical circuits -
> >> bridging two wires with a cliplead, at various points, to test
> connectivity.
> >
> > For sure. I would expect that it was standard practice in the days of
> > teleprinters and telegraphs, probably back into the 19th century. For the
> > notion of the loopback interface as a TCP/IP software construct, it seems
> > that BSD in 1981 is the origin.
> >
> > 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.
> >
> > Thanks for all the feedback.
> >
> > Brian
> >
> > _______
> > internet-history mailing list
> > internet-***@postel.org
> > http://mailman.postel.org/mailman/listinfo/internet-history
> > Contact list-***@postel.org for assistance.
> >
> _______
> internet-history mailing list
> internet-***@postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-***@postel.org for assistance.
>



--
New postal address:
Google
1875 Explorer Street, 10th Floor
Reston, VA 20190

[Brian E Carpenter]

> So, I'd advise caution in concluding that some features are not needed
> now, and were never really necessary. I'd advise the IPV6 crew to think
> about not only how things should work when they work, but also how to
> deal with the situation when they don't.

Absolutely, as a general principle.

Thanks very much,
Brian Carpenter

On 22/10/2017 09:29, Jack Haverty wrote:
> Hi Brian,
>
> When we were designing those initial capabilities into TCP/IP
> implementations, we were thinking not only of how everything would be
> used in everyday operation, but also how you would deal with problems -
> when things were not working as expected.
>
> Especially in those early days, IIRC things were more often not working
> than working... So tools, techniques, hooks, etc., for "fault
> isolation" were introduced. The early Internet was explicitly
> considered an "experiment", so lots of functions were needed to control
> and monitor that experiment.
>
> Loopback functionality is an example. So are other things, especially
> in ICMP, e.g., Ping, Source Routing, timestamping, etc. The IP
> "options" in particular was a means for hopefully adding new tools no
> one had thought of yet.
>
> Still-popular tools like Traceroute were possible because of the hooks
> we put in place. For example, IP addressing was specifically set up to
> provide each physical interface with an address. So a gateway/router,
> for example, had a separate IP address for each wire attached to it.
> That made it possible to use Ping, source-routing, etc., to "loop back"
> at many different points and determine exactly where a problem was
> occurring.
>
> The downside of that architectural choice of IP address per physical
> port was one of the items in the list of "things to work on" - namely
> "Multi-homed hosts". Our conclusion at the time (circa 1978) was that
> the advantages of having fault analysis tools exceeded the disadvantages
> of not dealing well with IP nodes that had multiple physical ports -
> something to be fixed "next year" as IPV4 phased into the next version.
> Didn't quite happen that way...
>
> So, I'd advise caution in concluding that some features are not needed
> now, and were never really necessary. I'd advise the IPV6 crew to think
> about not only how things should work when they work, but also how to
> deal with the situation when they don't.
>
> /Jack
>
>
> On 10/21/2017 12:36 PM, Brian E Carpenter wrote:
>> On 22/10/2017 02:54, Miles Fidelman wrote:
>>> On 10/20/17 11:44 PM, Jack Haverty wrote:
>>>
>>>> IIRC, loopback was a term used in modems at least as early as the late
>>>> 60s. Maybe before. When a line was put "in loopback" all the data
>>>> going out onto the line was reflected directly back to the sender.
>>>>
>>>> ....
>>>>
>>>> So, the specific term "loopback interface" probably depends on the
>>>> context. It may have been first used in Unix, but the concept of
>>>> "looping an interface" was much older. It existed in modems, and in the
>>>> ARPANET, and in the Internet, and was used primarily for debugging and
>>>> fault isolation during operations. When something works, you just keep
>>>> using it.....
>>>>
>>>>
>>> The term "loopback" goes all the way back to early electrical circuits -
>>> bridging two wires with a cliplead, at various points, to test connectivity.
>>
>> For sure. I would expect that it was standard practice in the days of
>> teleprinters and telegraphs, probably back into the 19th century. For the
>> notion of the loopback interface as a TCP/IP software construct, it seems
>> that BSD in 1981 is the origin.
>>
>> 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.
>>
>> Thanks for all the feedback.
>>
>> Brian
>>
>> _______
>> internet-history mailing list
>> internet-***@postel.org
>> http://mailman.postel.org/mailman/listinfo/internet-history
>> Contact list-***@postel.org for assistance.
>>
> _______
> internet-history mailing list
> internet-***@postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-***@postel.org for assistance.
> .
>

[Paul Vixie]

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 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.

--
P Vixie

[John Day]

The problem was solved 50 years ago. It is just that the Internet doesn’t like the solution.


>
> 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.
>
> --
> P Vixie
>
> _______
> internet-history mailing list
> internet-***@postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-***@postel.org for assistance.

[Brian E Carpenter]

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.

Brian

[Toerless Eckert]

On Sun, Oct 22, 2017 at 03:19:50AM -0700, Paul Vixie wrote:
> 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.

I am not sure if multihoming is a great unsolved problem in internetworking.
It just seems to be a problem with IPs ideology. As opposed to let's say
CLNS ideology of node addresses.

In the early 90th i had on pretty much every vendors unix system available nodes
with 10 Mbps ethernet and FDDI, and of course the FDDI on each node worked
randomnly 90% of the time (especially in a ring with 10++ vendor NICs). In
the face of NFS, the only way to keep the network running was to let those
MHH participate in the IGP and inject their addresses as host routes.
And when IPv6 came out i was so disappointed that it still did not
acknowledge / describe the notion of node addresses.

Now with IETF ANIMA WG and ACP, we're automation the creation and routing for
node addresses and try to figure out how to use the correct terminology.
"loopback" seems to be the common term used for "internal" interfaces. Not
that there is a real definition of "internal" interfaces either. And of
course there is also no IPv6 architecture description that "loopback" addresses
could have global scope addresses. Thats just a decade old deployment reality
not described by the architecture.

And thats just the tip of the iceberg.

Cheers
Toerless

[John Day]

Toerless,

You are correct. This problem was solved as soon as it was discovered around 1972 and solved several times. XNS, CYCLADES and as you point out CLNS all solved it. It is more a problem, as you say, with IP ideology.

As you say, it is just the tip of the iceberg.

Take care,
John

> On Oct 23, 2017, at 13:21, Toerless Eckert <***@cs.fau.de> wrote:
>
> On Sun, Oct 22, 2017 at 03:19:50AM -0700, Paul Vixie wrote:
>> 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.
>
> I am not sure if multihoming is a great unsolved problem in internetworking.
> It just seems to be a problem with IPs ideology. As opposed to let's say
> CLNS ideology of node addresses.
>
> In the early 90th i had on pretty much every vendors unix system available nodes
> with 10 Mbps ethernet and FDDI, and of course the FDDI on each node worked
> randomnly 90% of the time (especially in a ring with 10++ vendor NICs). In
> the face of NFS, the only way to keep the network running was to let those
> MHH participate in the IGP and inject their addresses as host routes.
> And when IPv6 came out i was so disappointed that it still did not
> acknowledge / describe the notion of node addresses.
>
> Now with IETF ANIMA WG and ACP, we're automation the creation and routing for
> node addresses and try to figure out how to use the correct terminology.
> "loopback" seems to be the common term used for "internal" interfaces. Not
> that there is a real definition of "internal" interfaces either. And of
> course there is also no IPv6 architecture description that "loopback" addresses
> could have global scope addresses. Thats just a decade old deployment reality
> not described by the architecture.
>
> And thats just the tip of the iceberg.
>
> Cheers
> Toerless
> _______
> internet-history mailing list
> internet-***@postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-***@postel.org for assistance.

[Paul Vixie]

there are two replies here, one to an echo through joe touch.

Toerless Eckert wrote:
> On Sun, Oct 22, 2017 at 03:19:50AM -0700, Paul Vixie wrote:
>> 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.
>
> I am not sure if multihoming is a great unsolved problem in internetworking.
> It just seems to be a problem with IPs ideology. As opposed to let's say
> CLNS ideology of node addresses.
>
[description of how to have every endpoint participate in IGP]
>
> 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."

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.

---

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

[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

--
---
***@cs.fau.de

[Joe Touch]

On Oct 23, 2017, at 3:00 PM, Toerless Eckert <***@cs.fau.de> wrote:

>> 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 ;-).

LISP is one example of a broad class of encapsulation-based systems that emulate either subsets or switching devices, e.g., including TRILL, 802.1Q-2014, etc., a class I’ve been referring to as recursive routers and is fundamental to network virtualization.

IMO, they’re no more a stop-gap to networking than VM is to memory.

But we’re digressing from the original thread...

Joe

[Paul Ruizendaal]

In documents about TCP/IP stacks from the 1978-1981 era there are often comments like "speed with local looping xx and speed looping through IMP xx". As Jack has pointed out, looping at various steps seems to have been standard practice at the time. I'm re-implementing some old stacks on vintage hardware and can confirm from first hand experience that a loopback interface is a convenient debugging setup.

Next, I can elaborate from the 1981 Gurwitz sources: it does not contain a loopback interface (device) as such, but the standard IMP device driver has #ifdef'ed code to operate either in normal mode or in loopback mode. The device driver configuration is still a simple hardcoded setup at this stage, with a comment saying that it is due to be reworked into a configurable setup.

The commit from Nov 1981 quoted below is very early in the 4.1+ networking development cycle, well before the release of 4.1a. As far as I can tell it is the first occurrence of a dedicated loopback device in the history of Arpa/Inet networking on Unix.


On 21 Oct 2017, at 2:12 , Jeremy C. Reed wrote:

> On Sat, 21 Oct 2017, Brian E Carpenter wrote:
>
>> So the question came up of when and where the term 'loopback
>> interface' arose. Does anybody here have an answer for that?
>
> In my BSD history research, the earliest reference (for BSD) I have is:
>
> BBN had successful tests with establishing connections and transmitting
> data between processes using the loopback
> mode.\cite{{bressler-bbn-198102}
>
> % http://www.dtic.mil/dtic/tr/fulltext/u2/a096114.pdf
> % R. D. Bressler
> % for nov 1, 1980 to jan 31, 1981
> % date stamped March 9, 1981
> @BOOK{bressler-bbn-198102,
> editor = "Robert D. Bressler",
> title = "{Combined Quarterly Technical Report No. 20}",
> publisher = "Bolt, Beranek, and Newman Inc.",
> address = "Cambridge, Mass.",
> year = 1981,
> month = feb
> }
>
> Document page 82, PDF page 89
> Now looking at it again I see that term used multiple times. I now
> see earlier references for loopback for IMP and 1822 interfaces and in
> early BBN reports but this is not about the "internet" interface as far
> as I can tell.
>
> The ARPANET Interface Message Processor (IMP) Port Expander (PE)
> Technical Report 1080-140-1
> November, 1980
> http://www.dtic.mil/dtic/tr/fulltext/u2/a155753.pdf
> recreated at
> http://www.warthman.com/images/SRI%20ARPANET-IMP.book.pdf
> talks about loopback mode.
> (Also at same time it is mentioned in BBN Report No. 4526.)
>
> The oldest Unix code reference I find is University of Illinois 'Network
> Unix' ncpk/drivers/net_ill.h
> /* defines for accessing bits in the imp interface */
> ...
> #define imloop 0000400 /* loop back */
>
> but I don't see anything using it. I don't know date of that but the
> system was from 1974-1975 and the file stamp is May 17 1979. This code
> is not about internet loopback though.
>
> As for the earliest Unix "internet" style loopback interface I find
> 4.1c.1 BSD's /sys/netinet/if_loop.c. Maybe from Joy or Eric Cooper (even
> if Joy committed it).
>
> D 4.1 81/11/29 22:18:03 wnj 1 0 00059/00000/00000
> MRs:
> COMMENTS:
> date and time created 81/11/29 22:18:03 by wnj
>
> 4.1 /* if_loop.c 4.1 81/11/29 */
> 4.1
> 4.1 /*
> 4.1 * Loopback interface driver for protocol testing and timing.
>
> This was after the initial BBN code being added to CSRG's SCCS and I
> don't see reference to it earlier in that code so I assume was not in
> the BBN deliverables. I think the BBN reference in regards to the VAX
> UNIX is using a loopback mode not in the Unix networking implementation
> itself, so may be the earliest implementation of internet driver for
> loopback interface. (It was originally hardcoded to be on 254 network,
> but on Dec 22, 1981 changed to be 127 (hardcoded). In March 1982,
> converted to use sockets and AF_INET. In May 1983, changed from
> 127.0.0.0 (broadcast) to 127.0.0.1. The hardcoded address was removed in
> March 1985. This is the same code that ended up in the "greatest
> software ever written" :)
>
> Jeremy C. Reed
>
> echo Fybjyl jevgvat zl OFQ uvfgbel obbx. Cyrnfr xrrc nfxvat zr. | \
> tr "OQCFnortuvxyzabcefgjl" "BDPSabeghiklmnoprstwy"
> _______
> internet-history mailing list
> internet-***@postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-***@postel.org for assistance.

[Vint Cerf]

i have this hazy feeling it might have originated in the port expander
adventure but it might simply have been a way to test TCP/IP locally
without actually leaving the computer.

v


On Fri, Oct 20, 2017 at 5:29 PM, Brian E Carpenter <
***@gmail.com> wrote:

> Hi,
>
> Over on ***@ietf.org we're discussing the issue of how to assign an
> address to a node without assigning it to a specific physical or tunnel
> interface. This is a minor gap in the IPv6 addressing architecture spec,
> but it creates a terminology issue in various other places.
>
> The thread started with the following message, and has got surprisingly
> long:
> https://mailarchive.ietf.org/arch/msg/ipv6/U0QzAWpZTypF8gyZZ8HPfXZLOPM
>
> So the question came up of when and where the term 'loopback interface'
> arose. Does anybody here have an answer for that?
>
> Regards
> Brian Carpenter
>
>
> _______
> internet-history mailing list
> internet-***@postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-***@postel.org for assistance.
>



--
New postal address:
Google
1875 Explorer Street, 10th Floor
Reston, VA 20190

[John Levine]

A little greppage finds that class A network 127 is marked as Reserved
in RFCs 790. 820, 870, 900, 923, 943, and 960. It is Loopback in RFCs
990, 997, and later ones.

The word loopback appears in other contexts in earlier RFCs but the
first application to IP I can find is in RFC 990 in 1986.

R's,
John

[John Levine]

In article <***@redbarn.org> you write:
>Brian Carpenter wrote:
>>> So having a dedicated address for
>>> loopback tests seems useless today.
>
>it's nowhere near useless. 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 ...

Even on machines that do have physical interfaces, puting a service
on a loopback address lets me be sure it's only available to other
processes on the same machine without having to screw around with
packet filters. The usual example is a DNS cache.

It seems to me that having a single loopback address rather than at
least a /64 is one of the more inexplicable misfeatures of IPv6.

R's,
John

[James Cloos]

>>>>> "JL" == John Levine <***@iecc.com> writes:

JL> It seems to me that having a single loopback address rather than at
JL> least a /64 is one of the more inexplicable misfeatures of IPv6.

I always disliked that, too. But we *can* use ::7f00:0000/104.

The only downside(?) is that assigning one address therein does not
automatically make the rest of the /104 work.

-JimC
--
James Cloos <***@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6

[Tony Finch]

John Levine <***@iecc.com> wrote:
>
> Even on machines that do have physical interfaces, puting a service
> on a loopback address lets me be sure it's only available to other
> processes on the same machine without having to screw around with
> packet filters.

That's not entirely true. The "weak endpoint model" followed by most
systems means that they will accept packets to any of their addresses on
any of their interfaces. This opens you up to attacks from malicious
devices on your LAN(s).

Actually, the weak endpoint model is probably less pervasive than it used
to be because some systems have implemented reverse path filtering.

Tony.
--
f.anthony.n.finch <***@dotat.at> http://dotat.at/ - I xn--zr8h punycode
Biscay, Fitzroy: Southwesterly backing southerly 4 or 5, occasionally 6 in
north. Moderate or rough, occasionally very rough in Fitzroy. Occasional rain
and fog patches in north. Moderate or good, occasionally very poor in north.

[Joe Touch]

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..).

Joe

> On Oct 23, 2017, at 4:56 AM, Tony Finch <***@dotat.at> wrote:
>
> John Levine <***@iecc.com> wrote:
>>
>> Even on machines that do have physical interfaces, puting a service
>> on a loopback address lets me be sure it's only available to other
>> processes on the same machine without having to screw around with
>> packet filters.
>
> That's not entirely true. The "weak endpoint model" followed by most
> systems means that they will accept packets to any of their addresses on
> any of their interfaces. This opens you up to attacks from malicious
> devices on your LAN(s).
>
> Actually, the weak endpoint model is probably less pervasive than it used
> to be because some systems have implemented reverse path filtering.
>
> Tony.
> --
> f.anthony.n.finch <***@dotat.at> http://dotat.at/ - I xn--zr8h punycode
> Biscay, Fitzroy: Southwesterly backing southerly 4 or 5, occasionally 6 in
> north. Moderate or rough, occasionally very rough in Fitzroy. Occasional rain
> and fog patches in north. Moderate or good, occasionally very poor in north.
> _______
> internet-history mailing list
> internet-***@postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-***@postel.org for assistance.

[Toerless Eckert]

Inline

On Mon, Oct 23, 2017 at 12:56:12PM +0100, Tony Finch wrote:
> John Levine <***@iecc.com> wrote:
> >
> > Even on machines that do have physical interfaces, puting a service
> > on a loopback address lets me be sure it's only available to other
> > processes on the same machine without having to screw around with
> > packet filters.
>
> That's not entirely true. The "weak endpoint model" followed by most
> systems means that they will accept packets to any of their addresses on
> any of their interfaces. This opens you up to attacks from malicious
> devices on your LAN(s).
>
> Actually, the weak endpoint model is probably less pervasive than it used
> to be because some systems have implemented reverse path filtering.

Any URL explaining why it would be an attack to accept packets
for an address you have on another interface ? I can not see that attack
vector.

AFAIK, the problem with weak endpoint model is only that other
nodes have problems performing correct RPF filtering for packets originated
from weak endpoint model nodes when the available addressing is not correctly
announced into routing. And with no equivalent to ES-IS, this requires
endpoints to have either some IGP or some form of LISP running
(LISP the concept, not the solution by the same name).

On 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..).
> Joe

Architecturally, there should be no reason for another addressing domain ("IPC")
if IP had a working definition of "node-local addressing". AFAIK, the loopback
addresses are meant to do this, but the RFCs IMHO do not call this out very
clearly. In multicast at least there is a node-local scope (FF01). Can't quite
remember (and to lazy to test now), if in TTL=0 worked to delivery traffic
only node-local at some point.

[ Btw: I could also tunnel any non-IP form of IPC if i have access to the OS. ]

Cheers
Teorless

[Joe Touch]

> On Oct 23, 2017, at 10:30 AM, Toerless Eckert <***@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..).
>> Joe
>
> Architecturally, there should be no reason for another addressing domain ("IPC")
> if IP had a working definition of "node-local addressing". AFAIK, the loopback
> addresses are meant to do this, but the RFCs IMHO do not call this out very
> clearly. In multicast at least there is a node-local scope (FF01). Can't quite
> remember (and to lazy to test now), if in TTL=0 worked to delivery traffic
> only node-local at some point.

You’ve hit the mail on the head. Only routers decrement TTLs. Multihoming works properly only with an internal virtual router inside each host:

J. Touch, T. Faber, “Dynamic Host Routing for Production Use of Developmental Networks,” in Proc. ICNP ’97, Atlanta, Oct. 1997, pp. 285-292.

But that still doesn’t warrant a strict need for self addressing beyond the addresses already available on other interfaces.

>
> [ 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

Joe

>
> Cheers
> Teorless

[Toerless Eckert]

On Mon, Oct 23, 2017 at 11:17:52AM -0700, Joe Touch wrote:
>
>
> > On Oct 23, 2017, at 10:30 AM, Toerless Eckert <***@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

--
---
***@cs.fau.de

[Joe Touch]

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.

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.

Jie


> On Oct 23, 2017, at 11:47 AM, Toerless Eckert <***@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 <***@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
>
> --
> ---
> ***@cs.fau.de

[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 <***@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 <***@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
> >
> > --
> > ---
> > ***@cs.fau.de

--
---
***@cs.fau.de

[Brian E Carpenter]

On 24/10/2017 08:42, 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.

I'm not sure this is really a "history" issue but I have to say that Joe is
correct. I'll take the details off list.

Brian

>
> It would preclude having a multiprocess stack too. You can’t coordinate components to process Ip using ip.
>
> 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.
>
> Jie
>
>
>> On Oct 23, 2017, at 11:47 AM, Toerless Eckert <***@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 <***@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
>>
>> --
>> ---
>> ***@cs.fau.de
>
>
> _______
> internet-history mailing list
> internet-***@postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-***@postel.org for assistance.
>

[Tony Finch]

Toerless Eckert <***@cs.fau.de> wrote:
> > John Levine <***@iecc.com> wrote:
> > >
> > > Even on machines that do have physical interfaces, puting a service
> > > on a loopback address lets me be sure it's only available to other
> > > processes on the same machine without having to screw around with
> > > packet filters.
>
> Any URL explaining why it would be an attack to accept packets
> for an address you have on another interface ? I can not see that attack
> vector.

I don't have a good link handy, so I'll try to explain it here...

In John's setup he assumes that a service bound to 127.0.0.1 is only
reachable by other processes on the same host. Maybe because of that the
service is configured to skip authentication/authorization checks.

If I'm on the same LAN as John's host, I can get packets to his supposedly
isolated service by crafting ethernet frames with his host's MAC address
as the destination but 127.0.0.1 as the IP destination.

You can use this trick for good as well as evil :-) Back in the days of
IP-based web virtual hosting we had a setup which bound about 96,000 IP
addresses on the loopback interface of the web servers. The routers in
front of these web servers had static routes configured for the loopback
web IP addresses with a next-hop of the web server's ethernet interface.

(More details about this hack at http://fanf.livejournal.com/124030.html)

Tony.
--
f.anthony.n.finch <***@dotat.at> http://dotat.at/ - I xn--zr8h punycode
Irish Sea: Southwest 6 to gale 8, decreasing 4 or 5 later. Moderate or rough.
Rain, fog patches. Moderate, occasionally very poor.

[Toerless Eckert]

On Tue, Oct 24, 2017 at 02:48:02PM +0100, Tony Finch wrote:
> > Any URL explaining why it would be an attack to accept packets
> > for an address you have on another interface ? I can not see that attack
> > vector.
>
> I don't have a good link handy, so I'll try to explain it here...
>
> In John's setup he assumes that a service bound to 127.0.0.1 is only
> reachable by other processes on the same host. Maybe because of that the
> service is configured to skip authentication/authorization checks.

And it should not need to (the service).

> If I'm on the same LAN as John's host, I can get packets to his supposedly
> isolated service by crafting ethernet frames with his host's MAC address
> as the destination but 127.0.0.1 as the IP destination.

Right. So at least the (IPv6) architecture security considerations
should to explain how the nodes IP stack needs to filter packets destined
to scoped addresses if received from interfaces not in that scope. Not
sure how much of that verbage exist(ed) at least back when the IPv6
architecture did still endorse site-scope addresses. Pretty sure it
was not written down for node-scoped addresses.

> You can use this trick for good as well as evil :-)

Can't come up with an example how to apply this for good.

> Back in the days of
> IP-based web virtual hosting we had a setup which bound about 96,000 IP
> addresses on the loopback interface of the web servers. The routers in
> front of these web servers had static routes configured for the loopback
> web IP addresses with a next-hop of the web server's ethernet interface.
>
> (More details about this hack at http://fanf.livejournal.com/124030.html)

Interesting. Looks from that blog as if there is a maze of different methods
of using multiple IP addresses inside a node. Do you think that it would be
good work for IETF to think about better standardization for those mechanisms ?
There is for example draft-templin-v6ops-pdhost-15 which also looks
into that direction but received little interest in the WG so far. Not
claiming that its current payload is good or bad, just that it goes in
that direction.

Toerless


> Tony.
> --
> f.anthony.n.finch <***@dotat.at> http://dotat.at/ - I xn--zr8h punycode
> Irish Sea: Southwest 6 to gale 8, decreasing 4 or 5 later. Moderate or rough.
> Rain, fog patches. Moderate, occasionally very poor.