<div dir="ltr">+1<div>v</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 21, 2017 at 4:29 PM, Jack Haverty <span dir="ltr"><<a href="mailto:jack@3kitty.org" target="_blank">jack@3kitty.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Brian,<br>
<br>
When we were designing those initial capabilities into TCP/IP<br>
implementations, we were thinking not only of how everything would be<br>
used in everyday operation, but also how you would deal with problems -<br>
when things were not working as expected.<br>
<br>
Especially in those early days, IIRC things were more often not working<br>
than working...  So tools, techniques, hooks, etc., for "fault<br>
isolation" were introduced.  The early Internet was explicitly<br>
considered an "experiment", so lots of functions were needed to control<br>
and monitor that experiment.<br>
<br>
Loopback functionality is an example.  So are other things, especially<br>
in ICMP, e.g., Ping, Source Routing, timestamping, etc.  The IP<br>
"options" in particular was a means for hopefully adding new tools no<br>
one had thought of yet.<br>
<br>
Still-popular tools like Traceroute were possible because of the hooks<br>
we put in place.  For example, IP addressing was specifically set up to<br>
provide each physical interface with an address.  So a gateway/router,<br>
for example, had a separate IP address for each wire attached to it.<br>
That made it possible to use Ping, source-routing, etc., to "loop back"<br>
at many different points and determine exactly where a problem was<br>
occurring.<br>
<br>
The downside of that architectural choice of IP address per physical<br>
port was one of the items in the list of "things to work on" - namely<br>
"Multi-homed hosts".  Our conclusion at the time (circa 1978) was that<br>
the advantages of having fault analysis tools exceeded the disadvantages<br>
of not dealing well with IP nodes that had multiple physical ports -<br>
something to be fixed "next year" as IPV4 phased into the next version.<br>
Didn't quite happen that way...<br>
<br>
So, I'd advise caution in concluding that some features are not needed<br>
now, and were never really necessary.  I'd advise the IPV6 crew to think<br>
about not only how things should work when they work, but also how to<br>
deal with the situation when they don't.<br>
<span class="HOEnZb"><font color="#888888"><br>
/Jack<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On 10/21/2017 12:36 PM, Brian E Carpenter wrote:<br>
> On 22/10/2017 02:54, Miles Fidelman wrote:<br>
>> On 10/20/17 11:44 PM, Jack Haverty wrote:<br>
>><br>
>>> IIRC, loopback was a term used in modems at least as early as the late<br>
>>> 60s.  Maybe before.  When a line was put "in loopback" all the data<br>
>>> going out onto the line was reflected directly back to the sender.<br>
>>><br>
>>> ....<br>
>>><br>
>>> So, the specific term "loopback interface" probably depends on the<br>
>>> context.  It may have been first used in Unix, but the concept of<br>
>>> "looping an interface" was much older.  It existed in modems, and in the<br>
>>> ARPANET, and in the Internet, and was used primarily for debugging and<br>
>>> fault isolation during operations.  When something works, you just keep<br>
>>> using it.....<br>
>>><br>
>>><br>
>> The term "loopback" goes all the way back to early electrical circuits -<br>
>> bridging two wires with a cliplead, at various points, to test connectivity.<br>
><br>
> For sure. I would expect that it was standard practice in the days of<br>
> teleprinters and telegraphs, probably back into the 19th century. For the<br>
> notion of the loopback interface as a TCP/IP software construct, it seems<br>
> that BSD in 1981 is the origin.<br>
><br>
> We could have another little chat about the loopback address in IP. I reached<br>
> the conclusion last night that it was never really necessary. All the TCP/IP<br>
> stacks that I know will happily send a message to any of their own assigned<br>
> addresses, without putting it on the wire. So having a dedicated address for<br>
> loopback tests seems useless today.<br>
><br>
> Thanks for all the feedback.<br>
><br>
>     Brian<br>
><br>
> _______<br>
> internet-history mailing list<br>
> <a href="mailto:internet-history@postel.org">internet-history@postel.org</a><br>
> <a href="http://mailman.postel.org/mailman/listinfo/internet-history" rel="noreferrer" target="_blank">http://mailman.postel.org/<wbr>mailman/listinfo/internet-<wbr>history</a><br>
> Contact <a href="mailto:list-owner@postel.org">list-owner@postel.org</a> for assistance.<br>
><br>
_______<br>
internet-history mailing list<br>
<a href="mailto:internet-history@postel.org">internet-history@postel.org</a><br>
<a href="http://mailman.postel.org/mailman/listinfo/internet-history" rel="noreferrer" target="_blank">http://mailman.postel.org/<wbr>mailman/listinfo/internet-<wbr>history</a><br>
Contact <a href="mailto:list-owner@postel.org">list-owner@postel.org</a> for assistance.<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">New postal address:<div>Google<br><div>1875 Explorer Street, 10th Floor</div><div>Reston, VA 20190</div></div></div></div>
</div>