The code you found may just be a safety valve to prevent the user from doing something stupid that will have undefined consequences down the line if executed. What you appear to have found is, quite likely, the equivalent of a buffer bounds check on input. Removing the check doesn’t inherently make the buffer infinite.
Owen
On Mar 26, 2022, at 09:38 , 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 universalHave 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
