[AfrIPv6-Discuss] AfrIPv6-Discuss Digest, Vol 149, Issue 1

[Lee Howard]

On 3/11/19 2:17 PM, JORDI PALET MARTINEZ via AfrIPv6-Discuss wrote:
>
> Responding below, in-line, and numbered the cases.
>
> I think I’m right, but happy to discuss/clarify!
>
>
> Regards,
>
> Jordi
>
> *De: *Lee Howard <lee.howard at retevia.net>
> *Responder a: *IPv6 in Africa Discussions <afripv6-discuss at afrinic.net>
> *Fecha: *lunes, 11 de marzo de 2019, 19:03
> *Para: *<afripv6-discuss at afrinic.net>
> *Asunto: *Re: [AfrIPv6-Discuss] AfrIPv6-Discuss Digest, Vol 149, Issue 1
>
>  1. If it is an IPv6 flow, it does not use the CLAT function in the
>     handset. It might use a NAT64 function at the provider edge.
>
> Let’s say if the source app is IPv6, using DNS64, it will be an 
> IPv6-only flow in the operator network and the NAT64 will be used only 
> if the destination is IPv4-only.
>
Yes, the phone will use IPv6, because the name server will only return a 
AAAA; the app will never see an IPv4 DNS response.
>
>  2. If it is an IPv4 flow, the handset translates from IPv4 to IPv6
>     (the CLAT function). My guess - and it's only speculation - is
>     that the handset takes a few milliseconds to do this for each
>     packet. The flow might also use a NAT64 function at the provider edge.
>
> If the source app is IPv4-only, the CLAT will do stateless NAT46 (how 
> this is done may depend on the implementation). If it is done “full 
> stateless” I guess is much faster than a NAT44 then a NAT46.
>
When would a handset do NAT44?

In a native dual-stack network, or native IPv4-only network, the handset 
never translates. In a 464xlat network, the handset translates to IPv6 
if the app uses IPv4 literals or expects IPv4. In Apple handsets, this 
doesn't happen because all apps are required to support IPv6 (with NAT64).

> In this case, it will always use NAT64, unless we work on this (case 
> for IPv4-only SmartTVs):
>
> https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/?include_text=1
>
> If we work on solving this issue, the NAT64 doesn’t need to be used! 
> And is not too complex, I think … EAMT already exist for that.
>
We should discuss that on v6ops. My initial reaction is that I'm tired 
of new transition technologies. Let it go, IPv4 will never be as good as 
native connectivity.

I also don't like the fact that rich CDNs already have preferential 
placement inside carriers' networks; if they want better connectivity, 
they should run IPv6, not expect the ISP to do translation for them.

Pushing more work onto the handset is the wrong direction. Work needs to 
be done on devices with big CPUs and connected power supplies.

>  3. If it was an IPv4-only network or dual-stack network, there's no
>     CLAT, only NAT at the provider edge.
>
> Depends on the deployment model. It may be only NAT at the CPE, or NAT 
> at the CPE and CGN, so we have NAT444 …
>
Yes, you're right, I was thinking about mobile networks.
>
> But in this case (3), if the destination is an IPv6-only datacenter 
> (Facebook is a simple example), you have also NAT446 at the datacenter 
> … (it may be just NAT46). There are different ways to do SIIT-DC or 
> other equivalent solutions.
>
Yes, also agreed. A residential network with NAT44 on the home router, 
CGN44 in the ISP, going to NAT46 at Facebook is NAT4446.

Lee


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/afripv6-discuss/attachments/20190311/780bd6a6/attachment.html>