Is there anyway to deploy ipv6 and push ipv4 traffic end to end across the ipv6 network. With out having an ipv4 address for everything that is ipv6? If someone could reach out off list if there is a real solution to deploy ipv6 as almost middleware.
On Sat, Aug 22, 2020 at 6:51 AM Brian <brian.bsi@gmail.com> wrote:
Is there anyway to deploy ipv6 and push ipv4 traffic end to end across the ipv6 network. With out having an ipv4 address for everything that is ipv6? If someone could reach out off list if there is a real solution to deploy ipv6 as almost middleware.
This has been deployed in many networks, mostly mobiles, but also wireline broadband and data center https://tools.ietf.org/html/rfc6877 https://tools.ietf.org/html/rfc7755
I've been looking into implementing 646XLAT, however I found the problem ends up with clients' routers. When you give them Ethernet cable that has internet on it, whatever it gets plugged into must support CLAT in order for 646XLAT to work. I was not able to find any small devices that support it natively, at least according to their description. The only way I found to enable CLAT support is to flash those devices with OpenWRT, which is not really an option when you are giving away those tiny boxes to residential clients when they sign up with you. So for now we're stuck with CGNAT. :( I do hope I'm wrong and you can tell me which device works with 646XLAT out of the box. And hopefully it's something TRENDnet's. -- Roman V Tatarnikov https://linkedin.com/in/rtatarnikov W: 310 929 2607 | C: 805 746 2886
You probably mean 464XLAT .... Ask you vendors. They should support it. Ask for RFC8585 support, even better. If they don't do, is because they are interested only in selling new boxes ... just something to think in the future about those vendors. I can tell you that many vendors now support or are waiting for some customers to ask for it, the CLAT. I've been doing this for many customers. Sometimes, they only do under request, same as many other firmware features. Regards, Jordi @jordipalet El 24/8/20 16:32, "NANOG en nombre de Roman Tatarnikov" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de r.tatarnikov@intlos.org> escribió: I've been looking into implementing 646XLAT, however I found the problem ends up with clients' routers. When you give them Ethernet cable that has internet on it, whatever it gets plugged into must support CLAT in order for 646XLAT to work. I was not able to find any small devices that support it natively, at least according to their description. The only way I found to enable CLAT support is to flash those devices with OpenWRT, which is not really an option when you are giving away those tiny boxes to residential clients when they sign up with you. So for now we're stuck with CGNAT. :( I do hope I'm wrong and you can tell me which device works with 646XLAT out of the box. And hopefully it's something TRENDnet's. -- Roman V Tatarnikov https://linkedin.com/in/rtatarnikov W: 310 929 2607 | C: 805 746 2886 ********************************************** 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 24/Aug/20 17:21, JORDI PALET MARTINEZ via NANOG wrote:
You probably mean 464XLAT ....
Ask you vendors. They should support it. Ask for RFC8585 support, even better.
If they don't do, is because they are interested only in selling new boxes ... just something to think in the future about those vendors.
I can tell you that many vendors now support or are waiting for some customers to ask for it, the CLAT. I've been doing this for many customers. Sometimes, they only do under request, same as many other firmware features.
If CLAT support were wide-spread, it would quickly accelerate the deployment of IPv6 in broadband applications. Not even Mikrotik are doing it, and they pretty much own the FTTH CPE market in many countries. If only CPE's could run Android, or Windows :-). Mark.
On 25/08/2020 17:13, Mark Tinka wrote:
If only CPE's could run Android, or Windows :-).
I'd wager that a lot of them already build upon a Linux kernel of some flavour. Tore (et al) wrote a CLAT for Linux that builds upon TAYGA's NAT64 functionality: https://github.com/toreanderson/clatd -- Tom
On 25/Aug/20 18:28, Tom Hill wrote:
I'd wager that a lot of them already build upon a Linux kernel of some flavour. Tore (et al) wrote a CLAT for Linux that builds upon TAYGA's NAT64 functionality: https://github.com/toreanderson/clatd
I guess my point was this is out in the wild on millions of devices working like a charm. For probably as long as I've known Cameron, even... All CPE vendors know that IPv6 is what will give them continued sales and growth. I'd rather they stopped fixing 6to4 bugs and actually wrote CLAT implementations. Chances are an 802.11ax wireless router you can pick up in the shop has some basic IPv6 support (you know, SLAAC... maybe PD if they really put in some elbow-grease), but not CLAT. All that tech. for some fancy wi-fi, and I can't do the basics? It's like router vendors telling me how many 10Gbps, 40Gbps and 100Gbps ports their new box or line card is shipping with, but don't understand all that speed means nothing if I can't get a feature I need to work due to immature software or chipset limitations. It's NOT ALWAYS about port or fabric speed. And it's NOT ALWAYS about the latest wi-fi standards. It's 2020. Mark.
On Tue, Aug 25, 2020 at 9:17 AM Mark Tinka <mark.tinka@seacom.com> wrote:
On 24/Aug/20 17:21, JORDI PALET MARTINEZ via NANOG wrote:
You probably mean 464XLAT ....
Ask you vendors. They should support it. Ask for RFC8585 support, even better.
If they don't do, is because they are interested only in selling new boxes ... just something to think in the future about those vendors.
I can tell you that many vendors now support or are waiting for some customers to ask for it, the CLAT. I've been doing this for many customers. Sometimes, they only do under request, same as many other firmware features.
If CLAT support were wide-spread, it would quickly accelerate the
deployment of IPv6 in broadband applications.
Not even Mikrotik are doing it, and they pretty much own the FTTH CPE
market in many countries.
If only CPE's could run Android, or Windows :-).
Mark.
Askey ships 464xlat boxes for T-Mobile in the USA, so they have the products and the knowledge to make it work https://www.askey.com.tw/index.html I am aware of other big CPE makers too, but this is the public one providing product today. Also, anything based on OpenWRT works... which is increasingly the base vendors build on.
On 25/Aug/20 18:28, Ca By wrote:
Askey ships 464xlat boxes for T-Mobile in the USA, so they have the products and the knowledge to make it work
https://www.askey.com.tw/index.html
I am aware of other big CPE makers too, but this is the public one providing product today. Also, anything based on OpenWRT works... which is increasingly the base vendors build on.
Thanks, Cameron. We'll reach out and see what we can do with them. Mark.
Many vendors are running on top of OpenWRT or Linux, and both of them have CLAT support.
Unfortunately, I can't give names which aren't already published, such as Sagemcom, D-Link, NEC and Technicolor. Believe me there are others, you just need to ask them.
This shouldn't be that hard. --- NDAs
Mikrotik is the worst vendor for anything related to transition. They only run pure dual-stack, and even on that, they are really bad. They even use a broken naming convention against the standards. They use 6to4 instead of 6in4, which get a lot of folks confused ...
Agreed. But they are just about the only mass CPE vendor that ships code to add capability, vs. the traditional ones who require you to buy a new router every year just to get new features. That and being so cheap, you can't talk customers out of preferring to buy them. It's not a great situation, but hey... supply & demand. --- I’ve managed to get better support from vendors which are different than Mikrotik. Some years ago, I even offered Mikrotik *free* help to correctly do transition … and I’m still waiting for a single response. I guess they have other priorities than IPv6 at all. --- I can buy 10-15 USD CPEs directly from China, with OpenWRT already installed, which have exactly the same design as the Mikrotik (same SoC, same number of LAN/WAN ports, etc.). ********************************************** 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 25/Aug/20 19:36, JORDI PALET MARTINEZ via NANOG wrote:
--- I’ve managed to get better support from vendors which are different than Mikrotik. Some years ago, I even offered Mikrotik **free** help to correctly do transition … and I’m still waiting for a single response. I guess they have other priorities than IPv6 at all.
--- I can buy 10-15 USD CPEs directly from China, with OpenWRT already installed, which have exactly the same design as the Mikrotik (same SoC, same number of LAN/WAN ports, etc.).
You're probably right. But if Mikrotik are having great success at meeting the budget of most providers and customers, perhaps a different approach is worth considering. Not that you haven't done you utmost best, as I know you to always do, Jordi. I wish I didn't have to deal with Mikrotik either, but reality is far more different. Heck, I even own and use one myself, for my home FTTH connection :-). Mark.
Even comparing Mikrotik (volume) vs low-volume purchases in China, there are few much cheaper products offering at least the same Mikrotik functions/performance. A few years ago, I was thinking that the cost of the “replacement” of the CPE was too high for most of the operators. Not because the CPE itself, but the logistics or actually replacing it. But since a few years, when you put the cost of CGN + IPv4 addresses (or actually just buying “more” IPv4 addresses and offering dual-stack without CGN – because the CGN will require you to swap the IPv4 pools just because Sony PSN is continuously blacklisting you) versus the lower number of IPv4 addresses needed for 464XLAT and lower number of NAT64 boxes, in most cases, it compensates for the cost of replacing the CPEs, and you have additional marketing advantages that you can sell and even charge for them, such as “Now we give you a box with Gigabit ports, greener for the planet - lower power consumption, better WiFi, better security, ready for the future with IPv6, IPv6 is faster with your social networks, youtube and many websites, etc., etc.) Regards, Jordi @jordipalet El 25/8/20 19:46, "NANOG en nombre de Mark Tinka" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de mark.tinka@seacom.com> escribió: On 25/Aug/20 19:36, JORDI PALET MARTINEZ via NANOG wrote: --- I’ve managed to get better support from vendors which are different than Mikrotik. Some years ago, I even offered Mikrotik *free* help to correctly do transition … and I’m still waiting for a single response. I guess they have other priorities than IPv6 at all. --- I can buy 10-15 USD CPEs directly from China, with OpenWRT already installed, which have exactly the same design as the Mikrotik (same SoC, same number of LAN/WAN ports, etc.). You're probably right. But if Mikrotik are having great success at meeting the budget of most providers and customers, perhaps a different approach is worth considering. Not that you haven't done you utmost best, as I know you to always do, Jordi. I wish I didn't have to deal with Mikrotik either, but reality is far more different. Heck, I even own and use one myself, for my home FTTH connection :-). 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 25/Aug/20 21:36, JORDI PALET MARTINEZ via NANOG wrote:
A few years ago, I was thinking that the cost of the “replacement” of the CPE was too high for most of the operators. Not because the CPE itself, but the logistics or actually replacing it.
Which makes (or made) the case for vCPE. You don't need to truck-roll. All the smarts happen in the data centre.
But since a few years, when you put the cost of CGN + IPv4 addresses (or actually just buying “more” IPv4 addresses and offering dual-stack without CGN – because the CGN will require you to swap the IPv4 pools just because Sony PSN is continuously blacklisting you) versus the lower number of IPv4 addresses needed for 464XLAT and lower number of NAT64 boxes, in most cases, it compensates for the cost of replacing the CPEs, and you have additional marketing advantages that you can sell and even charge for them, such as “Now we give you a box with Gigabit ports, greener for the planet - lower power consumption, better WiFi, better security, ready for the future with IPv6, IPv6 is faster with your social networks, youtube and many websites, etc., etc.)
Agreed. Whether you go vCPE and upgrade all your customers in one go without truck-rolling, or if you actually truck-roll and replace the CPE with those which support CLAT, it makes technical and commercial sense vs. having to deal with IPv4 and CGN's. Mark.
On 8/25/20 12:28 PM, Ca By wrote:
I am aware of other big CPE makers too, but this is the public one providing product today. Also, anything based on OpenWRT works... which is increasingly the base vendors build on.
Last I asked SmartRG (Adtran), they were supporting 464XLAT with CLAT, though I haven't verified that it works. They're at least acknowledging demand for it which is a nice step forward. -- Brandon Martin
Many vendors are running on top of OpenWRT or Linux, and both of them have CLAT support. Unfortunately, I can't give names which aren't already published, such as Sagemcom, D-Link, NEC and Technicolor. Believe me there are others, you just need to ask them. Mikrotik is the worst vendor for anything related to transition. They only run pure dual-stack, and even on that, they are really bad. They even use a broken naming convention against the standards. They use 6to4 instead of 6in4, which get a lot of folks confused ... Regards, Jordi @jordipalet El 25/8/20 18:15, "NANOG en nombre de Mark Tinka" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de mark.tinka@seacom.com> escribió: On 24/Aug/20 17:21, JORDI PALET MARTINEZ via NANOG wrote: > You probably mean 464XLAT .... > > Ask you vendors. They should support it. Ask for RFC8585 support, even better. > > If they don't do, is because they are interested only in selling new boxes ... just something to think in the future about those vendors. > > I can tell you that many vendors now support or are waiting for some customers to ask for it, the CLAT. I've been doing this for many customers. Sometimes, they only do under request, same as many other firmware features. If CLAT support were wide-spread, it would quickly accelerate the deployment of IPv6 in broadband applications. Not even Mikrotik are doing it, and they pretty much own the FTTH CPE market in many countries. If only CPE's could run Android, or Windows :-). 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 25/Aug/20 18:46, JORDI PALET MARTINEZ via NANOG wrote:
Many vendors are running on top of OpenWRT or Linux, and both of them have CLAT support.
Unfortunately, I can't give names which aren't already published, such as Sagemcom, D-Link, NEC and Technicolor. Believe me there are others, you just need to ask them.
This shouldn't be that hard.
Mikrotik is the worst vendor for anything related to transition. They only run pure dual-stack, and even on that, they are really bad. They even use a broken naming convention against the standards. They use 6to4 instead of 6in4, which get a lot of folks confused ...
Agreed. But they are just about the only mass CPE vendor that ships code to add capability, vs. the traditional ones who require you to buy a new router every year just to get new features. That and being so cheap, you can't talk customers out of preferring to buy them. It's not a great situation, but hey... supply & demand. Mark.
Another thing worth of consideration is that virtually any box with an OpenWRT image can support CLAT if it has enough resources. Owen
On Aug 24, 2020, at 8:21 AM, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote:
You probably mean 464XLAT ....
Ask you vendors. They should support it. Ask for RFC8585 support, even better.
If they don't do, is because they are interested only in selling new boxes ... just something to think in the future about those vendors.
I can tell you that many vendors now support or are waiting for some customers to ask for it, the CLAT. I've been doing this for many customers. Sometimes, they only do under request, same as many other firmware features.
Regards, Jordi @jordipalet
El 24/8/20 16:32, "NANOG en nombre de Roman Tatarnikov" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de r.tatarnikov@intlos.org> escribió:
I've been looking into implementing 646XLAT, however I found the problem ends up with clients' routers.
When you give them Ethernet cable that has internet on it, whatever it gets plugged into must support CLAT in order for 646XLAT to work. I was not able to find any small devices that support it natively, at least according to their description. The only way I found to enable CLAT support is to flash those devices with OpenWRT, which is not really an option when you are giving away those tiny boxes to residential clients when they sign up with you.
So for now we're stuck with CGNAT. :( I do hope I'm wrong and you can tell me which device works with 646XLAT out of the box. And hopefully it's something TRENDnet's.
-- Roman V Tatarnikov https://linkedin.com/in/rtatarnikov W: 310 929 2607 | C: 805 746 2886
********************************************** 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.
I just make it easy and don't support the client using their own router. Doesn't work? unplug your router and use mine. That eliminates a lot of problems. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Roman Tatarnikov" <r.tatarnikov@intlos.org> To: "Ca By" <cb.list6@gmail.com> Cc: "NANOG" <nanog@nanog.org> Sent: Saturday, August 22, 2020 12:55:08 PM Subject: Re: Ipv6 help I've been looking into implementing 646XLAT, however I found the problem ends up with clients' routers. When you give them Ethernet cable that has internet on it, whatever it gets plugged into must support CLAT in order for 646XLAT to work. I was not able to find any small devices that support it natively, at least according to their description. The only way I found to enable CLAT support is to flash those devices with OpenWRT, which is not really an option when you are giving away those tiny boxes to residential clients when they sign up with you. So for now we're stuck with CGNAT. :( I do hope I'm wrong and you can tell me which device works with 646XLAT out of the box. And hopefully it's something TRENDnet's. -- Roman V Tatarnikov https://linkedin.com/in/rtatarnikov W: 310 929 2607 | C: 805 746 2886
This is very common in many countries and not related to IPv6, but because many operators have special configs or features in the CPEs they provide. If you don’t use our own CPE, we can’t warrantee the service neither the support. El 25/8/20 21:00, "NANOG en nombre de Mike Hammett" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de nanog@ics-il.net> escribió: I just make it easy and don't support the client using their own router. Doesn't work? unplug your router and use mine. That eliminates a lot of problems. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From: "Roman Tatarnikov" <r.tatarnikov@intlos.org> To: "Ca By" <cb.list6@gmail.com> Cc: "NANOG" <nanog@nanog.org> Sent: Saturday, August 22, 2020 12:55:08 PM Subject: Re: Ipv6 help I've been looking into implementing 646XLAT, however I found the problem ends up with clients' routers. When you give them Ethernet cable that has internet on it, whatever it gets plugged into must support CLAT in order for 646XLAT to work. I was not able to find any small devices that support it natively, at least according to their description. The only way I found to enable CLAT support is to flash those devices with OpenWRT, which is not really an option when you are giving away those tiny boxes to residential clients when they sign up with you. So for now we're stuck with CGNAT. :( I do hope I'm wrong and you can tell me which device works with 646XLAT out of the box. And hopefully it's something TRENDnet's. -- Roman V Tatarnikov https://linkedin.com/in/rtatarnikov W: 310 929 2607 | C: 805 746 2886 ********************************************** 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 8/25/20 3:38 PM, JORDI PALET MARTINEZ via NANOG wrote:
This is very common in many countries and not related to IPv6, but because many operators have special configs or features in the CPEs they provide.
I really, really hate to force users to use my network edge router (I provide the ONT, though, and I provide an edge router that works and most users do take it), but it can be tough to ensure users have something that supports all the right modern features and can be configured via standard means. It would be nice if the consumer router industry could get its collective act together and at least come up with some easy-ish to understand feature support table that customers can match up with their service provider's list of needs. The status quo of a list of devices that work right (which is of course often staggeringly short if you're doing any of these modern transition mechanisms) that needs constant updating and may not be easily available is not ideal. Heck just having a real, complete list of supported features on the model support page on their website would be an improvement... -- Brandon Martin
I usually solve this problem by designing for NAT444 and dual-stack. This solves both problems and allows for users to migrate as they are able/need to. If you try and force the change, you will loose users.
On Aug 25, 2020, at 3:15 PM, Brandon Martin <lists.nanog@monmotha.net> wrote:
On 8/25/20 3:38 PM, JORDI PALET MARTINEZ via NANOG wrote:
This is very common in many countries and not related to IPv6, but because many operators have special configs or features in the CPEs they provide.
I really, really hate to force users to use my network edge router (I provide the ONT, though, and I provide an edge router that works and most users do take it), but it can be tough to ensure users have something that supports all the right modern features and can be configured via standard means.
It would be nice if the consumer router industry could get its collective act together and at least come up with some easy-ish to understand feature support table that customers can match up with their service provider's list of needs. The status quo of a list of devices that work right (which is of course often staggeringly short if you're doing any of these modern transition mechanisms) that needs constant updating and may not be easily available is not ideal.
Heck just having a real, complete list of supported features on the model support page on their website would be an improvement... -- Brandon Martin
On 25/Aug/20 22:40, Brian Johnson wrote:
I usually solve this problem by designing for NAT444 and dual-stack. This solves both problems and allows for users to migrate as they are able/need to. If you try and force the change, you will loose users.
At some point, you run out of IPv4. You could cascade to a high degree of NAT444, but then it gets hairy, and costly, at some point. Mark.
Over sub at around 20-40 to 1 is very easy now. With PBA, DET-NAT and other tools, the average customer largely doesn’t know it is happening and it solves for many provider side issues as well (logging being the biggest). For those customers who have issues, the over-sub ratios leave IPv4 space for those corner cases and/or native IPv6 should be made available. And before anyone yells that this "breaks something,” It was already broken.
On Aug 25, 2020, at 11:46 PM, Mark Tinka <mark.tinka@seacom.com> wrote:
On 25/Aug/20 22:40, Brian Johnson wrote:
I usually solve this problem by designing for NAT444 and dual-stack. This solves both problems and allows for users to migrate as they are able/need to. If you try and force the change, you will loose users.
At some point, you run out of IPv4.
You could cascade to a high degree of NAT444, but then it gets hairy, and costly, at some point.
Mark.
On 26/Aug/20 16:38, Brian Johnson wrote:
Over sub at around 20-40 to 1 is very easy now. With PBA, DET-NAT and other tools, the average customer largely doesn’t know it is happening and it solves for many provider side issues as well (logging being the biggest). For those customers who have issues, the over-sub ratios leave IPv4 space for those corner cases and/or native IPv6 should be made available.
And before anyone yells that this "breaks something,” It was already broken.
I'll dedicate my time to limited flexing with CPE vendors on implementing CLAT, thanks :-). If that doesn't work for me in the short term, hopefully, it will help someone else in the long run. Mark.
No, this doesn't work The point your're missing (when I talked before about putting all the costs to make a good calculation of each case and then replacing CPEs become actually cheaper) is that you need more IPv4 addresses in CGN than in NAT64 and further to that, in CGN, your IPv4 pools sooner or later become blocked by PSN (unless you don't have gammers among your customers). El 25/8/20 22:42, "NANOG en nombre de Brian Johnson" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de brian.johnson@netgeek.us> escribió: I usually solve this problem by designing for NAT444 and dual-stack. This solves both problems and allows for users to migrate as they are able/need to. If you try and force the change, you will loose users. > On Aug 25, 2020, at 3:15 PM, Brandon Martin <lists.nanog@monmotha.net> wrote: > > On 8/25/20 3:38 PM, JORDI PALET MARTINEZ via NANOG wrote: >> This is very common in many countries and not related to IPv6, but because many operators have special configs or features in the CPEs they provide. > > I really, really hate to force users to use my network edge router (I provide the ONT, though, and I provide an edge router that works and most users do take it), but it can be tough to ensure users have something that supports all the right modern features and can be configured via standard means. > > It would be nice if the consumer router industry could get its collective act together and at least come up with some easy-ish to understand feature support table that customers can match up with their service provider's list of needs. The status quo of a list of devices that work right (which is of course often staggeringly short if you're doing any of these modern transition mechanisms) that needs constant updating and may not be easily available is not ideal. > > Heck just having a real, complete list of supported features on the model support page on their website would be an improvement... > -- > Brandon Martin ********************************************** 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.
How doesn’t it work? As long as IPv6 is *on* NAT444 + dual stack has the same properties (or better, less PMTUD issues) as turning on 464XLAT in the CPE. Traffic shifts to IPv6 due to hosts preferring IPv6. You can still disable sending RA’s in either scenario. Mark
On 26 Aug 2020, at 16:51, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote:
No, this doesn't work
The point your're missing (when I talked before about putting all the costs to make a good calculation of each case and then replacing CPEs become actually cheaper) is that you need more IPv4 addresses in CGN than in NAT64 and further to that, in CGN, your IPv4 pools sooner or later become blocked by PSN (unless you don't have gammers among your customers).
El 25/8/20 22:42, "NANOG en nombre de Brian Johnson" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de brian.johnson@netgeek.us> escribió:
I usually solve this problem by designing for NAT444 and dual-stack. This solves both problems and allows for users to migrate as they are able/need to. If you try and force the change, you will loose users.
On Aug 25, 2020, at 3:15 PM, Brandon Martin <lists.nanog@monmotha.net> wrote:
On 8/25/20 3:38 PM, JORDI PALET MARTINEZ via NANOG wrote:
This is very common in many countries and not related to IPv6, but because many operators have special configs or features in the CPEs they provide.
I really, really hate to force users to use my network edge router (I provide the ONT, though, and I provide an edge router that works and most users do take it), but it can be tough to ensure users have something that supports all the right modern features and can be configured via standard means.
It would be nice if the consumer router industry could get its collective act together and at least come up with some easy-ish to understand feature support table that customers can match up with their service provider's list of needs. The status quo of a list of devices that work right (which is of course often staggeringly short if you're doing any of these modern transition mechanisms) that needs constant updating and may not be easily available is not ideal.
Heck just having a real, complete list of supported features on the model support page on their website would be an improvement... -- Brandon Martin
********************************************** 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.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
It was a way to say. Because you use IPv4 pools in the CGN. Then when detected by some services such as PSN, they are black-listed. You use other pools, they become black listed again, and so on. This is not the case with NAT64/464XLAT. So yeah, it works but the cost of purchasing CGN is actually becoming higher and you will need sooner or later, to buy more IPv4 addresses once all them are black-listed. I've not heard about anyone that has been able to convince Sony to clean their addresses from the PSN CGN black-list. El 26/8/20 9:07, "Mark Andrews" <marka@isc.org> escribió: How doesn’t it work? As long as IPv6 is *on* NAT444 + dual stack has the same properties (or better, less PMTUD issues) as turning on 464XLAT in the CPE. Traffic shifts to IPv6 due to hosts preferring IPv6. You can still disable sending RA’s in either scenario. Mark > On 26 Aug 2020, at 16:51, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote: > > No, this doesn't work > > The point your're missing (when I talked before about putting all the costs to make a good calculation of each case and then replacing CPEs become actually cheaper) is that you need more IPv4 addresses in CGN than in NAT64 and further to that, in CGN, your IPv4 pools sooner or later become blocked by PSN (unless you don't have gammers among your customers). > > El 25/8/20 22:42, "NANOG en nombre de Brian Johnson" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de brian.johnson@netgeek.us> escribió: > > I usually solve this problem by designing for NAT444 and dual-stack. This solves both problems and allows for users to migrate as they are able/need to. If you try and force the change, you will loose users. > > >> On Aug 25, 2020, at 3:15 PM, Brandon Martin <lists.nanog@monmotha.net> wrote: >> >> On 8/25/20 3:38 PM, JORDI PALET MARTINEZ via NANOG wrote: >>> This is very common in many countries and not related to IPv6, but because many operators have special configs or features in the CPEs they provide. >> >> I really, really hate to force users to use my network edge router (I provide the ONT, though, and I provide an edge router that works and most users do take it), but it can be tough to ensure users have something that supports all the right modern features and can be configured via standard means. >> >> It would be nice if the consumer router industry could get its collective act together and at least come up with some easy-ish to understand feature support table that customers can match up with their service provider's list of needs. The status quo of a list of devices that work right (which is of course often staggeringly short if you're doing any of these modern transition mechanisms) that needs constant updating and may not be easily available is not ideal. >> >> Heck just having a real, complete list of supported features on the model support page on their website would be an improvement... >> -- >> Brandon Martin > > > > > ********************************************** > 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. > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org ********************************************** 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.
I’ve not experienced this with PSN and NAT444. I have a LOT of customers doing it without issue. Maybee it’s that the customer has native IPv6 and solves for the problem that way, but then this just becomes make sure IPv6 is provided and it solves for the corner case.
On Aug 26, 2020, at 2:13 AM, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote:
It was a way to say.
Because you use IPv4 pools in the CGN. Then when detected by some services such as PSN, they are black-listed. You use other pools, they become black listed again, and so on.
This is not the case with NAT64/464XLAT.
So yeah, it works but the cost of purchasing CGN is actually becoming higher and you will need sooner or later, to buy more IPv4 addresses once all them are black-listed.
I've not heard about anyone that has been able to convince Sony to clean their addresses from the PSN CGN black-list.
El 26/8/20 9:07, "Mark Andrews" <marka@isc.org> escribió:
How doesn’t it work? As long as IPv6 is *on* NAT444 + dual stack has the same properties (or better, less PMTUD issues) as turning on 464XLAT in the CPE. Traffic shifts to IPv6 due to hosts preferring IPv6. You can still disable sending RA’s in either scenario.
Mark
On 26 Aug 2020, at 16:51, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote:
No, this doesn't work
The point your're missing (when I talked before about putting all the costs to make a good calculation of each case and then replacing CPEs become actually cheaper) is that you need more IPv4 addresses in CGN than in NAT64 and further to that, in CGN, your IPv4 pools sooner or later become blocked by PSN (unless you don't have gammers among your customers).
El 25/8/20 22:42, "NANOG en nombre de Brian Johnson" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de brian.johnson@netgeek.us> escribió:
I usually solve this problem by designing for NAT444 and dual-stack. This solves both problems and allows for users to migrate as they are able/need to. If you try and force the change, you will loose users.
On Aug 25, 2020, at 3:15 PM, Brandon Martin <lists.nanog@monmotha.net> wrote:
On 8/25/20 3:38 PM, JORDI PALET MARTINEZ via NANOG wrote:
This is very common in many countries and not related to IPv6, but because many operators have special configs or features in the CPEs they provide.
I really, really hate to force users to use my network edge router (I provide the ONT, though, and I provide an edge router that works and most users do take it), but it can be tough to ensure users have something that supports all the right modern features and can be configured via standard means.
It would be nice if the consumer router industry could get its collective act together and at least come up with some easy-ish to understand feature support table that customers can match up with their service provider's list of needs. The status quo of a list of devices that work right (which is of course often staggeringly short if you're doing any of these modern transition mechanisms) that needs constant updating and may not be easily available is not ideal.
Heck just having a real, complete list of supported features on the model support page on their website would be an improvement... -- Brandon Martin
********************************************** 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.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
********************************************** 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.
The crazy thing is that PSN doesn't (up to my knowledge) yet work with IPv6 ... but I understand that when several players are behind the same CGN, games don't work as expected (may be not all them). So, Sony decided long time ago to ban forever, any CGN IPv4 pools that they detect on that situation. It is not something that happens "immediately" you have a CGN, but I'n aware of several customers that got into that situation. Not just Sony, other services are doing the same. I heard about OpenDNS cases as well. El 26/8/20 16:42, "Brian Johnson" <brian.johnson@netgeek.us> escribió: I’ve not experienced this with PSN and NAT444. I have a LOT of customers doing it without issue. Maybee it’s that the customer has native IPv6 and solves for the problem that way, but then this just becomes make sure IPv6 is provided and it solves for the corner case. > On Aug 26, 2020, at 2:13 AM, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote: > > It was a way to say. > > Because you use IPv4 pools in the CGN. Then when detected by some services such as PSN, they are black-listed. You use other pools, they become black listed again, and so on. > > This is not the case with NAT64/464XLAT. > > So yeah, it works but the cost of purchasing CGN is actually becoming higher and you will need sooner or later, to buy more IPv4 addresses once all them are black-listed. > > I've not heard about anyone that has been able to convince Sony to clean their addresses from the PSN CGN black-list. > > > > El 26/8/20 9:07, "Mark Andrews" <marka@isc.org> escribió: > > How doesn’t it work? As long as IPv6 is *on* NAT444 + dual stack has the same properties (or better, less PMTUD issues) as turning on 464XLAT in the CPE. Traffic shifts to IPv6 due to hosts preferring IPv6. You can still disable sending RA’s in either scenario. > > Mark > >> On 26 Aug 2020, at 16:51, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote: >> >> No, this doesn't work >> >> The point your're missing (when I talked before about putting all the costs to make a good calculation of each case and then replacing CPEs become actually cheaper) is that you need more IPv4 addresses in CGN than in NAT64 and further to that, in CGN, your IPv4 pools sooner or later become blocked by PSN (unless you don't have gammers among your customers). >> >> El 25/8/20 22:42, "NANOG en nombre de Brian Johnson" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de brian.johnson@netgeek.us> escribió: >> >> I usually solve this problem by designing for NAT444 and dual-stack. This solves both problems and allows for users to migrate as they are able/need to. If you try and force the change, you will loose users. >> >> >>> On Aug 25, 2020, at 3:15 PM, Brandon Martin <lists.nanog@monmotha.net> wrote: >>> >>> On 8/25/20 3:38 PM, JORDI PALET MARTINEZ via NANOG wrote: >>>> This is very common in many countries and not related to IPv6, but because many operators have special configs or features in the CPEs they provide. >>> >>> I really, really hate to force users to use my network edge router (I provide the ONT, though, and I provide an edge router that works and most users do take it), but it can be tough to ensure users have something that supports all the right modern features and can be configured via standard means. >>> >>> It would be nice if the consumer router industry could get its collective act together and at least come up with some easy-ish to understand feature support table that customers can match up with their service provider's list of needs. The status quo of a list of devices that work right (which is of course often staggeringly short if you're doing any of these modern transition mechanisms) that needs constant updating and may not be easily available is not ideal. >>> >>> Heck just having a real, complete list of supported features on the model support page on their website would be an improvement... >>> -- >>> Brandon Martin >> >> >> >> >> ********************************************** >> 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. >> >> >> > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
On 26/Aug/20 18:42, JORDI PALET MARTINEZ via NANOG wrote:
The crazy thing is that PSN doesn't (up to my knowledge) yet work with IPv6 ...
To this day, my PS4, running Sony's latest code, does not support IPv6. That might be a good place to start, for them. At the rate they are doing, the PS5 might ship with RIPv2. Mark.
This sounds like a Sony problem more than a network problem. They need to get on the IPv6 train and play nice with the Internet. X-BOX has had IPv6 support since X-BOX One.
On Aug 26, 2020, at 1:09 PM, Mark Tinka <mark.tinka@seacom.com> wrote:
On 26/Aug/20 18:42, JORDI PALET MARTINEZ via NANOG wrote:
The crazy thing is that PSN doesn't (up to my knowledge) yet work with IPv6 ...
To this day, my PS4, running Sony's latest code, does not support IPv6.
That might be a good place to start, for them.
At the rate they are doing, the PS5 might ship with RIPv2.
Mark.
On 26/Aug/20 20:14, Brian Johnson wrote:
This sounds like a Sony problem more than a network problem. They need to get on the IPv6 train and play nice with the Internet. X-BOX has had IPv6 support since X-BOX One.
IIRC, someone here said the issue wasn't so much PS4 (which runs FreeBSD-9.0), but the PSN back-end. I can believe this, as Sony TV I bought back in 2015 had IPv6 support, on their own embedded OS. Mark.
Either way. Nothing you can do in the network will help Sony enable IPv6 capability, Or to serve their users even if using a technology that they do not like.
On Aug 26, 2020, at 1:17 PM, Mark Tinka <mark.tinka@seacom.com> wrote:
On 26/Aug/20 20:14, Brian Johnson wrote:
This sounds like a Sony problem more than a network problem. They need to get on the IPv6 train and play nice with the Internet. X-BOX has had IPv6 support since X-BOX One.
IIRC, someone here said the issue wasn't so much PS4 (which runs FreeBSD-9.0), but the PSN back-end.
I can believe this, as Sony TV I bought back in 2015 had IPv6 support, on their own embedded OS.
Mark.
On 26/Aug/20 20:20, Brian Johnson wrote:
Either way. Nothing you can do in the network will help Sony enable IPv6 capability, Or to serve their users even if using a technology that they do not like.
Agreed. The problem is gaming customers that neither care for nor know about how NAT444 and/or IPv6 play (no pun intended) here. Mark.
I‘m going further... They shouldn’t have to care. Sony should understand what they are delivering and the circumstance of that. That they refuse to serve some customers due to the technology they use is either a business decision or a faulty design. The end-customer (gamer) doesn’t care. They just want to play.
On Aug 26, 2020, at 1:31 PM, Mark Tinka <mark.tinka@seacom.com> wrote:
On 26/Aug/20 20:20, Brian Johnson wrote:
Either way. Nothing you can do in the network will help Sony enable IPv6 capability, Or to serve their users even if using a technology that they do not like.
Agreed.
The problem is gaming customers that neither care for nor know about how NAT444 and/or IPv6 play (no pun intended) here.
Mark.
On 26/Aug/20 20:38, Brian Johnson wrote:
I‘m going further... They shouldn’t have to care. Sony should understand what they are delivering and the circumstance of that. That they refuse to serve some customers due to the technology they use is either a business decision or a faulty design. The end-customer (gamer) doesn’t care. They just want to play.
Sony know that when connectivity breaks because they marked a NAT444'ed IP address as a DDoS source, the end-user won't complain to Sony (that's a customer service blackhole). The end-user will complain to the ISP. Chain of responsibility is in the ISP's disfavour. Sony don't have to do anything. It's like sending an e-mail to an abuse@ mail box. You sort of know it won't get answered, and are powerless if it isn't answered. Mark.
I can prove, as an ISP, that I am delivering the packets. Many providers will have to do this until the content moves to IPv6, so what will their excuse be? The provider has no choice when they have more customers than IPv4 address space. They will have to do something to provide access to the IPv4 Internet for these customers. If the ISP created a service that wasn’t NAT444 for gamers and charged accordingly, they would probably get drawn and quartered. It’s a no win situation and it really is Sony that is causing this issue. PR campaigns and educating customers is probably the only way they can win this argument, when they already have the technical battle won. Just checked with 2 of my customers who do NAT444 and no issues with PSN… YMMV.
On Aug 26, 2020, at 2:00 PM, Mark Tinka <mark.tinka@seacom.com> wrote:
On 26/Aug/20 20:38, Brian Johnson wrote:
I‘m going further... They shouldn’t have to care. Sony should understand what they are delivering and the circumstance of that. That they refuse to serve some customers due to the technology they use is either a business decision or a faulty design. The end-customer (gamer) doesn’t care. They just want to play.
Sony know that when connectivity breaks because they marked a NAT444'ed IP address as a DDoS source, the end-user won't complain to Sony (that's a customer service blackhole). The end-user will complain to the ISP.
Chain of responsibility is in the ISP's disfavour. Sony don't have to do anything. It's like sending an e-mail to an abuse@ mail box. You sort of know it won't get answered, and are powerless if it isn't answered.
Mark.
</rant on> This is nothing new, when I first started installing CGN platforms something like 10 years ago there was only ever one company that caused issues, can you guess which? It got to the point of lawyers exchanging desist letters as PSN constantly told our customers that they were blocking to contact us as somehow the ISP has control over what Sony blocks on PSN. They're the worst service company I have ever had the displeasure of dealing with, the arrogance and attitude of we are big, you are small we don't care about your customers was infuriating. Never have I seen a single call related to their opposition where as PSN accounted for about 10-20% of helpdesk calls. I don't understand why its seemingly impossible for them to implement ipv6 as almost everything I have deployed with CGN is dual stack V6. </rant complete> -----Original Message----- From: NANOG <nanog-bounces+tony=wicks.co.nz@nanog.org> On Behalf Of Brian Johnson Sent: Thursday, 27 August 2020 7:14 am To: Mark Tinka <mark.tinka@seacom.com> Cc: nanog@nanog.org Subject: Re: Ipv6 help I can prove, as an ISP, that I am delivering the packets. Many providers will have to do this until the content moves to IPv6, so what will their excuse be? The provider has no choice when they have more customers than IPv4 address space. They will have to do something to provide access to the IPv4 Internet for these customers. If the ISP created a service that wasn’t NAT444 for gamers and charged accordingly, they would probably get drawn and quartered. It’s a no win situation and it really is Sony that is causing this issue. PR campaigns and educating customers is probably the only way they can win this argument, when they already have the technical battle won. Just checked with 2 of my customers who do NAT444 and no issues with PSN… YMMV.
On Aug 26, 2020, at 2:00 PM, Mark Tinka <mark.tinka@seacom.com> wrote:
On 26/Aug/20 20:38, Brian Johnson wrote:
I‘m going further... They shouldn’t have to care. Sony should understand what they are delivering and the circumstance of that. That they refuse to serve some customers due to the technology they use is either a business decision or a faulty design. The end-customer (gamer) doesn’t care. They just want to play.
Sony know that when connectivity breaks because they marked a NAT444'ed IP address as a DDoS source, the end-user won't complain to Sony (that's a customer service blackhole). The end-user will complain to the ISP.
Chain of responsibility is in the ISP's disfavour. Sony don't have to do anything. It's like sending an e-mail to an abuse@ mail box. You sort of know it won't get answered, and are powerless if it isn't answered.
Mark.
On 8/26/20 9:28 AM, Tony Wicks wrote:
They're the worst service company I have ever had the displeasure of dealing with, the arrogance and attitude of we are big, you are small we don't care about your customers was infuriating. Never have I seen a single call related to their opposition where as PSN accounted for about 10-20% of helpdesk calls. I don't understand why its seemingly impossible for them to implement ipv6 as almost everything I have deployed with CGN is dual stack V6.
On 8/26/20 9:30 AM, Mark Tinka wrote:
We'll have to be creative with how we pressure them into getting serious about IPv6.
Do those guys attend NANOG meetings? >;-) (evil smile) scott
I have/do. Do you have a point?
On Aug 26, 2020, at 3:06 PM, surfer <surfer@mauigateway.com> wrote:
On 8/26/20 9:28 AM, Tony Wicks wrote:
They're the worst service company I have ever had the displeasure of dealing with, the arrogance and attitude of we are big, you are small we don't care about your customers was infuriating. Never have I seen a single call related to their opposition where as PSN accounted for about 10-20% of helpdesk calls. I don't understand why its seemingly impossible for them to implement ipv6 as almost everything I have deployed with CGN is dual stack V6.
On 8/26/20 9:30 AM, Mark Tinka wrote:
We'll have to be creative with how we pressure them into getting serious about IPv6.
Do those guys attend NANOG meetings? >;-) (evil smile)
scott
On 8/26/20 9:28 AM, Tony Wicks wrote:
They're the worst service company I have ever had the displeasure of dealing with, the arrogance and attitude of we are big, you are small we don't care about your customers was infuriating. Never have I seen a single call related to their opposition where as PSN accounted for about 10-20% of helpdesk calls. I don't understand why its seemingly impossible for them to implement ipv6 as almost everything I have deployed with CGN is dual stack V6. On 8/26/20 9:30 AM, Mark Tinka wrote: We'll have to be creative with how we pressure them into getting serious about IPv6. On Aug 26, 2020, at 3:06 PM, surfer <surfer@mauigateway.com> wrote:
Do those guys attend NANOG meetings? >;-) (evil smile)
On 8/26/20 10:09 AM, Brian Johnson wrote:
I have/do. Do you have a point?
I guess you're implying you work there. Maybe someone will bake a cake for your company. scott
I do not work at either NANOG or Sony. How would my response imply that? Again, what is your point? I have attended a lot of NANOG meetings and CGM/IPv6 transition was a point of discussion many times, but as usual it was always in the ether. Few actually deployed examples and always worried about breaking the Internet. We broke it decades ago and now we are reaping the rewards.
On Aug 26, 2020, at 4:22 PM, surfer <surfer@mauigateway.com> wrote:
On 8/26/20 9:28 AM, Tony Wicks wrote:
They're the worst service company I have ever had the displeasure of dealing with, the arrogance and attitude of we are big, you are small we don't care about your customers was infuriating. Never have I seen a single call related to their opposition where as PSN accounted for about 10-20% of helpdesk calls. I don't understand why its seemingly impossible for them to implement ipv6 as almost everything I have deployed with CGN is dual stack V6. On 8/26/20 9:30 AM, Mark Tinka wrote: We'll have to be creative with how we pressure them into getting serious about IPv6. On Aug 26, 2020, at 3:06 PM, surfer <surfer@mauigateway.com> wrote:
Do those guys attend NANOG meetings? >;-) (evil smile)
On 8/26/20 10:09 AM, Brian Johnson wrote:
I have/do. Do you have a point?
I guess you're implying you work there. Maybe someone will bake a cake for your company.
scott
On Aug 26, 2020, at 4:22 PM, surfer <surfer@mauigateway.com> wrote: On 8/26/20 9:28 AM, Tony Wicks wrote:
They're the worst service company I have ever had the displeasure of dealing with, the arrogance and attitude of we are big, you are small we don't care about your customers was infuriating. Never have I seen a single call related to their opposition where as PSN accounted for about 10-20% of helpdesk calls. I don't understand why its seemingly impossible for them to implement ipv6 as almost everything I have deployed with CGN is dual stack V6. On 8/26/20 9:30 AM, Mark Tinka wrote: We'll have to be creative with how we pressure them into getting serious about IPv6. On Aug 26, 2020, at 3:06 PM, surfer <surfer@mauigateway.com> wrote:
Do those guys attend NANOG meetings? >;-) (evil smile) On 8/26/20 10:09 AM, Brian Johnson wrote: I have/do. Do you have a point?
I guess you're implying you work there. Maybe someone will bake a cake for your company. On 8/26/20 6:59 PM, Brian Johnson wrote: I do not work at either NANOG or Sony. How would my response imply that? Again, what is your point?
I have attended a lot of NANOG meetings and CGM/IPv6 transition was a point of discussion many times, but as usual it was always in the ether. Few actually deployed examples and always worried about breaking the Internet. We broke it decades ago and now we are reaping the rewards. -----------------------------------------------------
:: I do not work at either NANOG or Sony. How would my response imply that? Again, what is your point? Because I said "Do those guys attend NANOG meetings?" and you said "I have/do." Seems pretty clear to me. My point is other NANOG folks could speak to the Sony network engineers directly and find out what Sony's plan is. scott
I must have been tired. I read it as do I go to NANOG meetings. Sorry for the confusion.
On Aug 27, 2020, at 12:59 PM, surfer <surfer@mauigateway.com> wrote:
On Aug 26, 2020, at 4:22 PM, surfer <surfer@mauigateway.com> wrote: On 8/26/20 9:28 AM, Tony Wicks wrote:
They're the worst service company I have ever had the displeasure of dealing with, the arrogance and attitude of we are big, you are small we don't care about your customers was infuriating. Never have I seen a single call related to their opposition where as PSN accounted for about 10-20% of helpdesk calls. I don't understand why its seemingly impossible for them to implement ipv6 as almost everything I have deployed with CGN is dual stack V6. On 8/26/20 9:30 AM, Mark Tinka wrote: We'll have to be creative with how we pressure them into getting serious about IPv6. On Aug 26, 2020, at 3:06 PM, surfer <surfer@mauigateway.com> wrote:
Do those guys attend NANOG meetings? >;-) (evil smile) On 8/26/20 10:09 AM, Brian Johnson wrote: I have/do. Do you have a point?
I guess you're implying you work there. Maybe someone will bake a cake for your company. On 8/26/20 6:59 PM, Brian Johnson wrote: I do not work at either NANOG or Sony. How would my response imply that? Again, what is your point?
I have attended a lot of NANOG meetings and CGM/IPv6 transition was a point of discussion many times, but as usual it was always in the ether. Few actually deployed examples and always worried about breaking the Internet. We broke it decades ago and now we are reaping the rewards. -----------------------------------------------------
:: I do not work at either NANOG or Sony. How would my response imply that? Again, what is your point?
Because I said "Do those guys attend NANOG meetings?" and you said "I have/do." Seems pretty clear to me.
My point is other NANOG folks could speak to the Sony network engineers directly and find out what Sony's plan is.
scott
They know we are there ... so they don't come! By the way I missed this in the previous email: I heard (not sure how much true on that) that they are "forced" to avoid CGN because the way games are often programmed in PSP break them. So maybe will not be enough to sort out the problem with an OS and/or PSN change, all the affected games, will need to be adjusted. Maybe the only way to force this is to tell our customers (many ISPs in every country) "don't buy Sony PS, they are unable to support new technologies, so you games will be blocked by Sony". Of course, unless we all decide to use 464XLAT instead of CGN ... which resolves the problem. A massive campaing could work ... El 26/8/20 22:08, "NANOG en nombre de surfer" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de surfer@mauigateway.com> escribió: On 8/26/20 9:28 AM, Tony Wicks wrote: > They're the worst service company I have ever had the displeasure of dealing with, the arrogance and attitude of we are big, you are small we don't care about your customers was infuriating. Never have I seen a single call related to their opposition where as PSN accounted for about 10-20% of helpdesk calls. I don't understand why its seemingly impossible for them to implement ipv6 as almost everything I have deployed with CGN is dual stack V6. On 8/26/20 9:30 AM, Mark Tinka wrote: > We'll have to be creative with how we pressure them into getting serious > about IPv6. Do those guys attend NANOG meetings? >;-) (evil smile) scott ********************************************** 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.
How does 464XLAT solve the problem if you are out of IPv4 space?
On Aug 26, 2020, at 3:23 PM, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote:
They know we are there ... so they don't come!
By the way I missed this in the previous email: I heard (not sure how much true on that) that they are "forced" to avoid CGN because the way games are often programmed in PSP break them. So maybe will not be enough to sort out the problem with an OS and/or PSN change, all the affected games, will need to be adjusted.
Maybe the only way to force this is to tell our customers (many ISPs in every country) "don't buy Sony PS, they are unable to support new technologies, so you games will be blocked by Sony". Of course, unless we all decide to use 464XLAT instead of CGN ... which resolves the problem.
A massive campaing could work ...
El 26/8/20 22:08, "NANOG en nombre de surfer" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de surfer@mauigateway.com> escribió:
On 8/26/20 9:28 AM, Tony Wicks wrote:
They're the worst service company I have ever had the displeasure of dealing with, the arrogance and attitude of we are big, you are small we don't care about your customers was infuriating. Never have I seen a single call related to their opposition where as PSN accounted for about 10-20% of helpdesk calls. I don't understand why its seemingly impossible for them to implement ipv6 as almost everything I have deployed with CGN is dual stack V6.
On 8/26/20 9:30 AM, Mark Tinka wrote:
We'll have to be creative with how we pressure them into getting serious about IPv6.
Do those guys attend NANOG meetings? >;-) (evil smile)
scott
********************************************** 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.
Because: 1) It needs *much less* IPv4 addresses (in the NAT64) for the same number of customers. 2) It provides the customers as many ports they need (no a limited number of ports per customer). 3) It is not blocked by PSN (don't know why because don't know how the games have problems with CGN). You could share among an *almost unlimited* number of subscribers an small IPv4 block (even just a /22). Regards, Jordi @jordipalet El 26/8/20 22:31, "Brian Johnson" <brian.johnson@netgeek.us> escribió: How does 464XLAT solve the problem if you are out of IPv4 space? > On Aug 26, 2020, at 3:23 PM, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote: > > They know we are there ... so they don't come! > > By the way I missed this in the previous email: I heard (not sure how much true on that) that they are "forced" to avoid CGN because the way games are often programmed in PSP break them. So maybe will not be enough to sort out the problem with an OS and/or PSN change, all the affected games, will need to be adjusted. > > Maybe the only way to force this is to tell our customers (many ISPs in every country) "don't buy Sony PS, they are unable to support new technologies, so you games will be blocked by Sony". Of course, unless we all decide to use 464XLAT instead of CGN ... which resolves the problem. > > A massive campaing could work ... > > > El 26/8/20 22:08, "NANOG en nombre de surfer" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de surfer@mauigateway.com> escribió: > > > > On 8/26/20 9:28 AM, Tony Wicks wrote: >> They're the worst service company I have ever had the displeasure of dealing with, the arrogance and attitude of we are big, you are small we don't care about your customers was infuriating. Never have I seen a single call related to their opposition where as PSN accounted for about 10-20% of helpdesk calls. I don't understand why its seemingly impossible for them to implement ipv6 as almost everything I have deployed with CGN is dual stack V6. > > On 8/26/20 9:30 AM, Mark Tinka wrote: >> We'll have to be creative with how we pressure them into getting serious >> about IPv6. > > > Do those guys attend NANOG meetings? >;-) (evil smile) > > scott > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Responses in-line
On Aug 26, 2020, at 4:07 PM, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote:
Because:
1) It needs *much less* IPv4 addresses (in the NAT64) for the same number of customers.
I cannot see how this is even possible. If I use private space internally to the CGN, then the available external space is the same and the internal customers are the same and I can do the same over sub ratio under both circumstance. Tell me how the math is different.
2) It provides the customers as many ports they need (no a limited number of ports per customer).
See response to answer 1
3) It is not blocked by PSN (don't know why because don't know how the games have problems with CGN).
Interesting, but I’m not sure how any over-loaded NAT translation would look different from the external system. Since you cannot explain it, it’s hard to discuss it.
You could share among an *almost unlimited* number of subscribers an small IPv4 block (even just a /22).
The math would be the same as a CGN, so I do not see how this is any less or more useful. It does, however, require CPE capability that appears lacking and NAT444 does not.
Regards, Jordi @jordipalet
El 26/8/20 22:31, "Brian Johnson" <brian.johnson@netgeek.us> escribió:
How does 464XLAT solve the problem if you are out of IPv4 space?
On Aug 26, 2020, at 3:23 PM, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote:
They know we are there ... so they don't come!
By the way I missed this in the previous email: I heard (not sure how much true on that) that they are "forced" to avoid CGN because the way games are often programmed in PSP break them. So maybe will not be enough to sort out the problem with an OS and/or PSN change, all the affected games, will need to be adjusted.
Maybe the only way to force this is to tell our customers (many ISPs in every country) "don't buy Sony PS, they are unable to support new technologies, so you games will be blocked by Sony". Of course, unless we all decide to use 464XLAT instead of CGN ... which resolves the problem.
A massive campaing could work ...
El 26/8/20 22:08, "NANOG en nombre de surfer" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de surfer@mauigateway.com> escribió:
On 8/26/20 9:28 AM, Tony Wicks wrote:
They're the worst service company I have ever had the displeasure of dealing with, the arrogance and attitude of we are big, you are small we don't care about your customers was infuriating. Never have I seen a single call related to their opposition where as PSN accounted for about 10-20% of helpdesk calls. I don't understand why its seemingly impossible for them to implement ipv6 as almost everything I have deployed with CGN is dual stack V6.
On 8/26/20 9:30 AM, Mark Tinka wrote:
We'll have to be creative with how we pressure them into getting serious about IPv6.
Do those guys attend NANOG meetings? >;-) (evil smile)
scott
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Brian Johnson <brian.johnson@netgeek.us> writes:
1) It needs *much less* IPv4 addresses (in the NAT64) for the same number of customers.
I cannot see how this is even possible. If I use private space internally to the CGN, then the available external space is the same and the internal customers are the same and I can do the same over sub ratio under both circumstance. Tell me how the math is different.
Because NAT64 implies DNS64, which avoids NATing any dual stack service. This makes a major difference today. Bjørn
On 27/Aug/20 07:58, Bjørn Mork wrote:
Because NAT64 implies DNS64, which avoids NATing any dual stack service. This makes a major difference today.
NAT64/DNS64 was the original solution. 464XLAT is the improved approach. See: https://tools.ietf.org/id/draft-ietf-v6ops-nat64-deployment-04.html Mark.
This one is the published version: https://datatracker.ietf.org/doc/rfc8683/ El 27/8/20 8:10, "NANOG en nombre de Mark Tinka" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de mark.tinka@seacom.com> escribió: On 27/Aug/20 07:58, Bjørn Mork wrote: > Because NAT64 implies DNS64, which avoids NATing any dual stack service. > This makes a major difference today. NAT64/DNS64 was the original solution. 464XLAT is the improved approach. See: https://tools.ietf.org/id/draft-ietf-v6ops-nat64-deployment-04.html 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 27/Aug/20 08:57, JORDI PALET MARTINEZ via NANOG wrote:
This one is the published version:
Good man. NAT64/DNS64 is broken. I found this out myself in 2011 when I deployed it at $old_job in Malaysia. Skype broke, as did IPv4 literals. At the time, it was better than nothing. Then again, the world wasn't scrounging for IPv4 as much as it is today. Mark.
On 27 Aug 2020, at 15:58, Bjørn Mork <bjorn@mork.no> wrote:
Brian Johnson <brian.johnson@netgeek.us> writes:
1) It needs *much less* IPv4 addresses (in the NAT64) for the same number of customers.
I cannot see how this is even possible. If I use private space internally to the CGN, then the available external space is the same and the internal customers are the same and I can do the same over sub ratio under both circumstance. Tell me how the math is different.
Because NAT64 implies DNS64, which avoids NATing any dual stack service. This makes a major difference today.
Only if you don’t have a CLAT installed and for home users that is suicide at there is too much IPv4 only equipment. What really pushes traffic to IPv6 is that hosts prefer IPv6 by default. This works as long as the clients see a dual stack network. And no NAT64 does not imply DNS64. You can publish a ipv4only.arpa zone with the mappings for the NAT64. There are now also RA options for publishing these mappings. There are also DHCPv6 options. Mark
Bjørn
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
If an ISP provides dual-stack to the customer, then the customer only uses IPv4 when required and then will only use NAT444 to compensate for a lack of IPv4 address space when an IPv4 connection is required. What am I missing?
On Aug 27, 2020, at 1:20 AM, Mark Andrews <marka@isc.org> wrote:
On 27 Aug 2020, at 15:58, Bjørn Mork <bjorn@mork.no> wrote:
Brian Johnson <brian.johnson@netgeek.us> writes:
1) It needs *much less* IPv4 addresses (in the NAT64) for the same number of customers.
I cannot see how this is even possible. If I use private space internally to the CGN, then the available external space is the same and the internal customers are the same and I can do the same over sub ratio under both circumstance. Tell me how the math is different.
Because NAT64 implies DNS64, which avoids NATing any dual stack service. This makes a major difference today.
Only if you don’t have a CLAT installed and for home users that is suicide at there is too much IPv4 only equipment.
What really pushes traffic to IPv6 is that hosts prefer IPv6 by default. This works as long as the clients see a dual stack network.
And no NAT64 does not imply DNS64. You can publish a ipv4only.arpa zone with the mappings for the NAT64. There are now also RA options for publishing these mappings. There are also DHCPv6 options.
Mark
Bjørn
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 27 Aug 2020, at 17:33, Brian Johnson <brian.johnson@netgeek.us> wrote:
If an ISP provides dual-stack to the customer, then the customer only uses IPv4 when required and then will only use NAT444 to compensate for a lack of IPv4 address space when an IPv4 connection is required. What am I missing?
Lots of assumptions people are making about how equipment is configured which is causing people to talk past each other.
On Aug 27, 2020, at 1:20 AM, Mark Andrews <marka@isc.org> wrote:
On 27 Aug 2020, at 15:58, Bjørn Mork <bjorn@mork.no> wrote:
Brian Johnson <brian.johnson@netgeek.us> writes:
1) It needs *much less* IPv4 addresses (in the NAT64) for the same number of customers.
I cannot see how this is even possible. If I use private space internally to the CGN, then the available external space is the same and the internal customers are the same and I can do the same over sub ratio under both circumstance. Tell me how the math is different.
Because NAT64 implies DNS64, which avoids NATing any dual stack service. This makes a major difference today.
Only if you don’t have a CLAT installed and for home users that is suicide at there is too much IPv4 only equipment.
What really pushes traffic to IPv6 is that hosts prefer IPv6 by default. This works as long as the clients see a dual stack network.
And no NAT64 does not imply DNS64. You can publish a ipv4only.arpa zone with the mappings for the NAT64. There are now also RA options for publishing these mappings. There are also DHCPv6 options.
Mark
Bjørn
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
I hope I’m not adding to any confusion. I find this conversation to be interesting and want it to be productive. I have not deployed 464XLAT and am only aware of android phones having a proper client. I have worked with so many CPE devices and know that most have solid deployments of the required CLAT client. I also predict this will not change any time soon. I live in “actually works and is solid” world. Not in “I wish this would work” world.
On Aug 27, 2020, at 2:50 AM, Mark Andrews <marka@isc.org> wrote:
On 27 Aug 2020, at 17:33, Brian Johnson <brian.johnson@netgeek.us> wrote:
If an ISP provides dual-stack to the customer, then the customer only uses IPv4 when required and then will only use NAT444 to compensate for a lack of IPv4 address space when an IPv4 connection is required. What am I missing?
Lots of assumptions people are making about how equipment is configured which is causing people to talk past each other.
On Aug 27, 2020, at 1:20 AM, Mark Andrews <marka@isc.org> wrote:
On 27 Aug 2020, at 15:58, Bjørn Mork <bjorn@mork.no> wrote:
Brian Johnson <brian.johnson@netgeek.us> writes:
1) It needs *much less* IPv4 addresses (in the NAT64) for the same number of customers.
I cannot see how this is even possible. If I use private space internally to the CGN, then the available external space is the same and the internal customers are the same and I can do the same over sub ratio under both circumstance. Tell me how the math is different.
Because NAT64 implies DNS64, which avoids NATing any dual stack service. This makes a major difference today.
Only if you don’t have a CLAT installed and for home users that is suicide at there is too much IPv4 only equipment.
What really pushes traffic to IPv6 is that hosts prefer IPv6 by default. This works as long as the clients see a dual stack network.
And no NAT64 does not imply DNS64. You can publish a ipv4only.arpa zone with the mappings for the NAT64. There are now also RA options for publishing these mappings. There are also DHCPv6 options.
Mark
Bjørn
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Thu, Aug 27, 2020 at 1:00 AM Brian Johnson <brian.johnson@netgeek.us> wrote:
I hope I’m not adding to any confusion. I find this conversation to be interesting and want it to be productive. I have not deployed 464XLAT and am only aware of android phones having a proper client.
Platforms with CLAT include: Android (since 4.3) Apple iOS (2 versions, HEv2 and real xlat) Cisco iOS (this is just their SIIT) Windows 10 (scoped only work on LTE modems) Linux and OpenWRT FreeBSD I have worked with so many CPE devices and know that most have solid
deployments of the required CLAT client. I also predict this will not change any time soon. I live in “actually works and is solid” world. Not in “I wish this would work” world.
On Aug 27, 2020, at 2:50 AM, Mark Andrews <marka@isc.org> wrote:
On 27 Aug 2020, at 17:33, Brian Johnson <brian.johnson@netgeek.us> wrote:
If an ISP provides dual-stack to the customer, then the customer only uses IPv4 when required and then will only use NAT444 to compensate for a lack of IPv4 address space when an IPv4 connection is required. What am I missing?
Lots of assumptions people are making about how equipment is configured which is causing people to talk past each other.
On Aug 27, 2020, at 1:20 AM, Mark Andrews <marka@isc.org> wrote:
On 27 Aug 2020, at 15:58, Bjørn Mork <bjorn@mork.no> wrote:
Brian Johnson <brian.johnson@netgeek.us> writes:
> 1) It needs *much less* IPv4 addresses (in the NAT64) for the same number of customers.
I cannot see how this is even possible. If I use private space
internally to the CGN, then the available external space is the same
and the internal customers are the same and I can do the same over sub
ratio under both circumstance. Tell me how the math is different.
Because NAT64 implies DNS64, which avoids NATing any dual stack service.
This makes a major difference today.
Only if you don’t have a CLAT installed and for home users that is suicide
at there is too much IPv4 only equipment.
What really pushes traffic to IPv6 is that hosts prefer IPv6 by default. This
works as long as the clients see a dual stack network.
And no NAT64 does not imply DNS64. You can publish a ipv4only.arpa zone with
the mappings for the NAT64. There are now also RA options for publishing these
mappings. There are also DHCPv6 options.
Mark
Bjørn
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 27/Aug/20 09:33, Brian Johnson wrote:
If an ISP provides dual-stack to the customer, then the customer only uses IPv4 when required and then will only use NAT444 to compensate for a lack of IPv4 address space when an IPv4 connection is required. What am I missing?
While modern OS's prefer IPv6, it doesn't mean the end-service supports IPv6 yet. If the end-service only supports IPv4, the OS won't try to connect on IPv6. More importantly, a customer assigned a public IPv4 address will never need to use the ISP's CGN nodes. NAT44(4) will only be required for customers that are unfortunate enough to require connectivity at a time when the ISP can no longer provide a public IPv4 address to them. You can't dynamically cycle customers between public and private IPv4 addresses based on demand. It's either they have a public IPv4 address, or a private IPv4 address. Not both. Yes, there are way you can do this, but it's not worth anyone's time and headache. 464XLAT means customers can only live on IPv6. The ISP can put aside a small amount of IPv4 to bridge connectivity between an IPv6-only customer to an IPv4-only service for as long as that end-service is IPv4-only. Once that IPv4-only services wakes up, gets some clue and turns on IPv6 (Sony and PSN, that means you), that is one online resources less that the IPv6-only customers requires the 464XLAT translation to reach. As more end-services turn on IPv6, there is nothing the ISP needs to do on the customer side, as they are already on IPv6, which was the biggest advantage of the NAT64/DNS64 transition mechanism, and is the biggest advantage of 464XLAT. Thus, the ISP's demand for 464XLAT reduces (and eventually goes away), as does their need to retain whatever amount of IPv4 space they required to support the 464XLAT nodes. Transitions mechanisms that seek to maintain IPv4 at the customer side expose themselves to additional migration work when the majority of the world is on IPv6. This is why I generally recommend ISP's (with the exception of my competitors, of course) to focus on 464XLAT, as when we get to that point, nothing needs to be done with the customer. There is value in that! Mark.
Great Write-up Mark. I have some points in-line...
On Aug 27, 2020, at 3:12 AM, Mark Tinka <mark.tinka@seacom.com> wrote:
On 27/Aug/20 09:33, Brian Johnson wrote:
If an ISP provides dual-stack to the customer, then the customer only uses IPv4 when required and then will only use NAT444 to compensate for a lack of IPv4 address space when an IPv4 connection is required. What am I missing?
While modern OS's prefer IPv6, it doesn't mean the end-service supports IPv6 yet. If the end-service only supports IPv4, the OS won't try to connect on IPv6.
Agree and understand this.
More importantly, a customer assigned a public IPv4 address will never need to use the ISP's CGN nodes. NAT44(4) will only be required for customers that are unfortunate enough to require connectivity at a time when the ISP can no longer provide a public IPv4 address to them.
Let’s just say that this is happening now for a large number of regional providers.
You can't dynamically cycle customers between public and private IPv4 addresses based on demand. It's either they have a public IPv4 address, or a private IPv4 address. Not both. Yes, there are way you can do this, but it's not worth anyone's time and headache.
Let’s say that we switch to a model of all NAT444 for IPv4, with an exception for paid static IPv4 customers and that rate is linked to the current going rate for an IP address on the market. :) This is easily doable with any of the access platforms and routing vendors I have worked with.
464XLAT means customers can only live on IPv6. The ISP can put aside a small amount of IPv4 to bridge connectivity between an IPv6-only customer to an IPv4-only service for as long as that end-service is IPv4-only. Once that IPv4-only services wakes up, gets some clue and turns on IPv6 (Sony and PSN, that means you), that is one online resources less that the IPv6-only customers requires the 464XLAT translation to reach.
As more end-services turn on IPv6, there is nothing the ISP needs to do on the customer side, as they are already on IPv6, which was the biggest advantage of the NAT64/DNS64 transition mechanism, and is the biggest advantage of 464XLAT.
Thus, the ISP's demand for 464XLAT reduces (and eventually goes away), as does their need to retain whatever amount of IPv4 space they required to support the 464XLAT nodes.
If I do dual-stack, but provide private IPv4 to the customer and NAT444 them, isn’t this accomplishing the same thing?
Transitions mechanisms that seek to maintain IPv4 at the customer side expose themselves to additional migration work when the majority of the world is on IPv6. This is why I generally recommend ISP's (with the exception of my competitors, of course) to focus on 464XLAT, as when we get to that point, nothing needs to be done with the customer. There is value in that!
So for 464XLAT I will need to install a PLAT capable device(s) as well as replace all CPE with CLAT capable devices ($$$$). I will also need to deal with the infancy period as I will GUARANTEE that the CPE will break badly and will create additional cost ($$$$). For NAT444 I just need to install NAT444 router(s) . No additional cost for CPE or added troubleshooting as the existing CPE is fully baked. Agreed that customers will need help with IPv6, but that will be required either way. Also, the customer maintains a native IPv4 service (all be it NATed) until IPv4 does the dodo dance. In the end, the provider turns-off the NAT444 and disables IPv4 on their core, which has already been enabled for IPv6 when deploying dual-stack.
Mark.
On 27/Aug/20 10:33, Brian Johnson wrote:
Let’s say that we switch to a model of all NAT444 for IPv4, with an exception for paid static IPv4 customers and that rate is linked to the current going rate for an IP address on the market. :)
This is easily doable with any of the access platforms and routing vendors I have worked with.
This is happening today. The problem isn't that it can't work. The problem is that as the days trudge on, private IPv4 will be the only option, even for customers willing to pay top $$ for one public IPv4 address. You can't sell what you don't have. So then you have to move from NAT44 to NAT444 to NAT4444 to NAT44444, just to keep recycling your private pool, and all the pleasure & joy that avenue brings along with it.
If I do dual-stack, but provide private IPv4 to the customer and NAT444 them, isn’t this accomplishing the same thing?
It is, but even if NAT works, it scales poorly and has inherent issues, as we all know. In the end, to scale it, you go CGN, which can be 10's of millions of $$/year with vendors if you are a large network (pretty much, every mobile provider today that didn't follow Cameron's route).
So for 464XLAT I will need to install a PLAT capable device(s)...
PLAT support has been around already with the traditional vendors. It's not new.
as well as replace all CPE with CLAT capable devices ($$$$). I will also need to deal with the infancy period as I will GUARANTEE that the CPE will break badly and will create additional cost ($$$$).
For NAT444 I just need to install NAT444 router(s) . No additional cost for CPE or added troubleshooting as the existing CPE is fully baked. Agreed that customers will need help with IPv6, but that will be required either way. Also, the customer maintains a native IPv4 service (all be it NATed) until IPv4 does the dodo dance. In the end, the provider turns-off the NAT444 and disables IPv4 on their core, which has already been enabled for IPv6 when deploying dual-stack.
Well, you need to run the numbers on time, support and acquisition of new revenue if you maintain NAT44, while the rest of the world (and your competitors) are going as native IPv6 as they can. You need to consider if it's worth taking the risk of being left behind, or not. Either way, your customers will, at some point or other, show you what will work :-). For me, my time is very limited, particularly on this rock we call earth. I could spend it maintaining a CGN, but I'd rather spend it chasing down CPE vendors to get CLAT support, or bad-mouthing Sony to get with the program. If I have to lose a few customers in the process, so be it. If I run out of breath before I reach my goal, well, hopefully the work done along the way will help the next idiot that sees things the same way I do :-). Mark.
> So for 464XLAT I will need to install a PLAT capable device(s)... PLAT support has been around already with the traditional vendors. It's not new. [Jordi] NAT64 (PLAT) is there available in excellent open source implementations. You can use VMs in big rackable servers and it gets even much cheaper. I know there is one open source implementation of NAT444. However, the number of NAT64 boxes that you need vs NAT444 is lower, and it will keep going lower as more and more services in Internet are IPv6 ready and those that suck more bw such as those video services, are already IPv6 and the increase in their traffic keeps going up. > as well as replace all CPE with CLAT capable devices ($$$$). I will also need to deal with the infancy period as I will GUARANTEE that the CPE will break badly and will create additional cost ($$$$). > > For NAT444 I just need to install NAT444 router(s) . No additional cost for CPE or added troubleshooting as the existing CPE is fully baked. Agreed that customers will need help with IPv6, but that will be required either way. Also, the customer maintains a native IPv4 service (all be it NATed) until IPv4 does the dodo dance. In the end, the provider turns-off the NAT444 and disables IPv4 on their core, which has already been enabled for IPv6 when deploying dual-stack. Well, you need to run the numbers on time, support and acquisition of new revenue if you maintain NAT44, while the rest of the world (and your competitors) are going as native IPv6 as they can. You need to consider if it's worth taking the risk of being left behind, or not. [Jordi] This is the key. Make your numbers, each network is a different world. Some questions: 1) How much cost the NAT64 vs CGN ? 2) How much traffic will move to IPv6 if you use a CPE with CLAT ? 3) How many IPv4 addresses you need using CGN vs NAT64 ? That may be a lot of money. 4) How much you will save in helpdesk support because CGN ? (Sony today, tomorrow some others) 5) How much you can ask your customers to contribute to the replacement of the CPE (which cost you below 20-25 USD including logistic to ship within your country) while offering them a dual radio and better WiFi, "faster IPv6 experience", less issues with apps because the CGN, faster LAN ports, future proof "New Internet" connection, better security (in the WiFi and a better firewall in the CPE), etc., etc. Is not that I like to use marketing, but it is a fact that if you don't do, sooner or later your competitor will do, and customers like to "upgrade" things (and everybody loves better WiFi). How many new customers you can get from the competitor because that marketing? All that means less investment in the operator side, which you can use to fund the acquisition or update of CPEs (in some projects we updated the Mikrotik rubish to OpenWRT!). My take on this. If you really want to keep using dual-stack, fine, but don't use CGN, you don't need that. It is way cheaper to just go into the transfers market and get more IPv4 addresses. Problem solved (including 1-4 above). Either way, your customers will, at some point or other, show you what will work :-). For me, my time is very limited, particularly on this rock we call earth. I could spend it maintaining a CGN, but I'd rather spend it chasing down CPE vendors to get CLAT support, or bad-mouthing Sony to get with the program. If I have to lose a few customers in the process, so be it. If I run out of breath before I reach my goal, well, hopefully the work done along the way will help the next idiot that sees things the same way I do :-). 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.
You need to understand the different way NAT64 works vs CGN (and 464XLAT uses NAT64 for the translation): The ports are allocated "on demand" in NAT64. While in CGN you allocate a number of ports per customer, for example, 2.000, 4.000, etc. If a customer is not using all the ports, they are just wasted. If a customer needs more ports, will have troubles. This doesn't happen in NAT64. Let's assume and operator that can get only a /22. Let's make some numbers. If an average user uses 300 ports (from a public IP). When using 464XLAT, the number of users within the network, which in IPv4 is behind NAT46, does not trigger that number of ports. Anyway, let's be pessimistic and assume they are quadruple 1,200 ports. Approximately 80% of the traffic (2 years ago it was 75%, in many cases it is reaching 90-95%) is IPv6. After the 1,200 ports we only count 20% for IPv4, which is 240 ports. Broadly speaking, if we assign NAT64 1,000 IPv4 addresses (assuming the operator needs 24 public IPv4 addresses for BGP and infrastructure, I have done it with much less - because 99% of the infrastructure can be IPv6-only or use private IPv4 for management), and that we use of each IPv4 address assigned to NAT64 only 64,511 ports (65,536-1,024), even knowing that they can all be used (may be you want to allocate some static IP/ports to some customers, etc.): 1,000 x 64,511 / 240 = 268,795 subscribers. This is assuming all the subscribers are using all the ports, which typically is not the case. Now, if you have a NAT64 that tracks connections with a 5-tuple, then the number of external ports per user will be almost unlimited. But also, this applies to the CLAT, which typically is doing (in CPEs) a stateful NAT44 (to a single private IPv4 address)+stateless NAT46. The NAT44 in iptables uses a 5-tuple for connection tracking, so the same external ports can be reused many times as the source address and destination address/port will be different. So in practical cases, the number of external ports only limits the number of parallel connections that a single host behind the NAT can have to the same destination address and port. El 27/8/20 6:55, "Brian Johnson" <brian.johnson@netgeek.us> escribió: Responses in-line > On Aug 26, 2020, at 4:07 PM, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote: > > Because: > > 1) It needs *much less* IPv4 addresses (in the NAT64) for the same number of customers. I cannot see how this is even possible. If I use private space internally to the CGN, then the available external space is the same and the internal customers are the same and I can do the same over sub ratio under both circumstance. Tell me how the math is different. > 2) It provides the customers as many ports they need (no a limited number of ports per customer). See response to answer 1 > 3) It is not blocked by PSN (don't know why because don't know how the games have problems with CGN). Interesting, but I’m not sure how any over-loaded NAT translation would look different from the external system. Since you cannot explain it, it’s hard to discuss it. > > You could share among an *almost unlimited* number of subscribers an small IPv4 block (even just a /22). The math would be the same as a CGN, so I do not see how this is any less or more useful. It does, however, require CPE capability that appears lacking and NAT444 does not. > > Regards, > Jordi > @jordipalet > > > > El 26/8/20 22:31, "Brian Johnson" <brian.johnson@netgeek.us> escribió: > > How does 464XLAT solve the problem if you are out of IPv4 space? > >> On Aug 26, 2020, at 3:23 PM, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote: >> >> They know we are there ... so they don't come! >> >> By the way I missed this in the previous email: I heard (not sure how much true on that) that they are "forced" to avoid CGN because the way games are often programmed in PSP break them. So maybe will not be enough to sort out the problem with an OS and/or PSN change, all the affected games, will need to be adjusted. >> >> Maybe the only way to force this is to tell our customers (many ISPs in every country) "don't buy Sony PS, they are unable to support new technologies, so you games will be blocked by Sony". Of course, unless we all decide to use 464XLAT instead of CGN ... which resolves the problem. >> >> A massive campaing could work ... >> >> >> El 26/8/20 22:08, "NANOG en nombre de surfer" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de surfer@mauigateway.com> escribió: >> >> >> >> On 8/26/20 9:28 AM, Tony Wicks wrote: >>> They're the worst service company I have ever had the displeasure of dealing with, the arrogance and attitude of we are big, you are small we don't care about your customers was infuriating. Never have I seen a single call related to their opposition where as PSN accounted for about 10-20% of helpdesk calls. I don't understand why its seemingly impossible for them to implement ipv6 as almost everything I have deployed with CGN is dual stack V6. >> >> On 8/26/20 9:30 AM, Mark Tinka wrote: >>> We'll have to be creative with how we pressure them into getting serious >>> about IPv6. >> >> >> Do those guys attend NANOG meetings? >;-) (evil smile) >> >> scott >> >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> >> > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > ********************************************** 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.
Responses in-line...
On Aug 27, 2020, at 2:22 AM, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote:
You need to understand the different way NAT64 works vs CGN (and 464XLAT uses NAT64 for the translation): The ports are allocated "on demand" in NAT64.
While in CGN you allocate a number of ports per customer, for example, 2.000, 4.000, etc.
If a customer is not using all the ports, they are just wasted. If a customer needs more ports, will have troubles.
So this is actually necessary to lower log volume. Without that, logging would have to be per session and would require excessive storage and long-term storage. With deterministic-NAT, we can all but eliminate logging as the external IP and port block is algorithmically reversible to the internal address and vice-versa.
This doesn't happen in NAT64.
Let's assume and operator that can get only a /22.
Let's make some numbers. If an average user uses 300 ports (from a public IP). When using 464XLAT, the number of users within the network, which in IPv4 is behind NAT46, does not trigger that number of ports. Anyway, let's be pessimistic and assume they are quadruple 1,200 ports.
Approximately 80% of the traffic (2 years ago it was 75%, in many cases it is reaching 90-95%) is IPv6. After the 1,200 ports we only count 20% for IPv4, which is 240 ports.
Broadly speaking, if we assign NAT64 1,000 IPv4 addresses (assuming the operator needs 24 public IPv4 addresses for BGP and infrastructure, I have done it with much less - because 99% of the infrastructure can be IPv6-only or use private IPv4 for management), and that we use of each IPv4 address assigned to NAT64 only 64,511 ports (65,536-1,024), even knowing that they can all be used (may be you want to allocate some static IP/ports to some customers, etc.):
1,000 x 64,511 / 240 = 268,795 subscribers. This is assuming all the subscribers are using all the ports, which typically is not the case.
So this is the same math for NAT444. The typical regional provider would be extremely happy getting this much mileage from a /22 block.
Now, if you have a NAT64 that tracks connections with a 5-tuple, then the number of external ports per user will be almost unlimited.
So we will have to log all sessions?
But also, this applies to the CLAT, which typically is doing (in CPEs) a stateful NAT44 (to a single private IPv4 address)+stateless NAT46. The NAT44 in iptables uses a 5-tuple for connection tracking, so the same external ports can be reused many times as the source address and destination address/port will be different. So in practical cases, the number of external ports only limits the number of parallel connections that a single host behind the NAT can have to the same destination address and port.
El 27/8/20 6:55, "Brian Johnson" <brian.johnson@netgeek.us> escribió:
Responses in-line
On Aug 26, 2020, at 4:07 PM, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote:
Because:
1) It needs *much less* IPv4 addresses (in the NAT64) for the same number of customers.
I cannot see how this is even possible. If I use private space internally to the CGN, then the available external space is the same and the internal customers are the same and I can do the same over sub ratio under both circumstance. Tell me how the math is different.
2) It provides the customers as many ports they need (no a limited number of ports per customer).
See response to answer 1
3) It is not blocked by PSN (don't know why because don't know how the games have problems with CGN).
Interesting, but I’m not sure how any over-loaded NAT translation would look different from the external system. Since you cannot explain it, it’s hard to discuss it.
You could share among an *almost unlimited* number of subscribers an small IPv4 block (even just a /22).
The math would be the same as a CGN, so I do not see how this is any less or more useful. It does, however, require CPE capability that appears lacking and NAT444 does not.
Regards, Jordi @jordipalet
El 26/8/20 22:31, "Brian Johnson" <brian.johnson@netgeek.us> escribió:
How does 464XLAT solve the problem if you are out of IPv4 space?
On Aug 26, 2020, at 3:23 PM, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote:
They know we are there ... so they don't come!
By the way I missed this in the previous email: I heard (not sure how much true on that) that they are "forced" to avoid CGN because the way games are often programmed in PSP break them. So maybe will not be enough to sort out the problem with an OS and/or PSN change, all the affected games, will need to be adjusted.
Maybe the only way to force this is to tell our customers (many ISPs in every country) "don't buy Sony PS, they are unable to support new technologies, so you games will be blocked by Sony". Of course, unless we all decide to use 464XLAT instead of CGN ... which resolves the problem.
A massive campaing could work ...
El 26/8/20 22:08, "NANOG en nombre de surfer" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de surfer@mauigateway.com> escribió:
On 8/26/20 9:28 AM, Tony Wicks wrote:
They're the worst service company I have ever had the displeasure of dealing with, the arrogance and attitude of we are big, you are small we don't care about your customers was infuriating. Never have I seen a single call related to their opposition where as PSN accounted for about 10-20% of helpdesk calls. I don't understand why its seemingly impossible for them to implement ipv6 as almost everything I have deployed with CGN is dual stack V6.
On 8/26/20 9:30 AM, Mark Tinka wrote:
We'll have to be creative with how we pressure them into getting serious about IPv6.
Do those guys attend NANOG meetings? >;-) (evil smile)
scott
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
********************************************** 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.
In many jurisdictions you need to log every connection even if all the ports belong to each customer. In others not. I've seen jurisdictions where you don't need to log anything and some others, like India, where MAP was discarded by the regulator, because MAP doesn't provide the 5-tuple log, so the deployment was stopped. So, in some places, where you will prefer a lower log volume, you can't do it. Or if you do it, it means you need more IPv4 addresses. Where is the balance? Up to each case. Is not the same as NAT444, because in NAT444 you need to predefine the number of ports per customer. So there is an under-utilization of IPv4 addresses, or you are exposed to calls to the helpdesk to resolve problems due to the too low number of ports. I've done some 464XLAT deplopyments, so I've "some" idea about what I'm talking about. Most of them small "pilots" (3.000 to 12.000 subscribers), right now doing one for 25.000.000 subscribers. Working without issues, just slowed down because the Covid-19 situation. I will prepare some slides about this project once allowed by my customer. El 27/8/20 9:50, "Brian Johnson" <brian.johnson@netgeek.us> escribió: Responses in-line... > On Aug 27, 2020, at 2:22 AM, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote: > > You need to understand the different way NAT64 works vs CGN (and 464XLAT uses NAT64 for the translation): The ports are allocated "on demand" in NAT64. > > While in CGN you allocate a number of ports per customer, for example, 2.000, 4.000, etc. > > If a customer is not using all the ports, they are just wasted. If a customer needs more ports, will have troubles. So this is actually necessary to lower log volume. Without that, logging would have to be per session and would require excessive storage and long-term storage. With deterministic-NAT, we can all but eliminate logging as the external IP and port block is algorithmically reversible to the internal address and vice-versa. > > This doesn't happen in NAT64. > > Let's assume and operator that can get only a /22. > > Let's make some numbers. If an average user uses 300 ports (from a public IP). When using 464XLAT, the number of users within the network, which in IPv4 is behind NAT46, does not trigger that number of ports. Anyway, let's be pessimistic and assume they are quadruple 1,200 ports. > > Approximately 80% of the traffic (2 years ago it was 75%, in many cases it is reaching 90-95%) is IPv6. After the 1,200 ports we only count 20% for IPv4, which is 240 ports. > > Broadly speaking, if we assign NAT64 1,000 IPv4 addresses (assuming the operator needs 24 public IPv4 addresses for BGP and infrastructure, I have done it with much less - because 99% of the infrastructure can be IPv6-only or use private IPv4 for management), and that we use of each IPv4 address assigned to NAT64 only 64,511 ports (65,536-1,024), even knowing that they can all be used (may be you want to allocate some static IP/ports to some customers, etc.): > > 1,000 x 64,511 / 240 = 268,795 subscribers. This is assuming all the subscribers are using all the ports, which typically is not the case. So this is the same math for NAT444. The typical regional provider would be extremely happy getting this much mileage from a /22 block. > > Now, if you have a NAT64 that tracks connections with a 5-tuple, then the number of external ports per user will be almost unlimited. So we will have to log all sessions? > > But also, this applies to the CLAT, which typically is doing (in CPEs) a stateful NAT44 (to a single private IPv4 address)+stateless NAT46. The NAT44 in iptables uses a 5-tuple for connection tracking, so the same external ports can be reused many times as the source address and destination address/port will be different. So in practical cases, the number of external ports only limits the number of parallel connections that a single host behind the NAT can have to the same destination address and port. > > > > El 27/8/20 6:55, "Brian Johnson" <brian.johnson@netgeek.us> escribió: > > Responses in-line > >> On Aug 26, 2020, at 4:07 PM, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote: >> >> Because: >> >> 1) It needs *much less* IPv4 addresses (in the NAT64) for the same number of customers. > > I cannot see how this is even possible. If I use private space internally to the CGN, then the available external space is the same and the internal customers are the same and I can do the same over sub ratio under both circumstance. Tell me how the math is different. > >> 2) It provides the customers as many ports they need (no a limited number of ports per customer). > > See response to answer 1 > >> 3) It is not blocked by PSN (don't know why because don't know how the games have problems with CGN). > > Interesting, but I’m not sure how any over-loaded NAT translation would look different from the external system. Since you cannot explain it, it’s hard to discuss it. > >> >> You could share among an *almost unlimited* number of subscribers an small IPv4 block (even just a /22). > > The math would be the same as a CGN, so I do not see how this is any less or more useful. It does, however, require CPE capability that appears lacking and NAT444 does not. > >> >> Regards, >> Jordi >> @jordipalet >> >> >> >> El 26/8/20 22:31, "Brian Johnson" <brian.johnson@netgeek.us> escribió: >> >> How does 464XLAT solve the problem if you are out of IPv4 space? >> >>> On Aug 26, 2020, at 3:23 PM, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote: >>> >>> They know we are there ... so they don't come! >>> >>> By the way I missed this in the previous email: I heard (not sure how much true on that) that they are "forced" to avoid CGN because the way games are often programmed in PSP break them. So maybe will not be enough to sort out the problem with an OS and/or PSN change, all the affected games, will need to be adjusted. >>> >>> Maybe the only way to force this is to tell our customers (many ISPs in every country) "don't buy Sony PS, they are unable to support new technologies, so you games will be blocked by Sony". Of course, unless we all decide to use 464XLAT instead of CGN ... which resolves the problem. >>> >>> A massive campaing could work ... >>> >>> >>> El 26/8/20 22:08, "NANOG en nombre de surfer" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de surfer@mauigateway.com> escribió: >>> >>> >>> >>> On 8/26/20 9:28 AM, Tony Wicks wrote: >>>> They're the worst service company I have ever had the displeasure of dealing with, the arrogance and attitude of we are big, you are small we don't care about your customers was infuriating. Never have I seen a single call related to their opposition where as PSN accounted for about 10-20% of helpdesk calls. I don't understand why its seemingly impossible for them to implement ipv6 as almost everything I have deployed with CGN is dual stack V6. >>> >>> On 8/26/20 9:30 AM, Mark Tinka wrote: >>>> We'll have to be creative with how we pressure them into getting serious >>>> about IPv6. >>> >>> >>> Do those guys attend NANOG meetings? >;-) (evil smile) >>> >>> scott >>> >>> >>> >>> ********************************************** >>> IPv4 is over >>> Are you ready for the new Internet ? >>> http://www.theipv6company.com >>> The IPv6 Company >>> >>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >>> >>> >>> >> >> >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> >> > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
I'm glad we don’t have the logging requirement in the US where I operate. Is it required in other NANOG locations? Canada? Mexico? Given that there is always the ability to assign additional port blocks as needed if a customer exceeds their allotment (requires logging but is still minimized due to the block assignment), I have had no issues as we are very conservative with the space we had. Most providers are just dealing with growth and not a full greenfield, so their existing space gets re-used in their NAT deployment and they cut more people over to it as needed. I was initially skeptical because I thought more things would break, but after some initial tweaking, monitoring and long-term grooming, the gremlins are at bay and the system runs well and without extra effort.
On Aug 27, 2020, at 3:30 AM, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote:
In many jurisdictions you need to log every connection even if all the ports belong to each customer. In others not. I've seen jurisdictions where you don't need to log anything and some others, like India, where MAP was discarded by the regulator, because MAP doesn't provide the 5-tuple log, so the deployment was stopped.
So, in some places, where you will prefer a lower log volume, you can't do it. Or if you do it, it means you need more IPv4 addresses. Where is the balance? Up to each case.
Is not the same as NAT444, because in NAT444 you need to predefine the number of ports per customer. So there is an under-utilization of IPv4 addresses, or you are exposed to calls to the helpdesk to resolve problems due to the too low number of ports.
I've done some 464XLAT deplopyments, so I've "some" idea about what I'm talking about. Most of them small "pilots" (3.000 to 12.000 subscribers), right now doing one for 25.000.000 subscribers. Working without issues, just slowed down because the Covid-19 situation. I will prepare some slides about this project once allowed by my customer.
El 27/8/20 9:50, "Brian Johnson" <brian.johnson@netgeek.us> escribió:
Responses in-line...
On Aug 27, 2020, at 2:22 AM, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote:
You need to understand the different way NAT64 works vs CGN (and 464XLAT uses NAT64 for the translation): The ports are allocated "on demand" in NAT64.
While in CGN you allocate a number of ports per customer, for example, 2.000, 4.000, etc.
If a customer is not using all the ports, they are just wasted. If a customer needs more ports, will have troubles.
So this is actually necessary to lower log volume. Without that, logging would have to be per session and would require excessive storage and long-term storage. With deterministic-NAT, we can all but eliminate logging as the external IP and port block is algorithmically reversible to the internal address and vice-versa.
This doesn't happen in NAT64.
Let's assume and operator that can get only a /22.
Let's make some numbers. If an average user uses 300 ports (from a public IP). When using 464XLAT, the number of users within the network, which in IPv4 is behind NAT46, does not trigger that number of ports. Anyway, let's be pessimistic and assume they are quadruple 1,200 ports.
Approximately 80% of the traffic (2 years ago it was 75%, in many cases it is reaching 90-95%) is IPv6. After the 1,200 ports we only count 20% for IPv4, which is 240 ports.
Broadly speaking, if we assign NAT64 1,000 IPv4 addresses (assuming the operator needs 24 public IPv4 addresses for BGP and infrastructure, I have done it with much less - because 99% of the infrastructure can be IPv6-only or use private IPv4 for management), and that we use of each IPv4 address assigned to NAT64 only 64,511 ports (65,536-1,024), even knowing that they can all be used (may be you want to allocate some static IP/ports to some customers, etc.):
1,000 x 64,511 / 240 = 268,795 subscribers. This is assuming all the subscribers are using all the ports, which typically is not the case.
So this is the same math for NAT444. The typical regional provider would be extremely happy getting this much mileage from a /22 block.
Now, if you have a NAT64 that tracks connections with a 5-tuple, then the number of external ports per user will be almost unlimited.
So we will have to log all sessions?
But also, this applies to the CLAT, which typically is doing (in CPEs) a stateful NAT44 (to a single private IPv4 address)+stateless NAT46. The NAT44 in iptables uses a 5-tuple for connection tracking, so the same external ports can be reused many times as the source address and destination address/port will be different. So in practical cases, the number of external ports only limits the number of parallel connections that a single host behind the NAT can have to the same destination address and port.
El 27/8/20 6:55, "Brian Johnson" <brian.johnson@netgeek.us> escribió:
Responses in-line
On Aug 26, 2020, at 4:07 PM, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote:
Because:
1) It needs *much less* IPv4 addresses (in the NAT64) for the same number of customers.
I cannot see how this is even possible. If I use private space internally to the CGN, then the available external space is the same and the internal customers are the same and I can do the same over sub ratio under both circumstance. Tell me how the math is different.
2) It provides the customers as many ports they need (no a limited number of ports per customer).
See response to answer 1
3) It is not blocked by PSN (don't know why because don't know how the games have problems with CGN).
Interesting, but I’m not sure how any over-loaded NAT translation would look different from the external system. Since you cannot explain it, it’s hard to discuss it.
You could share among an *almost unlimited* number of subscribers an small IPv4 block (even just a /22).
The math would be the same as a CGN, so I do not see how this is any less or more useful. It does, however, require CPE capability that appears lacking and NAT444 does not.
Regards, Jordi @jordipalet
El 26/8/20 22:31, "Brian Johnson" <brian.johnson@netgeek.us> escribió:
How does 464XLAT solve the problem if you are out of IPv4 space?
On Aug 26, 2020, at 3:23 PM, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote:
They know we are there ... so they don't come!
By the way I missed this in the previous email: I heard (not sure how much true on that) that they are "forced" to avoid CGN because the way games are often programmed in PSP break them. So maybe will not be enough to sort out the problem with an OS and/or PSN change, all the affected games, will need to be adjusted.
Maybe the only way to force this is to tell our customers (many ISPs in every country) "don't buy Sony PS, they are unable to support new technologies, so you games will be blocked by Sony". Of course, unless we all decide to use 464XLAT instead of CGN ... which resolves the problem.
A massive campaing could work ...
El 26/8/20 22:08, "NANOG en nombre de surfer" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de surfer@mauigateway.com> escribió:
On 8/26/20 9:28 AM, Tony Wicks wrote:
They're the worst service company I have ever had the displeasure of dealing with, the arrogance and attitude of we are big, you are small we don't care about your customers was infuriating. Never have I seen a single call related to their opposition where as PSN accounted for about 10-20% of helpdesk calls. I don't understand why its seemingly impossible for them to implement ipv6 as almost everything I have deployed with CGN is dual stack V6.
On 8/26/20 9:30 AM, Mark Tinka wrote:
We'll have to be creative with how we pressure them into getting serious about IPv6.
Do those guys attend NANOG meetings? >;-) (evil smile)
scott
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
On 26/Aug/20 22:23, JORDI PALET MARTINEZ via NANOG wrote:
Maybe the only way to force this is to tell our customers (many ISPs in every country) "don't buy Sony PS, they are unable to support new technologies, so you games will be blocked by Sony". Of course, unless we all decide to use 464XLAT instead of CGN ... which resolves the problem.
Somehow, I don't see this happening. Most ISP's probably know a little bit about gaming because the engineers have a console at home, or in the NOC. To get them to a level where they are actively asking customers not to buy games developed for Sony, at scale, is probably an entire project on its own that a basic ISP can't justify time for. Also, it's unlikely that end-users are going to listen to advice not to buy Sony games. All they'll hear is, "My ISP doesn't know how to fix this, so I must find another one that does". We need a better plan. As with everything in life, it probably comes down to a "Vijay Gill moving ATDN to IS-IS" type-thing, i.e., an actual person that understands what to do, cares about IPv6, and has influence within Sony. Mark.
Another approach (not likely to be any more successful than others mentioned) is to get the tech journalists to understand and write about the issues. That has the greatest chance of amplifying the message, but also given the poor quality of journalism across the board, I don't suspect it'll be easy to get a competent enough journalist to care. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mark Tinka" <mark.tinka@seacom.com> To: nanog@nanog.org Sent: Thursday, August 27, 2020 12:59:06 AM Subject: Re: Ipv6 help On 26/Aug/20 22:23, JORDI PALET MARTINEZ via NANOG wrote:
Maybe the only way to force this is to tell our customers (many ISPs in every country) "don't buy Sony PS, they are unable to support new technologies, so you games will be blocked by Sony". Of course, unless we all decide to use 464XLAT instead of CGN ... which resolves the problem.
Somehow, I don't see this happening. Most ISP's probably know a little bit about gaming because the engineers have a console at home, or in the NOC. To get them to a level where they are actively asking customers not to buy games developed for Sony, at scale, is probably an entire project on its own that a basic ISP can't justify time for. Also, it's unlikely that end-users are going to listen to advice not to buy Sony games. All they'll hear is, "My ISP doesn't know how to fix this, so I must find another one that does". We need a better plan. As with everything in life, it probably comes down to a "Vijay Gill moving ATDN to IS-IS" type-thing, i.e., an actual person that understands what to do, cares about IPv6, and has influence within Sony. Mark.
On 27/Aug/20 15:38, Mike Hammett wrote:
Another approach (not likely to be any more successful than others mentioned) is to get the tech journalists to understand and write about the issues. That has the greatest chance of amplifying the message, but also given the poor quality of journalism across the board, I don't suspect it'll be easy to get a competent enough journalist to care.
Not a bad idea, actually. I'm sure our community can learn and encourage a tech. journalist out there. Mark.
On 26/Aug/20 21:14, Brian Johnson wrote:
I can prove, as an ISP, that I am delivering the packets. Many providers will have to do this until the content moves to IPv6, so what will their excuse be? The provider has no choice when they have more customers than IPv4 address space. They will have to do something to provide access to the IPv4 Internet for these customers. If the ISP created a service that wasn’t NAT444 for gamers and charged accordingly, they would probably get drawn and quartered.
It’s a no win situation and it really is Sony that is causing this issue. PR campaigns and educating customers is probably the only way they can win this argument, when they already have the technical battle won.
In essence, yes. But most gaming customers don't have the time to decipher .pcap files proving that you delivered the traffic to Sony. And Sony are counting on this. We'll have to be creative with how we pressure them into getting serious about IPv6. Mark.
Mark: We are completely in agreement. Great dialog here.
On Aug 26, 2020, at 2:30 PM, Mark Tinka <mark.tinka@seacom.com> wrote:
On 26/Aug/20 21:14, Brian Johnson wrote:
I can prove, as an ISP, that I am delivering the packets. Many providers will have to do this until the content moves to IPv6, so what will their excuse be? The provider has no choice when they have more customers than IPv4 address space. They will have to do something to provide access to the IPv4 Internet for these customers. If the ISP created a service that wasn’t NAT444 for gamers and charged accordingly, they would probably get drawn and quartered.
It’s a no win situation and it really is Sony that is causing this issue. PR campaigns and educating customers is probably the only way they can win this argument, when they already have the technical battle won.
In essence, yes.
But most gaming customers don't have the time to decipher .pcap files proving that you delivered the traffic to Sony.
And Sony are counting on this.
We'll have to be creative with how we pressure them into getting serious about IPv6.
Mark.
And in the end it will come down to a clueful customer taking Sony to task. with the backing of a government for selling a product which is not fit for purpose. They have paid to play games and if Sony is blocking them because they happen to be on a CGN, which they have no control over, then Sony is in breach of lots of consumer laws around the planet. No EULA trumps the law. Here is Australia it would be the ACCC that would take them to task. -- Mark Andrews
On 27 Aug 2020, at 04:38, Brian Johnson <brian.johnson@netgeek.us> wrote:
I‘m going further... They shouldn’t have to care. Sony should understand what they are delivering and the circumstance of that. That they refuse to serve some customers due to the technology they use is either a business decision or a faulty design. The end-customer (gamer) doesn’t care. They just want to play.
On Aug 26, 2020, at 1:31 PM, Mark Tinka <mark.tinka@seacom.com> wrote:
On 26/Aug/20 20:20, Brian Johnson wrote:
Either way. Nothing you can do in the network will help Sony enable IPv6 capability, Or to serve their users even if using a technology that they do not like.
Agreed.
The problem is gaming customers that neither care for nor know about how NAT444 and/or IPv6 play (no pun intended) here.
Mark.
I believe Sony missed: 1) Telling the developers to make sure that they program with IPv6 in mind (MS/XBOX did for years). 2) Fully supporting IPv6 in the PSN and the PlayStation OS (MS/XBOS did). 3) Setting a deadline for developers to start using it (MS/XBOX did, Apple - different business I know - did for IPv6-only in iOS) And the PS developers missed by themselves all about IPv6. Furthermore, I still see some game makers *encouraging customers* to disable IPv6. I call this a *criminal action*. Sony has IPv6 in other products, but of course, it is a big company, many times it happens they are "disconnected" folks there. El 26/8/20 20:16, "NANOG en nombre de Brian Johnson" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de brian.johnson@netgeek.us> escribió: This sounds like a Sony problem more than a network problem. They need to get on the IPv6 train and play nice with the Internet. X-BOX has had IPv6 support since X-BOX One. > On Aug 26, 2020, at 1:09 PM, Mark Tinka <mark.tinka@seacom.com> wrote: > > > > On 26/Aug/20 18:42, JORDI PALET MARTINEZ via NANOG wrote: > >> The crazy thing is that PSN doesn't (up to my knowledge) yet work with IPv6 ... > > To this day, my PS4, running Sony's latest code, does not support IPv6. > > That might be a good place to start, for them. > > At the rate they are doing, the PS5 might ship with RIPv2. > > 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 26/Aug/20 22:12, JORDI PALET MARTINEZ wrote:
And the PS developers missed by themselves all about IPv6. Furthermore, I still see some game makers *encouraging customers* to disable IPv6. I call this a *criminal action*.
Most developers do not understand the constraints the industry is facing re: IPv4, or know that there are constraints but figure, "Ah, those network engineers will make a plan, don't worry about it, and don't care about IPv6". Mark.
On Wed, 26 Aug 2020 18:42:14 +0200, JORDI PALET MARTINEZ via NANOG said:
The crazy thing is that PSN doesn't (up to my knowledge) yet work with IPv6 .
Has anybody heard if they plan to fix that with the imminent Playstation 5? The PS4 OS will actually talk IPV6 far enough to DHCPv6 and answer pings from both on and off subnet, but none of the userspace does it because that API wasn't in the developer's kits at launch.
On 25/Aug/20 22:15, Brandon Martin wrote:
I really, really hate to force users to use my network edge router (I provide the ONT, though, and I provide an edge router that works and most users do take it), but it can be tough to ensure users have something that supports all the right modern features and can be configured via standard means.
It would be nice if the consumer router industry could get its collective act together and at least come up with some easy-ish to understand feature support table that customers can match up with their service provider's list of needs. The status quo of a list of devices that work right (which is of course often staggeringly short if you're doing any of these modern transition mechanisms) that needs constant updating and may not be easily available is not ideal.
Heck just having a real, complete list of supported features on the model support page on their website would be an improvement...
My experience is that the room of folk that prefer to run their own CPE is far less full than the ones who don't. So outside of some power users (who probably run a network of some kind), this isn't going to be a huge problem. Mark.
This is why we wrote RFC8585, so users can freely buy their own router ... The ISP can also list some of the compatible models in case they are using "additional" features. El 25/8/20 22:16, "NANOG en nombre de Brandon Martin" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de lists.nanog@monmotha.net> escribió: On 8/25/20 3:38 PM, JORDI PALET MARTINEZ via NANOG wrote: > This is very common in many countries and not related to IPv6, but > because many operators have special configs or features in the CPEs they > provide. I really, really hate to force users to use my network edge router (I provide the ONT, though, and I provide an edge router that works and most users do take it), but it can be tough to ensure users have something that supports all the right modern features and can be configured via standard means. It would be nice if the consumer router industry could get its collective act together and at least come up with some easy-ish to understand feature support table that customers can match up with their service provider's list of needs. The status quo of a list of devices that work right (which is of course often staggeringly short if you're doing any of these modern transition mechanisms) that needs constant updating and may not be easily available is not ideal. Heck just having a real, complete list of supported features on the model support page on their website would be an improvement... -- Brandon Martin ********************************************** 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 8/26/20 2:48 AM, JORDI PALET MARTINEZ via NANOG wrote:
This is why we wrote RFC8585, so users can freely buy their own router ...
It's a great RFC. Hopefully it continues to gain traction. Do you know of a single router available in the US (or even broader North American) retail market that has "RFC8585" printed anywhere on the outside of the box or even in the documentation one might actually consult pre-purchase? I would love to evaluate it (or, even better, a few of them) to ensure I'm compatible on the provider side with how the equipment makers have interpreted the RFC! Then I can also have some specific models to direct people toward along with "Or just look for 'RFC8585' on the box". But, right now, I am aware of none. -- Brandon Martin
I work and I'm in touch with many CPE vendors since long time ago ... many are on the way (I can remember about 12 on top of my head right now, but because contracts, can't name them). It takes time. However, in many cases, they just do for specific customers or specific models. I know other people that contacted the same vendors and they told them "we could do it for the model you use as well". In some cases, they require a minimum volume per year (less than what you could expect. I've seen cases that start with just 500 units per month). But this only works if you contact them. The CPE vendors business model seems to be very "ISP" direct. I think the retail marked models, unfortunately, will take a bit more time. A hint about some vendors: You may take a look at the co-authors in the RFC. El 26/8/20 18:30, "NANOG en nombre de Brandon Martin" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de lists.nanog@monmotha.net> escribió: On 8/26/20 2:48 AM, JORDI PALET MARTINEZ via NANOG wrote: > This is why we wrote RFC8585, so users can freely buy their own router ... It's a great RFC. Hopefully it continues to gain traction. Do you know of a single router available in the US (or even broader North American) retail market that has "RFC8585" printed anywhere on the outside of the box or even in the documentation one might actually consult pre-purchase? I would love to evaluate it (or, even better, a few of them) to ensure I'm compatible on the provider side with how the equipment makers have interpreted the RFC! Then I can also have some specific models to direct people toward along with "Or just look for 'RFC8585' on the box". But, right now, I am aware of none. -- Brandon Martin ********************************************** 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 26/Aug/20 18:48, JORDI PALET MARTINEZ via NANOG wrote:
I work and I'm in touch with many CPE vendors since long time ago ... many are on the way (I can remember about 12 on top of my head right now, but because contracts, can't name them). It takes time. However, in many cases, they just do for specific customers or specific models. I know other people that contacted the same vendors and they told them "we could do it for the model you use as well". In some cases, they require a minimum volume per year (less than what you could expect. I've seen cases that start with just 500 units per month).
But this only works if you contact them. The CPE vendors business model seems to be very "ISP" direct. I think the retail marked models, unfortunately, will take a bit more time.
A hint about some vendors: You may take a look at the co-authors in the RFC.
This is the bit I was referring to when I meant, "It shouldn't be this hard". It's one thing for big San Jose vendors to build boxes for specific customers based on volume or deal potential. It's another when consumer CPE's do not get critical love like CLAT until some large provider with millions of customers that is half-interested in spending some energy on this walks up dangling a potential cheque in front of them. If these CPE vendors are here, lurking, don't waste your time developing WMM for your wireless routers. Divert those resources to implementing CLAT rather. Customers are more likely to buy CPE if they perform the most basic functions well. Heck, half the work has already been done in OpenWRT... Mark.
On 8/26/20 12:48 PM, JORDI PALET MARTINEZ via NANOG wrote:
I work and I'm in touch with many CPE vendors since long time ago ... many are on the way (I can remember about 12 on top of my head right now, but because contracts, can't name them). It takes time. However, in many cases, they just do for specific customers or specific models. I know other people that contacted the same vendors and they told them "we could do it for the model you use as well". In some cases, they require a minimum volume per year (less than what you could expect. I've seen cases that start with just 500 units per month).
But this only works if you contact them. The CPE vendors business model seems to be very "ISP" direct. I think the retail marked models, unfortunately, will take a bit more time.
A hint about some vendors: You may take a look at the co-authors in the RFC.
The whole point here is not that some vendors can support these features in a semi-custom firmware image that's specific to a particular ISP deployment - I know that's a possibility and have vendors willing to work with me on a much smaller volume than even what you've indicated - but rather what about customers who want to "upgrade" their router or, for whatever reason (and there are some very valid ones) want to provide their own. Right now, it's essentially impossible for them to walk into a local retailer and walk out with a model that they know for sure will work with my network if I'm requiring e.g. 464XLAT for basic functionality. Even if they buy online and dive fairly deep into model documentation, it is still hard to come up with a model that they know will work, and the lack of documentation will limit their choice of models unnecessarily (i.e. there are probably some options that support the necessary functionality but don't advertise it in the slightest). If someone wants me to provide them with a router, then of course I'll hand them one that I know works on my network. That's easy since I have control over the selection of it (and have presumably done some testing) even if I don't have my own provider-customized firmware. I'll point out that 500 new services (taking a new router) per month is not a particularly small provider. It's not large, no, but it's also a lot bigger than many deployments are at least when they're new, and these are questions you have to essentially answer "up front" in many cases. -- Brandon Martin
In many situations it will make sense to keep the CPE provided by the ISP in a configuration equivalent to a "bridge" (I know is not a bridge, I'm trying to use a single word to describe it), so it runs things like the NAT for IPv4 and the CLAT for IPv6, even DHCP, or RA, etc. It all depends on what you have behind. Many customers will just have one or two routers acting just as APs in a single bridged domain, others may have different subnets, etc. This keeps the customer happy if they need to have a better WiFi, or whatever. If you have just a dozen of deployments per month, I think the choice to buy a good Chinese hardware that already comes with OpenWRT, or your preferred retail CPE that allows to be reflashed with OpenWRT, is handy. That system will work for most of the customers, and if some customer want a "bigger" system, just provide the low cost CPE as a "bridge" to its real network. El 30/8/20 3:05, "NANOG en nombre de Brandon Martin" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de lists.nanog@monmotha.net> escribió: On 8/26/20 12:48 PM, JORDI PALET MARTINEZ via NANOG wrote: > I work and I'm in touch with many CPE vendors since long time ago ... many are on the way (I can remember about 12 on top of my head right now, but because contracts, can't name them). It takes time. However, in many cases, they just do for specific customers or specific models. I know other people that contacted the same vendors and they told them "we could do it for the model you use as well". In some cases, they require a minimum volume per year (less than what you could expect. I've seen cases that start with just 500 units per month). > > But this only works if you contact them. The CPE vendors business model seems to be very "ISP" direct. I think the retail marked models, unfortunately, will take a bit more time. > > A hint about some vendors: You may take a look at the co-authors in the RFC. The whole point here is not that some vendors can support these features in a semi-custom firmware image that's specific to a particular ISP deployment - I know that's a possibility and have vendors willing to work with me on a much smaller volume than even what you've indicated - but rather what about customers who want to "upgrade" their router or, for whatever reason (and there are some very valid ones) want to provide their own. Right now, it's essentially impossible for them to walk into a local retailer and walk out with a model that they know for sure will work with my network if I'm requiring e.g. 464XLAT for basic functionality. Even if they buy online and dive fairly deep into model documentation, it is still hard to come up with a model that they know will work, and the lack of documentation will limit their choice of models unnecessarily (i.e. there are probably some options that support the necessary functionality but don't advertise it in the slightest). If someone wants me to provide them with a router, then of course I'll hand them one that I know works on my network. That's easy since I have control over the selection of it (and have presumably done some testing) even if I don't have my own provider-customized firmware. I'll point out that 500 new services (taking a new router) per month is not a particularly small provider. It's not large, no, but it's also a lot bigger than many deployments are at least when they're new, and these are questions you have to essentially answer "up front" in many cases. -- Brandon Martin ********************************************** 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.
Brandon Martin <lists.nanog@monmotha.net> writes:
On 8/25/20 3:38 PM, JORDI PALET MARTINEZ via NANOG wrote:
This is very common in many countries and not related to IPv6, but because many operators have special configs or features in the CPEs they provide.
I really, really hate to force users to use my network edge router (I provide the ONT, though, and I provide an edge router that works and most users do take it), but it can be tough to ensure users have something that supports all the right modern features and can be configured via standard means.
You aren't forcing anything if you allow the users to use any CPE and document the features it must/should have. You want IPv4 access without DNS? Then you need CLAT You don't know what CLAT is? Call your CPE vendor for support You don't care what CLAT is? Use our CPE You want to call us for support? Use our CPE There is no force here. It all is pretty similar to You want to connect the CPE to our ONT? Then you need Ethernet etc. excluding all those TokenRing routers.
It would be nice if the consumer router industry could get its collective act together and at least come up with some easy-ish to understand feature support table that customers can match up with their service provider's list of needs.
If you create such a feature table as the service provider, and the customer is unable to match it against their CPE documentation, then that's a problem between the CPE vendor and the customer. I can't understand why you want to make it your problem, as long as you offer a CPE that just works. Bjørn
On 26/Aug/20 10:49, Bjørn Mork wrote:
You aren't forcing anything if you allow the users to use any CPE and document the features it must/should have.
You want IPv4 access without DNS? Then you need CLAT You don't know what CLAT is? Call your CPE vendor for support You don't care what CLAT is? Use our CPE You want to call us for support? Use our CPE
There is no force here. It all is pretty similar to
You want to connect the CPE to our ONT? Then you need Ethernet etc.
excluding all those TokenRing routers.
To be fair, most customers don't care about features. A customer will buy an 802.11ax wi-fi router, completely forgetting that their demarc. CPE is ADSL or only good for 25Mbps FTTH. A customer will want to stream at 4K from their in-home DLNA server, connected to a wi-fi adapter, and totally forget that that wi-fi adapter only talks 802.11b. Or better, they'll have an 802.11ac wi-fi adapter in their DLNA server, but forget that the AP it's talking to is only connected at 10Mbps to the LAN. This stuff was easier when customers had dial-up or ADSL. It's going to get a lot more complicated to fully appreciate with FTTH, because most customers don't understand that the performance of any link is limited by the weakest one all the way from the user device, into their (W)LAN, and up to the package they bought from their ISP. So publishing features for a CPE for customers to buy won't work for the majority of folk. All they'll look at is, "Does it say Wi-Fi Router", has the Wi-Fi logo, pay, and leave. And the attendants in the shop are neither the wiser nor have the patience to clue Jane or Joe on proper home network design.
If you create such a feature table as the service provider, and the customer is unable to match it against their CPE documentation, then that's a problem between the CPE vendor and the customer.
I can't understand why you want to make it your problem, as long as you offer a CPE that just works.
I don't want a customer calling me anymore than the next ISP does. But, when a customer has a problem, they won't pick up the phone and call D-Link, TP-Link or Linksys. They'll call me, their provider. And this is true whether they got the CPE from me or by themselves from a store. We need to think outside of this NANOG group of nerds... Mark.
On 8/26/20 4:49 AM, Bjørn Mork wrote:
You aren't forcing anything if you allow the users to use any CPE and document the features it must/should have.
You want IPv4 access without DNS? Then you need CLAT You don't know what CLAT is? Call your CPE vendor for support You don't care what CLAT is? Use our CPE You want to call us for support? Use our CPE
There is no force here. It all is pretty similar to
You want to connect the CPE to our ONT? Then you need Ethernet etc.
excluding all those TokenRing routers.
I don't force them to. I was countering the other arguments up-thread from folks who do so, and I understand why they do. I'd say easily 90% of my customers take my offered RG-CPE without any questions whatsoever - they in fact have come to expect that I provide one. Of the remaining 10%, easily half or more of them are satisfied with the RG-CPE I provide after I explain a few things about it (and I have a cut-sheet for the support folks to do so where applicable). They mostly want to know that it's not a braindead piece of crap presumably because they've had bad experiences in the past with SP-provided RG-CPEs (e.g. AT&T U-Verse). It's the remainder I'm talking about. It's almost all "power users". but even where they do have a fairly firm grasp of basic and even moderately advanced home/SMB networking, they're often unfamiliar with SP-side features that have cropped up and start to burden the routers such as IPv6-IPv4 transition features. This is what I'd like to address in a more streamlined manner. To wit:
It would be nice if the consumer router industry could get its collective act together and at least come up with some easy-ish to understand feature support table that customers can match up with their service provider's list of needs.
If you create such a feature table as the service provider, and the customer is unable to match it against their CPE documentation, then that's a problem between the CPE vendor and the customer.
I can't understand why you want to make it your problem, as long as you offer a CPE that just works.
I would LOVE to be able to just create such a required features table. The issue is that there are virtually no retail (even niche online channels) CPE devices that clearly document their capabilities to match up with my feature table. That's what I'm whinging about that the retail RG-CPE industry really should address, IMO. I can adopt best practices to make sure I provide configuration info via the proper DHCP(v6) options, attempt to delay making such features mandatory by providing e.g. NAT444 fallback, etc. as long as possible, etc., but eventually, people are going to have to migrate to equipment that supports these more modern features or be left behind, and, right now, it's very tough to even identify whether a device you're looking at in Best Buy or WalMart supports them or not (leaving aside the fact, for now, that the answer is often "it doesn't"). So, I'm left with the "do what works" option of attempting to enumerate models known to work. Nobody likes this. Customers feel like they're unnecessarily constrained, and service providers have to maintain that list and deal with questions about it for something that should be 100% a customer decision. Or, I can just say "You have to use our RG-CPE otherwise you're on your own and I can't guarantee anything useful will even work.", and that's not a good way to sell service to the handful of generally outspoken customers who do want to do things their own way. -- Brandon Martin
Simplest solution that comes to mind is run a GRE/IPv6 tunnel from one end to the other with IPv4 addresses on the tunnel endpoints only. Owen
On Aug 22, 2020, at 6:47 AM, Brian <brian.bsi@gmail.com> wrote:
Is there anyway to deploy ipv6 and push ipv4 traffic end to end across the ipv6 network. With out having an ipv4 address for everything that is ipv6? If someone could reach out off list if there is a real solution to deploy ipv6 as almost middleware.
participants (15)
-
Bjørn Mork -
Brandon Martin -
Brian -
Brian Johnson -
Ca By -
JORDI PALET MARTINEZ -
Mark Andrews -
Mark Tinka -
Mike Hammett -
Owen DeLong -
Roman Tatarnikov -
surfer -
Tom Hill -
Tony Wicks -
Valdis Klētnieks