mirror of
https://github.com/dtaht/unicast-extensions.git
synced 2024-05-11 05:55:07 +00:00
Dave Taht
81 lines
2.9 KiB
Diff
81 lines
2.9 KiB
Diff
From 3ae2dcc876f237f886da9426aded7e6e9e88fbe9 Mon Sep 17 00:00:00 2001
|
|
From: Dave Taht <[email protected]>
|
|
Date: Sun, 18 Aug 2019 16:53:59 +0000
|
|
Subject: [RFC PATCH 1/2] Allow 225/8-231/8 as unicast
|
|
|
|
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.
|
|
|
|
# I really struggled with this - need to make a clear distinction
|
|
# between layer 2 and 3 - I have caps of this behavior
|
|
|
|
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 mcast
|
|
* 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
|
|
|