Re: Ipv6 help
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 wrote: > > > On Aug 26, 2020, at 4:22 PM, surfer 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 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 >
Re: Ipv6 help
On Aug 26, 2020, at 4:22 PM, surfer 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 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
Re: BGP route hijack by AS10990
On Mon, Aug 03, 2020 at 08:57:53AM -0400, Tom Beecher wrote: > Telia made a mistake. They owned it and will endeavor to do better. What > more can be asked? Figure out how that mistake happened -- what factors led to it? Then make changes so that it can't happen again, at least not in that particular way. (And if those changes are applicable to more than this isolated case: excellent. In that case, share them with all of us so that maybe they'll keep us from repeating the error.) "Stopping myself from making the same mistake twice" has probably been the most effective thing I've ever done. ---rsk
Re: Ipv6 help
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.
Re: Ipv6 help
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" 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.
Re: Ipv6 help
On Thu, Aug 27, 2020 at 1:00 AM Brian Johnson 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 wrote: > > > > > > > > > > > >> On 27 Aug 2020, at 17: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? > > > > > > 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 wrote: > > >>> > > >>> > > >>> > > On 27 Aug 2020, at 15:58, Bjørn Mork wrote: > > > > Brian Johnson 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: ma...@isc.org > > >>> > > >> > > > > > > -- > > > Mark Andrews, ISC > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > > > > > >
Re: Ipv6 help
> 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.
Re: Ipv6 help
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 NAT to NAT4, 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.
Re: Ipv6 help
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 > 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" escribió: > >Responses in-line... > >> On Aug 27, 2020, at 2:22 AM, JORDI PALET MARTINEZ via NANOG >> 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
Re: Ipv6 help
Great Write-up Mark. I have some points in-line... > On Aug 27, 2020, at 3:12 AM, Mark Tinka 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. >
Re: Ipv6 help
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" escribió: Responses in-line... > On Aug 27, 2020, at 2:22 AM, JORDI PALET MARTINEZ via NANOG 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" escribió: > >Responses in-line > >> On Aug 26, 2020, at 4:07 PM, JORDI PALET MARTINEZ via NANOG 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
Re: Ipv6 help
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.
Re: Ipv6 help
On 27/Aug/20 08:57, JORDI PALET MARTINEZ via NANOG wrote: > This one is the published version: > > https://datatracker.ietf.org/doc/rfc8683/ 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.
Re: Ipv6 help
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 wrote: > > > >> On 27 Aug 2020, at 17: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? > > 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 wrote: >>> >>> >>> On 27 Aug 2020, at 15:58, Bjørn Mork wrote: Brian Johnson 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: ma...@isc.org >>> >> > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >
Re: Ipv6 help
> On 27 Aug 2020, at 17: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? 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 wrote: >> >> >> >>> On 27 Aug 2020, at 15:58, Bjørn Mork wrote: >>> >>> Brian Johnson 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: ma...@isc.org >> > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Ipv6 help
Responses in-line... > On Aug 27, 2020, at 2:22 AM, JORDI PALET MARTINEZ via NANOG > 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" escribió: > >Responses in-line > >> On Aug 26, 2020, at 4:07 PM, JORDI PALET MARTINEZ via NANOG >> 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" 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 >>> 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 >>>
Re: Ipv6 help
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 wrote: > > > >> On 27 Aug 2020, at 15:58, Bjørn Mork wrote: >> >> Brian Johnson 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: ma...@isc.org >
Re: Ipv6 help
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" escribió: Responses in-line > On Aug 26, 2020, at 4:07 PM, JORDI PALET MARTINEZ via NANOG 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" 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 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" 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
Re: Ipv6 help
This one is the published version: https://datatracker.ietf.org/doc/rfc8683/ El 27/8/20 8:10, "NANOG en nombre de Mark Tinka" 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.
Re: Ipv6 help
> On 27 Aug 2020, at 15:58, Bjørn Mork wrote: > > Brian Johnson 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: ma...@isc.org
Re: Ipv6 help
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.
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.
