Hi, > > 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).
That would definitely work! > 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. I like it :) > 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.) I think for large-scale setups this would be an acceptable trade-off if done in batches on both sides: /64 (or /56 or /48, depending on what we know of the user's prefix) IPv6 to N addresses+ports IPv4. That way the absoute minimum number of IPv4 addresses can be calculated from the number of IPv6 customers. Which in my use case would be known. > Lots of things that could possibly be done here, glad I won't be the one > to implement them though. ;-) Hehe. Depending on Retevia's priorities I might be able to do some development, but that will be a few months in the future :) Cheers! Sander
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Jool-list mailing list [email protected] https://mail-lists.nic.mx/listas/listinfo/jool-list
