Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness

[JORDI PALET MARTINEZ <[e-mail]>]

Hi Vasilenko,

My presentations and I guess the ones from other people, are based in the *current* 464XLAT RFC6877, so they are correct.

Before working in the optimization, not having discovered this issue, I was convinced that stateless is much better. And this is still true, if it is supported in the SoC or implementation. However, it is not true if you want to have the optimization and avoid problems when there are proxies for servers, etc., which require tracking the connections as per 5.2.4.

However, because the optimization can be disabled, it is perfectly possible to support also stateless in a given product so to improve the performance. For example, you can have a SoC and a Linux based CPE that can do hardware stateless NAT46, in some cases (you're a geek and you don't have any IPv4-only smartTV), you could disable the optimization and increase the performance of the CPE. I know it is a extreme case, but it is not a big trouble in terms of implementation to support both ways.

The optimization requires it to be stateful this is clear. I fully agree that it should be more clear, but that doesn't change the status of the current reality or previous presentations of RFC6877.

Same about RFC8683 and RFC8585, they are refering to the actual RFC6877.

This is the same for *any* presentation or RFC referring to a previous RFC. Something may change, some new options could change something that, as in the current case, RFC6877 indicates it may be statless or stateful, and this doesn't invalidates previous work. Right?

I know for sure:
1) Android is stateful NAT44 then stateless NAT46. This has been confirmed by Lorenzo a couple of times in meetings, probably also in the mailing list.
2) OpenWRT it is stateful.
3) I've seen several Linux implementations. Under NDA, working with several CPEs vendors in several proyects, so I can't name them. Some are in the list and could say by themselves.
4) Jool is stateful NAT44 then stateless NAT46.
5) Several SoC (System on Chip) support only stateful NAT44, not directly stateless NAT46.

Ole has indicated that VPP is stateless NAT46, but it also supports supports stateful NAT44.

iOS doesn't support CLAT for the UE itself (because all the apps should be IPv6-only ready and the support of HEv2 does something similar), but for the tethering yes. However I don't know if it is statelss or stateful.

So I'm talking with the information I've for real.

Anyway, this doesn't excludes at all 464XLAT being used in broadband CPEs (T-Mobile also provides broadband service via 4G using 464XLAT, for example), broadband wired, etc. It is clear in RFC6877.

Similarly doesn't preclude that if you want to support the optimization, you make sure that you're using a stateful CLAT in case your existing implementation is stateless now.

Regards,
Jordi


El 15/7/20 17:53, "Vasilenko Eduard" <[e-mail]> escribió:

    Hi Jordi,
    Yes, this one looks like outside of any context: 
    " Consequently, the EAMT entries should not be used directly to
       establish a forwarding path, but instead, to create a stateful NAT
       entry for the 4-tuple for the duration of the session/connection. "
    It is difficult to understand that it is about mandatory stateful CLAT.

    About "everybody use stateful CLAT":
    Your presentation clearly state "Stateless CLAT" (slide 6): https://www.lacnic.net/innovaportal/file/2907/1/ipv6-trans-mechs-status_v1-short-jordi-palet.pdf
    And your RFC talking only about "stateless CLAT": https://www.rfc-editor.org/rfc/rfc8683.html

    RFC 8585 does not clarify type of CLAT.

    Many hundreds of stateless CLAT discussions is possible to google:
    https://conference.apnic.net/34/pdf/34th_apnic_464xlat.pdf
    https://ipv6council.be/IMG/pdf/12-wuyts-XLAT_at_the_CPE.pdf
    https://www.apricot.net/apricot2013/assets/20130226_apricot2013_ipv4_over_ipv6_1361969703.pdf
    https://datatracker.ietf.org/meeting/84/materials/slides-84-sunset4-1
    https://www.ipv6.org.uk/wp-content/uploads/2018/11/Nick-Heatley_BT_EE_464xlat_UKv6Council_20180925.pdf
    https://www.rfc-editor.org/rfc/rfc8683.html
    https://archive.nanog.org/sites/default/files/wednesday_general_byrne_breakingfree_11.pdf
    Is everybody talking about stateless, but implement stateful?

    At least somebody not:
    https://sites.google.com/site/tmoipv6/464xlat
    " No changes were required to the existing T-Mobile USA IPv6-only + NAT64/DNS64 to support the 464XLAT architecture.  The stateless RFC6145 translation on the handset was the only modification needed. "

    OK. Are you sure that Google Android support Stateful CLAT in principle?
    Because Linux does not.
    Linux daemon https://github.com/toreanderson/clatd
    Is based on http://www.litech.org/tayga/
    That claimed to be "stateless NAT64 implementation"

    Android looks a little behind (using previous version of CLATD): https://android.googlesource.com/platform/external/android-clat/+/c786b7409032050721021583236de8608ac8948e/clatd.h
    Android investigation is better to start here: https://android.googlesource.com/platform/external/android-clat/
    Hence, Android CLAT daemon does not support stateful CLAT too.

    Could it be that CLAT is used together with some other daemon for NAPT before CLAT?
    Looks like No CLAT daemon dependency: https://openwrt.org/packages/pkgdata/464xlat

    Then how is it possible that Statuful CLAT is used, if it is not supported on CPE/Smartphone?

    Eduard
    -----Original Message-----
    From: JORDI PALET MARTINEZ [mailto:[e-mail]] 
    Sent: 15 июля 2020 г. 17:17
    To: Vasilenko Eduard <[e-mail]>; [e-mail]
    Cc: [e-mail]
    Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness

    I think your point will be to make it clear in the document that for this optimization to work, the CLAT should be stateful?

    I think is there (5.2.4.  Forwarding path via stateful NAT for existing EAMT entries), but I will make sure to add the relevant text in the next version to make it clearer. 

    I insist: most of the CLAT implementations today (running in both CPEs and UEs) are stateful. At least this is the data I've.

    Regards,
    Jordi
    @jordipalet



    El 15/7/20 15:59, "v6ops en nombre de Vasilenko Eduard" <[e-mail] en nombre de [e-mail]> escribió:

        Hi Jordi,
        I still believe that tough (new) requirement that CLAT should become Stateful (mandatory)
        Make sense to insert into the document.

        And explanation why stateful NAPT is needed would be good.
        I have spent some time to research this - it is better to save time of other people.
        It is important point that is omitted in the document.

        For the name: I do not have any strong opinion.
        Just I see that draft is applicable mostly to MAP-T,
        And not much applicable to XLAT (because majority of installations have stateless CLAT).
        But the name mislead to opposite conclusion.

        Eduard
        -----Original Message-----
        From: Jordi Palet Martínez [mailto:[e-mail]] 
        Sent: 15 июля 2020 г. 16:48
        To: Vasilenko Eduard <[e-mail]>; [e-mail]
        Cc: [e-mail]
        Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness

        Hi Vasilenko,

        The implementations of 464XLAT, can do the same (and in fact, many of them is what they do). NAT44 stateful and the 46 stateless. Many SoC have embedded NAT44 acceleration, but not NAT46, so that explains it as well.

        I guess that could clear your concern?

        I've several customers doing 464XLAT in broadband, one of them 25.000.000 subscribers. There is no difference in doing 464XLAT in cellular and broadband.

        When we say in the title 464XLAT/NAT64, I think both are covered. But I've no issue to change the title if this makes sense to others. We could explictily say 464XLAT/NAT64/MAP-T or whatever. This is a minor detail, in my opinion.

        Regards,
        Jordi
        @jordipalet


        El 15/7/20 15:40, "Vasilenko Eduard" <[e-mail]> escribió:

            Hi all,
            I have concern on the capability to use this mechanism for 464XLAT, but it should be fine for MAP-T.

            We may have many hosts on CPE LAN. Typically, 70% of FBB traffic is still designated to IPv4 sites.
            Source UDP/TCP port collision is still very possible (i.e. active sessions from different host may have the same source TCP/UDP port),
            It is not stated anywhere in the document, but we need to squeeze (for path to Internet it would be "source IP address") many private IPv4 hosts to one IPv6 (assigned by carrier to CPE uplink).
            Classical N:1 problem that should be resolved by NAPT (port translation is mandatory).

            MAP-T has NAPT engine on CPE side - it make sense to clearly state in the document that we are going to reuse NAPT. Then translation would be:
            (1) NAPT44 for many private IPv4 to one public IPv4 (well, it could be not public, but public A+P has been given to MAP CE anyway - better to reuse it for unification)
            (2) SIIT (with EAMT) for single IPv4 to single IPv6 (1:1)

            XLAT/CLAT does have stateful NAPT by RFC 6877, but it is not popular - not implemented by many carriers (if any?).
            It would be the big news that Carriers should choose stateful CLAT option for 464XLAT.
            It is better to tell them upfront.

            The next question could be: does it make sense to use Stateless CLAT for basic 464XLAT and Stateful CLAT for traffic optimization to IPv4 sites?
            Or it is better to unify on Stateful CLAT for everything.

            In general, it is a revolution for 464XLAT. But it is smooth expansion for MAP-T.
            Hence, does it make sense to change the name of this draft to reflect MAP-T as the primary target?

            Eduard
            -----Original Message-----
            From: v6ops [mailto:[e-mail]] On Behalf Of [e-mail]
            Sent: 11 июля 2020 г. 15:34
            To: [e-mail]
            Cc: [e-mail]
            Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02.txt


            A New Internet-Draft is available from the on-line Internet-Drafts directories.
            This draft is a work item of the IPv6 Operations WG of the IETF.

                    Title           : 464XLAT/NAT64 Optimization
                    Authors         : Jordi Palet Martinez
                                      Alejandro D'Egidio
            	Filename        : draft-ietf-v6ops-464xlat-optimization-02.txt
            	Pages           : 21
            	Date            : 2020-07-11

            Abstract:
               IP/ICMP Translation Algorithm (SIIT) can be used to provide access
               for IPv4-only devices or applications to IPv4-only or dual-stack
               destinations over IPv6-only infrastructure.  In that case, the
               traffic flows are translated twice: first from IPv4 to IPv6
               (stateless NAT46 at the ingress point to the IPv6-only
               infrastructure) and then from IPv6 back to IPv4 (stateful NAT64, at
               the egress point).  When the destination is IPv6-enabled, the second
               translation might be avoided.  This document describes a possible
               optimization to 464XLAT and MAP-T to avoid translating IPv6 flows
               back to IPv4 if the destination is reachable over IPv6.  The proposed
               solution would significantly reduce the NAT64 utilization in the
               operator's network.


            The IETF datatracker status page for this draft is:
            https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat-optimization/

            There are also htmlized versions available at:
            https://tools.ietf.org/html/draft-ietf-v6ops-464xlat-optimization-02
            https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-optimization-02

            A diff from the previous version is available at:
            https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-optimization-02


            Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

            Internet-Drafts are also available by anonymous FTP at:
            ftp://ftp.ietf.org/internet-drafts/


            _______________________________________________
            v6ops mailing list
            [e-mail]
            https://www.ietf.org/mailman/listinfo/v6ops



        **********************************************
        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.



        _______________________________________________
        v6ops mailing list
        [e-mail]
        https://www.ietf.org/mailman/listinfo/v6ops



    **********************************************
    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.






**********************************************
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.