<div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 24, 2021 at 5:29 AM Douglas Fischer <<a href="mailto:fischerdouglas@gmail.com">fischerdouglas@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small">P.S.: Forking thread from CGNAT.<br><br>Hello Jordi!<br><br>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.</div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small"><br>But I'm still, as it was in 2018, primarily concerned to avoid end-user support tickets.<br><br>And I'm still hooked on some specific issues... For example:<br>- SIP/Voip Applications, that almost all the providers do not work correctly on when those streams and connections pass over some v6 only paths.</div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small">- Applications with some source-based restrictions(some Internet Banking, some Compan-VPNs).</div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small">- Games (this is the champion of support tickets).<br><br>For that, with 464Xlat we still keep in pain...</div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">Is this pain you have lived or verified with first hand testing?</div><div dir="auto"><br></div><div dir="auto">I am operate 464xlat broadband network, and do not have this pain in the general case. That said, there are cpe specific qa concerns, but that is always the case, regardless of tech</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small" dir="auto"><br>But using DualStack with Good Quality CGNAT, the support tickets statistics are reduced to less than 5%.<br><br><br>So, the question here is:<br>How not use Dual-Stack and keep the support tickets as low as possible?<br><br><br>* "Good Quality CGNAT" means:<br> - OBVIOUSLY have an extensive, deep, and GOOD deployment of IPv6(to avoid as much as possible the use of IPv4)<br> - Good rules of CGNAT By-Pass (Ex.: Traffic between customers and Internal Servers don't need to be NATed.)<br> - CGNAT with support to PCP, UPnP, and NAT-Algs. Preferably BPA - Bulk Port Allocation.<br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em qua., 24 de fev. de 2021 às 04:11, JORDI PALET MARTINEZ via NANOG <<a href="mailto:nanog@nanog.org" target="_blank">nanog@nanog.org</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Regards,<br>
Jordi<br>
@jordipalet<br>
<br>
<br>
<br>
El 24/2/21 3:13, "NANOG en nombre de Owen DeLong via NANOG" <nanog-bounces+jordi.palet=<a href="mailto:consulintel.es@nanog.org" target="_blank">consulintel.es@nanog.org</a> en nombre de <a href="mailto:nanog@nanog.org" target="_blank">nanog@nanog.org</a>> escribió:<br>
<br>
<br>
<br>
    > On Feb 22, 2021, at 6:44 AM, <a href="mailto:nanog@jima.us" target="_blank">nanog@jima.us</a> wrote:<br>
    > <br>
    > While I don't doubt the accuracy of Lee's presentation at the time, at least two base factors have changed since then:<br>
    > <br>
    > - Greater deployment of IPv6 content (necessitating less CGN capacity per user)<br>
<br>
    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.<br>
<br>
    > - 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<br>
<br>
    While that’s true, even at current prices, IPv4 addresses are cheaper to buy and/or lease than CGN.<br>
<br>
    > 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.<br>
<br>
    Yep.<br>
<br>
    I still think that implementing CGN is a good way to burn cash vs. the alternatives, but YMMV.<br>
<br>
    Owen<br>
<br>
    > <br>
    > - Jima<br>
    > <br>
    > From: NANOG On Behalf Of Owen DeLong<br>
    > Sent: Sunday, February 21, 2021 16:59<br>
    > To: Steve Saner<br>
    > Cc: <a href="mailto:nanog@nanog.org" target="_blank">nanog@nanog.org</a><br>
    > Subject: Re: CGNAT<br>
    > <br>
    > <br>
    > On Feb 18, 2021, at 8:38 AM, Steve Saner wrote:<br>
    > <br>
    >> 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.<br>
    > <br>
    > IPv6 Migration is generally not aided by CGNAT.<br>
    > <br>
    > In general, the economics today still work out to make purchasing or leasing addresses more favorable than CGNAT.<br>
    > <br>
    > It’s a bit dated by now, but still very relevant, see Lee Howard’s excellent research presented at the 2012 Rocky<br>
    > mountain v6 task force meeting:<br>
    > <br>
    > <a href="https://www.rmv6tf.org/wp-content/uploads/2012/11/TCO-of-CGN1.pdf" rel="noreferrer" target="_blank">https://www.rmv6tf.org/wp-content/uploads/2012/11/TCO-of-CGN1.pdf</a><br>
    > <br>
    > Owen<br>
    > <br>
    > <br>
    > 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.<br>
    > <br>
    > Thanks<br>
    > <br>
    > -- <br>
    > Steve Saner<br>
    > ideatek HUMAN AT OUR VERY FIBER<br>
    > 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.<br>
    > <br>
<br>
<br>
<br>
<br>
**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
<a href="http://www.theipv6company.com" rel="noreferrer" target="_blank">http://www.theipv6company.com</a><br>
The IPv6 Company<br>
<br>
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.<br>
<br>
<br>
<br></blockquote></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><font size="2" style="color:rgb(0,0,0)"><span style="font-family:"courier new",monospace">Douglas Fernando Fischer</span><br style="font-family:"courier new",monospace"><span style="font-family:"courier new",monospace">Engº de Controle e Automação</span></font><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;text-align:left;line-height:130%;font-family:"courier new",monospace;color:black"></div></div></div>
</blockquote></div></div>