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

    > <Unrelated wishful thinking>
    > I keep having hopeful dreams that one day netfilter will grow support for
    > cross-protocol NAT (IE: NAT a TCPv4 connection over TCPv6 to the IPv6-only
    > local web server, or vice versa). It would seem that would require a merged
    > "xtables" program.
    > 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.


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

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

    > You'd probably also want "-j BRIDGE_TEST" and
    > "-j ROUTE_TEST" to compute the output network interface without actually
    > modifying the addresses.
    > 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 :)

    > nettables -A OUTPUT -j ROUTE
    > nettables -A OUTPUT -j TRANSMIT

    pkttables it is!

    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

    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 22:01    [W:0.024 / U:5.320 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site