On Thursday 2012-08-09 22:09, kaber@xxxxxxxxx wrote:
>+config IP6_NF_TARGET_NPT
>+ tristate "NPT (Network Prefix translation) target support"
>+ depends on NETFILTER_ADVANCED
>+ help
>+ This option adda `SNPT' and `DNPT' target, which perform stateless
>+ IPv6-to-IPv6 Network Prefix Translation (RFC 6296).
Fixes/suggestion in the help text (near "adda" and subsequent).
config IP6_NF_TARGET_NPT
tristate "NPT (Network Prefix translation) target support"
depends on NETFILTER_ADVANCED
---help---
This option adds the "SNPT" and "DNPT" targets, which perform stateless
IPv6-to-IPv6 Network Prefix Translation per RFC 6296.
>+/*
>+ * Copyright (c) 2011, 2012 Patrick McHardy <kaber@xxxxxxxxx>
>+ *
>+ * This program is free software; you can redistribute it and/or modify
>+ * it under the terms of the GNU General Public License version 2 as
>+ * published by the Free Software Foundation.
>+ */
GNU sometimes has a strange way of expressing their (C) lines,
listing all years separately, as if "1989-1991,1994-1999,2001-2005" was not
sufficient. In your case, would "2011-2012" work?
Any objection to adding a "(or later)" clause to the set?
>+static int ip6t_npt_checkentry(const struct xt_tgchk_param *par)
>+{
>+ struct ip6t_npt_tginfo *npt = par->targinfo;
>+ __sum16 src_sum = 0, dst_sum = 0;
>+ unsigned int i;
>+
>+ if (npt->src_pfx_len > 64 || npt->dst_pfx_len > 64)
>+ return -EINVAL;
While the RFC probably only specifies masks up to /64,
the general algorithm is sustainable up to at least /96.
Extending the RFC's section 3.6 ("/48 Prefix Mapping") example,
fd01:0203:0405:0001:0000:0000:0000:1234/112 (specification per `ip
addr`) would become 2001:0db8:0001:0000:0000:0000:d550:1234.
Not everybody runs exclusively on EUI64-SLAAC / PRIVACY addresses :)
>+static struct xt_target ip6t_npt_target_reg[] __read_mostly = {
>+ {
>+ .name = "SNPT",
IETF did quite a job again... NPT as an acronym is quite
close to NAPT - too close.
Since it's essentially NETMAP, having something in that ballpark
may seem more fitting. NPMAP? (Translation is mapping -
henceforh "Network Prefix Mapping")
I would hint towards choosing a different name; the P in NPT
may be (mis)understood as port (due to the common "NAPT")
keyword.
>+ .target = ip6t_snpt_tg,
>+ .targetsize = sizeof(struct ip6t_npt_tginfo),
>+ .checkentry = ip6t_npt_checkentry,
>+ .family = NFPROTO_IPV6,
>+ .hooks = (1 << NF_INET_LOCAL_IN) |
>+ (1 << NF_INET_POST_ROUTING),
>+ .me = THIS_MODULE,
Should perhaps a .table = "mangle" be added?
Are any tricks on the userspace side needed to use SNPT/SNPMAP?
Since I spot no code telling conntrack about the address mingling,
one would have to use -j CT --notrack or the rawpost table, like
it's done for RAWSNAT in xtables-addons, would he not?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
