Merge branch 'ipv4-unicast'

Seth David Schoen says:

====================
Treat IPv4 lowest address as ordinary unicast address

Treat the lowest address in a subnet (the address within the subnet
which contains all 0 bits) as an ordinary unicast address instead
of as a potential second broadcast address.  For example, in subnet
192.168.17.24/29, which contains 8 addresses, make address 192.168.17.24
usable as a normal unicast address (while continuing to support
192.168.17.31 as a broadcast address).

Since EVERY network number or subnet formerly had its host number 0
reserved, this patchset adds 1 more usable host address to every network
and subnet (i.e., 2^(32-n)-1 instead of 2^(32-n)-2 addresses available
for assignment on each IPv4 /n subnet).  For small subnets, this is a
significant gain; instead of 6 usable host addresses, a /29 would now
contain 7, a 16% increase.

The reserving of host number 0 for broadcast came about in RFC 1122 from
1989 (page 31, "IP addresses are not permitted to have the value 0 or -1
for any of the <Host-number>, <Network-number>, or <Subnet-number>
fields (except in the special cases listed above)" and page 66, "There
is a class of hosts [4.2BSD Unix and its derivatives, but not 4.3BSD]
that use non-standard broadcast address forms, substituting 0 for -1.
All hosts SHOULD recognize and accept any of these non-standard
broadcast addresses as the destination address of an incoming
datagram.").  This has been repeated in subsequent RFCs, always with
backwards-compatibility rationales.  Network troubles (broadcast storms)
ensued when some early hosts on a LAN treated the lowest address as
unicast and others treated it as broadcast.  Multiple 1989 changes to IP
successfully prevented these.  The key was adding the layering violation
rule requiring hosts to ignore all IP datagrams with unicast destination
addresses that were received in low-level (Ethernet) broadcasts.  That
change is still in effect, and this patchset does not alter it.  All
operating systems since 4.3BSD, including all the current BSD OSes, now
use the standard IP broadcast address.  4.2BSD has been obsolete for
more than 30 years, and all modern hosts ignore hardware broadcasts
containing unicast IP addresses, so there is no modern likelihood of
broadcast storms even when hosts disagree on the unicast vs. broadcast
status of a given address.

Tests with this patchset show that other Linux hosts on the local segment
simply ignore a host numbered with the lowest address, both for incoming
and outgoing packet purposes.  They don't interoperate with it, but they
also don't cause broadcast storms or any other malfunction.  If patched,
they have no trouble interoperating with a host at the lowest address.

Unmodified "distant" hosts that are not on the same segment successfully
interoperate, as long as the gateway on the local segment, and the local
host itself using the lowest address, have this patch.  (Distant hosts
have no way of knowing whether a given address is the lowest address
in a faraway network segment, so they treat it no differently than any
other unicast address.)  This means that each local site can change this
behavior locally, resulting immediately in global interoperability with
the newly usable lowest local address.

Modern software and documentation continues to use the definition of the
directed, or "net-directed", broadcast address as "a host ID of all one
bits".  The Internet no longer gets any benefit from having two different
broadcast addresses usable on every Ethernet segment.  I have not been
able to find any documentation that suggests that users or software should
ever intentionally use the all-zero form, or that justifies it other than
as a historic Berkeleyism.  RFCs 1112, 1812, and 3021 state that hosts and
routers need to maintain compatibility with the old form -- but they give
no rationale other than the past existence of the 4.2BSD behavior.

We're happy to provide more historical details or information about
behavior of other systems in this regard by e-mail or as future patches
to kernel documentation files.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

net/ipv4/fib_frontend.c

@@ -1122,10 +1122,8 @@ void fib_add_ifaddr(struct in_ifaddr *ifa)
 				  prefix, ifa->ifa_prefixlen, prim,
 				  ifa->ifa_rt_priority);
 
-		/* Add network specific broadcasts, when it takes a sense */
+		/* Add the network broadcast address, when it makes sense */
 		if (ifa->ifa_prefixlen < 31) {
-			fib_magic(RTM_NEWROUTE, RTN_BROADCAST, prefix, 32,
-				  prim, 0);
 			fib_magic(RTM_NEWROUTE, RTN_BROADCAST, prefix | ~mask,
 				  32, prim, 0);
 		}

tools/testing/selftests/net/unicast_extensions.sh

@@ -189,6 +189,15 @@ segmenttest 255.255.255.1 255.255.255.254 24 "assign and ping inside 255.255.255
 route_test 240.5.6.7 240.5.6.1  255.1.2.1    255.1.2.3      24 "route between 240.5.6/24 and 255.1.2/24 (is allowed)"
 route_test 0.200.6.7 0.200.38.1 245.99.101.1 245.99.200.111 16 "route between 0.200/16 and 245.99/16 (is allowed)"
 #
+# Test support for lowest address ending in .0
+segmenttest 5.10.15.20 5.10.15.0 24 "assign and ping lowest address (/24)"
+#
+# Test support for lowest address not ending in .0
+segmenttest 192.168.101.192 192.168.101.193 26 "assign and ping lowest address (/26)"
+#
+# Routing using lowest address as a gateway/endpoint
+route_test 192.168.42.1 192.168.42.0 9.8.7.6 9.8.7.0 24 "routing using lowest address"
+#
 # ==============================================
 # ==== TESTS THAT CURRENTLY EXPECT FAILURE =====
 # ==============================================
@@ -202,14 +211,6 @@ segmenttest 255.255.255.1 255.255.255.255 16 "assigning 255.255.255.255 (is forb
 # Currently Linux does not allow this, so this should fail too
 segmenttest 127.99.4.5 127.99.4.6 16 "assign and ping inside 127/8 (is forbidden)"
 #
-# Test support for lowest address
-# Currently Linux does not allow this, so this should fail too
-segmenttest 5.10.15.20 5.10.15.0 24 "assign and ping lowest address (is forbidden)"
-#
-# Routing using lowest address as a gateway/endpoint
-# Currently Linux does not allow this, so this should fail too
-route_test 192.168.42.1 192.168.42.0 9.8.7.6 9.8.7.0 24 "routing using lowest address (is forbidden)"
-#
 # Test support for unicast use of class D
 # Currently Linux does not allow this, so this should fail too
 segmenttest 225.1.2.3 225.1.2.200 24 "assign and ping class D address (is forbidden)"