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.john...@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.john...@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.john...@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...@nanog.org en nombre de >>>> sur...@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. > > >
