| Message ID | 1560442237-6336-2-git-send-email-dave.taht@gmail.com |
|---|---|
| State | RFC |
| Delegated to: | David Miller |
| Headers | show |
| Series | Allow 0.0.0.0/8 as a valid address range | expand |
Dave Taht <dave.taht@gmail.com> writes: > The longstanding prohibition against using 0.0.0.0/8 dates back > to two issues with the early internet. > > There was an interoperability problem with BSD 4.2 in 1984, fixed in > BSD 4.3 in 1986. BSD 4.2 has long since been retired. > > Secondly, addresses of the form 0.x.y.z were initially defined only as > a source address in an ICMP datagram, indicating "node number x.y.z on > this IPv4 network", by nodes that know their address on their local > network, but do not yet know their network prefix, in RFC0792 (page > 19). This usage of 0.x.y.z was later repealed in RFC1122 (section > 3.2.2.7), because the original ICMP-based mechanism for learning the > network prefix was unworkable on many networks such as Ethernet (which > have longer addresses that would not fit into the 24 "node number" > bits). Modern networks use reverse ARP (RFC0903) or BOOTP (RFC0951) > or DHCP (RFC2131) to find their full 32-bit address and CIDR netmask > (and other parameters such as default gateways). 0.x.y.z has had > 16,777,215 addresses in 0.0.0.0/8 space left unused and reserved for > future use, since 1989. > > This patch allows for these 16m new IPv4 addresses to appear within > a box or on the wire. Layer 2 switches don't care. > > 0.0.0.0/32 is still prohibited, of course. > > Signed-off-by: Dave Taht <dave.taht@gmail.com> Well, I see no reason why we shouldn't allow this. Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
diff --git a/include/linux/in.h b/include/linux/in.h index 4d2fedfb753a..1873ef642605 100644 --- a/include/linux/in.h +++ b/include/linux/in.h @@ -63,7 +63,7 @@ static inline bool ipv4_is_all_snoopers(__be32 addr) static inline bool ipv4_is_zeronet(__be32 addr) { - return (addr & htonl(0xff000000)) == htonl(0x00000000); + return (addr == 0); } /* Special-Use IPv4 Addresses (RFC3330) */
The longstanding prohibition against using 0.0.0.0/8 dates back to two issues with the early internet. There was an interoperability problem with BSD 4.2 in 1984, fixed in BSD 4.3 in 1986. BSD 4.2 has long since been retired. Secondly, addresses of the form 0.x.y.z were initially defined only as a source address in an ICMP datagram, indicating "node number x.y.z on this IPv4 network", by nodes that know their address on their local network, but do not yet know their network prefix, in RFC0792 (page 19). This usage of 0.x.y.z was later repealed in RFC1122 (section 3.2.2.7), because the original ICMP-based mechanism for learning the network prefix was unworkable on many networks such as Ethernet (which have longer addresses that would not fit into the 24 "node number" bits). Modern networks use reverse ARP (RFC0903) or BOOTP (RFC0951) or DHCP (RFC2131) to find their full 32-bit address and CIDR netmask (and other parameters such as default gateways). 0.x.y.z has had 16,777,215 addresses in 0.0.0.0/8 space left unused and reserved for future use, since 1989. This patch allows for these 16m new IPv4 addresses to appear within a box or on the wire. Layer 2 switches don't care. 0.0.0.0/32 is still prohibited, of course. Signed-off-by: Dave Taht <dave.taht@gmail.com> --- include/linux/in.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)