Support nat64

[bukepo]

This PR enables NAT64 service.

[lanyuwen]

it looks script/_nat64 was not added? :)

[bukepo]

Thanks, added now.

[bukepo]

The reserved prefix 64:ff9b:1::/48 is not allowed by tayga currently, so this PR doesn't change the prefix, leaving it as the default value 2001:db8:1:ffff::/96. Thoughts? @jwhui

[jwhui]

I think this is fine for now. The new prefix is still in draft-spec stage and not yet an RFC.

[jwhui]

@bukepo, can you add/create wiki content for configuring/using the NAT64 service?

[lanyuwen]

2001:db8:1:ffff::/96 would be an option, it can be used to support NAT of both global and private IPv4 addresses, but the flaw may be that "2001:db8::/32" prefix was designated for documentation only purpose [RFC3849]

Another option of prefix would be using the well-known prefix 64:ff9b::/96 defined in RFC6052. The benefit would be that since it's a widely used NAT64 prefix, and we can use some public DNS64 service instead of deploying our own. For example, Google provides a public DNS64 server which bonds responses to "64:ff9b::/96" prefix. Drawback is that this prefix is not allowed to use for private IPv4 addresses such as "192.168.1.xxx".

No matter which one to use here, we should allow people to configure it easily. Hopefully we can make it done through #23 soon. The question mainly is about which one to use for default prefix when people don't care about it at all.

Any thoughts on which one to use for default? @jwhui

[jwhui]

Yes, 2001:db8::/32 is reserved for documentation purposes only and should not be used in practice. The default should be the well-known prefix 64::ff9b::/96 RFC 6052. I also agree we should allow a user to manually configure the NAT64 prefix.

Long-term, we should support the prefix reserved for Local-use IPv4/IPv6 Translation draft-ietf-v6ops-v4v6-xlat-prefix-00.

[bukepo]

Thanks for your suggestions. I will update this PR and create wiki page later. @jwhui @lanyuwen