Re: [v6ops] reclassify 464XLAT as standard instead of info

[Lorenzo Colitti <[e-mail]>]

On Wed, Sep 20, 2017 at 10:10 AM, David Schinazi <[e-mail]>
wrote:

> > If you do it with SLAAC, as described in the RFC, the NAT46 will be
> stateful (by means of a previous NAT44) because you don’t have a specific
> /64 for the translation. Otherwise will be stateless.
>
> I don't think that's correct. In order to make 464XLAT stateless you need
> a separate /128, not /64. And SLAAC allows you to generate that extra /128.
> As far as I know, this is how Android works.
>

The NAT46 part of 464xlat is always stateless. Device-originated traffic
does not require any NAT table entries. On Android, the IPv4 stack emits
packets using an IPv4 address in 192.0.0.0/29 and then we statelessly
translate them to IPv6. However, when enabling IPv4 tethering, devices
behind the hotspot are NATed, so that, say, 192.168.43.12 first goes
through stateful NAT44 to 192.0.0.4 before being statelessly translated to
IPv6.

Instead of NAT4464, it would have been possible to use extra IPv6 addresses
to represent the tethered devices. On mobile networks, which provide a
dedicated /64 and guarantee no collisions the implementation could just
statelessly translate 192.168.43.12 to c0a8:2b0c and store that in a
well-known place in the IID somewhere. On networks that have other devices
on them the translation would need to be stateful, and in order to make it
stateless, another prefix could be requested (e.g., via DHCPv6 PD). In
effect that would change NAT4464 back to NAT464

On Android we chose not to do this because of the extra complexity. We
already had to support IPv4 NAT for native IPv4 connections, and it seemed
pointless to save an extra NAT step when the packet always has to go
through a stateful NAT64 anyway.

As far the discussion of changing the Category of the RFC, I'm not sure
> what it accomplishes, and whether it's worth spending time on.
>

+1