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. 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 620.543.5026. Then take all steps necessary to permanently delete the email and all attachments from your computer system.
I recommend you to take a look at DANOS. https://danosproject.atlassian.net/wiki/spaces/DAN/pages/416153601/Carrier+G... - A very active open-source project. - Sponsored by AT&T. - Uses Vyatta (and DPDK for good performance) - The Routing Engine is based on FRR. - Syntax sounds like Junos. - Is the ONLY ONE open source project(at least that I know) that implements CGNAT on Bulk Port Allocation mode(not deterministic/predefined). - Had very good improvements on PCP recently. - Supports a few NAT-ALGs. I and some good friends here in Brazil had some good experiences with it. Marcelo Gondin wrote this tutorial in pt_BR, mentioning about a case with: 26Gbps / 1.5Mpps / 11502 simultaneous clients / 192 used Públic IPv4 addresses. https://wiki.brasilpeeringforum.org/w/CGNAT_Bulk_Port_Allocation_com_DPDK Em sex., 19 de fev. de 2021 às 11:57, Steve Saner <ssaner@ideatek.com> escreveu:
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.
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 620.543.5026. Then take all steps necessary to permanently delete the email and all attachments from your computer system.
-- Douglas Fernando Fischer Engº de Controle e Automação
Not the Cheapest option out there but the most rock solid one I have found is to install the extended service/multi service cards in the BNG and do it locally there. We are currently using both Juniper MX480/960 with MS-MPC cards and Nokia 7750 SR with ISA or ESA cards. Its also well worth running dual stack IPv6 as you can bypass 40%+ traffic from the CGN process for all that CDN traffic. From: NANOG <nanog-bounces+tony=wicks.co.nz@nanog.org> On Behalf Of Steve Saner Sent: Friday, 19 February 2021 5:39 am To: nanog@nanog.org Subject: CGNAT 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. 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> 620.543.5026. Then take all steps necessary to permanently delete the email and all attachments from your computer system.
Why not go whole hog and provide IPv4 as a service? That way you are not waiting for your customers to turn up IPv6 to take the load off your NAT box. Yes, you can do it dual stack but you have waited so long you may as well miss that step along the deployment path. -- Mark Andrews
On 20 Feb 2021, at 01:55, Steve Saner <ssaner@ideatek.com> 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.
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 620.543.5026. Then take all steps necessary to permanently delete the email and all attachments from your computer system.
I’m sure the large parts of the world already doing this would disagree. -- Mark Andrews
On 20 Feb 2021, at 07:11, Tony Wicks <tony@wicks.co.nz> wrote:
Because then a large part of the Internet won't work....
From: NANOG <nanog-bounces+tony=wicks.co.nz@nanog.org> on behalf of Mark Andrews <marka@isc.org> Sent: Saturday, 20 February 2021, 9:04 am To: Steve Saner Cc: nanog@nanog.org Subject: Re: CGNAT
Why not go whole hog and provide IPv4 as a service? That way you are not waiting for your customers to turn up IPv6 to take the load off your NAT box.
Yes, you can do it dual stack but you have waited so long you may as well miss that step along the deployment path. -- Mark Andrews
On 20 Feb 2021, at 01:55, Steve Saner <ssaner@ideatek.com> 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.
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 620.543.5026. Then take all steps necessary to permanently delete the email and all attachments from your computer system.
On 19/02/2021 20:11, Tony Wicks wrote:
Because then a large part of the Internet won't work....
Hey, look on the bright side: customers won't be able to use Twitter to complain! :D Ofc, IPv4aaS has many good success stories out there; Sky Italia are running MAP-T, many, many mobile ISPs are running 464XLAT with great success. We're in a situation where making IPv6 a *prerequisite* of your IPv4 connectivity can realistically improve your margins when some sort of CGNAT gateway is a requirement. Yes it requires looking at your CPE support, but if you're doing even 00,000's of subs, I'm sure the benefits aren't trivial when viewed through the lens of the number of connections that a single Chrome tab can happily chew through. -- Tom
That’s provably not true if the IPv4AAS implementation is done carefully. Owen
On Feb 19, 2021, at 12:11 PM, Tony Wicks <tony@wicks.co.nz> wrote:
Because then a large part of the Internet won't work....
From: NANOG <nanog-bounces+tony=wicks.co.nz@nanog.org> on behalf of Mark Andrews <marka@isc.org> Sent: Saturday, 20 February 2021, 9:04 am To: Steve Saner Cc: nanog@nanog.org Subject: Re: CGNAT
Why not go whole hog and provide IPv4 as a service? That way you are not waiting for your customers to turn up IPv6 to take the load off your NAT box.
Yes, you can do it dual stack but you have waited so long you may as well miss that step along the deployment path. -- Mark Andrews
On 20 Feb 2021, at 01:55, Steve Saner <ssaner@ideatek.com> 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.
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 620.543.5026 <tel:620.543.5026>. Then take all steps necessary to permanently delete the email and all attachments from your computer system.
IPv4AAS will also work easily for any ISP on the planet. CGNAT requires IPv4 address space between the CGNAT and the customer CPE which doesn’t overlap with that on the Internet nor that behind the CPE (no you can’t use RFC 1918). 100.64/10 gives you ~4M addresses which fit this criteria but that isn’t enough without reuse for the larger ISPs. IPv4AAS uses no IPv4 addresses between the B4/NAT64/… and the CPE. You should also be able to out source IPv4AAS to specialist providers. There is no requirement to run your own hardware. You just populate your DHCPv6/RA/IPV4ONLY.ARPA with the correct information and the traffic will be delivered to the specialist providers. I’m not sure if there are any out there yet but it is a business opportunity for anyone that is already running such boxes. Mark
On 24 Feb 2021, at 09:43, Owen DeLong <owen@delong.com> wrote:
That’s provably not true if the IPv4AAS implementation is done carefully.
Owen
On Feb 19, 2021, at 12:11 PM, Tony Wicks <tony@wicks.co.nz> wrote:
Because then a large part of the Internet won't work....
From: NANOG <nanog-bounces+tony=wicks.co.nz@nanog.org> on behalf of Mark Andrews <marka@isc.org> Sent: Saturday, 20 February 2021, 9:04 am To: Steve Saner Cc: nanog@nanog.org Subject: Re: CGNAT
Why not go whole hog and provide IPv4 as a service? That way you are not waiting for your customers to turn up IPv6 to take the load off your NAT box.
Yes, you can do it dual stack but you have waited so long you may as well miss that step along the deployment path. -- Mark Andrews
On 20 Feb 2021, at 01:55, Steve Saner <ssaner@ideatek.com> 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.
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 620.543.5026. Then take all steps necessary to permanently delete the email and all attachments from your computer system.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Feb 18, 2021, at 8:38 AM, Steve Saner <ssaner@ideatek.com> 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 <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 620.543.5026 <tel:620.543.5026>. Then take all steps necessary to permanently delete the email and all attachments from your computer system.
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) - 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 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. - 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.
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.
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.
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
On Wed, Feb 24, 2021 at 5:29 AM Douglas Fischer <fischerdouglas@gmail.com> wrote:
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...
Is this pain you have lived or verified with first hand testing? 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
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
Is this pain you have lived or verified with first hand testing?
Yep! A lot!
LOL gamers can be pretty much insistent... (haha.jpg + haha-crying.jpg) And Specifically on SIP/Voip over the Internet, with deep analysis at all the parts involved. The most common issue is incoming Calls to SIP endpoints behind 464Xlat using IPv4 with unidirectional audio. And several types of causes: - CPEs receives the RTP-Stream but doesn't Re-Map it correctly to the IPv4 inside end-point - Jool receives the RTP-Stream but ignores it and don't map it to the "fake" v6 address - Some APPs do (by some crazy reason) the re-write of Session Layer header to v6 address, and Sip-Proxys ignores it... After hours and hours fighting against the lions, we decided: "Let's keep those clients in Dual-Stak and CGNAT" and it just worked. And after that, the obvious conclusions: - Why will us keep that much options of endpoints connections, if only one solves all the problems? - We will need to train the guys on the Dual-Stack/CGNAT Scnario, and 464Xlat Scenario... Knowing about Danos, about Jool... - It doesn't scale! -- Douglas Fernando Fischer Engº de Controle e Automação
Well then use one of the encapsulating IPv4AAS mechanisms rather than 464XLAT (DS-Lite, MAP-E). They don’t involve translating the payload between IPv4 and IPv6. That said what you are reporting below are implementation bugs. Did you report them to the vendor? Did you install the fix? Rewriting is required as you may have native IPv6 clients rather than clients behind a CLAT on the customer side.
On 25 Feb 2021, at 01:48, Douglas Fischer <fischerdouglas@gmail.com> wrote:
Is this pain you have lived or verified with first hand testing?
Yep! A lot!
LOL gamers can be pretty much insistent... (haha.jpg + haha-crying.jpg)
And Specifically on SIP/Voip over the Internet, with deep analysis at all the parts involved. The most common issue is incoming Calls to SIP endpoints behind 464Xlat using IPv4 with unidirectional audio. And several types of causes: - CPEs receives the RTP-Stream but doesn't Re-Map it correctly to the IPv4 inside end-point - Jool receives the RTP-Stream but ignores it and don't map it to the "fake" v6 address - Some APPs do (by some crazy reason) the re-write of Session Layer header to v6 address, and Sip-Proxys ignores it...
After hours and hours fighting against the lions, we decided: "Let's keep those clients in Dual-Stak and CGNAT" and it just worked.
And after that, the obvious conclusions: - Why will us keep that much options of endpoints connections, if only one solves all the problems? - We will need to train the guys on the Dual-Stack/CGNAT Scnario, and 464Xlat Scenario... Knowing about Danos, about Jool... - It doesn't scale!
-- Douglas Fernando Fischer Engº de Controle e Automação
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Hello Mark... Yes, until when I was decided to Fight Agins IPv4, I tried the Fixes. But after some time, I saw that very little of the problems were due to inadequacies of the ISP's responsibility equipment. Most of the difficulties stemmed from: A) Choices of end-users in their networks. (Something that the ISP may even try to influence, but that ends up bringing more "childrens" to the support queue, as customers said, "Your company that recommended me to use software X instead of Y, so you have to teach me how to use software X".) B) Lack of adequate support for IPv6 by the companies that provided the service on the internet (eGames, IPTV, SIP-VOIP). After some time beating the dead horse, and mainly seeing that these problems did not happen with Dual-Stack, I decided to do what I was able to do well. Since 1-2 years ago, things have improved a lot in these two points, pointed out as problems that do not concern the ISP. Perhaps it is time to review this approach. Em qua., 24 de fev. de 2021 às 18:35, Mark Andrews <marka@isc.org> escreveu:
Well then use one of the encapsulating IPv4AAS mechanisms rather than 464XLAT (DS-Lite, MAP-E). They don’t involve translating the payload between IPv4 and IPv6. That said what you are reporting below are implementation bugs. Did you report them to the vendor? Did you install the fix? Rewriting is required as you may have native IPv6 clients rather than clients behind a CLAT on the customer side.
On 25 Feb 2021, at 01:48, Douglas Fischer <fischerdouglas@gmail.com> wrote:
Is this pain you have lived or verified with first hand testing?
Yep! A lot!
LOL gamers can be pretty much insistent... (haha.jpg + haha-crying.jpg)
And Specifically on SIP/Voip over the Internet, with deep analysis at all the parts involved. The most common issue is incoming Calls to SIP endpoints behind 464Xlat using IPv4 with unidirectional audio. And several types of causes: - CPEs receives the RTP-Stream but doesn't Re-Map it correctly to the IPv4 inside end-point - Jool receives the RTP-Stream but ignores it and don't map it to the "fake" v6 address - Some APPs do (by some crazy reason) the re-write of Session Layer header to v6 address, and Sip-Proxys ignores it...
After hours and hours fighting against the lions, we decided: "Let's keep those clients in Dual-Stak and CGNAT" and it just worked.
And after that, the obvious conclusions: - Why will us keep that much options of endpoints connections, if only one solves all the problems? - We will need to train the guys on the Dual-Stack/CGNAT Scnario, and 464Xlat Scenario... Knowing about Danos, about Jool... - It doesn't scale!
-- Douglas Fernando Fischer Engº de Controle e Automação
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
-- Douglas Fernando Fischer Engº de Controle e Automação
Here goes a link fo an excellent analysis of IPv6 and Playstation This says a lot about why some prefer DualStack. https://toreanderson.github.io/2021/02/23/ipv6-support-in-the-playstation-5.... Em ter., 2 de mar. de 2021 às 07:59, Douglas Fischer < fischerdouglas@gmail.com> escreveu:
Hello Mark...
Yes, until when I was decided to Fight Agins IPv4, I tried the Fixes.
But after some time, I saw that very little of the problems were due to inadequacies of the ISP's responsibility equipment.
Most of the difficulties stemmed from: A) Choices of end-users in their networks. (Something that the ISP may even try to influence, but that ends up bringing more "childrens" to the support queue, as customers said, "Your company that recommended me to use software X instead of Y, so you have to teach me how to use software X".) B) Lack of adequate support for IPv6 by the companies that provided the service on the internet (eGames, IPTV, SIP-VOIP).
After some time beating the dead horse, and mainly seeing that these problems did not happen with Dual-Stack, I decided to do what I was able to do well.
Since 1-2 years ago, things have improved a lot in these two points, pointed out as problems that do not concern the ISP. Perhaps it is time to review this approach.
Em qua., 24 de fev. de 2021 às 18:35, Mark Andrews <marka@isc.org> escreveu:
Well then use one of the encapsulating IPv4AAS mechanisms rather than 464XLAT (DS-Lite, MAP-E). They don’t involve translating the payload between IPv4 and IPv6. That said what you are reporting below are implementation bugs. Did you report them to the vendor? Did you install the fix? Rewriting is required as you may have native IPv6 clients rather than clients behind a CLAT on the customer side.
On 25 Feb 2021, at 01:48, Douglas Fischer <fischerdouglas@gmail.com> wrote:
Is this pain you have lived or verified with first hand testing?
Yep! A lot!
LOL gamers can be pretty much insistent... (haha.jpg + haha-crying.jpg)
And Specifically on SIP/Voip over the Internet, with deep analysis at all the parts involved. The most common issue is incoming Calls to SIP endpoints behind 464Xlat using IPv4 with unidirectional audio. And several types of causes: - CPEs receives the RTP-Stream but doesn't Re-Map it correctly to the IPv4 inside end-point - Jool receives the RTP-Stream but ignores it and don't map it to the "fake" v6 address - Some APPs do (by some crazy reason) the re-write of Session Layer header to v6 address, and Sip-Proxys ignores it...
After hours and hours fighting against the lions, we decided: "Let's keep those clients in Dual-Stak and CGNAT" and it just worked.
And after that, the obvious conclusions: - Why will us keep that much options of endpoints connections, if only one solves all the problems? - We will need to train the guys on the Dual-Stack/CGNAT Scnario, and 464Xlat Scenario... Knowing about Danos, about Jool... - It doesn't scale!
-- Douglas Fernando Fischer Engº de Controle e Automação
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
-- Douglas Fernando Fischer Engº de Controle e Automação
-- Douglas Fernando Fischer Engº de Controle e Automação
Hi Douglas, In a different mailing list, we had a discussion with Tore about his testing and other testing that may not be available in that blog. It was basically about 464XLAT. As you know IPv6-only with IPv4aaS, provides *dual-stack* in the customer LANs, where the PS5 was sitting. So, we concluded in that discussion that there is *no difference* for the PS5 being used with 464XLAT vs “regular dual-stack”, as expected. Further to that, I’ve done a very complete testing, for a customer, with a PS4 in a LAN with 464XLAT and everything worked fine. Unfortunately, as this was contracted by a customer, I can’t disclose all the test set, but believe me it worked. It is a deployment with 25.000.000 customers, using GPON, DSL and cellular. Regards, Jordi @jordipalet El 5/4/21 21:32, "NANOG en nombre de Douglas Fischer" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de fischerdouglas@gmail.com> escribió: Here goes a link fo an excellent analysis of IPv6 and Playstation This says a lot about why some prefer DualStack. https://toreanderson.github.io/2021/02/23/ipv6-support-in-the-playstation-5.... Em ter., 2 de mar. de 2021 às 07:59, Douglas Fischer <fischerdouglas@gmail.com> escreveu: Hello Mark... Yes, until when I was decided to Fight Agins IPv4, I tried the Fixes. But after some time, I saw that very little of the problems were due to inadequacies of the ISP's responsibility equipment. Most of the difficulties stemmed from: A) Choices of end-users in their networks. (Something that the ISP may even try to influence, but that ends up bringing more "childrens" to the support queue, as customers said, "Your company that recommended me to use software X instead of Y, so you have to teach me how to use software X".) B) Lack of adequate support for IPv6 by the companies that provided the service on the internet (eGames, IPTV, SIP-VOIP). After some time beating the dead horse, and mainly seeing that these problems did not happen with Dual-Stack, I decided to do what I was able to do well. Since 1-2 years ago, things have improved a lot in these two points, pointed out as problems that do not concern the ISP. Perhaps it is time to review this approach. Em qua., 24 de fev. de 2021 às 18:35, Mark Andrews <marka@isc.org> escreveu: Well then use one of the encapsulating IPv4AAS mechanisms rather than 464XLAT (DS-Lite, MAP-E). They don’t involve translating the payload between IPv4 and IPv6. That said what you are reporting below are implementation bugs. Did you report them to the vendor? Did you install the fix? Rewriting is required as you may have native IPv6 clients rather than clients behind a CLAT on the customer side.
On 25 Feb 2021, at 01:48, Douglas Fischer <fischerdouglas@gmail.com> wrote:
Is this pain you have lived or verified with first hand testing?
Yep! A lot!
LOL gamers can be pretty much insistent... (haha.jpg + haha-crying.jpg)
And Specifically on SIP/Voip over the Internet, with deep analysis at all the parts involved. The most common issue is incoming Calls to SIP endpoints behind 464Xlat using IPv4 with unidirectional audio. And several types of causes: - CPEs receives the RTP-Stream but doesn't Re-Map it correctly to the IPv4 inside end-point - Jool receives the RTP-Stream but ignores it and don't map it to the "fake" v6 address - Some APPs do (by some crazy reason) the re-write of Session Layer header to v6 address, and Sip-Proxys ignores it...
After hours and hours fighting against the lions, we decided: "Let's keep those clients in Dual-Stak and CGNAT" and it just worked.
And after that, the obvious conclusions: - Why will us keep that much options of endpoints connections, if only one solves all the problems? - We will need to train the guys on the Dual-Stack/CGNAT Scnario, and 464Xlat Scenario... Knowing about Danos, about Jool... - It doesn't scale!
-- Douglas Fernando Fischer Engº de Controle e Automação
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Douglas Fernando Fischer Engº de Controle e Automação -- 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.
Jordi, If I sum the numbers of times "It is a deployment with 25.000.000 customers, using GPON, DSL and cellular." (or similar)(EN, ES, PT) appears on my mail box, I guess will be over 2 hundred... But every time it hits on: -> Support Tickets! What do they tell us? -> Field Support and L1 Support Guys. Do they agree with that? Let me be clear: - I like IPv6! - I encourage the use of IPv6! - I think those guys that say "IPv6 won't be adopted" a bunch of lunatics! But, more important than IPv4, IPv6, "IPv12" is that my customers become happy and D'ONT BOTHER ME. If I would use IPX/SPX and get them even happier than they are today, I would do! The important message on Tore's post IS NOT "464XLAT is better then Dual Stack". The important message on Tore's post IS NOT "Sony and Playstation are doing IPv6 in the wrong way!". Could you please help every ISP, Every Gamer, demanding Sony and Playstation to do IPv6 the right way, without wanting to "seize the occasion" to publicize the IPv6 transition case and consultancy service? <CuteCatAskLooking> Please? </CuteCatAskLooking> Em seg., 5 de abr. de 2021 às 17:02, JORDI PALET MARTINEZ via NANOG < nanog@nanog.org> escreveu:
Hi Douglas,
In a different mailing list, we had a discussion with Tore about his testing and other testing that may not be available in that blog. It was basically about 464XLAT.
As you know IPv6-only with IPv4aaS, provides **dual-stack** in the customer LANs, where the PS5 was sitting.
So, we concluded in that discussion that there is **no difference** for the PS5 being used with 464XLAT vs “regular dual-stack”, as expected.
Further to that, I’ve done a very complete testing, for a customer, with a PS4 in a LAN with 464XLAT and everything worked fine. Unfortunately, as this was contracted by a customer, I can’t disclose all the test set, but believe me it worked. It is a deployment with 25.000.000 customers, using GPON, DSL and cellular.
Regards,
Jordi
@jordipalet
El 5/4/21 21:32, "NANOG en nombre de Douglas Fischer" < nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de fischerdouglas@gmail.com> escribió:
Here goes a link fo an excellent analysis of IPv6 and Playstation
This says a lot about why some prefer DualStack.
https://toreanderson.github.io/2021/02/23/ipv6-support-in-the-playstation-5....
Em ter., 2 de mar. de 2021 às 07:59, Douglas Fischer < fischerdouglas@gmail.com> escreveu:
Hello Mark...
Yes, until when I was decided to Fight Agins IPv4, I tried the Fixes.
But after some time, I saw that very little of the problems were due to inadequacies of the ISP's responsibility equipment.
Most of the difficulties stemmed from: A) Choices of end-users in their networks. (Something that the ISP may even try to influence, but that ends up bringing more "childrens" to the support queue, as customers said, "Your company that recommended me to use software X instead of Y, so you have to teach me how to use software X".) B) Lack of adequate support for IPv6 by the companies that provided the service on the internet (eGames, IPTV, SIP-VOIP).
After some time beating the dead horse, and mainly seeing that these problems did not happen with Dual-Stack, I decided to do what I was able to do well.
Since 1-2 years ago, things have improved a lot in these two points, pointed out as problems that do not concern the ISP. Perhaps it is time to review this approach.
Em qua., 24 de fev. de 2021 às 18:35, Mark Andrews <marka@isc.org> escreveu:
Well then use one of the encapsulating IPv4AAS mechanisms rather than 464XLAT (DS-Lite, MAP-E). They don’t involve translating the payload between IPv4 and IPv6. That said what you are reporting below are implementation bugs. Did you report them to the vendor? Did you install the fix? Rewriting is required as you may have native IPv6 clients rather than clients behind a CLAT on the customer side.
On 25 Feb 2021, at 01:48, Douglas Fischer <fischerdouglas@gmail.com> wrote:
Is this pain you have lived or verified with first hand testing?
Yep! A lot!
LOL gamers can be pretty much insistent... (haha.jpg + haha-crying.jpg)
And Specifically on SIP/Voip over the Internet, with deep analysis at all the parts involved. The most common issue is incoming Calls to SIP endpoints behind 464Xlat using IPv4 with unidirectional audio. And several types of causes: - CPEs receives the RTP-Stream but doesn't Re-Map it correctly to the IPv4 inside end-point - Jool receives the RTP-Stream but ignores it and don't map it to the "fake" v6 address - Some APPs do (by some crazy reason) the re-write of Session Layer header to v6 address, and Sip-Proxys ignores it...
After hours and hours fighting against the lions, we decided: "Let's keep those clients in Dual-Stak and CGNAT" and it just worked.
And after that, the obvious conclusions: - Why will us keep that much options of endpoints connections, if only one solves all the problems? - We will need to train the guys on the Dual-Stack/CGNAT Scnario, and 464Xlat Scenario... Knowing about Danos, about Jool... - It doesn't scale!
-- Douglas Fernando Fischer Engº de Controle e Automação
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
--
Douglas Fernando Fischer Engº de Controle e Automação
--
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.
-- Douglas Fernando Fischer Engº de Controle e Automação
The important message on Tore's post IS ALL ABOUT "Sony and Playstation are doing IPv6 in the wrong way!". Em seg., 5 de abr. de 2021 às 19:16, Douglas Fischer < fischerdouglas@gmail.com> escreveu:
Jordi, If I sum the numbers of times "It is a deployment with 25.000.000 customers, using GPON, DSL and cellular." (or similar)(EN, ES, PT) appears on my mail box, I guess will be over 2 hundred...
But every time it hits on: -> Support Tickets! What do they tell us? -> Field Support and L1 Support Guys. Do they agree with that?
Let me be clear: - I like IPv6! - I encourage the use of IPv6! - I think those guys that say "IPv6 won't be adopted" a bunch of lunatics!
But, more important than IPv4, IPv6, "IPv12" is that my customers become happy and D'ONT BOTHER ME. If I would use IPX/SPX and get them even happier than they are today, I would do!
The important message on Tore's post IS NOT "464XLAT is better then Dual Stack". The important message on Tore's post IS NOT "Sony and Playstation are doing IPv6 in the wrong way!".
Could you please help every ISP, Every Gamer, demanding Sony and Playstation to do IPv6 the right way, without wanting to "seize the occasion" to publicize the IPv6 transition case and consultancy service? <CuteCatAskLooking> Please? </CuteCatAskLooking>
Em seg., 5 de abr. de 2021 às 17:02, JORDI PALET MARTINEZ via NANOG < nanog@nanog.org> escreveu:
Hi Douglas,
In a different mailing list, we had a discussion with Tore about his testing and other testing that may not be available in that blog. It was basically about 464XLAT.
As you know IPv6-only with IPv4aaS, provides **dual-stack** in the customer LANs, where the PS5 was sitting.
So, we concluded in that discussion that there is **no difference** for the PS5 being used with 464XLAT vs “regular dual-stack”, as expected.
Further to that, I’ve done a very complete testing, for a customer, with a PS4 in a LAN with 464XLAT and everything worked fine. Unfortunately, as this was contracted by a customer, I can’t disclose all the test set, but believe me it worked. It is a deployment with 25.000.000 customers, using GPON, DSL and cellular.
Regards,
Jordi
@jordipalet
El 5/4/21 21:32, "NANOG en nombre de Douglas Fischer" < nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de fischerdouglas@gmail.com> escribió:
Here goes a link fo an excellent analysis of IPv6 and Playstation
This says a lot about why some prefer DualStack.
https://toreanderson.github.io/2021/02/23/ipv6-support-in-the-playstation-5....
Em ter., 2 de mar. de 2021 às 07:59, Douglas Fischer < fischerdouglas@gmail.com> escreveu:
Hello Mark...
Yes, until when I was decided to Fight Agins IPv4, I tried the Fixes.
But after some time, I saw that very little of the problems were due to inadequacies of the ISP's responsibility equipment.
Most of the difficulties stemmed from: A) Choices of end-users in their networks. (Something that the ISP may even try to influence, but that ends up bringing more "childrens" to the support queue, as customers said, "Your company that recommended me to use software X instead of Y, so you have to teach me how to use software X".) B) Lack of adequate support for IPv6 by the companies that provided the service on the internet (eGames, IPTV, SIP-VOIP).
After some time beating the dead horse, and mainly seeing that these problems did not happen with Dual-Stack, I decided to do what I was able to do well.
Since 1-2 years ago, things have improved a lot in these two points, pointed out as problems that do not concern the ISP. Perhaps it is time to review this approach.
Em qua., 24 de fev. de 2021 às 18:35, Mark Andrews <marka@isc.org> escreveu:
Well then use one of the encapsulating IPv4AAS mechanisms rather than 464XLAT (DS-Lite, MAP-E). They don’t involve translating the payload between IPv4 and IPv6. That said what you are reporting below are implementation bugs. Did you report them to the vendor? Did you install the fix? Rewriting is required as you may have native IPv6 clients rather than clients behind a CLAT on the customer side.
On 25 Feb 2021, at 01:48, Douglas Fischer <fischerdouglas@gmail.com> wrote:
Is this pain you have lived or verified with first hand testing?
Yep! A lot!
LOL gamers can be pretty much insistent... (haha.jpg + haha-crying.jpg)
And Specifically on SIP/Voip over the Internet, with deep analysis at all the parts involved. The most common issue is incoming Calls to SIP endpoints behind 464Xlat using IPv4 with unidirectional audio. And several types of causes: - CPEs receives the RTP-Stream but doesn't Re-Map it correctly to the IPv4 inside end-point - Jool receives the RTP-Stream but ignores it and don't map it to the "fake" v6 address - Some APPs do (by some crazy reason) the re-write of Session Layer header to v6 address, and Sip-Proxys ignores it...
After hours and hours fighting against the lions, we decided: "Let's keep those clients in Dual-Stak and CGNAT" and it just worked.
And after that, the obvious conclusions: - Why will us keep that much options of endpoints connections, if only one solves all the problems? - We will need to train the guys on the Dual-Stack/CGNAT Scnario, and 464Xlat Scenario... Knowing about Danos, about Jool... - It doesn't scale!
-- Douglas Fernando Fischer Engº de Controle e Automação
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
--
Douglas Fernando Fischer Engº de Controle e Automação
--
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.
-- Douglas Fernando Fischer Engº de Controle e Automação
-- Douglas Fernando Fischer Engº de Controle e Automação
In the pilot we have got, up to now, *0* support tickets related to 464XLAT, just normal ones. I think Cameron already told, if I’m not confused, they didn’t get support tickets, and they are doing 464XLAT in cellular and broadband for many years with hundreds of millions of customers. I don’t understand what you mean with the support folks, they just do what their boss decides, like in any other technology deployment. Of course I agree that Sony PS is not doing well, but they have been doing so bad for ages already (compared with Microsoft, Google, etc., etc.), unfortunately they don’t go to events or respond to emails to help them. If someone has a better contact, will be happy to help! Regards, Jordi @jordipalet El 6/4/21 0:18, "NANOG en nombre de Douglas Fischer" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de fischerdouglas@gmail.com> escribió: Jordi, If I sum the numbers of times "It is a deployment with 25.000.000 customers, using GPON, DSL and cellular." (or similar)(EN, ES, PT) appears on my mail box, I guess will be over 2 hundred... But every time it hits on: -> Support Tickets! What do they tell us? -> Field Support and L1 Support Guys. Do they agree with that? Let me be clear: - I like IPv6! - I encourage the use of IPv6! - I think those guys that say "IPv6 won't be adopted" a bunch of lunatics! But, more important than IPv4, IPv6, "IPv12" is that my customers become happy and D'ONT BOTHER ME. If I would use IPX/SPX and get them even happier than they are today, I would do! The important message on Tore's post IS NOT "464XLAT is better then Dual Stack". The important message on Tore's post IS NOT "Sony and Playstation are doing IPv6 in the wrong way!". Could you please help every ISP, Every Gamer, demanding Sony and Playstation to do IPv6 the right way, without wanting to "seize the occasion" to publicize the IPv6 transition case and consultancy service? <CuteCatAskLooking> Please? </CuteCatAskLooking> Em seg., 5 de abr. de 2021 às 17:02, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> escreveu: Hi Douglas, In a different mailing list, we had a discussion with Tore about his testing and other testing that may not be available in that blog. It was basically about 464XLAT. As you know IPv6-only with IPv4aaS, provides *dual-stack* in the customer LANs, where the PS5 was sitting. So, we concluded in that discussion that there is *no difference* for the PS5 being used with 464XLAT vs “regular dual-stack”, as expected. Further to that, I’ve done a very complete testing, for a customer, with a PS4 in a LAN with 464XLAT and everything worked fine. Unfortunately, as this was contracted by a customer, I can’t disclose all the test set, but believe me it worked. It is a deployment with 25.000.000 customers, using GPON, DSL and cellular. Regards, Jordi @jordipalet El 5/4/21 21:32, "NANOG en nombre de Douglas Fischer" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de fischerdouglas@gmail.com> escribió: Here goes a link fo an excellent analysis of IPv6 and Playstation This says a lot about why some prefer DualStack. https://toreanderson.github.io/2021/02/23/ipv6-support-in-the-playstation-5.... Em ter., 2 de mar. de 2021 às 07:59, Douglas Fischer <fischerdouglas@gmail.com> escreveu: Hello Mark... Yes, until when I was decided to Fight Agins IPv4, I tried the Fixes. But after some time, I saw that very little of the problems were due to inadequacies of the ISP's responsibility equipment. Most of the difficulties stemmed from: A) Choices of end-users in their networks. (Something that the ISP may even try to influence, but that ends up bringing more "childrens" to the support queue, as customers said, "Your company that recommended me to use software X instead of Y, so you have to teach me how to use software X".) B) Lack of adequate support for IPv6 by the companies that provided the service on the internet (eGames, IPTV, SIP-VOIP). After some time beating the dead horse, and mainly seeing that these problems did not happen with Dual-Stack, I decided to do what I was able to do well. Since 1-2 years ago, things have improved a lot in these two points, pointed out as problems that do not concern the ISP. Perhaps it is time to review this approach. Em qua., 24 de fev. de 2021 às 18:35, Mark Andrews <marka@isc.org> escreveu: Well then use one of the encapsulating IPv4AAS mechanisms rather than 464XLAT (DS-Lite, MAP-E). They don’t involve translating the payload between IPv4 and IPv6. That said what you are reporting below are implementation bugs. Did you report them to the vendor? Did you install the fix? Rewriting is required as you may have native IPv6 clients rather than clients behind a CLAT on the customer side.
On 25 Feb 2021, at 01:48, Douglas Fischer <fischerdouglas@gmail.com> wrote:
Is this pain you have lived or verified with first hand testing?
Yep! A lot!
LOL gamers can be pretty much insistent... (haha.jpg + haha-crying.jpg)
And Specifically on SIP/Voip over the Internet, with deep analysis at all the parts involved. The most common issue is incoming Calls to SIP endpoints behind 464Xlat using IPv4 with unidirectional audio. And several types of causes: - CPEs receives the RTP-Stream but doesn't Re-Map it correctly to the IPv4 inside end-point - Jool receives the RTP-Stream but ignores it and don't map it to the "fake" v6 address - Some APPs do (by some crazy reason) the re-write of Session Layer header to v6 address, and Sip-Proxys ignores it...
After hours and hours fighting against the lions, we decided: "Let's keep those clients in Dual-Stak and CGNAT" and it just worked.
And after that, the obvious conclusions: - Why will us keep that much options of endpoints connections, if only one solves all the problems? - We will need to train the guys on the Dual-Stack/CGNAT Scnario, and 464Xlat Scenario... Knowing about Danos, about Jool... - It doesn't scale!
-- Douglas Fernando Fischer Engº de Controle e Automação
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Douglas Fernando Fischer Engº de Controle e Automação -- 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. -- 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.
Em ter., 6 de abr. de 2021 às 04:32, JORDI PALET MARTINEZ via NANOG < nanog@nanog.org> escreveu:
I don’t understand what you mean with the support folks, they just do
what their boss decides, like in any other technology deployment. Well, Jordi... Do You know what is the important Body Part? https://www.reddit.com/r/Jokes/comments/2vgpzs/the_most_important_body_part/ 😂😅 To me(and all that I know in ISP industries, including the very small and the big ones) according to what is explained on the link above, if the ISP would be a human body, the support would be equivalent to the rectum.
On 4/5/21 22:00, JORDI PALET MARTINEZ via NANOG wrote:
Further to that, I’ve done a very complete testing, for a customer, with a PS4 in a LAN with 464XLAT and everything worked fine. Unfortunately, as this was contracted by a customer, I can’t disclose all the test set, but believe me it worked. It is a deployment with 25.000.000 customers, using GPON, DSL and cellular.
Jordi, one of these days, you are going to have to tell us if this is real :-). Mark.
I wish I could do it already! As soon as the client starts the massive deployment, it should be announced. Covid delayed it at least for 1 year up to now … Regards, Jordi @jordipalet El 6/4/21 7:07, "NANOG en nombre de Mark Tinka" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de mark@tinka.africa> escribió: On 4/5/21 22:00, JORDI PALET MARTINEZ via NANOG wrote: Further to that, I’ve done a very complete testing, for a customer, with a PS4 in a LAN with 464XLAT and everything worked fine. Unfortunately, as this was contracted by a customer, I can’t disclose all the test set, but believe me it worked. It is a deployment with 25.000.000 customers, using GPON, DSL and cellular. Jordi, one of these days, you are going to have to tell us if this is real :-). Mark. ********************************************** 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.
On 4/5/21 21:30, Douglas Fischer wrote:
Here goes a link fo an excellent analysis of IPv6 and Playstation
This says a lot about why some prefer DualStack.
https://toreanderson.github.io/2021/02/23/ipv6-support-in-the-playstation-5.... <https://toreanderson.github.io/2021/02/23/ipv6-support-in-the-playstation-5.html>
Refusing to configure an IPv6 address because there is no IPv6 DNS resolver included in the SLAAC or DHCPv6 messages is very, very broken. Mark.
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.
Hi Steve We are looking at implementing a similar solution with A10 for CGNAT. 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. The numbers below are for a similar target of subscriber’s and peak bandwidth. We assumed a couple of numbers: Current Peak Bandwidth = 40G Remaining IPv4 traffic after migration = 20% (Seen references to 10% or 20% on this forum) Future Bandwidth Growth = 2x (no data behind this assumption) Future CGNAT’ed bandwidth = 15Gbps Equipment & budget lifecycle = 7Yr Getting that data led us to this price comparison: Solution Lifecycle/ Term Annual Cost/Sub Product Lifecycle Cost/Sub Lease IPv4 Cogent 7 $ 4.45 $ 31.13 A10 CGNAT 15Gb 7Yr 7 $ 1.21 $ 8.47 A10 CGNAT 40Gb 7Yr 7 $ 1.95 $ 13.68 Purchase @ $25 7Yr 7 $ 3.57 $ 25.00 The current plan is implement an A10 CGNAT solution after upgrading our network for IPv6. In the interim we will have to lease IPv4 to tide us over. I would be curious to see what other’s estimate the costs of various approaches. Feel free to ping me off-list for more specific numbers. Kevin Burke 802-540-0979 Burlington Telecom 200 Church St, Burlington, VT From: NANOG <nanog-bounces+kburke=burlingtontelecom.com@nanog.org> on behalf of Steve Saner <ssaner@ideatek.com> Date: Friday, February 19, 2021 at 9:56 AM To: "nanog@nanog.org" <nanog@nanog.org> Subject: CGNAT 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. 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 620.543.5026<tel:620.543.5026>. Then take all steps necessary to permanently delete the email and all attachments from your computer system.
participants (11)
-
Ca By -
Douglas Fischer -
JORDI PALET MARTINEZ -
Kevin Burke -
Mark Andrews -
Mark Tinka -
nanog＠jima.us -
Owen DeLong -
Steve Saner -
Tom Hill -
Tony Wicks