Let's Focus on Moving Forward Re: V6 still not supported Re: 20220326125.AYC

Owen DeLong owen at delong.com
Tue Mar 29 19:29:51 UTC 2022


Just because there is a small code snippet you found that prevents casting 240/4 as unicast on an interface doesn’t mean that removing that code will magically make 240/4 usable in the entire stack.

It’s also important to note that there are at least a dozen IPv4 stacks in common use with differing code implementations and underlying assumptions baked into the code in various places. Your Q.E.D. is, in fact, a demonstration of the fact that you are still lack some background and experience in networking software.

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 at 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 at avinta.com> <mailto:aychen at 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
> 
> 
>  <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon>	Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link> <x-msg://41/#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220329/93ae29e1/attachment.html>


More information about the NANOG mailing list