Hi Richard, Please see inline.
Thanks, Ian > On 15 Feb 2018, at 15:47, Richard Patterson <[email protected]> wrote: > > Hi All, > > Apologies, I was unsure on if this belonged in v6ops, softwires or > elsewhere, but I'll start here. > > I've been putting MAP-T through its paces in our lab recently, using > OpenWRT/LEDE as the MAP CE, and have come across a slight issue with > how things are currently implemented. > When using a BMR that overloads a subscriber's IPv4 address, and > allocates each subscriber multiple port sets, OpenWRT currently > instantiates iptables SNAT rules for each port set. > > Problem is, netfilter doesn't consider the current conntrack session > state when it's evaluating the rules. The result is that the first > matching rule is always used, and if all sports in that port set are > consumed, then any new flows are dropped. > > Now I don't consider this to be an OpenWRT implementation issue, and I > doubt it will be considered a bug in netfilter either, as I believe > it's known and expected behaviour. > At best I think it's a netfilter feature/enhancement request to be > able to fully support RFC7597/9. > > As far as I see it, the mitigations are: > * Use BMRs that assign only a single contiguous port set to each subscriber [if - A driver for PSID mechanism is the ability to algorithmically exclude ports 0-1023 from allocation to a client. A BMR that defines a single port range has ‘offset=0’, and so PSID=0 will contain all (or a portion, depending on sharing ratio) of the well-known ports. If this is not a problem for your clients, then this could be a solution. Another possibility to make this work would be if it is possible to prevent the v6 prefix which maps to PSID=0 for each IPv6 address from allocation to a client (e.g. via the DHCPv6 server). One final suggestion here is that depending on what you’re available address blocks and desired sharing ratios are, you could define the map domain to try and maximise the value of M (RFC7597 Appendix), while keeping the offset a-bits at 6. This will give clients the largest possible contiguous block of ports to use for snat, but the overhead in wasted (either excluded from use by the algorithm, or not being used due to the problem you describe) is going to be high.] > * Feature request over on the Netfilter Bugzilla ( > https://bugzilla.netfilter.org/show_bug.cgi?id=1227 ) to consider > conntrack sessions before SNATting [if - I don’t have any personal experience here, but it’s certainly worth a try. I guess it might take a while before something come out of it though] > * Create specific SNAT rules that match original sport range to the > same outside sport range, and then have a catch-all rule at the end. > (Bit of a kludge and won't stop the catch-all getting overloaded) [if - The catch-all is the problem here as for any useful sharing ratio, the bulk of outgoing s-ports will be in the catch-all. Another approach might be to map a larger range of outgoing s-ports to the smaller range of external s-ports - e.g. with a 64:1 sharing ratio, offset 6, there will be 63 blocks of 4 external ports allocated, so if original sport 0-1023 SNAT to 1024-1027, 1024-2047 to 2048-2051 etc. (you would need to do something like 63488-25535 at the end)] > > Can anyone else think of a better approach to the iptables ruleset, or > even better is anyone in this WG a Netfilter dev? [if - Not to my knowledge, but if there is anyone, then please shout!] > > -Richard > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
