LinuxLists.cc - [PATCH 001/001] ipv4: enable use of 240/4 address space

[permalink] [raw]

Subject: Re: [PATCH 001/001] ipv4: enable use of 240/4 address space

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

> 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.
>
> Signed-off-by: Vince Fuller <[email protected]>

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.

2008-01-11 11:17:19

by Andi Kleen

[permalink] [raw]

Subject: Re: [PATCH 001/001] ipv4: enable use of 240/4 address space

Vince Fuller <[email protected]> writes:

> 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

2008-01-11 12:41:30

[permalink] [raw]

Subject: Re: [PATCH 001/001] ipv4: enable use of 240/4 address space

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

> Vince Fuller <[email protected]> writes:
>
> > 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

2008-01-11 17:31:58

by Vince Fuller

[permalink] [raw]

Subject: Re: [PATCH 001/001] ipv4: enable use of 240/4 address space

On Fri, Jan 11, 2008 at 12:17:02PM +0100, Andi Kleen wrote:
> Vince Fuller <[email protected]> writes:
>
> > 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

2008-01-12 01:49:17

[permalink] [raw]

Subject: Re: [PATCH 001/001] ipv4: enable use of 240/4 address space

From: YOSHIFUJI Hideaki / $B5HF#1QL@(B <[email protected]>
Date: Fri, 11 Jan 2008 21:41:20 +0900 (JST)

> 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.

2008-01-12 01:50:16

[permalink] [raw]

Subject: Re: [PATCH 001/001] ipv4: enable use of 240/4 address space

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

> 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.

2008-01-12 05:12:32

[permalink] [raw]

Subject: Re: [PATCH 001/001] ipv4: enable use of 240/4 address space

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

> From: YOSHIFUJI Hideaki / $B5HF#1QL@(B <[email protected]>
> Date: Fri, 11 Jan 2008 21:41:20 +0900 (JST)
>
> > 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.

No, we did never make consensus on it.

> 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

2008-01-12 05:47:33

[permalink] [raw]

Subject: Re: [PATCH 001/001] ipv4: enable use of 240/4 address space

Hello.

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

> #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))
> +*/

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

2008-01-12 11:23:44

[permalink] [raw]

Subject: Re: [PATCH 001/001] ipv4: enable use of 240/4 address space

On Jan 11 2008 17:49, David Miller wrote:
>From: Vince Fuller <[email protected]>
>Date: Fri, 11 Jan 2008 09:29:15 -0800
>
>> 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.

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

2008-01-17 23:04:23

[permalink] [raw]

Subject: Re: [PATCH 001/001] ipv4: enable use of 240/4 address space

On Jan 7 2008 17:10, Vince Fuller wrote:
>--- net/ipv4/devinet.c.orig 2007-04-12 10:16:23.000000000 -0700
>+++ net/ipv4/devinet.c 2008-01-07 16:55:59.000000000 -0800
>@@ -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?

2008-01-18 00:40:59

by Vince Fuller

[permalink] [raw]

Subject: Re: [PATCH 001/001] ipv4: enable use of 240/4 address space

On Fri, Jan 18, 2008 at 12:04:06AM +0100, Jan Engelhardt wrote:
>
> On Jan 7 2008 17:10, Vince Fuller wrote:
> >--- net/ipv4/devinet.c.orig 2007-04-12 10:16:23.000000000 -0700
> >+++ net/ipv4/devinet.c 2008-01-07 16:55:59.000000000 -0800
> >@@ -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?

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

2008-01-18 01:14:14

[permalink] [raw]

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

On Jan 7 2008 17:10, Vince Fuller wrote:
>
>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.

Signed-off-by: Jan Engelhardt <[email protected]>

diff --git a/include/linux/in.h b/include/linux/in.h
index 27d8a5a..b01bf75 100644
--- a/include/linux/in.h
+++ b/include/linux/in.h
@@ -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)

2008-01-18 01:26:47

[permalink] [raw]

Subject: 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:

> diff --git a/include/linux/in.h b/include/linux/in.h
> index 27d8a5a..b01bf75 100644
> --- a/include/linux/in.h
> +++ b/include/linux/in.h
> @@ -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.

> @@ -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

2008-01-18 01:52:22

[permalink] [raw]

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

On Jan 18 2008 10:26, YOSHIFUJI Hideaki / 吉藤英明 wrote:
>> -#define IN_EXPERIMENTAL(a) ((((long int) (a)) & 0xf0000000) == 0xf0000000)
>> -#define IN_BADCLASS(a) IN_EXPERIMENTAL((a))
>
>No, please keep these macros.
>
>> @@ -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,

Unalign? IPv6? "Limited" broadcast?

>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.

Signed-off-by: Jan Engelhardt <[email protected]>

diff --git a/include/linux/in.h b/include/linux/in.h
index 27d8a5a..4887768 100644
--- a/include/linux/in.h
+++ b/include/linux/in.h
@@ -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)
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index 8b1509b..f5bd33b 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -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;
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index d18fdb1..9d6e7af 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -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;
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 8ddcd3f..367e097 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -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;
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 1e59c0d..9f0ea73 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -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;

2008-01-18 02:13:27

[permalink] [raw]

Subject: 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:

>
> On Jan 18 2008 10:26, YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote:
> >> -#define IN_EXPERIMENTAL(a) ((((long int) (a)) & 0xf0000000) == 0xf0000000)
> >> -#define IN_BADCLASS(a) IN_EXPERIMENTAL((a))
> >
> >No, please keep these macros.
> >
> >> @@ -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,
>
> 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.

> -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

2008-01-18 02:15:29

[permalink] [raw]

Subject: 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 / $B5HF#1QL@(B <[email protected]> says:

> 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

2008-01-19 13:44:26

[permalink] [raw]

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

On Jan 18 2008 11:13, YOSHIFUJI Hideaki / 吉藤英明 wrote:
>> -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.

Signed-off-by: Jan Engelhardt <[email protected]>
---
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(-)

diff --git a/include/linux/in.h b/include/linux/in.h
index 27d8a5a..70c6df8 100644
--- a/include/linux/in.h
+++ b/include/linux/in.h
@@ -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)
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index 8b1509b..496503c 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -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;
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index d18fdb1..eebccdb 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -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;
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 8ddcd3f..995b453 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -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;
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 1e59c0d..1e484f7 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -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;

--
1.5.3.4

2008-01-19 15:30:29

[permalink] [raw]

Subject: 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:

> 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.
>
> Signed-off-by: Jan Engelhardt <[email protected]>
Acked-by: YOSHIFUJI Hideaki <[email protected]>

--yoshfuji

2008-01-21 11:20:08