[Jool-list] BIB-less NAT64

Tore Anderson tore at fud.no
Tue Sep 5 06:39:08 CDT 2017


* Sander Steffann

>> IPv6 client:port         Public v4:port        Dest v4:port #1:
>> [2001:db8::1]:60000  ->  192.0.2.1:54321  ->   ebay.co.uk:443 #2:
>> [2001:db8::a]:40000  ->  192.0.2.1:54321  ->   amazon.com:443 #n:
>> [.................]  ->  192.0.2.1:54321  ->   [............]
> 
> Technically possible, but in our case we want/need to log the BIB
> entries so that if abuse is detected we can trace it back to the
> originator. And we explicitly don't want to log where the user is
> connecting to (privacy), only which IPv6 user got which IPv4
> address+port at which point in time.

Right. A variant of this could possibly be to allow re-use of IPv4
transport addresses only for connections originating from the same client:

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  ->   amazon.com:443
[2001:db8::a]:40000  ->  192.0.2.1:43210  ->   ebay.co.uk:443
[2001:db8::a]:30000  ->  192.0.2.1:43210  ->   amazon.com:443
[.................]  ->  192.0.2.1:54321  ->   [............]

Or possibly aggregate it so that all individual IPv6 clients within the
same /64 or /48 or whatever can re-use the same external IPv4
address:port tuple(s).

Then you'd only need to log the assignment of the public_v4:port to the
given IPv6 client/prefix for abuse purposes, yet still get the benefit
of being able to overcommit the public IPv4 pool compared to standard NAT64.

The public_v4:port assignments to new IPv6 clients/prefixes could even
be done in batches of N at a time, to further reduce the amount of logs
you need to retain. (At the expense of further reducing the amount of
overcommitment you can do, of course.)

Lots of things that could possibly be done here, glad I won't be the one
to implement them though. ;-)

Tore


More information about the Jool-list mailing list