I think that you're talking about dynamic port assignments, no? https://tools.ietf.org/html/draft-ietf-sunset4-nat64-port-allocation-01#section-2.2.2
We already have an issue for that (#175), but I gave it less priority than the framework switch (#140). Mainly because there's so much right now that depends on #140. I'm even being my usual naive again, hoping that we might get rid of GRO/LRO by being a device driver. (I was deeply submerged in #140 before this week's avalanche of issues came up.) I'd rather work on #140 since we've been postponing it for so long, but you know I get pumped up about whatever generates buzz. I think I recall that you've already complained about the static assignments, but I didn't get the impression that it was more than academic curiosity/experimentation back then. I guess I was wrong; you do seem to care about it quite a bit. Cast a vote on #175? On Fri, Sep 8, 2017 at 3:23 PM, Tore Anderson <[email protected]> wrote: > * Alberto Leiva > > > The solution will be somewhat more viable if you throw --mark into the > > mix (https://jool.mx/en/usr-flags-pool4.html#--mark). The reason for > > this is that pool4 entries wearing different marks are basically members > > of different pools, so if you have this pool4, for example (Note the > > first column, which represents the mark): > > > > $ jool --pool4 --display > > 0 TCP 192.0.2.1 1-65535 > > 1 TCP 192.0.2.2 1-65535 > > 2 TCP 192.0.2.3 1-65535 > > 3 TCP 192.0.2.4 1-65535 > > > > Then the peak of the graph will be 65535 for any connection (as opposed > > to 4 * 65535). This would have the added benefit that, if one of your > > users is attacking you, he or she will only mess up their own pool4 and > > not affect everyone else. > > This is nice, but if your user population is large (imagine a public > NAT64 instance serving the entire Internet), it gets problematic to > pre-allocate these client-private pool4s. > > So I was thinking: > > What if Jool could dynamically allocate a private «BIB pool» containing > $X ports whenever a new client comes along? Where «client» here actually > means a /$Y mask (typically /64 or /56 or /48). > > Assume pool4 is 192.0.2.0/24, X=128, and Y=64. > > - Client 2001:db8:1:1::1 comes along (first time seen), initiating a new > TCP session. > > - Jool proceeds to allocate a «BIB pool» of 2001:db8:1:1::/64 - > 192.0.2.0:[128-255]. This event should be logged for abuse tracing > purposes. > > - Jool picks 192.0.2.0:128 as source v4/port of the connection in > question. > > - A second connection from 2001:db8:1:1::2 comes along. Since it's the > same /64, no new «BIB pool» is allocated. Instead a source v4:port is > picked from 192.0.2.0:[128-255] (if «fake NAT64» is enabled, could even > be 192.0.2.0:128 even though there's another active session using that > tuple, provided the destination is different). > > - A third connection from 2001:db8:1:2::3 comes along. Since it's not in > the same /64 as the previous two, a new BIB pool (192.0.2.0:[256-383]) > is allocated (and logged), and the source v4:port gets picked from there. > > - Turns out, 2001:db8:1:1::/64 belongs to Sander and his T-Rex, and he's > spamming new connections. The algorithm gets slow as it tries hard to > find free v4:port tuples in 192.0.2.0:[128-255], but only for Sander, > not for clients in 2001:db8:1:2::/64 or anywhere else. > > - When 192.0.2.0:[128-255] is completely exhausted, Jool could possibly > allocate (and log) another batch of 128 ports. Now 2001:db8:1:1::/64 is > allocated 192.0.2.0:[128-255] and 192.0.2.0:[384-511]. This would allow > for having the default port-set size reasonably small, while still > allowing for «power users» to get all the ports they're likely to need. > > - Administrator should be able to limit the maximum number of extra > batches each client/mask should be allowed to obtain (could even be 0). > This would ensure Sander's T-Rex couldn't monopolise the entire pool4 > all by himself and/or grind Jool to a halt for all clients. > > - 2001:db8:1:2::3 has gone to bed and there are no longer any active > sessions using the 192.0.2.0:[256-383] pool. Jool deallocates it (after > a configurable grace period, perhaps?), logging that it does so. Later, > perhaps after a configurable quarantine period, it would reallocate it > to another client/mask. > > Tore >
_______________________________________________ Jool-list mailing list [email protected] https://mail-lists.nic.mx/listas/listinfo/jool-list
