[lkml]   [2007]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Scaling Max IP address limitation
On Jun 24, 2007, at 15:58:54, Jan Engelhardt wrote:
> On Jun 24 2007 15:08, Kyle Moffett wrote:
>> Do you really need that many IP addresses? When somebody finally
>> gets around to implementing REDIRECT support for ip6tables then
>> you could just redirect them all to the same port on the local
>> system.
> The way I see it, it's: "if someone gets around to implement *IPv6
> NAT*" (which, if its designers were asked, is contrary to the idea
> of ipv6).

I totally agree. On the other hand, you need REDIRECT for things
like transparent proxies which by definition aren't visible as
anything other than a router or bridge.

>> Having routing table operations, IPsec transformations, etc just
>> be another step in the firewall rules would also be useful. It
>> would be handy to be able to "-j ROUTE", then "-j IPSEC", then "-j
>> ROUTE" again, to re-route the now-encapsulated IPsec packets to
>> their proper destination.
> Absolutely...
>> That would also eliminate the sort-of-hacky problems with
>> destination network interface in the bridging code:
> Where's the hack? iptables operates on what it sees, and it sees
> br0. The physdev match is justified IMO.

The problem is this:
I want to be able to filter bridged network traffic *both* based on
the IP layer *and* the physical device it's going to be routed out.
Due to fundamental problems with a statically-ordered architecture,
it's impossible to get both, see commit
68df071a201f06b08cdc07111c6d4af918e64edd (found here: http://
026388.html). Basically if you want such cross-layer hooks, right
now your *ONLY* choice is to use marks with 2 drawbacks: (1) There
are a very small number of marks which must be carefully allocated by
your firewall-setup script (2) Marks are inherently extremely
fragile for passing data between layers.

>> "-j BRIDGE" might be another step in the process, and conceivably
>> you could have independent bridge MAC tables too.
> Whether a packet goes out a bridge (was that the intention of -j
> BRIDGE?) is determined by the routing table, which, in most cases,
> is just a matter of destination address.

No, the intent of "-j BRIDGE" would be _after_ "-j ROUTE" and some
kind of "-j ARP", to actually compute which physical port a given
packet should go.

>> That would also appear to get rid of the need for all tables other
>> than
>> "filter" and all predefined chains other than "INPUT" and
>> "OUTPUT". Default
>> rules would be these:
>> nettables -A INPUT -j CONNTRACK
>> nettables -A INPUT -j LOCALMATCH
>> nettables -A INPUT --for-this-host -j ACCEPT
>> nettables -A INPUT -j OUTPUT
> I'd prefer if Linux outputted its packets by default :)

Well the problem is this: Do you want the packet accepted locally or
forwarded. If forwarded, how do you want it routed, and which
physical port do you want it to go out? Without a statically-coded
ordering for all those things there is no way to say what the
"default" is. You would need some way to switch between iptables/
ip6tables (for compatibility) and pkttables/nettables (for advanced

> But this idea may have its benefit: by not restricting rules to
> certain positions like currently, throughput could be achieved.
> "Evil packets" f.e. could be dropped really early. (Well, you could
> also drop them early _today_, but a DROP in the mangle table will
> everyone make their eyes roll

It does give you a million more ways to shoot yourself in the foot.
Some things would have constraints like "output device must be
set" (BRIDGE/ARP, for example). If you accidentally stuck non-
constrained things in the wrong order you could get totally-non-IP-
compliant behavior. On the other hand, it does give you many choices
about IPsec before or after ROUTING (or after one routing step and
before another), etc.

Kyle Moffett

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-06-24 23:55    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean