Implement "Fake" NAT64?

[ydahhrk]

The mailing lists have been unusually noisy lately. I'm uploading issues described there to make sure I don't forget them.

Tore came up with a variant to NAT64. Idea starts here, current work is in the fake-nat64 branch.

If this idea proves a reasonable tradeoff between gains and drawbacks, it will be offered as an alternate operation mode despite being nonstandard.

[ydahhrk]

2018-11-25 Update

Somebody asked for this feature in the survey.

Which is fine, I guess. I'll see if it can be added without breaking existing answers Ok, done. But thing is, Fake NAT64 is already implemented, and (because it goes against standards) I was hoping to get some practical feedback on how it behaves in a real environment before committing it to stable. So far it seems nobody has tested it.

Should I just merge it regardless?

[toreanderson]

Somebody asked for this feature in the survey.

That would be me...

Which is fine, I guess. I'll see if it can be added without breaking existing answers Ok, done. But thing is, Fake NAT64 is already implemented, and (because it goes against standards) I was hoping to get some practical feedback on how it behaves in a real environment before committing it to stable. So far it seems nobody has tested it.

Yeah, sorry about that. Had too much on my plate lately...

I feel pretty sure that even though it's not part of the RFC, this is a feature that you'll find in most commercial NAT64 appliances. Reason is that if you're doing NAT64 on, say, millions of mobile subscribers, you simply need to be able to overload the available pool of IPv4 transport addresses as much as you can. Otherwise you'll end up running out of them way too fast.

Should I just merge it regardless?

Fine by me! 👍 If so I'll probably just try to enable it after upgrading to v3.6.x, and let you know how it goes.

[ydahhrk]

Just leaving this here because I had almost forgotten it: https://mail-lists.nic.mx/pipermail/jool-list/2017-September/000129.html