<div dir="ltr">> The reason I'm asking is a «problem» I've seen with Jool's NAT64: it can<br>> only handle 2^16 * $number_of_addresses_in_pool4 concurrent connections<br>> (per protocol).<br><br>Are you sure?<br><br>You're making it sound like you can only have as many connections as the maximum number of BIB entries given your pool4. If this is truly the case, this is a bug. Each BIB entry should be able to have multiple sessions, and each session should represent a connection.<br><br>Of course, every one of a BIB's sessions must share client v6 transport address ("IPv6 Remote" in Jool's -sd output) and pool4 transport address ("IPv4 Local"). But AFAIK this is a limitation of NAT64 itself, not just Jool's.<br><br>> Would it be<br>> possible to do NAT64 with the BIB completely disabled?<br><br>I don't see any more problems with this either. Actually, implementing a prototype would be really easy; it's mostly just a matter of removing code. The hard part is going to be engineering this in a way that strikes a proper balance between maximizing code reuse and not complicating things too much (but this can be done later). And handling the reprobatory stares from a few IETF folks, I guess. :p<br><br>-----------------<br><br>Okay, guys. Prototype ready. I didn't test a gazillion connections, but as far as basic functionality goes, it looks stable. Don't quote me on that, though.<br><br>Experimental branch in fake-nat64, in case anyone wants to try it out: <a href="https://github.com/NICMx/Jool/tree/fake-nat64">https://github.com/NICMx/Jool/tree/fake-nat64</a><br><br>(Perhaps we should name it something that does not include "nat64" to prevent the term from getting even more corrupted.)<br><br>The code is enforcing remote IPv6 address uniqueness and also [local IPv4 address, remote IPv4 address] uniqueness. Aside from that, anything goes. The code does not attempt to create sessions in the 4-to-6 direction. --bib won't work anymore, --logging-bib and --address-dependent-filtering won't do anything. --mark should still work, for all your abuse detection purposes.<br><br>This thing makes mask-choosing trivial. It's way faster than a stock NAT64.<br><br>> mhh looks for me wrong. What happens if the source will connect with<br>> more than one connectionat the same time to the same target and port:<br><br>Ok, I do believe the prototype will prevent this by trying to use the next available source port on collision. We'll see how it goes.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 5, 2017 at 5:30 PM, Sander Steffann <span dir="ltr"><<a href="mailto:sander@steffann.nl" target="_blank">sander@steffann.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
> mhh looks for me wrong. What happens if the source will connect with<br>
> more than one connectionat the same time to the same target and port:<br>
><br>
> IPv6 client:port Public v4:port Dest v4:port<br>
> [2001:db8::1]:60000 -> <a href="http://192.0.2.1:54321" rel="noreferrer" target="_blank">192.0.2.1:54321</a> -> <a href="http://ebay.co.uk:443" rel="noreferrer" target="_blank">ebay.co.uk:443</a><br>
> [2001:db8::1]:50000 -> <a href="http://192.0.2.1:54321" rel="noreferrer" target="_blank">192.0.2.1:54321</a> -> <a href="http://ebay.co.uk:443" rel="noreferrer" target="_blank">ebay.co.uk:443</a><br>
> [2001:db8::1]:40000 -> <a href="http://192.0.2.1:54321" rel="noreferrer" target="_blank">192.0.2.1:54321</a> -> <a href="http://amazon.com:443" rel="noreferrer" target="_blank">amazon.com:443</a><br>
> [2001:db8::a]:40000 -> <a href="http://192.0.2.1:43210" rel="noreferrer" target="_blank">192.0.2.1:43210</a> -> <a href="http://amazon.com:443" rel="noreferrer" target="_blank">amazon.com:443</a><br>
> [2001:db8::a]:30000 -> <a href="http://192.0.2.1:43210" rel="noreferrer" target="_blank">192.0.2.1:43210</a> -> <a href="http://amazon.com:443" rel="noreferrer" target="_blank">amazon.com:443</a><br>
> [.................] -> <a href="http://192.0.2.1:54321" rel="noreferrer" target="_blank">192.0.2.1:54321</a> -> [............]<br>
<br>
</span>If multiple connections from the same source to the same destination are used then the NAT64 needs to use a separate port. But using the same port in the cases where the destination is different would be a massive saving on ports, and therefore on expensive IPv4 addresses.<br>
<span class=""><br>
> From my point of view this will break connections.<br>
<br>
</span>If it was implemented as you show then it would indeed break.<br>
<br>
Cheers,<br>
Sander<br>
<br>
<br>______________________________<wbr>_________________<br>
Jool-list mailing list<br>
<a href="mailto:Jool-list@nic.mx">Jool-list@nic.mx</a><br>
<a href="https://mail-lists.nic.mx/listas/listinfo/jool-list" rel="noreferrer" target="_blank">https://mail-lists.nic.mx/<wbr>listas/listinfo/jool-list</a><br>
<br></blockquote></div><br></div>