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.
