Below, in-line
Regards, Jordi De: Lee Howard <[email protected]> Responder a: IPv6 in Africa Discussions <[email protected]> Fecha: lunes, 11 de marzo de 2019, 19:58 Para: <[email protected]> Asunto: Re: [AfrIPv6-Discuss] AfrIPv6-Discuss Digest, Vol 149, Issue 1 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 <[email protected]> Responder a: IPv6 in Africa Discussions <[email protected]> Fecha: lunes, 11 de marzo de 2019, 19:03 Para: <[email protected]> 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? There are good and bad CLAT implementations. The bad ones instead of doing stateless NAT46 do a stateful NAT44 than stateless NAT46 … 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. Is nothing new is is just an operations practice for CDNs (they do for 100.64/10 when there is CGN). Is just making sure that the CLAT implementation follows the SHOULD for supporting EAMT as indicated in the SIIT RFC … long history but yes, it is v6ops. 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. The CDNs are dual-stack today. The problem is not at the CDN, is at the SmartTV which is IPv4-only. Pushing more work onto the handset is the wrong direction. Work needs to be done on devices with big CPUs and connected power supplies. Agree, as said this case is basically for CEs because there are IPv4-only STBs and SmartTVs … it may apply also to a handset with a broken app, but I don’t think it is the case anymore today. 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 _______________________________________________ AfrIPv6-Discuss mailing list [email protected] https://lists.afrinic.net/mailman/listinfo/afripv6-discuss ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
_______________________________________________ AfrIPv6-Discuss mailing list [email protected] https://lists.afrinic.net/mailman/listinfo/afripv6-discuss
