Netdev Archive on lore.kernel.org
 help / color / Atom feed
* [net-next 0/1] Allow 0.0.0.0/8 as a valid address range
@ 2019-06-22 17:07 Dave Taht
  2019-06-22 17:07 ` [PATCH net-next 1/1] " Dave Taht
  0 siblings, 1 reply; 4+ messages in thread
From: Dave Taht @ 2019-06-22 17:07 UTC (permalink / raw)
  To: netdev; +Cc: Dave Taht

My talk's slides and video at netdev 0x13 about

"Potential IPv4 Unicast expansions" is up, here: 

https://netdevconf.org/0x13/session.html?talk-ipv4-unicast-expansions

There are roughly 419 million IPv4 addresses that are unallocated and
unused in the 0, localhost, reserved future multicast, and 240/4
spaces.

Linux already supports 240/4 fully. SDN's such as AWS already support
the entire IPv4 address space as a unicast playground.

This first patch for 0/8 was intended primarily as a conversation
starter - arguably we should rename the function across 22 fairly
"hot" files - but:

Should Linux treat these ranges as policy, and no longer enforce via
mechanism?

A full patchset for adding 225-232, and 127 address spaces is on github:
https://github.com/dtaht/unicast-extensions

with the very few needed patches for routing daemons and BSD also
available there.

Dave Taht (1):
  Allow 0.0.0.0/8 as a valid address range

 include/linux/in.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.17.1


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [PATCH net-next 1/1] Allow 0.0.0.0/8 as a valid address range
  2019-06-22 17:07 [net-next 0/1] Allow 0.0.0.0/8 as a valid address range Dave Taht
@ 2019-06-22 17:07 ` " Dave Taht
  2019-06-26 20:20   ` David Miller
  0 siblings, 1 reply; 4+ messages in thread
From: Dave Taht @ 2019-06-22 17:07 UTC (permalink / raw)
  To: netdev; +Cc: Dave Taht, John Gilmore

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>
Signed-off-by: John Gilmore <gnu@toad.com>
Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>

---
 include/linux/in.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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) */
-- 
2.17.1


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH net-next 1/1] Allow 0.0.0.0/8 as a valid address range
  2019-06-22 17:07 ` [PATCH net-next 1/1] " Dave Taht
@ 2019-06-26 20:20   ` David Miller
  2019-07-14  3:57     ` Paul Marks
  0 siblings, 1 reply; 4+ messages in thread
From: David Miller @ 2019-06-26 20:20 UTC (permalink / raw)
  To: dave.taht; +Cc: netdev, gnu

From: Dave Taht <dave.taht@gmail.com>
Date: Sat, 22 Jun 2019 10:07:34 -0700

> 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>
> Signed-off-by: John Gilmore <gnu@toad.com>
> Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>

Applied, thanks for following up on this.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH net-next 1/1] Allow 0.0.0.0/8 as a valid address range
  2019-06-26 20:20   ` David Miller
@ 2019-07-14  3:57     ` Paul Marks
  0 siblings, 0 replies; 4+ messages in thread
From: Paul Marks @ 2019-07-14  3:57 UTC (permalink / raw)
  To: David Miller; +Cc: dave.taht, netdev, gnu

On Wed, Jun 26, 2019 at 1:20 PM David Miller <davem@davemloft.net> wrote:
>
> From: Dave Taht <dave.taht@gmail.com>
> Date: Sat, 22 Jun 2019 10:07:34 -0700
>
> > 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>
> > Signed-off-by: John Gilmore <gnu@toad.com>
> > Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
>
> Applied, thanks for following up on this.

This breaks an undocumented feature of Linux:

$ telnet 0.0.0.1 22
Trying 0.0.0.1...
telnet: Unable to connect to remote host: Invalid argument

It's sometimes useful to put 0.x.x.x in command-line flags,
/etc/hosts, or other config files, because it forces connect() to fail
immediately, instead of sending packets and waiting for a timeout.

Given that this has been user-visible for decades, is it a good idea
to pull out the rug?

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-22 17:07 [net-next 0/1] Allow 0.0.0.0/8 as a valid address range Dave Taht
2019-06-22 17:07 ` [PATCH net-next 1/1] " Dave Taht
2019-06-26 20:20   ` David Miller
2019-07-14  3:57     ` Paul Marks

Netdev Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/netdev/0 netdev/git/0.git
	git clone --mirror https://lore.kernel.org/netdev/1 netdev/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 netdev netdev/ https://lore.kernel.org/netdev \
		netdev@vger.kernel.org netdev@archiver.kernel.org
	public-inbox-index netdev


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.netdev


AGPL code for this site: git clone https://public-inbox.org/ public-inbox