On 16 February 2018 at 11:18, Ian Farrer <[email protected]> wrote: > > [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.]
The first option is what I'm currently leaning towards, although your final suggestion isn't a bad idea either. If we can dimension the blocks sufficiently at the required ratio, and just overlook the wastage. I did notice something else interesting in the Netfilter/iptables documentaiton today though. It appears as though up to kernel 2.6.11-rc1, it did have the ability to utilise multiple SNAT source address ranges (and presumably ports): """ In Kernels up to 2.6.10, you can add several --to-source options. For those kernels, if you specify more than one source address, either via an address range or multiple --to-source options, a simple round-robin (one after another in cycle) takes place between these addresses. Later Kernels (>= 2.6.11-rc1) don't have the ability to NAT to multiple ranges anymore. """ Might see if I can track that commit down to find out what happened. -Richard _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
