netdev - Re: [PATCHv2 net-next] ipv4: Add interface option to enable routing of 127.0.0.0/8

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 12 Jun 2012 15:50:19 -0400
From:	Thomas Graf <tgraf@...radead.org>
To:	Rick Jones <rick.jones2@...com>
Cc:	netdev@...r.kernel.org, tgraf@...g.ch,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCHv2 net-next] ipv4: Add interface option to enable routing
 of 127.0.0.0/8

On Tue, Jun 12, 2012 at 11:13:12AM -0700, Rick Jones wrote:
> I'd go beyond "traditionally forbidden" and call it something
> considered fundamental.  That 127.0.0.1 (et al) can only be reached
> by entities on the same system is rather deeply ingrained in the
> collective consciousness after 30-odd years.

I absolutely agree with regard to 127.0.0.1 but I do not fully
agree with regard to 127/8 in general.

> This change would make 127/8 a de facto RFC 1918 address right?  It
> would not be publicly routable.  Are there actually entities who
> have exhausted 10/8, 172.16/12 and 192.168/16?

This is not about enabling 127/8 to become publicly routeable.
This is about enabling 127/8 for host internal routing, f.e.
virtual bridges, ifb devices, or dummy devices.

The problem with 10/8, 172.162/12 and 192.168/16 is that these
ranges are often in use by VPNs and thus unavailable. None of these
addresses are guaranteed to be available on a random system.

An example for such usage would be virtualization where you want
to assign addresses to guests which are guaranteed to be available
in host scope as well.

Yes, if someone enables this on a publicly facing interface that
will enable the possibility to violate the RFC but he might as well
do that by using a raw socket.

> Are there any other stacks which can do this, or would this be an
> "RFC 1918" network between (newer)Linux systems only?  (Assuming
> non-newer-linux-based routers would be happy with it)

AFAIK none but I could be wrong. Again, this option is not intended
to be used on any public interfaces. However, if you want to enable
this in your own private network, fine with me again.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html