[Jool-list] BIB-less NAT64

[Alberto Leiva]

> The reason I'm asking is a «problem» I've seen with Jool's NAT64: it can
> only handle 2^16 * $number_of_addresses_in_pool4 concurrent connections
> (per protocol).

Are you sure?

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.

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.

> Would it be
> possible to do NAT64 with the BIB completely disabled?

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

-----------------

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.

Experimental branch in fake-nat64, in case anyone wants to try it out:
https://github.com/NICMx/Jool/tree/fake-nat64

(Perhaps we should name it something that does not include "nat64" to
prevent the term from getting even more corrupted.)

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.

This thing makes mask-choosing trivial. It's way faster than a stock NAT64.

> mhh looks for me wrong. What happens if the source will connect with
> more than one connectionat the same time to the same target and port:

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.

On Tue, Sep 5, 2017 at 5:30 PM, Sander Steffann <sander at steffann.nl> wrote:

> Hi,
>
> > mhh looks for me wrong. What happens if the source will connect with
> > more than one connectionat the same time to the same target and port:
> >
> > IPv6 client:port         Public v4:port        Dest v4:port
> > [2001:db8::1]:60000  ->  192.0.2.1:54321  ->   ebay.co.uk:443
> > [2001:db8::1]:50000  ->  192.0.2.1:54321  ->   ebay.co.uk:443
> > [2001:db8::1]:40000  ->  192.0.2.1:54321  ->   amazon.com:443
> > [2001:db8::a]:40000  ->  192.0.2.1:43210  ->   amazon.com:443
> > [2001:db8::a]:30000  ->  192.0.2.1:43210  ->   amazon.com:443
> > [.................]  ->  192.0.2.1:54321  ->   [............]
>
> 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.
>
> > From my point of view this will break connections.
>
> If it was implemented as you show then it would indeed break.
>
> Cheers,
> Sander
>
>
> _______________________________________________
> Jool-list mailing list
> Jool-list at nic.mx
> https://mail-lists.nic.mx/listas/listinfo/jool-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail-lists.nic.mx/pipermail/jool-list/attachments/20170905/26e8fe23/attachment.html>