<div dir="ltr"><div><div><div>I think that you're talking about dynamic port assignments, no?<br><a href="https://tools.ietf.org/html/draft-ietf-sunset4-nat64-port-allocation-01#section-2.2.2">https://tools.ietf.org/html/draft-ietf-sunset4-nat64-port-allocation-01#section-2.2.2</a><br><br></div>We already have an issue for that (#175), but I gave it less priority than the framework switch (#140).<br></div>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.<br></div><div>(I was deeply submerged in #140 before this week's avalanche of issues came up.)<br><br></div><div>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.<br><br></div><div>Cast a vote on #175?<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 8, 2017 at 3:23 PM, Tore Anderson <span dir="ltr"><<a href="mailto:tore@fud.no" target="_blank">tore@fud.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Alberto Leiva<br>
<span class=""><br>
> The solution will be somewhat more viable if you throw --mark into the<br>
> mix (<a href="https://jool.mx/en/usr-flags-pool4.html#--mark" rel="noreferrer" target="_blank">https://jool.mx/en/usr-flags-<wbr>pool4.html#--mark</a>). The reason for<br>
> this is that pool4 entries wearing different marks are basically members<br>
> of different pools, so if you have this pool4, for example (Note the<br>
> first column, which represents the mark):<br>
><br>
> $ jool --pool4 --display<br>
> 0 TCP 192.0.2.1 1-65535<br>
> 1 TCP 192.0.2.2 1-65535<br>
> 2 TCP 192.0.2.3 1-65535<br>
> 3 TCP 192.0.2.4 1-65535<br>
><br>
> Then the peak of the graph will be 65535 for any connection (as opposed<br>
> to 4 * 65535). This would have the added benefit that, if one of your<br>
> users is attacking you, he or she will only mess up their own pool4 and<br>
> not affect everyone else.<br>
<br>
</span>This is nice, but if your user population is large (imagine a public<br>
NAT64 instance serving the entire Internet), it gets problematic to<br>
pre-allocate these client-private pool4s.<br>
<br>
So I was thinking:<br>
<br>
What if Jool could dynamically allocate a private «BIB pool» containing<br>
$X ports whenever a new client comes along? Where «client» here actually<br>
means a /$Y mask (typically /64 or /56 or /48).<br>
<br>
Assume pool4 is <a href="http://192.0.2.0/24" rel="noreferrer" target="_blank">192.0.2.0/24</a>, X=128, and Y=64.<br>
<br>
- Client 2001:db8:1:1::1 comes along (first time seen), initiating a new<br>
TCP session.<br>
<br>
- Jool proceeds to allocate a «BIB pool» of 2001:db8:1:1::/64 -<br>
192.0.2.0:[128-255]. This event should be logged for abuse tracing purposes.<br>
<br>
- Jool picks <a href="http://192.0.2.0:128" rel="noreferrer" target="_blank">192.0.2.0:128</a> as source v4/port of the connection in question.<br>
<br>
- A second connection from 2001:db8:1:1::2 comes along. Since it's the<br>
same /64, no new «BIB pool» is allocated. Instead a source v4:port is<br>
picked from 192.0.2.0:[128-255] (if «fake NAT64» is enabled, could even<br>
be <a href="http://192.0.2.0:128" rel="noreferrer" target="_blank">192.0.2.0:128</a> even though there's another active session using that<br>
tuple, provided the destination is different).<br>
<br>
- A third connection from 2001:db8:1:2::3 comes along. Since it's not in<br>
the same /64 as the previous two, a new BIB pool (192.0.2.0:[256-383])<br>
is allocated (and logged), and the source v4:port gets picked from there.<br>
<br>
- Turns out, 2001:db8:1:1::/64 belongs to Sander and his T-Rex, and he's<br>
spamming new connections. The algorithm gets slow as it tries hard to<br>
find free v4:port tuples in 192.0.2.0:[128-255], but only for Sander,<br>
not for clients in 2001:db8:1:2::/64 or anywhere else.<br>
<br>
- When 192.0.2.0:[128-255] is completely exhausted, Jool could possibly<br>
allocate (and log) another batch of 128 ports. Now 2001:db8:1:1::/64 is<br>
allocated 192.0.2.0:[128-255] and 192.0.2.0:[384-511]. This would allow<br>
for having the default port-set size reasonably small, while still<br>
allowing for «power users» to get all the ports they're likely to need.<br>
<br>
- Administrator should be able to limit the maximum number of extra<br>
batches each client/mask should be allowed to obtain (could even be 0).<br>
This would ensure Sander's T-Rex couldn't monopolise the entire pool4<br>
all by himself and/or grind Jool to a halt for all clients.<br>
<br>
- 2001:db8:1:2::3 has gone to bed and there are no longer any active<br>
sessions using the 192.0.2.0:[256-383] pool. Jool deallocates it (after<br>
a configurable grace period, perhaps?), logging that it does so. Later,<br>
perhaps after a configurable quarantine period, it would reallocate it<br>
to another client/mask.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tore<br>
</font></span></blockquote></div><br></div>