Not Making Use of 240/4 NetBlock Re: 202203171125.AYC

Thu Mar 17 15:32:57 UTC 2022

Hi, Mark:

1)    " ... known defective products ...   ": Could you please define 
what do you mean? And, what "products" do you have in mind? Otherwise, 
this sounds like a scare tactic without a foundation.

Regards,

Abe (2022-03-17 11:32)

------------------------------

NANOG Digest, Vol 170, Issue 19

Message: 35
Date: Thu, 17 Mar 2022 09:48:04 +1100
From: Mark Andrews<marka at isc.org>
To: Owen DeLong<owen at delong.com>
Cc: Sylvain Baya<abscoco at gmail.com>,bzs at theworld.com, Niels Bakker
	<niels=nanog at bakker.net>,nanog at nanog.org
Subject: Re: Not Making Use of 240/4 NetBlock
Message-ID:<1C6B1AD8-399E-4B3C-B3AD-A5C846F62925 at isc.org>
Content-Type: text/plain; charset=utf-8

It?s a business problem for the RIR?s. Selling / leasing known defective products is against lots of consumer law.
-- Mark Andrews

> On 17 Mar 2022, at 03:43, Owen DeLong<owen at delong.com>  wrote:
>
> ?
>
>>> On Mar 15, 2022, at 19:23 , Mark Andrews<marka at isc.org>  wrote:
>>>
>>>
>>>
>>>> On 16 Mar 2022, at 02:54, Owen DeLong via NANOG<nanog at nanog.org>  wrote:
>>> 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.
>> Actually it would be fundamentally different to 4/8 or 1/8.  You are looking at firmware upgrades
>> rather than dealing with squatters and out-of-date ACLs both of which are self-inflicted by one
>> of the parties.  Routers and end devices that don?t know how to hand 240/4 are no self inflicted
>> injuries.  Issuing 4/8 or 1/8 worked for parties that had been following the rules.  With 240/4
>> there where no rules to follow which results in RIR?s leasing known defective addresses.
> I was speaking from an RIR allocation perspective, NOT talking about the technological hurdles
> to implementation.
>
> I was specifically responding to someone?s question about how the RIRs would be impacted by
> this if it were to come to pass.
>
> I addressed your concern in the following paragraph as an aside, however.
>
>>> 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>  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>
>>>> [2]:<https://www.nro.net/accountability/rir-accountability/q-and-a/>
>>>>
>>>> Shalom,
>>>> --sb.
>>>>
>>>>
>>>> On March 14, 2022 at 00:45niels=nanog at bakker.net  (Niels Bakker) wrote:
>>>>> *bzs at theworld.com  (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
>>>> 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>
>>>> Subscribe to Mailing List:<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)
>>>>
>>>>
>> -- 
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742              INTERNET:marka at isc.org
>>
------------------------------

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