Aliasing the loopback.

I'm not going to let this go untested.

AFAIK, the loopback network of any operating system is intended solely for
its own use, is by convention (or perhaps standard) always 127.0.0.0 where
the local machine is thus 127.0.0.1, and is under no circumstances safely
permitted to see or be seen by any other network. Thus, permitting the
loopback to be other than localhost.localdomain is a dangerous and useless
configuration; adding an alias thereto establishes such a configuration and
must be considered "a very BAD thing to do!!".

If this is not true, I beg to be informed!! In that case, please cite
relevant RFC or STD.

Thanks,

Bill Tallman
--
Registered Linux User: #221586
Mdk-9.0 and IceWM
Gkrellm still watches over me...

"William D. Tallman" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> I'm not going to let this go untested.
>
> AFAIK, the loopback network of any operating system is intended solely for
> its own use, is by convention (or perhaps standard) always 127.0.0.0 where
> the local machine is thus 127.0.0.1,

well thats correct.

> and is under no circumstances safely
> permitted to see or be seen by any other network.

False. Its my interface, if I want my other to connect to it, it can.
Thats just the same as adding an ethernet card, isnt it?


Adding an alias 'localhost' interface will just mean that I have another
interface with no physical connection. I already have one of those
127.0.0.1, whats wrong with having another ?


> Thus, permitting the loopback to be other than localhost.localdomain is a
dangerous and
> useless configuration; adding an alias thereto establishes such a
configuration and
> must be considered "a very BAD thing to do!!".

No.
I already dealt with "dangerous".
"useless". Well what if I was testing a system which was to run on three
computers, but I had one computer. I wanted to try to simulate three
machines as closely as possible, so that I could be sure it would work on
three machines...

So I could have the programs run on three different IP addresses.. which
requires I have three interfaces. whats wrong with having two alias
interfaces of the LO interface to get two extra addresses ?

So its not irrelevant.


> If this is not true, I beg to be informed!! In that case, please cite
> relevant RFC or STD.

These say what TO DO to be standard.

Not often do they say what is BAD
They certainly do not say what is NOT bad.

I can't be expected to refer to a document that tells you what is NOT BAD..

Its like being asked to find a law which allows me to breath.
"The Breath Act , World Parliament, 2004

Section 44, part 6
Clause 7. And Leon may breath the air contained inside volume called the
"atmosphere" , as defined by section 11 part 3 clause 88. He may consume
oxygen from that air and release Carbon Dioxide into the atmosphere, and as
well exchange some water , saliva, dead cells, halitosis and gingovitis
bacteria, and any bacteria, virus or fungi he may or may not be infected
with .






>
> Thanks,
>
> Bill Tallman
> --
> Registered Linux User: #221586
> Mdk-9.0 and IceWM
> Gkrellm still watches over me...

"Leon." <(E-Mail Removed)> wrote:
>"William D. Tallman" <(E-Mail Removed)> wrote in message
>news:(E-Mail Removed)...
>> I'm not going to let this go untested.
>>
>> AFAIK, the loopback network of any operating system is intended solely for
>> its own use, is by convention (or perhaps standard) always 127.0.0.0 where
>> the local machine is thus 127.0.0.1,
>
>well thats correct.
>
>> and is under no circumstances safely
>> permitted to see or be seen by any other network.
>
>False. Its my interface, if I want my other to connect to it, it can.
>Thats just the same as adding an ethernet card, isnt it?

See RFC1122,

"3.2.1.3 Addressing: RFC-791 Section 3.2

...

(g) { 127, <any> }

Internal host loopback address. Addresses of this form
MUST NOT appear outside a host.

>Adding an alias 'localhost' interface will just mean that I have another
>interface with no physical connection. I already have one of those
>127.0.0.1, whats wrong with having another ?

Actually you have significantly *more* than just 1! The entire
127.x.x.x range of addresses is assigned to the loopback device
because, as ifconfig will show, it has a net mask of 255.0.0.0.
Hence if you try, for example, to ping address 127.1.220.140, it
will indeed work!

Which means that you don't need to alias anything. All you have
to do to have "another" loopback by name, is put the name into
the /etc/hosts file:

127.0.0.2 my.local.host mylocalhost
127.0.0.3 my.other.host myotherhost

And now you can ping any of those names.

>> Thus, permitting the loopback to be other than localhost.localdomain is a dangerous and
>> useless configuration; adding an alias thereto establishes such a configuration and
>> must be considered "a very BAD thing to do!!".
>
>No.

Wellllll, it depends on how one does it. Assigning
localhost.localdomain to 127.0.0.2 is fine. But doing what
RedHat and a few camp followers have done and associating that
name with 127.0.0.1 is just plain *wrong*.

See RFC1537, and read any good book on network administration.
Here are at least three,

"TCP/IP Network Administration", 2nd Ed., Hunt,
O'Reilly 1998. See pages 50-51, plus

"Running Linux", 3rd Ed., Welsh, Dalheimer and
Kaufman, O'Reilly 1999. See page 530.

"Linux Network Administrator's Guide", Kirch,
O'Reilly 1995. See pages 64 and 65.

>I already dealt with "dangerous".
>"useless". Well what if I was testing a system which was to run on three
>computers, but I had one computer. I wanted to try to simulate three
>machines as closely as possible, so that I could be sure it would work on
>three machines...

See above. Or you could also use one or more dummy devices, and
assign whatever IP addresses you wished.

(However... be forewarned that a single computer with three
ports, whether they are RS-232, ethernet, or whatever, does
*not* emulate three computers each with one port! Lots of
people have tried that and discovered that their programs
depended on synchronous processing, and worked quite differently
with the asynchronous processing of a real network.)

> So I could have the programs run on three different IP addresses.. which
>requires I have three interfaces. whats wrong with having two alias
>interfaces of the LO interface to get two extra addresses ?
>
>So its not irrelevant.

It isn't, but the means to accomplish it isn't perhaps what you
thought.

--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) (E-Mail Removed)

Floyd Davidson wrote:

> "Leon." <(E-Mail Removed)> wrote:
>>"William D. Tallman" <(E-Mail Removed)> wrote in message
>>news:(E-Mail Removed)...
>>> I'm not going to let this go untested.
>>>
>>> AFAIK, the loopback network of any operating system is intended solely
>>> for its own use, is by convention (or perhaps standard) always 127.0.0.0
>>> where the local machine is thus 127.0.0.1,
>>
>>well thats correct.
>>
>>> and is under no circumstances safely
>>> permitted to see or be seen by any other network.
>>
>>False. Its my interface, if I want my other to connect to it, it can.
>>Thats just the same as adding an ethernet card, isnt it?

That you have to ask the question suggests that you may not know the answer.
You can indeed do anything you wish, though it may be more difficult than
you expect to avoid responsibility for the consequences. And even more
difficult to avoid the occurrence of such consequences!

> See RFC1122,
>
> "3.2.1.3 Addressing: RFC-791 Section 3.2
>
> ...
>
> (g) { 127, <any> }
>
> Internal host loopback address. Addresses of this form
> MUST NOT appear outside a host.

Exactly so. Incidentally, IIRC, 791 and 1122 are the RFCs that support the
IP standard, STD 1, are they not?

>>Adding an alias 'localhost' interface will just mean that I have another
>>interface with no physical connection. I already have one of those
>>127.0.0.1, whats wrong with having another ?
>
> Actually you have significantly *more* than just 1! The entire
> 127.x.x.x range of addresses is assigned to the loopback device
> because, as ifconfig will show, it has a net mask of 255.0.0.0.
> Hence if you try, for example, to ping address 127.1.220.140, it
> will indeed work!

Heh heh, just tried it and you're correct!

> Which means that you don't need to alias anything. All you have
> to do to have "another" loopback by name, is put the name into
> the /etc/hosts file:
>
> 127.0.0.2 my.local.host mylocalhost
> 127.0.0.3 my.other.host myotherhost
>
> And now you can ping any of those names.

So, in fact you can alias anything you want, which is obvious. The question
is what one can safely do with these aliases.

>>> Thus, permitting the loopback to be other than localhost.localdomain is
>>> a dangerous and
>>> useless configuration; adding an alias thereto establishes such a
>>> configuration and must be considered "a very BAD thing to do!!".
>>
>>No.
>
> Wellllll, it depends on how one does it. Assigning
> localhost.localdomain to 127.0.0.2 is fine. But doing what
> RedHat and a few camp followers have done and associating that
> name with 127.0.0.1 is just plain *wrong*.
>
> See RFC1537, and read any good book on network administration.

Yep:

------------------------------------------------------------
Also each nameserver should run primary for 0.0.127.in-addr.arpa;
that zone file should contain a SOA and NS record and an entry:

1 PTR localhost.

There has been extensive discussion about whether or not to append
the local domain to it. The conclusion was that "localhost." would be
the best solution; reasons given were:

- "localhost" itself is used and expected to work on some systems.

- translating 127.0.0.1 into "localhost.my_domain" can cause some
software to connect to itself using the loopback interface when
it didn't want to.

Note that all domains that contain hosts should have a "localhost" A
record in them.
------------------------------------------------------------

> Here are at least three,
>
> "TCP/IP Network Administration", 2nd Ed., Hunt,
> O'Reilly 1998. See pages 50-51, plus
>
> "Running Linux", 3rd Ed., Welsh, Dalheimer and
> Kaufman, O'Reilly 1999. See page 530.
>
> "Linux Network Administrator's Guide", Kirch,
> O'Reilly 1995. See pages 64 and 65.
>
>>I already dealt with "dangerous".
>>"useless". Well what if I was testing a system which was to run on three
>>computers, but I had one computer. I wanted to try to simulate three
>>machines as closely as possible, so that I could be sure it would work on
>>three machines...
>
> See above. Or you could also use one or more dummy devices, and
> assign whatever IP addresses you wished.
>
> (However... be forewarned that a single computer with three
> ports, whether they are RS-232, ethernet, or whatever, does
> *not* emulate three computers each with one port! Lots of
> people have tried that and discovered that their programs
> depended on synchronous processing, and worked quite differently
> with the asynchronous processing of a real network.)

Yes. The question is not only what one is likely to do with one's own
system, but what one may possibly to to/with external networks. This is
not a rhetorical question: I don't know the answer, but I suspect that it
might be of interest to those whose who may not be as well informed as they
think.

The RFCs mention what might happen with applications, but nothing is said
about what happens when an external network wrongly connects to the
loopback of a server, for instance.

>> So I could have the programs run on three different IP addresses.. which
>>requires I have three interfaces. whats wrong with having two alias
>>interfaces of the LO interface to get two extra addresses ?
>>
>>So its not irrelevant.
>
> It isn't, but the means to accomplish it isn't perhaps what you
> thought.
>

Thanks for the RFC citation.

Bill Tallman
--
Registered Linux User: #221586
Mdk-9.0 and IceWM
Gkrellm still watches over me...

William D. Tallman <(E-Mail Removed)> wrote:
> > the /etc/hosts file:
> >
> > 127.0.0.2 my.local.host mylocalhost
> > 127.0.0.3 my.other.host myotherhost
> >
> > And now you can ping any of those names.

> So, in fact you can alias anything you want, which is obvious. The question
> is what one can safely do with these aliases.

Anything. Packets aimed at those addresses will never ever leave your
kernel. And obviously, they will never enter it ... hmm, I guess you
could try forming a packet that says it is aimed at 127.0.0.1 and
physically putting it on the LAN. I'm not sure what a NIC would do if
it were configured to accept for 127.0.0.1 and saw such a packet
passing ... probably ignore it. The NICs must have all the rfcs in the
worls programmed into their firmware nowadays.

Peter

> Anything. Packets aimed at those addresses will never ever leave your
> kernel. And obviously, they will never enter it ... hmm, I guess you
> could try forming a packet that says it is aimed at 127.0.0.1 and
> physically putting it on the LAN. I'm not sure what a NIC would do if
> it were configured to accept for 127.0.0.1 and saw such a packet
> passing ... probably ignore it. The NICs must have all the rfcs in the
> worls programmed into their firmware nowadays.

You're confusing your networking layers. The NIC doesn't know a thing
about IP or IP-related RFC's. It's job doesn't have anything to do with
IP, or any subset of IP. The job of the NIC is to get ethernet frames
moved around, and that's it.

So, as long as the card in question has the MAC address that the frame
is destined for, it's going to accept it. It's not going to waste time
trying to decide if the frame's payload even contains IP. It's just
going to do it's job, accept the frame, and pass it up the chain. What
happens after that is none of the NIC's business! = )

steve

Steve Wolfe <(E-Mail Removed)> wrote:
> > Anything. Packets aimed at those addresses will never ever leave your
> > kernel. And obviously, they will never enter it ... hmm, I guess you
> > could try forming a packet that says it is aimed at 127.0.0.1 and
> > physically putting it on the LAN. I'm not sure what a NIC would do if
> > it were configured to accept for 127.0.0.1 and saw such a packet
> > passing ... probably ignore it. The NICs must have all the rfcs in the
> > worls programmed into their firmware nowadays.

> You're confusing your networking layers. The NIC doesn't know a thing
> about IP or IP-related RFC's.

It often does nowadays, I believe. It has an IP netmask that works
using internal firmware filters to tell it what passing packets to pass
in. (and usually there are some number like 8 or 16 filters that can be
programmed into the card - any more and you ahve to do the filtering in
the driver software).

This has been the situation for about 7 years. Remember that you can
put it in promiscuous mode? In which it listens to all passing packets?
Well, you can also put it in imbetween modes, where it takes only some
packets. Or at least that is my belief! But I am not a networking
expert! About the last card I recall that had absolutely no internal
programmable filters at all was the ne2000. or possibly the 3c509.

> It's job doesn't have anything to do with
> IP, or any subset of IP. The job of the NIC is to get ethernet frames
> moved around, and that's it.

Yep.

> So, as long as the card in question has the MAC address that the frame
> is destined for, it's going to accept it.

Explain "promiscuous mode", then! I'd be happy to believe you, but you
have to give me an explanation of that little problem for your theory
first!

> It's not going to waste time
> trying to decide if the frame's payload even contains IP. It's just
> going to do it's job, accept the frame, and pass it up the chain. What
> happens after that is none of the NIC's business! = )

Peter

Steve Wolfe wrote:

>> Anything. Packets aimed at those addresses will never ever leave your
>> kernel. And obviously, they will never enter it ... hmm, I guess you
>> could try forming a packet that says it is aimed at 127.0.0.1 and
>> physically putting it on the LAN. I'm not sure what a NIC would do if
>> it were configured to accept for 127.0.0.1 and saw such a packet
>> passing ... probably ignore it. The NICs must have all the rfcs in the
>> worls programmed into their firmware nowadays.
>
> You're confusing your networking layers. The NIC doesn't know a thing
> about IP or IP-related RFC's. It's job doesn't have anything to do with
> IP, or any subset of IP. The job of the NIC is to get ethernet frames
> moved around, and that's it.
>
> So, as long as the card in question has the MAC address that the frame
> is destined for, it's going to accept it. It's not going to waste time
> trying to decide if the frame's payload even contains IP. It's just
> going to do it's job, accept the frame, and pass it up the chain. What
> happens after that is none of the NIC's business! = )
>
> steve

Dunno who you were answering here, Steve, but it doesn't match the post to
which it is attached.

Bill Tallman
--
Registered Linux User: #221586
Mdk-9.0 and IceWM
Gkrellm still watches over me...

> > So, as long as the card in question has the MAC address that the
frame
> > is destined for, it's going to accept it.
>
> Explain "promiscuous mode", then!

Easy. The card will accept whichever packets it receives, regardless of
MAC address. IP addressing isn't involved in switching the card in or out
of promiscuous mode.

steve

(E-Mail Removed) (P.T. Breuer) wrote in message news:<(E-Mail Removed)>...
> William D. Tallman <(E-Mail Removed)> wrote:
> > > the /etc/hosts file:
> > >
> > > 127.0.0.2 my.local.host mylocalhost
> > > 127.0.0.3 my.other.host myotherhost
> > >
> > > And now you can ping any of those names.
>
> > So, in fact you can alias anything you want, which is obvious. The question
> > is what one can safely do with these aliases.
>
> Anything. Packets aimed at those addresses will never ever leave your
> kernel. And obviously, they will never enter it ... hmm, I guess you
> could try forming a packet that says it is aimed at 127.0.0.1 and
> physically putting it on the LAN. I'm not sure what a NIC would do if
> it were configured to accept for 127.0.0.1 and saw such a packet
> passing ... probably ignore it. The NICs must have all the rfcs in the
> worls programmed into their firmware nowadays.
>
> Peter

Finally!! I hadda sign up with Google to get this post... <sigh>

Hi Peter!

How would you do this? As far as my equipment goes, it'd take a
computer to create the packet, and then it would go to the loopback
directly. Dunno whether that's true of windows, I'll have to try that
next time I get on the windows machine.

I've no idea what sort of info the firmware on NICs have, but AFAIK,
they basically talk MAC and little else. According to the OSI/IP
model, they are at the data-link level at best, and just pass on what
they're given from the network level. I've still got lots to learn
about this stuff.

Good to hear from you again!

Bill Tallman