[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    [W:0.026 / U:3.556 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site