Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion

Hi Lee,

Responses below in-line.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de Lee Howard <lee@asgard.org>
Fecha: martes, 29 de mayo de 2018, 22:06
Para: <v6ops@ietf.org>
Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion

    On 05/29/2018 02:27 PM, JORDI PALET MARTINEZ wrote:
    > I understand your point that NAT64 was meant to be "imperfect", but this is something that is not valid for operators. Operators need to support existing customers with existing devices and apps, that only have IPv4 support, and this is only possible with NAT64 + CLAT.

    This statement is too broad in several ways.
    "Operators" may use 2G, 3G, LTE, fixed wireless, DSL, FTTH, DOCSIS, PON, 
    Wi-Fi, or local Ethernet.
    They may serve different kinds of customers, including their enterprise 
    users, homes, businesses, mobile handsets, mobile tablets, hospitality, 
    retail Wi-Fi. Some of those cases may not require IPv4 at the host, or 
    even the app. Even in a heterogeneous network, an operator may prefer to 
    offer NAT64 only to some customers, and native dual-stack to others, 
    rather than requiring a CLAT of all of them.

If the CE supports CLAT, but is getting dual stack in the WAN, then CLAT should not be used, so the operator will make sure that those customers have a different information by means of the provisioning or whatever. Nevertheless, I think this is out of the scope of this document (draft-ietf-v6ops-transition-ipv4aas is probably the most appropriate for that).

    To say that existing customers have IPv4-only requirements is true for a 
    specific subset of the kinds of networks and the endpoints served. 
    IPv6-only may work, or NAT64 may work.

    Further, as far as I can tell, MAP solves as many use cases, with as 
    much scale, as 464xlat. DS-Lite also solves the use cases, but maybe not 
    at the same scale. And so on.

Agree, but my comment was in the scope of "if you want to use NAT64, you better do 464XLAT". But still yes, this need to be better qualified, as that sentence only makes sense if you still need to provide "dual-stack" inside the customer CE.  

    For the sake of this document, I agree that NAT64 is the focus, and CLAT 
    provides a useful reference, but it is not the only way to deploy NAT64.

Today I believe is difficult to find cases that differ from "if you want to use NAT64, you better do 464XLAT ": almost every residential and business customer of every ISP in the world still has the need to have support for IPv4-only devices and apps. This will change in the next years? Yes, for sure.

    > What I disagree with you is in your comment that anyone who is willing to deploy (let's concentrate in) 464XLAT, will do DNS64 too. This is actually not needed in that case.
    >
    > I've no problem to add text, to more explicitly say "If you're going to deploy NAT64, you need DNS64, and here are some limitations".

    That would be better. Experience suggests that anyone deploying NAT64 
    and/or 464xlat will deploy DNS64 too, so explicit exceptions would be nice.

    > Would you agree that if an operator deploying IPv6-only access want to make sure that the customers using some IPv4-only devices work fine, the only way is using NAT64+CLAT, and that using NAT64+DNS64 will not work?

    I don't agree with that, as I said above.
    >
    > Regards,
    > Jordi
    >   
    >   
    Lee

    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
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.