Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block

Fri Jan 12 19:55:10 UTC 2024

Hi, Tony:

0)    As the saying goes, there is more than one way to skin a cat. We 
do not need to address a request by literally following the thought 
trend. In troubleshooting, engineers are taught to look for the 
Root-Cause which more than often turns out to be something else 
originally thought. In this case, the "Any idea" hints that requester is 
open-minded for possible alternatives other than stated on the surface.

1)    When reviewing a problem, we need to go one or more steps toward 
the source or the origin to look for the solution. Since the predominant 
operation model is CDN supported by CG-NAT, the primary reason to look 
for a publicly routable IPv4 address is to create another CG-NAT 
cluster. On the other hand, if there is a way to expand the capacity of 
the existing CG-NAT cluster, the need for additional publicly routable 
IPv4 address is reduced.

Regards,

Abe (2024-01-12 14:54)

On 2024-01-10 23:26, Tony Wicks wrote:
>
> 2)    "... an operator clearly looking to acquire *publicly routable* 
> space without being clear that this suggestion wouldn't meet their 
> needs.  ":
>
>     Since 240/4 has 256M addresses while 100.64/10 has only 4M, a 
> current CG-NAT cluster can be expanded 64 fold once the 240/4 is used. 
> Looking from another angle, an IAP will then be able to expand the 
> subscriber set 64 fold with still the original one publicly routable 
> IPv4 address.
>
> The OP asked for “Any idea please on the best way to buy IPv4 blocs 
> and what is the price”. I would expect they want actual public IPv4 
> address blocks and not internal CGNAT space. While the idea of using 
> 240/4 instead of 100.64/10 would certainly have some merit I don’t 
> believe its in any way related to what this OP asked for.
>
> regards
>

-- 
This email has been checked for viruses by Avast antivirus software.
www.avast.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20240112/239e6089/attachment.html>