Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-00.txt

[Lorenzo Colitti <[e-mail]>]

On Wed, Feb 15, 2012 at 10:42, Masanobu Kawashima
<[e-mail]>wrote:

> We have published draft-ietf-v6ops-464xlat-00 as WG draft.
> We welcome all your comments.
>

I like this, because it makes it relatively easy to provide legacy IPv4
connectivity on a device that has IPv6-only connectivity.

It's a particularly good fit for 3GPP devices like mobile phones because
it's relatively simple, can be implemented entirely in userspace, and
requires no provisioning that isn't already provided by 3GPP (a /64 and a
DNS server). And it's just a combination of existing standards.

By comparison, I think solutions like 4rd require a more complex device
implementation, need the kernel to pick ports in a way that will be
understood by the translator, and require provisioning as to what mapping
algorithm and port ranges to use. I can see why you would use something
like 4rd in a wireline CPE, but on something like a smartphone, which is
already behind an IPv4 NAT today and most applications already support
IPv6, the IPv4 connectivity is only really used for a few apps anyway.

I have one question, though: why does the CLAT require a /96? Wouldn't it
be simpler if it uses just one /128 and performed NAT44 for clients behind
it?

That way, if the CLAT have one /64 like in the 3GPP case, you don't have to
worry about DAD and NDP proxying.