Not Making Use of 240/4 NetBlock

Tue Mar 15 15:54:23 UTC 2022

Having spent nearly 15 years on the ARIN Advisory Council, I think I’m able
to claim some detailed knowledge on the subject.

In general, the RIRs themselves maintain neutrality about such things, looking to their
respective communities for input on what to do. However, so long as the IETF and
has not designated the space Unicast Address Space to be delegated to the
RIRs for allocation/assignment, IANA will not delegate it to the RIRs and the RIRs
won’t, therefore, delegate it to users.

If you really want to see this happen (and I still argue that the amount of effort already wasted
discussing this idea vastly exceeds what would be needed towards IPv6 to get beyond
caring about it), then the first step must be to convince the IETF to designate the
space IPv4 Unicast and instruct the IANA to begin issuing those /8s to the RIRs.

Once that happens, the rest of the allocation process is basically automatic. From a policy
perspective at the RIR level, it will be no different than say 4/8 or 1/8.

Now, convincing vendors to update their firmware, software, etc. is another matter
and entirely outside of the control of the RIRs. Merchant compliance with IETF standards
is generally considered useful, but it is entirely voluntary and even in the best of
circumstances doesn’t every happen instantaneously and almost always involves
some stumbles along the way.

Owen

> On Mar 15, 2022, at 02:54 , Sylvain Baya <abscoco at gmail.com> wrote:
> 
> Dear NANOG-ers,
> Hope this email finds you in good health!
> Please see my comments below, inline...
> 
> Le mardi 15 mars 2022, <bzs at theworld.com <mailto:bzs at theworld.com>> a écrit :
> 
> 
> Hi Barry,
> Thanks for your email, brother!
> 
>  
> But the RIRs are the ones fielding requests for IPv4 space, and have
> some notion of how policy implementation might work in practice, so
> should have a lot of useful input.
> 
> 
> ...of course, it appears that RIRs have the opportunity
>  to add their useful inputs, as Impact Analysis Report
>  (IAR); during the Policy Development Process (PDP)
>  initiated by the *appropriate* [1] Internet community.
> They explain it themselves here [2].
> __
> [1]: <https://tools.ietf.org/html/rfc7020 <https://tools.ietf.org/html/rfc7020>>
> [2]: <https://www.nro.net/accountability/rir-accountability/q-and-a/ <https://www.nro.net/accountability/rir-accountability/q-and-a/>>
> 
> Shalom,
> --sb.
> 
>  
> On March 14, 2022 at 00:45 niels=nanog at bakker.net <mailto:nanog at bakker.net> (Niels Bakker) wrote:
>  > * bzs at theworld.com <mailto:bzs at theworld.com> (bzs at theworld.com <mailto:bzs at theworld.com>) [Mon 14 Mar 2022, 00:31 CET]:
>  > >Personally I'd rather hear from the RIRs regarding the value or not 
>  > >of making more IPv4 space such as 240/4 available. They're on the 
>  > >front lines of this.
>  > 
>  > You've got your policy development process diagram upside down. The 
>  > community decides what the RIRs implement. They're not in touch with 
>  > merchant silicon manufacturers.
>  > 
>  > 
>  >      -- Niels.
> 
> -- 
>         -Barry Shein
> 
> Software Tool & Die    | bzs at TheWorld.com             | http://www.TheWorld.com <http://www.theworld.com/>
> Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*
> 
> 
> -- 
> Best Regards !
> __
> baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure <https://cmnog.cm/dokuwiki/Structure>>
> Subscribe to Mailing List: <https://lists.cmnog.cm/mailman/listinfo/cmnog/ <https://lists.cmnog.cm/mailman/listinfo/cmnog/>>
> __
> #‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous tous! ‪#‎Amen‬!»
> ‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬
> «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après TOI, ô DIEU!»(#Psaumes42:2)
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220315/a0383e5c/attachment.html>