Hi Douglas,

 

I’ve done a lot of testing in several countries and customer networks and I’ve never got a single failure because 464XLAT.

 

If anything failed, we tested it with a pure IPv4 network and dual-stack network. They failed as well.

 

For example, I recall, in a customer deployment, that PlayStation 4 was not working … surprise. It was a specific problem *at that specific time*, so it was also not working with IPv4-only. Retested a couple of days after, and it worked.

 

I talk very frequently with other engineers which have also deployed 464XLAT in both cellular and wireline, and I’ve never heard any complain about any specific application or service not working because 464XLAT, so I’m not alone on this.

 

So, I think experience talk. Probably the question is about the same as you’re indicating “good quality” (whatever, including experience in the matter), makes things work without issues!

 

Regards,

Jordi

@jordipalet

 

 

 

El 24/2/21 14:28, "Douglas Fischer" <fischerdouglas@gmail.com> escribió:

 

P.S.: Forking thread from CGNAT.

Hello Jordi!

Since our last heated talk about transitions methods(Rosario, 2018?), I must recognize that the intolerance to other scenarios other than dual-stack had reduced(mostly because of improvements on the applications in generral). I'm even considering the possibility of using 464Xlat on some scenarios.


But I'm still, as it was in 2018, primarily concerned to avoid end-user support tickets.

And I'm still hooked on some specific issues... For example:
- SIP/Voip Applications, that almost all the providers do not work correctly on when those streams and connections pass over some v6 only paths.

- Applications with some source-based restrictions(some Internet Banking, some Compan-VPNs).

- Games (this is the champion of support tickets).

For that, with 464Xlat we still keep in pain...
But using DualStack with Good Quality CGNAT, the support tickets statistics are reduced to less than 5%.


So, the question here is:
How not use Dual-Stack and keep the support tickets as low as possible?


* "Good Quality CGNAT" means:
 - OBVIOUSLY have an extensive, deep, and GOOD deployment of IPv6(to avoid as much as possible the use of IPv4)
 - Good rules of CGNAT By-Pass (Ex.: Traffic between customers and Internal Servers don't need to be NATed.)
 - CGNAT with support to PCP, UPnP, and NAT-Algs. Preferably BPA - Bulk Port Allocation.

 

Em qua., 24 de fev. de 2021 às 04:11, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> escreveu:

I did this "economics" exercise for a customer having 25.000.000 customers (DSL, GPON and cellular). Even updating/replacing the CPEs, the cost of 464XLAT deployment was cheaper than CGN or anything else.

Also, if you consider the cost of buying more IPv4 addresses instead of investing that money in CGN, you avoid CGN troubles (like black listening your IPv4 addresses by Sony and others and the consequently operation/management expenses to rotate IPv4 addresses in the CGN, resolve customers problems, etc.), it becomes cheaper than CGN boxes.

It's easy to predict that you will buy now CGN and tomorrow you will need to buy some new IPv4 addresses because that black listening.

Regards,
Jordi
@jordipalet



El 24/2/21 3:13, "NANOG en nombre de Owen DeLong via NANOG" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de nanog@nanog.org> escribió:



    > On Feb 22, 2021, at 6:44 AM, nanog@jima.us wrote:
    >
    > While I don't doubt the accuracy of Lee's presentation at the time, at least two base factors have changed since then:
    >
    > - Greater deployment of IPv6 content (necessitating less CGN capacity per user)

    This is only true if the ISP in question is implementing IPv6 along side their CGN deployment and only if they get a significant uptake of IPv6 capability by their end users.

    > - Increased price of Legacy IP space on the secondary market (changing the formula) -- strictly speaking, this presentation was still in "primary market" era for LACNIC/ARIN/AFRINIC

    While that’s true, even at current prices, IPv4 addresses are cheaper to buy and/or lease than CGN.

    > IPv6 migration is not generally aided by CGNAT, but CGNAT deployment is generally aided by IPv6 deployment; to reiterate the earlier point, any ISPs deploying CGNAT without first deploying IPv6 are burning cash.

    Yep.

    I still think that implementing CGN is a good way to burn cash vs. the alternatives, but YMMV.

    Owen

    >
    > - Jima
    >
    > From: NANOG On Behalf Of Owen DeLong
    > Sent: Sunday, February 21, 2021 16:59
    > To: Steve Saner
    > Cc: nanog@nanog.org
    > Subject: Re: CGNAT
    >
    >
    > On Feb 18, 2021, at 8:38 AM, Steve Saner wrote:
    >
    >> We are starting to look at CGNAT solutions. The primary motivation at the moment is to extend current IPv4 resources, but IPv6 migration is also a factor.
    >
    > IPv6 Migration is generally not aided by CGNAT.
    >
    > In general, the economics today still work out to make purchasing or leasing addresses more favorable than CGNAT.
    >
    > It’s a bit dated by now, but still very relevant, see Lee Howard’s excellent research presented at the 2012 Rocky
    > mountain v6 task force meeting:
    >
    > https://www.rmv6tf.org/wp-content/uploads/2012/11/TCO-of-CGN1.pdf
    >
    > Owen
    >
    >
    > We've been in touch with A10. Just wondering if there are some alternative vendors that anyone would recommend. We'd probably be looking at a solution to support 5k to 15k customers and bandwidth up to around 30-40 gig as a starting point. A solution that is as transparent to user experience as possible is a priority.
    >
    > Thanks
    >
    > --
    > Steve Saner
    > ideatek HUMAN AT OUR VERY FIBER
    > This email transmission, and any documents, files or previous email messages attached to it may contain confidential information. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you are not, or believe you may not be, the intended recipient, please advise the sender immediately by return email or by calling tel:620.543.5026. Then take all steps necessary to permanently delete the email and all attachments from your computer system.
    >




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



 

--

Douglas Fernando Fischer
Engº de Controle e Automação


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