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

[Alexandre Petrescu <[e-mail]>]

Lorenzo - I am not interfering with your discussion, but let me say this.

Le 21/09/2017 à 07:46, Lorenzo Colitti a écrit :
[...]

> Instead of NAT4464, it would have been possible to use extra IPv6 
> addresses to represent the tethered devices.

If you can make DHCPv6-PD software available on Android without needing
to root-risk the device, then I can look at making DHCPv6-PD deliver
these extra addresses.

> On mobile networks, which provide a dedicated /64 and guarantee no
> collisions

Some cellular mobile network provides a dedicated /64 per UE, but also
DHCPv6-PD service, at the same time.  I would like to use that, on Android.

> 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

I will try to understand that, but see above what I can do.

Alex

> 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
> 
> 
> _______________________________________________ v6ops mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>