[RFC PATCH net-next 0/2] more IPv4 unicast extensions

[RFC PATCH net-next 0/2] more IPv4 unicast extensions

[Dave Taht]

Adding support in linux for the 240/4 and 0/8 ipv4 address ranges were
easy, no brainer removals of obsolete support for obsolete
specifications. Has anyone noticed yet?

The following two patches are intended as discussion points fot
my https://linuxplumbersconf.org/event/4/contributions/457/
talk today.

Dave Taht (2):
  Allow 225/8-231/8 as unicast
  Reduce localhost to a /16

 include/linux/in.h | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

-- 
2.17.1

[RFC PATCH net-next 1/2] Allow 225/8-231/8 as unicast

[Dave Taht]

This patch converts the long "reserved for future use" multicast
address space, 225/8-231/8 - 120m addresses - for use as unicast
addresses instead.

In a comprehensive survey of all the open source code on the planet
we found no users of this range. We found some official and unofficial
usage of addresses in 224/8 and in 239/8 - both spaces at well under
50% allocation in the first place, so we anticipate no additional growth
for any reason, into the 225-231 spaces.

There will be some short term incompatabilities induced.

The principal flaw of converting this space to unicast involves
a non-uniext box, sending a packet to the formerly multicast address, 
and the reply coming back from that "formerly multicast" address
as unicast.

The return packet will be dropped because the source of the reply is unicast
(L2) with what the non-uniext box considers to be multicast (L3).

and, like all multicast packets sent anywhere, the attempt will still
flood all ports on the local switch.

A tcp attempt fails immediately due to the inherent IN_MULTICAST
check in the existing kernel. Some stacks (not linux) MAY do more 
of the wrong thing here.

As for userspace exposure...

We were only able to find 89 packages in fedora that used the IN_MULTICAST
macro. Currently the plan is not to kill IN_MULTICAST, (as doing it right
requires access to the big endian macros) but retire its usages in
the kernel (already done) and then the very few programs that use it userspace.

All the routing daemons we've inspected and modified don't use IN_MULTICAST.
The patches to them are trivial.

New users of multicast, seem to always pick something out of the 224/8
or 239/8 ranges, which are untouched by this patch.

Additional potential problems include: 

* hardware offloads that explicitly check for multicast
* binary firmware that explicitly checks for multicast
* a tiny cpu hit

Whether or not these problems are worth addressing to regain 120m
useful unicast addresses in the next decade is up for debate.

---
 include/linux/in.h | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/linux/in.h b/include/linux/in.h
index 1873ef642605..8665842a3589 100644
--- a/include/linux/in.h
+++ b/include/linux/in.h
@@ -42,7 +42,10 @@ static inline bool ipv4_is_loopback(__be32 addr)
 
 static inline bool ipv4_is_multicast(__be32 addr)
 {
-	return (addr & htonl(0xf0000000)) == htonl(0xe0000000);
+	if((addr & htonl(0xf0000000)) == htonl(0xe0000000))
+		return !((htonl(addr) >= 0xe1000000) &&
+			 (htonl(addr) < 0xe8000000));
+	return 0;
 }
 
 static inline bool ipv4_is_local_multicast(__be32 addr)
-- 
2.17.1

[RFC PATCH net-next 2/2] Reduce localhost to 127.0.0.0/16

[Dave Taht]

The 127 concept of "localhost" was  basically a straight port over from
original ARPANET behavior. At the time it was envisioned that
many services would exist in the mainframe that would need to be
individually addressable, and long predated alternative approaches
such as tipc, etc.

This reduces 127.0.0.0/8 to a /16, and opens up 127.1.0.0 and above
for use as real, unicast addresses either on the wire or internal
to containers, virtual machines, vpns, etc.

The only major uses of 127 to date have been (of
course) 127.0.0.1 and 127.0.1.1 (for dns), and various adhoc uses
for things like anti-spam daemons.

Linux also has a non-standard treatment of the entire 127 address
space - anything sent to any address there "just works". This patch
preserves that behavior for 127.0.0.0/16 only.

Other uses, such as ntp's 127.127 "handle" for it, doesn't actually
touch the stack.  We've seen 127.x used for chassis access and a few
other explicit uses in the field, but very little.

There is some small hope that we can preserve the original intent of
"localhost" in an age of stacked vms and containers, where instead of
using rfc1918 nat at each level, we can route, instead.


---
 include/linux/in.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/linux/in.h b/include/linux/in.h
index 8665842a3589..6e4f37e5bf51 100644
--- a/include/linux/in.h
+++ b/include/linux/in.h
@@ -37,7 +37,9 @@ static inline int proto_ports_offset(int proto)
 
 static inline bool ipv4_is_loopback(__be32 addr)
 {
-	return (addr & htonl(0xff000000)) == htonl(0x7f000000);
+	if((addr & htonl(0xff000000)) == htonl(0x7f000000))
+		return( addr & htonl(0x00ff0000)) == 0;
+	return 0;
 }
 
 static inline bool ipv4_is_multicast(__be32 addr)
-- 
2.17.1