In article <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]> wrote:
>> > Now I can see why this might have been considered a good idea.
>> >A remote host would not be able to reply to a 127 sourced address.
>>
>> Argh, they broke this too?
>
>No your setup was broken anyway - see RFC792, RFC 1122
[sounds of reading documents via grep]
OK, RFC792 doesn't seem to mention loopback at all, and RFC1122 only
mentions loopback when mentioning that ICMP messages can't be sent in
reply to a loopback address. However, if we take that sentence literally,
we can't do a significant part of ICMP at all over loopback (e.g. 'ping
127.0.0.1' is not allowed. The rule is correct but the examples are wrong.
Note that in this case 127.0.1.x _are_ unique host IP addresses.
The transparent proxy code has bound to these addresses. If we were
insane enough to allow 127.x.x.x traffic across Ethernet, you'd be
able to reach distinct servers at each of these addresses, but we had
firewall rules to prevent that. Each machine was basically set up
in a point-to-point network of ssh connections, and exactly the same
configuration worked no matter where the machine was physically connected
as long as it could reach at least one of the other machines.
Yes, it _was_ ugly, but it used to work and it used to be useful.
>> I used to use 127.0.1.0 as a virtual subnet via IP transparent proxy.
>> You would connect to 127.0.1.0 and your connection request would be
>> turned into a transparent proxy request in user space and forwarded
>> somewhere (in this case over an ssh port forwarding tunnel).
>
>Use an RFC1597 space for it
I do this now and have done so for years. I have gateways that do IP
routing over HTTPS using RFC1597 addresses. Just assume you want to
connect two networks and the only two communication channels available
from one to the other are smoke signals and a Netscape Proxy Server.
The requirement that made us use loopback instead of something like the
dummy interface was that the packets had to come back. If you send to
the dummy address the packets just disappear. At the time we were doing
this there were stability or availability problems with things like netlink,
slip-over-pty, and other ways to get this.
Of course in 2.2, and even in 2.0, there's lots of different options
to implement similar effects. A transparent ethernet bridge over HTTPS
would solve a few lingering compatibility problems once and for all...
--
Zygo Blaxell, Linux Engineer, Corel Corporation, [EMAIL PROTECTED] (work),
[EMAIL PROTECTED] (play). It's my opinion, I tell you! Mine! All MINE!
Size of 'diff -Nurw [...] winehq corel' as of Fri Feb 19 11:14:00 EST 1999
Lines/files: In 1660 / 125, Out 35527 / 395, Both 36791 / 459
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
