It was quite frustrating since we did not have the background in networking software

You clearly still do not, if you sincerely believe that commenting out a single function in every vendor software implementation is all that it would take. 

No need to respond ; I will be filtering all future messages from you to /dev/null . Good luck with your efforts.

On Sat, Mar 26, 2022 at 12:42 PM Abraham Y. Chen <aychen@avinta.com> wrote:
Hi, Paul:

1)    " ...  may be in fact: /writing/* and */deploying/* the code  ... ":    Having no idea why and how the 240/4 netblock became so mysteriously kept away from being used while the IPv4 was officially already on its way to "Sun Set", we started the conventional approach as you stated. It was quite frustrating since we did not have the background in networking software. One day, we came across a short program code fragment that did the function of disabling 240/4 addressed IP packets. It is the "there exists an example" moment for us, like proofing a mathematics theorem. After all, there was no magic separating 240/4 from the rest of the IPv4 address pool to start with. It cleared our mind about this particular task. Now, we only cite this reference to challenge those software engineers who may state that using the 240/4 in their code is a lot more involved.   .... Q.E.D.  😉

Regards,


Abe (2022-03-26 12:37 EDT)




On 2022-03-26 09:52, Paul Rolland wrote:
Hello,

On Sat, 26 Mar 2022 09:35:30 -0400
"Abraham Y. Chen" <aychen@avinta.com> wrote:

touching the hardware, by implementing the EzIP technique (*/disabling/* 
the program code that has been */disabling/* the use of the 240/4 
netblock), an existing CG-NAT module becomes a RAN! As to universal 
Have you ever considered that this may be in fact:

*/writing/* and */deploying/* the code that will allow the use of 240/4 the
way you expect 


Paul



Virus-free. www.avast.com