Skip to contentSkip to conversation

ipv4: enable use of 240/4 address space

PATCH In review Vince Fuller 5 participants 20 messages Jan 8, 2008 – Jan 21, 2008

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 ipv4: enable use of 240/4 address space

from Vince Fuller <[email protected]>

This set of diffs modify the 2.6.20 kernel to enable use of the 240/4 (aka "class-E") address space as consistent with the Internet Draft draft-fuller-240space-00.txt.

---

linux/in.h renamed from linux/in.h.orig +8 -0
@@ -215,8 +215,16 @@ struct sockaddr_in {
 #define	IN_MULTICAST(a)		IN_CLASSD(a)
 #define IN_MULTICAST_NET	0xF0000000
 
+#define IN_CLASSE(a)		((((long int) (a)) & 0xf0000000) == 0xf0000000)
+#define	IN_CLASSE_NET		0xffffff00
+#define	IN_CLASSE_NSHIFT	8
+#define	IN_CLASSE_HOST		(0xffffffff & ~IN_CLASSE_NET)
+
+/* 
+ * these are no longer used
 #define	IN_EXPERIMENTAL(a)	((((long int) (a)) & 0xf0000000) == 0xf0000000)
 #define	IN_BADCLASS(a)		IN_EXPERIMENTAL((a))
+*/
 
 /* Address to accept any incoming messages. */
 #define	INADDR_ANY		((unsigned long int) 0x00000000)
ipv4/devinet.c renamed from ipv4/devinet.c.orig +2 -0
@@ -594,6 +594,8 @@ static __inline__ int inet_abc_len(__be3
 			rc = 16;
 		else if (IN_CLASSC(haddr))
 			rc = 24;
+		else if (IN_CLASSE(haddr))
+			rc = 24;
 	}
 
   	return rc;
ipv4/fib_frontend.c renamed from ipv4/fib_frontend.c.orig +1 -1
@@ -152,7 +152,7 @@ unsigned inet_addr_type(__be32 addr)
 	struct fib_result	res;
 	unsigned ret = RTN_BROADCAST;
 
-	if (ZERONET(addr) || BADCLASS(addr))
+	if (ZERONET(addr) || addr == INADDR_BROADCAST)
 		return RTN_BROADCAST;
 	if (MULTICAST(addr))
 		return RTN_MULTICAST;
ipv4/ipconfig.c renamed from ipv4/ipconfig.c.orig +2 -0
@@ -379,6 +379,8 @@ static int __init ic_defaults(void)
 			ic_netmask = htonl(IN_CLASSB_NET);
 		else if (IN_CLASSC(ntohl(ic_myaddr)))
 			ic_netmask = htonl(IN_CLASSC_NET);
+		else if (IN_CLASSE(ntohl(ic_myaddr)))
+			ic_netmask = htonl(IN_CLASSE_NET);
 		else {
 			printk(KERN_ERR "IP-Config: Unable to guess netmask for address %u.%u.%u.%u\n",
 				NIPQUAD(ic_myaddr));
ipv4/route.c renamed from ipv4/route.c.orig +6 -6
@@ -1140,7 +1140,7 @@ void ip_rt_redirect(__be32 old_gw, __be3
 		return;
 
 	if (new_gw == old_gw || !IN_DEV_RX_REDIRECTS(in_dev)
-	    || MULTICAST(new_gw) || BADCLASS(new_gw) || ZERONET(new_gw))
+	    || MULTICAST(new_gw) || new_gw == INADDR_BROADCAST || ZERONET(new_gw))
 		goto reject_redirect;
 
 	if (!IN_DEV_SHARED_MEDIA(in_dev)) {
@@ -1617,7 +1617,7 @@ static int ip_route_input_mc(struct sk_b
 	if (in_dev == NULL)
 		return -EINVAL;
 
-	if (MULTICAST(saddr) || BADCLASS(saddr) || LOOPBACK(saddr) ||
+	if (MULTICAST(saddr) || saddr == INADDR_BROADCAST || LOOPBACK(saddr) ||
 	    skb->protocol != htons(ETH_P_IP))
 		goto e_inval;
 
@@ -1935,7 +1935,7 @@ static int ip_route_input_slow(struct sk
 	   by fib_lookup.
 	 */
 
-	if (MULTICAST(saddr) || BADCLASS(saddr) || LOOPBACK(saddr))
+	if (MULTICAST(saddr) || saddr == INADDR_BROADCAST || LOOPBACK(saddr))
 		goto martian_source;
 
 	if (daddr == htonl(0xFFFFFFFF) || (saddr == 0 && daddr == 0))
@@ -1947,7 +1947,7 @@ static int ip_route_input_slow(struct sk
 	if (ZERONET(saddr))
 		goto martian_source;
 
-	if (BADCLASS(daddr) || ZERONET(daddr) || LOOPBACK(daddr))
+	if (ZERONET(daddr) || LOOPBACK(daddr))
 		goto martian_destination;
 
 	/*
@@ -2171,7 +2171,7 @@ static inline int __mkroute_output(struc
 		res->type = RTN_BROADCAST;
 	else if (MULTICAST(fl->fl4_dst))
 		res->type = RTN_MULTICAST;
-	else if (BADCLASS(fl->fl4_dst) || ZERONET(fl->fl4_dst))
+	else if (ZERONET(fl->fl4_dst))
 		return -EINVAL;
 
 	if (dev_out->flags & IFF_LOOPBACK)
@@ -2391,7 +2391,7 @@ static int ip_route_output_slow(struct r
 	if (oldflp->fl4_src) {
 		err = -EINVAL;
 		if (MULTICAST(oldflp->fl4_src) ||
-		    BADCLASS(oldflp->fl4_src) ||
+		    oldflp->fl4_src == INADDR_BROADCAST ||
 		    ZERONET(oldflp->fl4_src))
 			goto out;
 
maintainer
#1 lore raw

From: Vince Fuller <[email protected]>
Date: Mon, 7 Jan 2008 17:10:57 -0800

Quoted 7 lines

from Vince Fuller <[email protected]>

This set of diffs modify the 2.6.20 kernel to enable use of the 240/4 (aka "class-E") address space as consistent with the Internet Draft draft-fuller-240space-00.txt.

There has been more than 90K worth of changes to the files you are changing since 2.6.20

It is generally unwise to submit patches against such old kernel versions, they rarely apply, so please respin your patch against more current sources.

Please also remove the trailing whitespace, like the one found here:

+#define IN_CLASSE_HOST (0xffffffff & ~IN_CLASSE_NET)
+
+/*
^^^^^

Thanks.

#2 lore raw
In reply to Vince Fuller
Quoted 5 lines · Vince Fuller

from Vince Fuller <[email protected]>

This set of diffs modify the 2.6.20 kernel to enable use of the 240/4 (aka "class-E") address space as consistent with the Internet Draft draft-fuller-240space-00.txt.

Wouldn't it be wise to at least wait for it becoming an RFC first?

-Andi

#3 lore raw

In article <[email protected]> (at Fri, 11 Jan 2008 12:17:02 +0100), Andi Kleen <[email protected]> says:

Quoted 9 lines
Quoted 5 lines · Vince Fuller

from Vince Fuller <[email protected]>

This set of diffs modify the 2.6.20 kernel to enable use of the 240/4 (aka "class-E") address space as consistent with the Internet Draft draft-fuller-240space-00.txt.

Wouldn't it be wise to at least wait for it becoming an RFC first?

I do think so, too.

There is no positive consesus on this draft
at the intarea meeting in Vancouver, right?

We cannot / should not enable that space until we have reached a consensus on it.

--yoshfuji

maintainer
#4 lore raw

From: YOSHIFUJI Hideaki / 吉藤英明 <[email protected]>
Date: Fri, 11 Jan 2008 21:41:20 +0900 (JST)

Quoted 5 lines

There is no positive consesus on this draft
at the intarea meeting in Vancouver, right?

We cannot / should not enable that space until we have reached a consensus on it.

This is so incredibly incorrect.

There is consensus on making network stacks able to use this address space. And that is all that the patch does.

The consensus is only missing on whether to make the address space public or private.

This is also clearly spelled out in the draft.

It is important to get as large of a head start on this as possible because of how long it takes to deploy something like this.

#5 lore raw

In article <[email protected]> (at Fri, 11 Jan 2008 17:48:57 -0800 (PST)), David Miller <[email protected]> says:

Quoted 6 lines

From: YOSHIFUJI Hideaki / 吉藤英明 <[email protected]>
Date: Fri, 11 Jan 2008 21:41:20 +0900 (JST)

Quoted 3 lines

There is no positive consesus on this draft
at the intarea meeting in Vancouver, right?

Quoted 7 lines
Quoted 2 lines

We cannot / should not enable that space until we have reached a consensus on it.

This is so incredibly incorrect.

There is consensus on making network stacks able to use this address space. And that is all that the patch does.

No, we did never make consensus on it.

Quoted 8 lines

The consensus is only missing on whether to make the address space public or private.

This is also clearly spelled out in the draft.

It is important to get as large of a head start on this as possible because of how long it takes to deploy something like this.

Okay, though I am afraid this space will not be used widely, we should be ready for it.

I'll make some more comments on the patch itself from another point view.

--yoshfuji

#6 lore raw
In reply to Andi Kleen
Quoted 9 lines · Andi Kleen
Quoted 5 lines · Vince Fuller

from Vince Fuller <[email protected]>

This set of diffs modify the 2.6.20 kernel to enable use of the 240/4 (aka "class-E") address space as consistent with the Internet Draft draft-fuller-240space-00.txt.

Wouldn't it be wise to at least wait for it becoming an RFC first?

There is reasonable consensus on making use of 240/4; some applications, such as ISAKMP and automatic ipv6-to-IPv4 tunneling, still need to determine if they should treat the space as "public" or "private" but that shouldn't affect whether kernel support is added.

Solaris recently added support for 240/4 and OSX already has it. I thought the Linux kernel developers might appreciate having patches to do likewise.

I leave it up to you, the developers, to decide if you want to use these patches.

	--Vince
maintainer
#7 lore raw

From: Vince Fuller <[email protected]>
Date: Fri, 11 Jan 2008 09:29:15 -0800

Quoted 2 lines

I leave it up to you, the developers, to decide if you want to use these patches.

Vince, please just ignore these turkeys who are dismissing your patch and respin it against current sources as I asked of you.

I'll apply it, immediately, because it is the only correct course of action.

Thanks a lot.

#8 lore raw
Quoted 6 lines · David Miller

From: Vince Fuller <[email protected]>
Date: Fri, 11 Jan 2008 09:29:15 -0800

Quoted 2 lines

I leave it up to you, the developers, to decide if you want to use these patches.

Quoted 6 lines

Vince, please just ignore these turkeys who are dismissing your patch and respin it against current sources as I asked of you.

I'll apply it, immediately, because it is the only correct course of action.

I strongly agree. Linux should set standards, or at least help them become one.

#9 lore raw
In reply to Vince Fuller

Hello.

In article <[email protected]> (at Mon, 7 Jan 2008 17:10:57 -0800), Vince Fuller <[email protected]> says:

linux/in.h struct sockaddr_in { · line 227

Quoted 12 lines

#define IN_MULTICAST_NET 0xF0000000

linux/in.h renamed from linux/in.h.orig +8 -0
+#define IN_CLASSE(a)		((((long int) (a)) & 0xf0000000) == 0xf0000000)
+#define	IN_CLASSE_NET		0xffffff00
+#define	IN_CLASSE_NSHIFT	8
+#define	IN_CLASSE_HOST		(0xffffffff & ~IN_CLASSE_NET)
+
+/* 
+ * these are no longer used
 #define	IN_EXPERIMENTAL(a)	((((long int) (a)) & 0xf0000000) == 0xf0000000)
 #define	IN_BADCLASS(a)		IN_EXPERIMENTAL((a))
+*/

Please do not remove this, but have these instead:

#define IN_EXPERIMENTAL(a) IN_CLASSE((a))
#define IN_BADCASS(a) IN_CLASSE((a))

And, I think it is good to remove BADCLASS() (inside #ifdef __KERNEL__ .. #endif) because we do not have its users any longer, right?

Regards,

--yoshfuji

#10 lore raw
In reply to Vince Fuller

ipv4/devinet.c static __inline__ int inet_abc_len(__be3 · line 601

Quoted 11 lines · Vince Fuller
ipv4/devinet.c renamed from ipv4/devinet.c.orig +2 -0
@@ -594,6 +594,8 @@ static __inline__ int inet_abc_len(__be3
 			rc = 16;
 		else if (IN_CLASSC(haddr))
 			rc = 24;
+		else if (IN_CLASSE(haddr))
+			rc = 24;
 	}
 
  	return rc;

Any particular reason why 24?

#11 lore raw
Quoted 12 lines · Jan Engelhardt
Quoted 10 lines · Vince Fuller
ipv4/devinet.c renamed from ipv4/devinet.c.orig +2 -0
@@ -594,6 +594,8 @@ static __inline__ int inet_abc_len(__be3
 			rc = 16;
 		else if (IN_CLASSC(haddr))
 			rc = 24;
+		else if (IN_CLASSE(haddr))
+			rc = 24;
 	}
 
Quoted 3 lines

ipv4/devinet.c static __inline__ int inet_abc_len(__be3 · line 601

Quoted 1 line
ipv4/devinet.c renamed from ipv4/devinet.c.orig +0 -0
  	return rc;

Any particular reason why 24?

Using the same default as old-style "class-C" seemed to be the most expedient thing to do.

In normal practice, the mask should be explicitly configured so this case should not be frequently encountered.

	--Vince
#12 lore raw

PATCH 1/1 IPv4: Enable use of 240/4 address space

In reply to Vince Fuller
Quoted 5 lines · Vince Fuller

This set of diffs modify the 2.6.20 kernel to enable use of the 240/4 (aka "class-E") address space as consistent with the Internet Draft draft-fuller-240space-00.txt.

Below is a patch against davem/net-2.6.25. It might look very spartan, but that is actually all that is needed on a sane system. No class E macros or so needed.

Only the ipv4_is_badclass() might need renaming if you think it really needs a name change. Or maybe a comment. Comments please :)

===
ancestor 7651a1f7ebe567f9088283f6354a5634b5dccb8e
commit 44762168d7cbefc4f8753a79d99a761cbd9875d9

Author: Jan Engelhardt <[email protected]>
Date:   Fri Jan 18 02:10:44 2008 +0100

IPv4: enable use of 240/4 address space

This short patch modifies the IPv4 networking to enable use of the 240.0.0.0/4 (aka "class-E") address space as propsed in the internet draft draft-fuller-240space-00.txt.

include/linux/in.h +1 -4
index 27d8a5a..b01bf75 100644
@@ -216,9 +216,6 @@ struct sockaddr_in {
 #define	IN_MULTICAST(a)		IN_CLASSD(a)
 #define IN_MULTICAST_NET	0xF0000000
 
-#define	IN_EXPERIMENTAL(a)	((((long int) (a)) & 0xf0000000) == 0xf0000000)
-#define	IN_BADCLASS(a)		IN_EXPERIMENTAL((a))
-
 /* Address to accept any incoming messages. */
 #define	INADDR_ANY		((unsigned long int) 0x00000000)
 
@@ -264,7 +261,7 @@ static inline bool ipv4_is_local_multicast(__be32 addr)
 
 static inline bool ipv4_is_badclass(__be32 addr)
 {
-	return (addr & htonl(0xf0000000)) == htonl(0xf0000000);
+	return addr == 0xFFFFFFFF;
 }
 
 static inline bool ipv4_is_zeronet(__be32 addr)
#13 lore raw

Re: [PATCH] IPv4: Enable use of 240/4 address space

In article <[email protected]> (at Fri, 18 Jan 2008 02:13:52 +0100 (CET)), Jan Engelhardt <[email protected]> says:

Quoted 5 lines
include/linux/in.h +0 -0
index 27d8a5a..b01bf75 100644

include/linux/in.h struct sockaddr_in { · line 221

Quoted 9 lines
include/linux/in.h +0 -3
@@ -216,9 +216,6 @@ struct sockaddr_in {
 #define	IN_MULTICAST(a)		IN_CLASSD(a)
 #define IN_MULTICAST_NET	0xF0000000
 
-#define	IN_EXPERIMENTAL(a)	((((long int) (a)) & 0xf0000000) == 0xf0000000)
-#define	IN_BADCLASS(a)		IN_EXPERIMENTAL((a))
-
 /* Address to accept any incoming messages. */
 #define	INADDR_ANY		((unsigned long int) 0x00000000)
 

No, please keep these macros.

include/linux/in.h static inline bool ipv4_is_local_multicast(__be32 addr) · line 266

Quoted 8 lines
include/linux/in.h +1 -1
@@ -264,7 +261,7 @@ static inline bool ipv4_is_local_multicast(__be32 addr)
 
 static inline bool ipv4_is_badclass(__be32 addr)
 {
-	return (addr & htonl(0xf0000000)) == htonl(0xf0000000);
+	return addr == 0xFFFFFFFF;
 }
 

To (un)align the IN_BADCLASS macro and ipv6_is_badclass() definition, you should change the name anyway, e.g., ipv6_is_limited_broadcast() or some something alike.

--yoshfuji

#14 lore raw

Re: [PATCH] IPv4: Enable use of 240/4 address space

Quoted 7 lines · YOSHIFUJI Hideaki / 吉藤英明

Review

Quoted 2 lines
(quoted diff) +0 -2
-#define	IN_EXPERIMENTAL(a)	((((long int) (a)) & 0xf0000000) == 0xf0000000)
-#define	IN_BADCLASS(a)		IN_EXPERIMENTAL((a))

No, please keep these macros.

Quoted 2 lines
(quoted diff) +0 -0
@@ -264,7 +261,7 @@ static inline bool ipv4_is_local_multicast(__be32 addr)
 
Quoted 8 lines

Review static inline bool ipv4_is_local_multicast(__be32 addr) · line 266

Quoted 6 lines
(quoted diff) +1 -1
 static inline bool ipv4_is_badclass(__be32 addr)
 {
-	return (addr & htonl(0xf0000000)) == htonl(0xf0000000);
+	return addr == 0xFFFFFFFF;
 }
 

To (un)align the IN_BADCLASS macro and ipv6_is_badclass() definition,

Unalign? IPv6? "Limited" broadcast?

Quoted 2 lines

you should change the name anyway, e.g., ipv6_is_limited_broadcast() or some something alike.

===

Author: Jan Engelhardt <[email protected]>
Date:   Fri Jan 18 02:51:34 2008 +0100

IPv4: enable use of 240/4 address space

This short patch modifies the IPv4 networking to enable use of the 240.0.0.0/4 (aka "class-E") address space as propsed in the internet draft draft-fuller-240space-00.txt.

include/linux/in.h +2 -2
index 27d8a5a..4887768 100644
@@ -262,9 +262,9 @@ static inline bool ipv4_is_local_multicast(__be32 addr)
 	return (addr & htonl(0xffffff00)) == htonl(0xe0000000);
 }
 
-static inline bool ipv4_is_badclass(__be32 addr)
+static inline bool ipv4_is_broadcast(__be32 addr)
 {
-	return (addr & htonl(0xf0000000)) == htonl(0xf0000000);
+	return addr == 0xFFFFFFFF;
 }
 
 static inline bool ipv4_is_zeronet(__be32 addr)
include/net/addrconf.h +1 -1
index 8b1509b..f5bd33b 100644
@@ -262,7 +262,7 @@ static inline int ipv6_isatap_eui64(u8 *eui, __be32 addr)
 		  ipv4_is_private_172(addr) || ipv4_is_test_192(addr) ||
 		  ipv4_is_anycast_6to4(addr) || ipv4_is_private_192(addr) ||
 		  ipv4_is_test_198(addr) || ipv4_is_multicast(addr) ||
-		  ipv4_is_badclass(addr)) ? 0x00 : 0x02;
+		  ipv4_is_broadcast(addr)) ? 0x00 : 0x02;
 	eui[1] = 0;
 	eui[2] = 0x5E;
 	eui[3] = 0xFE;
net/core/pktgen.c +1 -1
index d18fdb1..9d6e7af 100644
@@ -2266,7 +2266,7 @@ static void mod_cur_headers(struct pktgen_dev *pkt_dev)
 
 					while (ipv4_is_loopback(s) ||
 					       ipv4_is_multicast(s) ||
-					       ipv4_is_badclass(s) ||
+					       ipv4_is_broadcast(s) ||
 					       ipv4_is_zeronet(s) ||
 					       ipv4_is_local_multicast(s)) {
 						t = random32() % (imx - imn) + imn;
net/ipv4/fib_frontend.c +1 -1
index 8ddcd3f..367e097 100644
@@ -176,7 +176,7 @@ static inline unsigned __inet_dev_addr_type(struct net *net,
 	unsigned ret = RTN_BROADCAST;
 	struct fib_table *local_table;
 
-	if (ipv4_is_zeronet(addr) || ipv4_is_badclass(addr))
+	if (ipv4_is_zeronet(addr) || ipv4_is_broadcast(addr))
 		return RTN_BROADCAST;
 	if (ipv4_is_multicast(addr))
 		return RTN_MULTICAST;
net/ipv4/route.c +6 -6
index 1e59c0d..9f0ea73 100644
@@ -1154,7 +1154,7 @@ void ip_rt_redirect(__be32 old_gw, __be32 daddr, __be32 new_gw,
 		return;
 
 	if (new_gw == old_gw || !IN_DEV_RX_REDIRECTS(in_dev)
-	    || ipv4_is_multicast(new_gw) || ipv4_is_badclass(new_gw)
+	    || ipv4_is_multicast(new_gw) || ipv4_is_broadcast(new_gw)
 	    || ipv4_is_zeronet(new_gw))
 		goto reject_redirect;
 
@@ -1634,7 +1634,7 @@ static int ip_route_input_mc(struct sk_buff *skb, __be32 daddr, __be32 saddr,
 	if (in_dev == NULL)
 		return -EINVAL;
 
-	if (ipv4_is_multicast(saddr) || ipv4_is_badclass(saddr) ||
+	if (ipv4_is_multicast(saddr) || ipv4_is_broadcast(saddr) ||
 	    ipv4_is_loopback(saddr) || skb->protocol != htons(ETH_P_IP))
 		goto e_inval;
 
@@ -1891,7 +1891,7 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
 	   by fib_lookup.
 	 */
 
-	if (ipv4_is_multicast(saddr) || ipv4_is_badclass(saddr) ||
+	if (ipv4_is_multicast(saddr) || ipv4_is_broadcast(saddr) ||
 	    ipv4_is_loopback(saddr))
 		goto martian_source;
 
@@ -1904,7 +1904,7 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
 	if (ipv4_is_zeronet(saddr))
 		goto martian_source;
 
-	if (ipv4_is_badclass(daddr) || ipv4_is_zeronet(daddr) ||
+	if (ipv4_is_broadcast(daddr) || ipv4_is_zeronet(daddr) ||
 	    ipv4_is_loopback(daddr))
 		goto martian_destination;
 
@@ -2125,7 +2125,7 @@ static inline int __mkroute_output(struct rtable **result,
 		res->type = RTN_BROADCAST;
 	else if (ipv4_is_multicast(fl->fl4_dst))
 		res->type = RTN_MULTICAST;
-	else if (ipv4_is_badclass(fl->fl4_dst) || ipv4_is_zeronet(fl->fl4_dst))
+	else if (ipv4_is_broadcast(fl->fl4_dst) || ipv4_is_zeronet(fl->fl4_dst))
 		return -EINVAL;
 
 	if (dev_out->flags & IFF_LOOPBACK)
@@ -2276,7 +2276,7 @@ static int ip_route_output_slow(struct rtable **rp, const struct flowi *oldflp)
 	if (oldflp->fl4_src) {
 		err = -EINVAL;
 		if (ipv4_is_multicast(oldflp->fl4_src) ||
-		    ipv4_is_badclass(oldflp->fl4_src) ||
+		    ipv4_is_broadcast(oldflp->fl4_src) ||
 		    ipv4_is_zeronet(oldflp->fl4_src))
 			goto out;
 
#15 lore raw

Re: [PATCH] IPv4: Enable use of 240/4 address space

In article <[email protected]> (at Fri, 18 Jan 2008 02:52:08 +0100 (CET)), Jan Engelhardt <[email protected]> says:

Quoted 18 lines · YOSHIFUJI Hideaki / 吉藤英明
Quoted 7 lines

Review

Quoted 2 lines
(quoted diff) +0 -2
-#define	IN_EXPERIMENTAL(a)	((((long int) (a)) & 0xf0000000) == 0xf0000000)
-#define	IN_BADCLASS(a)		IN_EXPERIMENTAL((a))

No, please keep these macros.

Quoted 2 lines
(quoted diff) +0 -0
@@ -264,7 +261,7 @@ static inline bool ipv4_is_local_multicast(__be32 addr)
 
Quoted 8 lines

include/linux/in.h static inline bool ipv4_is_local_multicast(__be32 addr) · line 269

Quoted 6 lines
include/linux/in.h +1 -1
 static inline bool ipv4_is_badclass(__be32 addr)
 {
-	return (addr & htonl(0xf0000000)) == htonl(0xf0000000);
+	return addr == 0xFFFFFFFF;
 }
 

To (un)align the IN_BADCLASS macro and ipv6_is_badclass() definition,

Quoted 1 line

Unalign? IPv6? "Limited" broadcast?

Sorry, ipv4_is_badclass().
Assuming IN_BADCLASS() is still there, we should not reuse the name of "ipv6_is_badclass" because the their meanings are different.

include/linux/in.h static inline bool ipv4_is_local_multicast(__be32 addr) · line 266

Quoted 3 lines
include/linux/in.h +1 -1
-static inline bool ipv4_is_badclass(__be32 addr)
+static inline bool ipv4_is_broadcast(__be32 addr)
 {

I'm just afraid that people might think ipv4_is_broadcast is for testing subnet broadcast address.

255.255.255.255 is "limited broadcast address"
(vs subnet broadcast address, which can be forwarded by routers).

--yoshfuji

#16 lore raw

Re: [PATCH] IPv4: Enable use of 240/4 address space

In article <[email protected]> (at Fri, 18 Jan 2008 11:13:19 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 <[email protected]> says:

Quoted 2 lines

Assuming IN_BADCLASS() is still there, we should not reuse the name of "ipv6_is_badclass" because the their meanings are different.

Again, ipv4_is_badclass()....
My hands almost automatically type "6" after "ipv"...

--yoshfuji

#17 lore raw

Re: [PATCH] IPv4: Enable use of 240/4 address space

In reply to YOSHIFUJI Hideaki / 吉藤英明
Quoted 9 lines · YOSHIFUJI Hideaki / 吉藤英明

Review

Quoted 3 lines
(quoted diff) +1 -1
-static inline bool ipv4_is_badclass(__be32 addr)
+static inline bool ipv4_is_broadcast(__be32 addr)
 {

I'm just afraid that people might think ipv4_is_broadcast is for testing subnet broadcast address.

255.255.255.255 is "limited broadcast address"
(vs subnet broadcast address, which can be forwarded by routers).

From 84bccef295aa9754ee662191e32ba1d64edce2ba Mon Sep 17 00:00:00 2001
From: Jan Engelhardt <[email protected]>
Date: Fri, 18 Jan 2008 02:10:44 +0100
Subject: [PATCH] IPv4: enable use of 240/4 address space

This short patch modifies the IPv4 networking to enable use of the 240.0.0.0/4 (aka "class-E") address space as propsed in the internet draft draft-fuller-240space-00.txt.

---
 include/linux/in.h      |    5 +++--
 include/net/addrconf.h  |    2 +-
 net/core/pktgen.c       |    2 +-
 net/ipv4/fib_frontend.c |    2 +-
 net/ipv4/route.c        |   12 ++++++------
 5 files changed, 12 insertions(+), 11 deletions(-)
include/linux/in.h +3 -2
index 27d8a5a..70c6df8 100644
@@ -262,9 +262,10 @@ static inline bool ipv4_is_local_multicast(__be32 addr)
 	return (addr & htonl(0xffffff00)) == htonl(0xe0000000);
 }
 
-static inline bool ipv4_is_badclass(__be32 addr)
+static inline bool ipv4_is_lbcast(__be32 addr)
 {
-	return (addr & htonl(0xf0000000)) == htonl(0xf0000000);
+	/* limited broadcast */
+	return addr == INADDR_BROADCAST;
 }
 
 static inline bool ipv4_is_zeronet(__be32 addr)
include/net/addrconf.h +1 -1
index 8b1509b..496503c 100644
@@ -262,7 +262,7 @@ static inline int ipv6_isatap_eui64(u8 *eui, __be32 addr)
 		  ipv4_is_private_172(addr) || ipv4_is_test_192(addr) ||
 		  ipv4_is_anycast_6to4(addr) || ipv4_is_private_192(addr) ||
 		  ipv4_is_test_198(addr) || ipv4_is_multicast(addr) ||
-		  ipv4_is_badclass(addr)) ? 0x00 : 0x02;
+		  ipv4_is_lbcast(addr)) ? 0x00 : 0x02;
 	eui[1] = 0;
 	eui[2] = 0x5E;
 	eui[3] = 0xFE;
net/core/pktgen.c +1 -1
index d18fdb1..eebccdb 100644
@@ -2266,7 +2266,7 @@ static void mod_cur_headers(struct pktgen_dev *pkt_dev)
 
 					while (ipv4_is_loopback(s) ||
 					       ipv4_is_multicast(s) ||
-					       ipv4_is_badclass(s) ||
+					       ipv4_is_lbcast(s) ||
 					       ipv4_is_zeronet(s) ||
 					       ipv4_is_local_multicast(s)) {
 						t = random32() % (imx - imn) + imn;
net/ipv4/fib_frontend.c +1 -1
index 8ddcd3f..995b453 100644
@@ -176,7 +176,7 @@ static inline unsigned __inet_dev_addr_type(struct net *net,
 	unsigned ret = RTN_BROADCAST;
 	struct fib_table *local_table;
 
-	if (ipv4_is_zeronet(addr) || ipv4_is_badclass(addr))
+	if (ipv4_is_zeronet(addr) || ipv4_is_lbcast(addr))
 		return RTN_BROADCAST;
 	if (ipv4_is_multicast(addr))
 		return RTN_MULTICAST;
net/ipv4/route.c +6 -6
index 1e59c0d..1e484f7 100644
@@ -1154,7 +1154,7 @@ void ip_rt_redirect(__be32 old_gw, __be32 daddr, __be32 new_gw,
 		return;
 
 	if (new_gw == old_gw || !IN_DEV_RX_REDIRECTS(in_dev)
-	    || ipv4_is_multicast(new_gw) || ipv4_is_badclass(new_gw)
+	    || ipv4_is_multicast(new_gw) || ipv4_is_lbcast(new_gw)
 	    || ipv4_is_zeronet(new_gw))
 		goto reject_redirect;
 
@@ -1634,7 +1634,7 @@ static int ip_route_input_mc(struct sk_buff *skb, __be32 daddr, __be32 saddr,
 	if (in_dev == NULL)
 		return -EINVAL;
 
-	if (ipv4_is_multicast(saddr) || ipv4_is_badclass(saddr) ||
+	if (ipv4_is_multicast(saddr) || ipv4_is_lbcast(saddr) ||
 	    ipv4_is_loopback(saddr) || skb->protocol != htons(ETH_P_IP))
 		goto e_inval;
 
@@ -1891,7 +1891,7 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
 	   by fib_lookup.
 	 */
 
-	if (ipv4_is_multicast(saddr) || ipv4_is_badclass(saddr) ||
+	if (ipv4_is_multicast(saddr) || ipv4_is_lbcast(saddr) ||
 	    ipv4_is_loopback(saddr))
 		goto martian_source;
 
@@ -1904,7 +1904,7 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
 	if (ipv4_is_zeronet(saddr))
 		goto martian_source;
 
-	if (ipv4_is_badclass(daddr) || ipv4_is_zeronet(daddr) ||
+	if (ipv4_is_lbcast(daddr) || ipv4_is_zeronet(daddr) ||
 	    ipv4_is_loopback(daddr))
 		goto martian_destination;
 
@@ -2125,7 +2125,7 @@ static inline int __mkroute_output(struct rtable **result,
 		res->type = RTN_BROADCAST;
 	else if (ipv4_is_multicast(fl->fl4_dst))
 		res->type = RTN_MULTICAST;
-	else if (ipv4_is_badclass(fl->fl4_dst) || ipv4_is_zeronet(fl->fl4_dst))
+	else if (ipv4_is_lbcast(fl->fl4_dst) || ipv4_is_zeronet(fl->fl4_dst))
 		return -EINVAL;
 
 	if (dev_out->flags & IFF_LOOPBACK)
@@ -2276,7 +2276,7 @@ static int ip_route_output_slow(struct rtable **rp, const struct flowi *oldflp)
 	if (oldflp->fl4_src) {
 		err = -EINVAL;
 		if (ipv4_is_multicast(oldflp->fl4_src) ||
-		    ipv4_is_badclass(oldflp->fl4_src) ||
+		    ipv4_is_lbcast(oldflp->fl4_src) ||
 		    ipv4_is_zeronet(oldflp->fl4_src))
 			goto out;
 
Signature · 1 line
1.5.3.4
#18 lore raw

Re: [PATCH] IPv4: Enable use of 240/4 address space

In article <[email protected]> (at Sat, 19 Jan 2008 14:44:13 +0100 (CET)), Jan Engelhardt <[email protected]> says:

Quoted 10 lines

From 84bccef295aa9754ee662191e32ba1d64edce2ba Mon Sep 17 00:00:00 2001
From: Jan Engelhardt <[email protected]>
Date: Fri, 18 Jan 2008 02:10:44 +0100
Subject: [PATCH] IPv4: enable use of 240/4 address space

This short patch modifies the IPv4 networking to enable use of the 240.0.0.0/4 (aka "class-E") address space as propsed in the internet draft draft-fuller-240space-00.txt.

--yoshfuji

maintainer Applied
#19 lore raw

Re: [PATCH] IPv4: Enable use of 240/4 address space

From: YOSHIFUJI Hideaki / 吉藤英明 <[email protected]>
Date: Sun, 20 Jan 2008 00:30:19 +0900 (JST)

Quoted 7 lines

In article <[email protected]> (at Sat, 19 Jan 2008 14:44:13 +0100 (CET)), Jan Engelhardt <[email protected]> says:

Quoted 5 lines

From 84bccef295aa9754ee662191e32ba1d64edce2ba Mon Sep 17 00:00:00 2001
From: Jan Engelhardt <[email protected]>
Date: Fri, 18 Jan 2008 02:10:44 +0100
Subject: [PATCH] IPv4: enable use of 240/4 address space

Quoted 6 lines
Quoted 5 lines

This short patch modifies the IPv4 networking to enable use of the 240.0.0.0/4 (aka "class-E") address space as propsed in the internet draft draft-fuller-240space-00.txt.

I've applied this to net-2.6.25, thanks everyone.

I know I said we should deploy this as fast as possible, but we are really coming down the wire as far as releasing 2.6.24 is concerned and I don't want to put anything into my pushes to Linus that he might not like and thus cause the entire set of bug fixes to be rejected.

Thanks again.